Firstly, the literal. Mike Stirling released a new version of FPGASpectrum during the week and I took some time from working on ZX Prism to check it out. I was impressed. Mike has very quickly added a number of new features
- AY Soundchip core
- IO Port 7FFD controlling RAM/ROM paging as on all 128K Spectrums
- IO Port 1FFD controlling ROM and CP/M memory modes as on the +2A and +3
- ZXMMC+ (allowing the Spectrum to access SD Cards and adding another 128K of RAM and 128K of ROM)
This left me in a quandry. I'd been going to add 128K support to ZX Prism as part of the memory expansion to 512K (or 1MB if I could get the DE1's DRAM working), and whilst I'd been going to add IDE support to ZXPrism (via a divIDE interface), the ZXMMC+ allows access to the SD Card slot which is already on-board.... So... do I use THIS as the new foundation for ZX Prism and start merging in the changes I'd made to Mike's original VHDL, or do I try to merge Mike's changes into ZX Prism?
Either way, I had to rethink how I was going to do Prism's expanded memory (as ZXMMC support uses 256K of the DE1's SRAM)
I decided on the former - after all, I knew exactly what changes and additions I'd made for Prism. Memory-wise, the upper 256K of the SRAM is used by the ZXMMC+ implementation. The lower 256K of the SRAM will be switchable in 16x16K pages at 0xC000 (using the Pentagon 256 decoding of port 0x7FFD to switch it). I'll be using on-FPGA memory cells for the video ram (pages 5,7,D and F) due to the way the video subsystem will be reading it - this gives another 64K of the SRAM available for.. something.
So, much of my time recently has been spent on integrating my changes into Mike's new codebase. As I'm new to VHDL and FPGAs, this has been a learning experience as Mike has changed from using a schematic top level to using a VHDL top level - therefore my progress is slower than it might have been otherwise. All good learning though.
As part of integrating the ZX Prism code, I decided to take a look at how the Spectrum's interrupt was being generated (aha, there's the other tie-in with the post's title).
Some code on the Spectrum relies heavily on certain features of the Spectrum hardware:
- accurate generation and duration of the Spectrum's video interrupt
- accurate emulation of memory/IO contention (ZX Prism's bus is arbitrated by timeslicing so there's no need for contention in order for things to work, but it IS needed for Spectrum code to run at predictable speeds)
- the Spectrum's floating bus
I'll be looking at all of these things (as I know Mike is,), but the easiest thing to look at was the video interrupt, which I coded to behave precisely as Chris Smith describes in the ULA book. Once this was done, I tried running some of the software which wasn't working correctly:
- ULATEST3 - still crashed
- Aquaplane - border effect still starts too early on the screen
- FUSETEST - no longer crashes