41CL and available flash pages

[grsbanks]

When updating the module library on my 41CL, I tend to save the state of the calculator in a high address flash page somewhere between 0x3f0 and 0x3ff. This is all well and good until something within the library starts using this area.

OK, we're a way off that happening as of today. I see that the last occupied page in the 02/05 update is 0x2cc so there should still be around 300 pages available to use for this on a v5 board, but I was wondering if there are any plans to set aside a range, i.e. commit to not adding modules to that range so that individual users can use that part of flash as they see fit?

[Monte Dalrymple]

(05-10-2020 10:09 AM)grsbanks Wrote:  When updating the module library on my 41CL, I tend to save the state of the calculator in a high address flash page somewhere between 0x3f0 and 0x3ff. This is all well and good until something within the library starts using this area.

OK, we're a way off that happening as of today. I see that the last occupied page in the 02/05 update is 0x2cc so there should still be around 300 pages available to use for this on a v5 board, but I was wondering if there are any plans to set aside a range, i.e. commit to not adding modules to that range so that individual users can use that part of flash as they see fit?

0x1F8-0x1FF will remain uncommitted, as will 0x3F8-0x3FF (if I have anything to say about it.) Is that enough space, or should I reserve more?

[grsbanks]

(05-10-2020 03:34 PM)Monte Dalrymple Wrote:  0x1F8-0x1FF will remain uncommitted, as will 0x3F8-0x3FF (if I have anything to say about it.) Is that enough space, or should I reserve more?

That leaves at least 8 pages available, 16 on a V5 board. With the machine backup just taking one page, you can go 8 months without having to erase a sector and start over. So, for this particular application, it's perfectly adequate IMO.

Would it be an idea to block out more pages on the V5 board with its higher capacity for future applications? Say, 32 contiguous pages from 0x3e0 to 0x3ff? OK, I'm not aware of any applications that would use them right now, but maybe that's because there has been no promise that the pages would always be available, so nobody wanted to use them.

[David Hayden]

