Friday, August 29, 2014

Apologies for being quiet for a while - lots of tuning and small changes have been taking place. It's probably easiest to report just what's been going on by sharing this excerpt from the changelog:ZX Prism version 0.12
Archived: 25/8/2014 (non-released, but flashed to board)

After noting that shadow warriors screen corruption stopped in 7MHz mode (though it still crashed), added check for CLK_EN='0' for SRAM_WE. This stopped the screen corruption in all CPU speeds though the game still crashes.

Disabled 56MHz clock speed as I couldn't get it to run without random crashing

Reinstated partial address decoding for port 7FFD (fixes crashes/odd behavior in some 128K games which don't fully address the port). Am currently using the partial decoding as used on the Spectrum +3, +2A and +2B

Fixed another problem with interrupts - the video clock derived interrupts were running at half speed.

"tuned" interrupt signal duration so that they are different for each clock speed, using R-Type as a test. Settled now for values for each clock speed which i) don't cause R-Type to crash, ii) Allow R-Type to detect keypresses, iii) Allow R-Types screen updating to happen properly. These will not likely be the final durations ;)

Saturday, August 9, 2014

Just a small update for today as it's been a fairly busy week so I've not had much time to spend working on ZX Prism lately.

Firstly, ZXPrism now has 512K available to it (in addition to the 32K video RAM). Up until this week, ZX Prism was running as a 32K machine, with its video RAM paged into the memory space 0x4000 - 0xBFFF. This arrangement was merely for testing. Prism's memory arrangement is now much more like you'd expect on a Spectrum 128, with video RAM at 0x4000 - 0x7FFF and 'ordinary' RAM between 0x8000 and 0xFFFF.

Like on the Spectrum 128 etc, the extra RAM is split into 16K banks which get paged into the area 0xC000 - 0xFFFF; as ZX Prism has 512K, this equals 32 x 16K pages of RAM which I'll refer to as pages 0 - 31. Page 2 is always paged into memory area 0x8000 - 0xBFFF (currently; this page may be changed to be selectable in future). The memory which is paged into 0xC000 - 0xFFFF is selected using IO port 7FFD - the same as on the Spectrum 128 - but of course ZX Prism has more pages available than on the 128 so ZX Prism uses bits 6 and 7 of port 7FFD in addition to bits 0 to 2. This matches the way that the Russian Pentagon 512 does it:

ZX Prism's SRAM is actually 256K of 16 bit RAM. Bit 4 of the page number determines if the upper or lower byte of the 16 bit data bus are to be used, effectively splitting the SRAM into two lots of 256K which is how 512K is achieved.

Currently ZX Prism's ROM is stored on the FPGA and is the original Sinclair ROM from the 16/48K Spectrum. As such, the ROM bank select currently does nothing. The "lock" to 48K mode also isn't yet implemented (though it would be trivial to do so), so ZX Prism currently perpetually runs in "USR 0" mode.

The additional memory was tested a number of ways - firstly RAMTOP was set to below 0xC000 and then unique test data was written to each page; then the data from each page was read back and verified. Of course there's not much 512K software (at least not that's available as a TAP/TZX file) to test, but I've tested several 128K games.

Speaking of tapes, I'd been finding loading to be a little unreliable. Everything would be OK for 3 or so minutes but then it would fail. It didn't matter if this was a turbo loader or standard loader. Eventually I found that one of the resistors in the tape-in circuit was getting very warm - when I swapped that out for a resistor of the same value but higher current rating, things got a lot more reliable. I still seem to have to use a higher volume level than on a normal Spectrum - I suspect that's due to the Spectrum's ULA working at 5v, and the Max3232 RS232 UART that I'm using to buffer input between tape and FPGA is expecting a higher voltage.

Finally, I've started hooking up the MMC slots so I can start implementing DivMMC and getting ESXDOS working. I'll have to do some more research on when exactly ESXDOS needs to be paged in and out of the ROM area (it reacts to an NMI switch, pages in as a shadow ROM on RST8, and has tape traps at least... and I have no idea of what triggers them - or what triggers a page out). I also need to know how the DivMMC does its ROM/RAM paging. If anyone can help, leave me a comment or seek me out on WoSF.

I've already done a bunch of Googling and searching threads on the World of Spectrum forums... Looks like I'll have to ask the designers/coders (or an emulator author perhaps) directly. Andrew Owen's already managed to give me a certain amount of insight, but I'm far from clear on all points!

Finally, a picture of ZX Prism as it currently looks. Please ignore any dodgy soldering you might notice. I've just got a new soldering iron, and it's a huge upgrade from my last one!

The dev board is a Black Gold Cyclone IV kit, which is very nice but you have to translate all the documentation from Chinese! This dev board comes with 256K of 16 bit SRAM, a similar sized FLASH, about 4MB of SDRAM, RS232, VGA, USB, PS/2 (which was broken on my board), and a LAN socket as well as the 7 segment displays and LCD screen. The veroboard contains the analogue circuitry for tape-in and (untested as yet) tape-out, the dual MMC sockets, and also the break-out connector for the PS/2 and VGA daughterboard (not pictured) which replace the implementation of each on the main dev board (the PS/2 socket was broken on delivery, and the on-board VGA was 8 colour only)

Sunday, August 3, 2014

Spent the weekend tying up some loose ends and working on the user-definable palettes. ULAplus support is pretty much working now (it's currenlty missing the ability to read the palette back, and the ULAplus specification includes the Timex screen modes which aren't implemented yet).

I've also hooked the SRAM up, so Prism now has 48K. There's 512K SRAM on the dev board and Prism will have access to all that once I've implemented bank switching.