gents,
any hints to a fast solution for copying a contiguous memory block (say, a 64kB block from address 0h to 30000h)? i'm currently investigating how to swap the 64kB ROM area with a 2 x 32kB ram area of my FRAM71 module.
http://www.flickr.com/photos/75954327@N05/
that would give the opportunity to "upgrade" an HP-71B with 1BBBB firmware to 2CDCC (or whatever else one would like to put in there). in order to test that "swap" feature, i simply copy the rom area to 30000h, then swap the addresses and set OD to high. however, the copy process via peek/poke is pretty time consuming, and considering the many "memory lost"s along the road, i would rather prefer a faster solution...

thanks in advance,

hans

Edited: 5 Feb 2012, 10:53 a.m. after one or more responses were posted

Use CMOVE in Forth?

Hi,

you could use a small copy routine using Saturn machine language.

Actually there are suitable routines in the ROM,

like MOVEUP or MOVEDN, which expect the source in D0 and target in D1, and the amount of nibs to copy in C[A].

To call the routines from Basic, you may have to write a small BIN file,

or create a LEX file with a suitable keyword, like MEMCPY(src,tgt,nibs)

which then will call the internal memory copy routine.

However I'm sure someone already wrote s.t. like this back then,

so you may also check the LEX file library;-)

HTH

Ray

Edited: 5 Feb 2012, 5:04 p.m.

I am pretty sure you will need to resort to assembler for this. It is possible that if the peek and poke commands make good use of the processor peeking and poking multiple, up to 16 nibbles at a time may be faster than a single peek and poke. However it can never be as efficient as something written in assembler. Peek would read the target memory into a variable you assigned and then poke would read the data from that variable and write it out to your target address, so your data is handled twice. With a solution written in assembler you could go directly from your source location to you target location.

Memory moving is one where the simplified bus structure of the Saturn processor bites you. The design has all memory devices keeping a local copy of both the program counter and data pointer, and before reading or writing, the CPU sends out a command to tell memory devices load a one of these registers and then 5 more bus cycles to clock out the 5 nibbles of the 20 bit address then the read or write command at which point on the strobe you may read or write data, however the architecture allows for up to 16 data strobes following sending out an address and bus command with each strobe the memory device are supposed to increment their local copy of the address in use (program counter or data pointer). So it would seem to me that the most efficient way to do this would be read 16 nibbles into a register and then write them out to the target. I am sure that it is not coincidence that the working registers in the Saturn are 16 nibbles in size, briefly looking at the instructions available there seems to be instructions to load and save a register in one shot. There are also two data pointer registers that could hold the source and target addresses which should be pretty efficient.

If you get your FRAM module into production, I would be certainly be interested in acquiring one!

craig,
thanks for your interest! there are three FRAM71 currently in prototype state. putting documents and everything else together will take another 6 months. i'll be putting up a doc in the articles section here, so that everybody can decide whether he/she would like to order an FRAM71. if everything works fine, there will be a batch of 25 units (pc.b.s. without parts are already done). anyway, there will be the opportunity to buy the un-assembled p.c.b. for those who don't mind a little soldering challenge.



hans

Edited: 7 Feb 2012, 5:19 a.m.