Somewhat related, I had an unfortunate occurence several months ago when I updated the flash pages in my 41CL. I had a backup in one of the pages and I believe that the update process checked the CRC of my backup page, realized that it was different from the CRC in the database (all F's) and dutifully updated it with a blank page. Ouch.

So, while reserved pages are definitely great, I think it would also be wonderful if the update process didn't touch pages that are empty in the official ROMs, but actually contain something.

Dave

[grsbanks]

If ranges of pages were to be "officially" blocked out for end-user applications, how hard would it be to have commands such as FLUPD at the very least, but perhaps also FLCHK? and FDBCHK?, "know" about those reserved ranges and just ignore any discrepancies with the module database?

[rprosperi]

You can just exclude those pages when you do the scans for changes, and then you can still use the ALL when you do the actual updates.

[grsbanks]

(05-10-2020 10:28 PM)rprosperi Wrote:  You can just exclude those pages when you do the scans for changes, and then you can still use the ALL when you do the actual updates.

That's a very good point that I had overlooked. It would just make things that little bit easier if the scan automatically excluded the "reserved" ranges so you can scan '*' in CPONLY mode.

[Monte Dalrymple]

I will look into excluding those reserved ranges, but make no promises. YUPS is completely full, and it took me almost a week to find the bytes to add the CPONLY function. The problem is that any change will affect all board revisions, so V2 will skip 0x0F8-0x0FF, V3/V4 will skip 0x1F8-0x1FF and V5 will skip 0x3F8-0x3FF. I will try to implement it so that the "*" automatically excludes the top sector, but specifying it directly will still be allowed.

I use the top sector for backups and just do FLCHK? "000>3F7" to skip that sector, but that's just me.

It sounds like I need to look into creating a "41CL Backup Functions" to help manage the process of backups. I've been thinking about it for a while, but haven't found the time or motivation yet. The one complication is the "expanded memory" in pages 0x801-0x803 and deciding whether or not to include those in a backup.

[grsbanks]

(05-11-2020 04:24 PM)Monte Dalrymple Wrote:  It sounds like I need to look into creating a "41CL Backup Functions" to help manage the process of backups. I've been thinking about it for a while, but haven't found the time or motivation yet. The one complication is the "expanded memory" in pages 0x801-0x803 and deciding whether or not to include those in a backup.

I was thinking along the same lines and waiting for 5 minutes to myself to build a ROM image with the relevant FOCAL commands to ensure that the correct ROM modules are loaded and then to perform the update automatically.

Sadly, the one thing lacking is time, which is a precious commodity at the moment with work going absolutely berserk and my partner in hospital.

[Monte Dalrymple]

(05-11-2020 04:24 PM)Monte Dalrymple Wrote:  I will look into excluding those reserved ranges, but make no promises. YUPS is completely full, and it took me almost a week to find the bytes to add the CPONLY function. The problem is that any change will affect all board revisions, so V2 will skip 0x0F8-0x0FF, V3/V4 will skip 0x1F8-0x1FF and V5 will skip 0x3F8-0x3FF. I will try to implement it so that the "*" automatically excludes the top sector, but specifying it directly will still be allowed.

I use the top sector for backups and just do FLCHK? "000>3F7" to skip that sector, but that's just me.

It sounds like I need to look into creating a "41CL Backup Functions" to help manage the process of backups. I've been thinking about it for a while, but haven't found the time or motivation yet. The one complication is the "expanded memory" in pages 0x801-0x803 and deciding whether or not to include those in a backup.

My head hurts from all the wall-banging, but what I have right now is:

For V2 boards, "*" means 000-0FF (no sector skipped)
For V3/V4 boards, "*" means 000-1F7 (single top sector skipped)
For V5 boards, "*" means 000-3DF (top four sectors skipped)

My thinking was to reserve more space where more space was available.

Is this reasonable? Or should I just skip just the top sector all the time?

[hth]

(05-22-2020 09:47 PM)Monte Dalrymple Wrote:  My head hurts from all the wall-banging, but what I have right now is:

For V2 boards, "*" means 000-0FF (no sector skipped)
For V3/V4 boards, "*" means 000-1F7 (single top sector skipped)
For V5 boards, "*" means 000-3DF (top four sectors skipped)

My thinking was to reserve more space where more space was available.

Is this reasonable? Or should I just skip just the top sector all the time?

I would prefer to have more than one top sector free. I have a V4 board and all my own ROMs are outside the area as they arrived after the available space was "filled up".

I have 6 pages of my own code, 10 if I count the test images. One sector is 8 pages, so it is not a lot of space. I just took 1C8 (which seemed to hold strange stuff I never need), but I am violating the ROM placement. It works as I do not use the auto updates as I skipped the serial port and do it manually using HP-IL.

[Monte Dalrymple]

(05-22-2020 10:23 PM)hth Wrote:  

(05-22-2020 09:47 PM)Monte Dalrymple Wrote:  My head hurts from all the wall-banging, but what I have right now is:

For V2 boards, "*" means 000-0FF (no sector skipped)
For V3/V4 boards, "*" means 000-1F7 (single top sector skipped)
For V5 boards, "*" means 000-3DF (top four sectors skipped)

My thinking was to reserve more space where more space was available.

Is this reasonable? Or should I just skip just the top sector all the time?

I would prefer to have more than one top sector free. I have a V4 board and all my own ROMs are outside the area as they arrived after the available space was "filled up".

I have 6 pages of my own code, 10 if I count the test images. One sector is 8 pages, so it is not a lot of space. I just took 1C8 (which seemed to hold strange stuff I never need), but I am violating the ROM placement. It works as I do not use the auto updates as I skipped the serial port and do it manually using HP-IL.

I can do that, or I can moved your stuff to 1C8 and put the stuff at 1C8 in V5-only memory. That would allow more people to play with your stuff.

I can also find another sector to move up into V5-only memory and then still have two sectors open in V3/V4.

After all that squeezing I just realized that it will be simple to do:
For V2 boards, "*" means 000-0FF (no sector skipped)
For V3/V4 boards, "*" means 000-1EF (two top sectors skipped)
For V5 boards, "*" means 000-3CF (six top sectors skipped)

[rprosperi]

I agree, more than 1 sector is useful for lots of things, and I think you're 2nd proposal seems fine.

Also, I think your suggestion to put hth's stuff at 1C8 makes more sense, and bump the other less-used stuff into v5.

Thanks for continually improving the 41CL!

[Ángel Martin]

Sorry but I disagree. I'd much rather re-purpose the contents in 1C8 than give away another top sector. The way it is now reserving the top sector 1F8-1FF hurts badly enough, so losing yet another one is not a palatable perspective.

Pls. do not remove the current contents of 1F0-1F7.

[rprosperi]

I believe (Monte, please confirm or correct me) that the plan is to simply change the range which is scanned when using the wildcard "*". Knowledgeable users will still be able to specify the upper sectors for scanning/updating, so they could still be used for ROM storage, however the simpler updating procedures would just not clobber these upper sectors so they could also be used for backups or other custom purposes.

[Monte Dalrymple]

(05-24-2020 01:07 PM)rprosperi Wrote:  I believe (Monte, please confirm or correct me) that the plan is to simply change the range which is scanned when using the wildcard "*". Knowledgeable users will still be able to specify the upper sectors for scanning/updating, so they could still be used for ROM storage, however the simpler updating procedures would just not clobber these upper sectors so they could also be used for backups or other custom purposes.

Yes, the plan is to change the range covered by the "*" option for the update functions. The sector(s) not scanned would never be used for released images and would be available for user use (typically for backups.)

Currently the top sector is uncommitted for V3/V4/V5, although they are still scanned and updated. I am trying to decide if this is enough. If you are only backing up page 0x800 this is room for eight backups. But if you are also backing up the Expanded Memory in pages 0x801-0x803 you would be limited to just two backups. This is what prompted me to consider making the uncommitted space larger.

If 1F0-1F7 changed to uncommitted the images there would find another home somewhere in the V3/V4 address space. There are a number of images in prime V3/V4 real estate that should probably be moved up into V5-only space. For example AFDE, AFDF, B52B, FACC, K135, L119, MILE, P3BC, and SEAK are all military/government and have already been replaced in the V2 map.

If I move those images, then there will be plenty of room to move Hakan's code into the V3/V4 space. This will satisfy his requirement, plus make this excellent code available to more users.

So, proposal 3 is to rearrange things, moving some obscure images into V5 space, moving Hakan's stuff into V3/V4 space, freeing up more pages for more general-interest stuff in V3/v4 space, and going back to 1 uncommitted sector in V3/V4 and 4 uncommitted sectors in V5.

Does this satisfy the majority?

[rprosperi]

Makes sense to move the odd Army/USAF modules up into V5-land, rather than crowding V3/V4 users that couldn't load Hakan's stuff w/o lots of tedious customizing.

It seems to me that more than 1 sector is OK to block at the top of V3/V4, but most likely having a V5 board is a strong influence there.

[Ángel Martin]

(05-24-2020 05:16 PM)Monte Dalrymple Wrote:  So, proposal 3 is to rearrange things, moving some obscure images into V5 space, moving Hakan's stuff into V3/V4 space, freeing up more pages for more general-interest stuff in V3/v4 space, and going back to 1 uncommitted sector in V3/V4 and 4 uncommitted sectors in V5.

Does this satisfy the majority?

Works for me. I assume the stuff in 1C8 will also qualify as : move to V5" category.

[twoweims]

(05-11-2020 04:24 PM)Monte Dalrymple Wrote:  It sounds like I need to look into creating a "41CL Backup Functions" to help manage the process of backups. I've been thinking about it for a while, but haven't found the time or motivation yet. The one complication is the "expanded memory" in pages 0x801-0x803 and deciding whether or not to include those in a backup.

Maybe instead of a dedicated "41CL Backup Functions" ROM it would be sufficient to just include some example scenarios in the existing manuals. The 41CL Update Functions has this sort of information presented very well for different update scenarios.

I am a relatively new 41CL User and would certainly appreciate any help in getting my head around the process of backing up to and restoring from Flash.