This is a bit of a bump.

I've been grappling with some stability issues in both versions of my POC V2 design. I'm now considering the possibility that improper wait-stating may be the culprit. I explain some more in this post.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Hoping you figure out the RDY issue as I've got no hope of figuring it out myself!

I still haven't gotten around to trying this shadowing method yet, I'm doing something else for the time being as I'm still making lots of changes to the ROM
Some background, my memory map is


What I'm doing at the moment is paging 0x6000-0x7FFF in from RAM2 at boot and then using an S-Record loader to load a new ROM image to this space.
Once loaded I use a short piece of code in RAM to flip an output on my 28L92 DUART which tells the CPLD to decode 0xE000-0xFFFF to RAM2 instead of ROM. any accesses to addresses 0x6000-0x7FFF decode to RAM1 after that point.

So basically at boot it's actually

Once the overlay output is set on the DUART it becomes



I actually quite like this, it means I don't have to use my janky protoboard ROM Emulator & Raspberry pi any more

Your mapping should work but I believe it may be easier to do something different:

During startup 0xE000..0xFFFF is ROM when (and only when) RWB is 1. The region is RAM2 when (and only when) RWB=0. This actually means any access there will READ ROM and WRITE RAM2. Once you have read out all ROM (and write it back to the same address into the RAM2) you can turn off ROM access during RWB=1 and instead accessing RAM2 in that region. And of course you could disable any wait states then.

So the logic equations might s.th. like:


You may even try to write RAM2 during read of ROM:



Hope I did not overlook s.th.

The problem there is that my /MRD signal is shared between ROM/RAM/IO.

This is fine because if I assert /MWR at the same time as /MRD whenever the ROM is enabled & selected this will write whatever is in the ROM to the underlying RAM. I can then read the whole ROM space and it'll be copied very quickly.

The problem becomes when I want to load something else into that RAM, any reads of the ROM at all will overwrite the RAM again and if I don't assert /MWR then both the ROM and RAM will drive the bus at the same time.

So you have a global /MWR and /MRD and can control RAM and ROM only by their chip selects.

Then you are right, you can't read ROM and write RAM simultaneously on one hand and later write RAM again without getting trouble.

At least you can read out ROM during BOOT_IN_PROGRESS and write the value back into RAM using the same address, then in- or decrement the pointer and copy the next byte until you are through. Then you can turn off ROM and getting rid of the one cycle penalty.



One option you might consider is to write protect the RAM after ROM copy using the BOOT_IN_PROGRESS signal. If you then would like to change the RAM you only need to turn BOOT_IN_PROGRESS on (which turns read access to ROM on as well) but not to copy ROM code but placing something new into RAM and then protect it again.
This could prevent RAM contents from programs that behave a little different from what you intent



Edit(1): During copy or later writes you cannot use the lower part of the RAM2 with the suggested code above. But you could add RAM2_CS true for read access in the lower part of it if you wish.

You may want to look at how the Acorn 6502 Second Processor did it.

It came up with a heavily divided clock speed to suit a low-cost 2KB ROM, which was mapped at the very top of the memory map, overlaying the Tube I/O and some of the RAM. The control signal selecting this clock speed directed all reads in the top 2KB to the ROM, all other reads to the RAM, and all writes to the RAM.

The RESET vector promptly reads and rewrites every ROM address that didn't clobber the Tube I/O, then performs an arbitrary access to a low RAM address which has the side-effect of dropping the boot control signal. At that point the clock goes to full speed and the ROM drops out. The top 2KB of RAM now contained a copy of the ROM, so the boot process continued.

Apparently it took about a quarter-second to complete that sequence.