41 MCODE - Copying bank-switched pages

[Ángel Martin]

There are almost no tools available to extract or copy code from a bank switched ROM. When faced with that challenge I typically used ad-hoc modifications of Warren Furlow's short routine "CB", posted at a TOS near you...

CB is specific for fixed source and destination pages, as well as only useful for the second bank. Preparing a more general-purpose function was always on my mind, and finally here it is available.

CPYBNK is a prompting function. It has a customized prompt with three distinct sections that are shown on the screen as the data entry progresses. The parameters entered are as follows:

- Bank number, an integer decimal from 1 to 4
- Source page, an hex value from 0 to F
- Destination page, same as above.

The copy is always made into the main bank of the destination page (bank-1). This is typically a Q-RAM page in an MLDL (or a RAM page on the CL) thus only supports one bank. Besides the practical usage is intended to copy elusive, hard-to-reach code buried into secondary banks – therefore it wouldn’t appear very sensible to copy it into equally obscure destinations.

CPYBNK is last-minute addition to the CLXMEM module – even if it's not related to the Expanded memory subject. The function code is long enough so there’s no chance to include it in the PowerCL module, therefore it’s here as a second best place to include it in.

See the attached write up and QRG for CLXMEM, including the CPYBNK details.

PS. Edited with updated function code. QRG posted at TOS.

[Gene]

Great addition, Angel.

How about this for a project ?

A function that gives a directory of 41CL ram pages that have data stored on them. After a while, someone might forget if they have copied something to 806,809, etc. What ram pages have been used so unused pages can be found?

:-)

[Ángel Martin]

(10-12-2014 11:55 AM)Gene Wrote:  A function that gives a directory of 41CL ram pages that have data stored on them. After a while, someone might forget if they have copied something to 806,809, etc. What ram pages have been used so unused pages can be found?
:-)

Neat idea but is it possible at all? When is the content in a RAM page a valid one, meaning it does have a sensible coding as opposed to random bytes (even if not zeros or "FFF"s). For what I know the RAM contents can be altered or changed in different degrees without the batteries...

[Monte Dalrymple]

(10-12-2014 11:55 AM)Gene Wrote:  How about this for a project ?

A function that gives a directory of 41CL ram pages that have data stored on them. After a while, someone might forget if they have copied something to 806,809, etc. What ram pages have been used so unused pages can be found?

:-)

The only way that I can think of to do something like this would be to reserve a RAM page to hold some kind of "valid" bit corresponding to each RAM page. You would need to manually set/clear the bits as you used pages though. Conceptually it's not much different from what I do in the Image Database and the Flash Database.

[Ángel Martin]

(10-12-2014 11:00 PM)Monte Dalrymple Wrote:  The only way that I can think of to do something like this would be to reserve a RAM page to hold some kind of "valid" bit corresponding to each RAM page. You would need to manually set/clear the bits as you used pages though. Conceptually it's not much different from what I do in the Image Database and the Flash Database.

How about a reserved memory area with a bit set/clear status toggled or edited with any PLUG/Unplug action? That'll be just 122 bits (each one representing the latest action on each of the RAM block 0x805 up to 0x87F), so could be allocated within block 0x804 perhaps.

The updating could be done as part of the PLUG code - I guess.

[Monte Dalrymple]

(10-13-2014 11:56 AM)Ángel Martin Wrote:  How about a reserved memory area with a bit set/clear status toggled or edited with any PLUG/Unplug action? That'll be just 122 bits (each one representing the latest action on each of the RAM block 0x805 up to 0x87F), so could be allocated within block 0x804 perhaps.

The updating could be done as part of the PLUG code - I guess.

Yes, this would be easy to do, but it only covers a subset of the ways that RAM pages might be used. Right now "PLUG ?IMG ?" will show RAM pages currently plugged in. There are also the cases of copying something other than an image to RAM, and edited image in RAM that has never been plugged in, etc. This is why I don't think that any "automatic" accounting is going to be sufficient.

[Ángel Martin]

(10-13-2014 01:36 PM)Monte Dalrymple Wrote:  There are also the cases of copying something other than an image to RAM, and edited image in RAM that has never been plugged in, etc. This is why I don't think that any "automatic" accounting is going to be sufficient.

Yes you're right, I also thought about a few other ways to "defeat" my ill-conceived automated mechanism. So it'd have to be a manual one, yet it certainly can be assisted by a function to "flag" or mark a given RAM block as a valid image.

A slow approach could be based on calculating the ROM checksum and compare it with the value stored at 0x8xxFFF; it there's a match then the block is OK - unfortunately the reverse (bad checksum) doesn't necessarily means it is not (non-conclusive).

[Gene]

My original thought was to find ram pages that had been used to store updated rom images or other well-behaved data. My fear had been that it could become easy to forget that 809 had been used previously ... or was it 808? :-)

So, what are the used (or unused) ram pages? that's essentially my question.

[Monte Dalrymple]

(10-13-2014 11:40 PM)Gene Wrote:  My original thought was to find ram pages that had been used to store updated rom images or other well-behaved data. My fear had been that it could become easy to forget that 809 had been used previously ... or was it 808? :-)

So, what are the used (or unused) ram pages? that's essentially my question.

One way to start would be to initialize the first word of every RAM page to 0 after the Memory Lost. Since this isn't a valid first word for an image, it is a reliable indicator that the RAM page doesn't contain an image. This even works for HEPAX memory pages. This at least makes it possible to check individual pages; just YPEEK the first word. This approach might even be better than using a separate table, but I'll have to think about it.

When I get around to writing the "Flash Functions" module I'll try to include some functions to support this: one to automatically zero the first word of every RAM page, and perhaps another to scan RAM for non-zero first words. But if I do that maybe I need to change the name of the module to "Memory Functions."

Monte

[Ángel Martin]

(10-14-2014 06:32 PM)Monte Dalrymple Wrote:  One way to start would be to initialize the first word of every RAM page to 0 after the Memory Lost. Since this isn't a valid first word for an image, it is a reliable indicator that the RAM page doesn't contain an image. This even works for HEPAX memory pages. This at least makes it possible to check individual pages; just YPEEK the first word. This approach might even be better than using a separate table, but I'll have to think about it.

Since the RAM contents survives the Memory Lost event, wouldn't the automated erasing you describe mess up with all the valid pages then? The first word of the block has the XROM# in those instances.

[Monte Dalrymple]

(10-15-2014 05:47 AM)Ángel Martin Wrote:  Since the RAM contents survives the Memory Lost event, wouldn't the automated erasing you describe mess up with all the valid pages then? The first word of the block has the XROM# in those instances.

I wouldn't do it as part of the polling point routine, but only by user command. Probably makes sense to prompt for a start and stop page address.