ROM emulation/copier

[banedon]

Hi guys

I'm thinking of creating my first ROM emulator/copier and just want to run my rough plan of action passed some folks who have done it previously.

This is what I was thinking of doing:

* The entire memory map uses 64KB RAM - no ROM. Some space is reserved for I/O
* Use an uC (Atmel 328P or 324P) to control the clock source for PHI2
* Allow the uC to control the 65C02S using the /RESET line
* When the system starts up, the uC hold /RESET low and stop PHI2
* It then copies the 6502 firmware/BIOS into the upper part of RAM and set the Reset, NMI and IRQ vector addresses
* the 6502 /RESET is released and PHI2 is started

What do you think?

My main question: if the 65C02 /RESET is held low, is the address and data buses tri-stated by the 65C02?

[Oneironaut]

I think that works perfectly up to 25MHz on a 65C02 with 10ns SRAM.
But that is only because I have it working that way right now!

Note: Using BE as per BDD's info below as well.

brad

[BigDumbDinosaur]

banedon wrote:

I'm thinking of creating my first ROM emulator/copier and just want to run my rough plan of action passed some folks who have done it previously.

This is what I was thinking of doing:

* The entire memory map uses 64KB RAM - no ROM. Some space is reserved for I/O
* Use an uC (Atmel 328P or 324P) to control the clock source for PHI2
* Allow the uC to control the 65C02S using the /RESET line
* When the system starts up, the uC hold /RESET low and stop PHI2
* It then copies the 6502 firmware/BIOS into the upper part of RAM and set the Reset, NMI and IRQ vector addresses
* the 6502 /RESET is released and PHI2 is started

What do you think?

My main question: if the 65C02 /RESET is held low, is the address and data buses tri-stated by the 65C02?

Asserting reset doesn't tri-state the 65C02. You'd have to assert (negate) BE (bus enable) to do that. When BE is asserted, A0-A15, D0-D7 and RWB go high-Z.

I'm not sure what the purpose would be of stopping Ø2 while loading your ROM image into RAM. Continuously holding reset down is sufficient halt the 65C02. Note that Ø2 must be running and stable before releasing reset.

[banedon]

Thanks guys: That is very useful info. I'll let you know how it goes when I build it. In the mean time, if you have further thoughts please let me know.

[banedon]

OK. Doing some testing on my existing 65C02 system, when I send BE low the buses all go high-z as advertised by the datasheet. However, I cannot seem to get the CPU to resume unless I reset it.
Is this by design or does anyone know a way of getting the CPU to continue? I.e. can you use a arbitrator to pull BE low, thus pausing the 65C02 so that another uC/uP can drive the buses and then tell the 65C02 to resume. I thought driving BE high would do this, but it doesn't seem to.
[edit] I wonder if an NMI or IRQ would do it?

[Dr Jefyll]

banedon wrote:

I.e. can you use a arbitrator to pull BE low, thus pausing the 65C02 [...]

Sounds as if you're overestimating BE. The effect of that input is a lot dumber than you might suppose or wish it to be. All it does is tristate the CPU bus lines (and R/W) just as some external '245 tristate buffers would do. IOW the pause is something you have to establish yourself, either by stopping the clock or by pulling RDY low.

Failing to pause the CPU when BE has gone low means any program presently running will crash (tristate buses mean no more instructions arriving from memory!). That's tolerable prior to initial reset, but otherwise might not agree with your plans.

[banedon]

So can you get away with asserting RDY followed by BE, do whatever, then send BE high and then RDY? However, I'm guessing this will still empty out what the 65C02 was doing so would still have the same issue?
So how on earth do you take control of the bus without getting possible contention and without having to reset? It must be do-able as I think this was done with the Commodore 128. Although that might have been with a modified 6510... not sure.
Or combine the above with detecting the next rising edge of PHI2 and then do it then?

[BigDumbDinosaur]

banedon wrote:

So can you get away with asserting RDY followed by BE, do whatever, then send BE high and then RDY? However, I'm guessing this will still empty out what the 65C02 was doing so would still have the same issue?

Asserting RDY will cause the MPU to halt on the next Ø2 high, holding all registers in whatever state they were in at the time. When RDY is released the MPU will restart on the next Ø2 high, no reset needed.

[BigDumbDinosaur]

Dr Jefyll wrote:

Sounds as if you're overestimating BE...Failing to pause the CPU when BE has gone low means any program presently running will crash (tristate buses mean no more instructions arriving from memory!).

Worse yet, if the MPU is still running after tri-stating the buses, it might load random garbage for instructions, depending on bus capacitance, noise from nearby circuits, etc. There's no telling what might happen.

[banedon]

Oh well. At least I should be able to do the ROM simulator/copy.

[BigEd]

(To avoid confusion, it might be worth avoiding this "asserting" word- half the time it's used incorrectly. For an active-high signal like RDY, assert means take it high. But generally we're interested in using RDY to stall the machine, which means we need to take it low, which is de-asserting it. For an active-low signal like NMI, it's asserted when it's brought low. As noted before, it would be more consistent and less surprising if RDY were called STALL and were an active low input. That would be exactly the same as it is now, with respect to logic levels, but would have us correctly saying that we assert STALL by bringing it low. More precisely, we'd call it \STALL or STALL* or STALLB.)