The one part of C-64 memory that had to be accessed on a regular basis was video RAM ($0400-$07FF) and the matching color RAM, since that was the means by which a running program ultimately drove the display. However, as you noted, the SuperCPU was able to shadow a lot of what was going on in the C-64.

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

Basically in Amiga terms, it turned the C64 into ChipRAM, while FastRAM was on the SCPU.

There also was a single byte write buffer into the 64, so that there'd be no slowdown in writing there if it wasn't busy. (No clue if the Amiga did that, though they'd be a bit silly not to.) Reads of course would have to round-trip at 1MHz.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

I started thinking about this idea again and it seems like you could use a second EEPROM for memory mapping. Using it to select banks seems like it would be impractical (even more so than this idea already is.) If I drive all the chip selects directly from the second EEPROM at 55ns and don't use any other logic would my read cycle be 30 + 55 + 55 + 10 = 150ns? And would the write cycle be 30 + 55 + 25 + 25 (RAM setup time) = 135ns? It makes me wonder if there is any way to replace the second EEPROM with 12ns SRAM...

I know it's not an ideal way to do it but just for fun I thought out how you might store memory map signals in an EEPROM then load them into a 12ns SRAM before the system starts. Do you think something like the following would work? I was thinking a 555 timer could keep its output high for about half a second which would disable the 6502 and all the peripherals, while enabling the EEPROM output and putting the 12ns SRAM in write mode. A 16-bit timer would cycle through all the addresses and an 8 bit timer running from the main clock would generate divided down write signals for the 12ns SRAM and advance the 16 bit counter to copy the whole EEPROM to the SRAM. After the 555 output goes low (and stays low), the EEPROM and 16 bit counter are disabled, the 12ns SRAM goes into read mode to drive the control signals, and the 6502 and peripherals are enabled.

I think the data lines for the SD card and LCD might need to be qualified with the signal from the 555 to avoid writing garbage data to them. The data-in line for the SPI peripherals might be able to be taken from the 6502 data bus. I could also drive the SPI clock with the SPI buffer and free up D7 of the SRAM, but I think I might be able to bit bang faster this way if I set the clock high for all addresses but one zp address and read that address to strobe the clock low. I could also put 10 NOPs in a row somewhere with the clock low at every one of them followed by a RET, then I could jump to the NOP that corresponds to how long the clock needs to be low. If I can free up another pin, I could also drive the SPI data-in from it directly which would make bitbanging even faster.

Do you think this would work?

Here is another way I thought about doing it. I got rid of the second ROM and added a transparent buffer so the 6502 can read from the ROM at start up and all writes go to the memory map SRAM. After the 555 fires, the memory map SRAM goes into read mode to control the peripherals and a buffer separates its data lines from the 6502 data bus. Another selector switches control of the ROM from the 6502 to the memory map SRAM. I think doing it this way would get me down to 12ns for the SRAM to do the memory decoding plus 3-4ns more for a 74ABT244 to control the ROM or 15-20ns more for the 74HC670 to drive the SRAM.

Doing it this way I could set the reset vector to one part of ROM with a routine to write all the memory map values then when the RAM takes over decoding it can set that part of the address space to something else since I don't need that part of ROM any more.

I also added qualification with Phi2 for writing the 74_670 and SRAM. I don't think the last schematic would have worked without those.

I was thinking a little more about generating control signals with an EEPROM or fast SRAM and found this video on the C64: https://www.youtube.com/watch?v=ofg33zk9uCA

It seems replacing the PLA unit (which generates control signals) with a 45ns EEPROM caused bus contention as the EEPROM data outputs were garbage during transition. How is that situation different from what you might get with 74xx logic? Couldn't you also get bus contention in the 10s of ns if different chips in your circuit take different amounts of time to switch?

Depends on the actual circuit. If carefully designed, the output gates of combinational logic can be synchronised such that problems with "garbage" output data is minimised.

Mark

Druzyek, I was looking at the most recent drawing you posted, and (forgive me for saying) it seems a bit hard to comprehend. May I suggest you organize the diagram so most of the signals travel left to right? Also it's helpful if you use thin lines for individual signals and thick lines for groups, such as the data bus. Like this:
Here's the same idea taken even further. As much as possible the inputs of the chips are drawn on the left and outputs on the right. To do that you may have to re-arrange the drawing, but it's worth it because the result is easier to understand. Well, that's my opinion at least!
Have you considered alternatives to the 555 one-shot? It is an analog timer, and maybe it makes more sense to use some sort of digital signal to tell you when the startup sequence is complete. Just an idea.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Good idea! Thanks for the advice and the example.

If there is something cheaper, smaller, or less power consuming, sure. I just need something to give a nice clock edge to switch from writing the memory map to normal operation.

I have been thinking about doing something similar with a microcontroller, which we discussed a little in another thread. Here is a simplified version of what I am thinking, which requires a lot less logic.


I could get rid of the NOT and OR here if I could route R/W and clock through the memory map SRAM too, but I'm afraid the garbage coming out before the lines settle could cause inadvertent writes. Maybe if I hook the kind of RAM I'm interested in to an oscilloscope and look at the transitions, I can see if inadvertent writes would be any less likely using some pins than others.

My plan is for the microcontroller to start the 6502 and feed it 0x0000 as the reset vector. Since the microcontroller is not connected to the address lines, it will have to count cycles to know when to provide the address. Starting at 0x0000, the microcontroller writes the CS and OE signals to the memory map (also connected to the address bus) for that address then feeds a NOP to the 6502 to advance the address counter to the next value. After it writes all these values, it feeds more bytes to the 6502 to make it write a small bootloader to load code from the SD card. Then the microcontroller z-states its outputs to the memory map RAM and switches the memory map RAM to output mode, so that it can provide control signals. Last, the microcontroller sets the output pin to the 6502 clock to its own clock (up to 20MHz), z-states its connection to the 6502 data bus, puts itself to sleep and the 6502 runs the bootloader. The microcontroller can wake up from sleep based on a timer and trigger the 6502 interrupt, or the 6502 can wake the microcontroller from sleep by writing to a buffer connected to a microcontroller pin. With more cycle counting, the two chips can exchange data to read timer values, read and write serial, or whatever else the microcontroller can do.

The main hiccup is what the outputs of the 15ns SRAM I would use for the memory map look like when the address lines are settling. If they output data from other addresses while transitioning, it will be fine, but if they output random garbage, all of the peripherals could briefly be put into output mode at the same time, which would be bad.

(If you already have an 8 bit and a 16 bit counter to control the copy of the EEPROM into the SRAM, wouldn't it be straightforward to add a 1 bit saturating counter to detect the end of the copy and allow the CPU to run? Which is to say, you're speaking in terms of timers and adding a timed transition, but if you think in terms of counters and counting, that might give some ideas.)