Because the Atmega at the userport is limited in speed and kernal (FFD2) compatibility I decided to take an large AVR to read the SRAM without help of the kernal.
I tested the Xmega 128 with the 3.2 inch 16-bit display.
The Xmega is specified for 32 MHz. I tryed 64 MHz successful but I think 48 MHz is enough for a 25 Hz screen refresh rate.
The Xmega halts the CPU, disables the CPU-adress-buffers, enables the xmega-buffers and reads the VIC-register (there is RAM), one screen-row and one color-row.
Each reading sequence is about 16 us -> fast enough for disk load and save! (max. 42 us is allowed, because of the original VIC2). Than the Xmega checks the register for screen base adress, backgroundcolor, characterset/base and prints one row to the screen.
The CPU halts 1940 times per second - in total the CPU stops 42us of a second - not noticable ;-)
I got a screen-refresh-rate of 26 Hz.
Later with sprites it will be a little bit slower - or maybe I try the Xmega @ 56 MHz.
The Xmega runs with 3.3V so I need two HCT245 buffers to raise the adress-bus to 5V.
To read the 5V databus with the 3.3V Xmega inputs I use a LVT245 buffer.
I ANDed RDY from Xmega with the RW=READ so the CPU will only stop in read-cycle. This is nessesary because the CPU-databus must be input and not in conflict with the SRAM output.
To readout one byte from the RAM the HCT245 needs about 10ns, the GAL max. 15ns, the SRAM 15ns and the LVT 4ns! - I need only 3 NOPs = 63ns in the Xmega - very fast!
Now with the Rockwell CPU all is perfect - with the WDC there are again stability issues!
Very interesting! Do you publish your code anywhere?
ReplyDelete