The border is currently controlled by an OUT to an 8 bit latch and currently replaces the usual 3 bit border. Another latch has been implemented which selects the CPU speed and in the future will also reflect "machine type" (or at least which memory paging system to use). Setting and unsetting bits 0 and 1of this latch selects between the 4 CPU speeds implemented.
- 00 - (default) 3.5MHz
- 01 - 7Mhz
- 10 - 14Mhz
- 11 - 21Mhz
Speaking of implementing memory contention. At 3.5Mhz I want this to be as accurate to ZX Spectrum timings as possible. My attempts thus far to implement ANY sort of delay when the CPU address space is within video RAM have been unsuccessful:
- Machine seemed to run as usual. Could load from tape successfully. Aquaplane's border effect switches colour around 12 lines early - this is the same as without the contention circuit. Conclusion: contention enabling logic was incorrect.
- Machine seemed to run as usual. Loading from tape was unsuccessful - pilot tones were detected, but data wasn't correctly decoded. Conclusion: CPU was being disabled for too many cycles.
- Machine seemed to run as usual. Loading from tape was unsuccessful - pilot tones were not detected. Conclusion: CPU was being disabled for too many cycles.
- Machine displayed garbage on screen and didn't initialise. Conclusion: as soon as contention was applied, the CPU was effectively halted (this was backed up by monitoring the address bus)
Additionally, I've confirmed that code using the R register fails consistently. Speedlock 1 works right up until the loading completes and then crashes. Most machine test suites (ulatest3, fusetest etc) fail spectacularly - the two aforementioned test suites crash in fact.
I shall revisit memory contention later. For now, I can live with the fact that some software which relies on cycle-accurate memory contention (eg for border effects) will look odd. The crashes and apparently incorrect CPU behaviour is more of an issue, but again I can do little about it at the moment. The T80 code isn't well documented at all and I'm still learning the ropes with VHDL really. A little bird tells me that someone working on another "advanced Spectrum" style project has done some bugfixes to command timing and flag behaviour, so I'm hoping they'll share them with other T80 users in the future.
Finally, I talked to Andrew Owen regarding reserving a block of IO addresses in the ZXI standard. This means that the ZX Prism's IO addressing won't clash with any other ZXI certified device, for example Spectranet and ULAplus (though of course ZX Prism will be providing ULAplus functionality at its usual ports anyway). This is especially important if I intend to add an edge connector to ZX Prism so that it can use existing ZX Spectrum peripherals like divIDE etc, or should I build a plug-in for a standard ZX Spectrum which provides some or all of the ZX Prism's extended functionality.
The range I have been allocated is xE3Bh which gives me 16 IO addresses which should be plenty. Currently I've earmarked:
- 0E3Bh - ZXPrism hardware control (CPU speed, memory paging method select, etc)
- 1E3Bh - ZXPrism screen resolution select/attribute decode method select
- 4E3Bh - Border colour
- 6E3Bh - Memory Page at 8000h
- 7E3bh - Memory Page at C000h
- BE3Bh - (write only) ULA2 palette (colour select)
- FE3Bh - (write only) ULA2 palette (R/G/B data)
Currently I'm planning using 16K memory pages (per Spectrum 128/Scorpion/Pentagon). This may change to 8K pages (Timex/Spectrum SE/ZX81) or be switchable, however I don't want the memory bank switching to become too complicated.