So I took a couple of steps back and also a small break to brainstorm a feature wishlist. I then thought about how all the different proposed features would work, which I considered "essential" and which were not essential but could be produced easily using the technology required to realise the "essential" features.
As anyone following this blog will be all too aware, this process has taken some time, not least because a number of other areas of my life have been vying for my time as well. It's all for the best though, and the specification boasts a strong and usable feature list.
Here's a taster.
Memory
- The all-RAM "Special" memory mode available in the Spectrum +2A/B and +3 will be replicated meaning ZX Prism will be able to run the various software that requires it.
- Outside of the "Special" memory mode, the ROM area (0x0000 - 0x3FFF) is selected from 32 pages of FLASH (512K) or 32 pages of non-volatile RAM. This arrangement is controlled in the same way as the memory in the ZXMMC+ interface, including the fact that the page number selected is affected by the 128K ROM selection bit of port 7FFD. Unlike ZXMMC+, ZXPrism also watches the ROM selection bit of port 1FFD so that 64K rom sets (eg +3 or +3e) can be used.
- The memory between 0xC000 and 0xFFFF, is 16K selected from a set of 64 pages, for a total memory of 1MB. The page number is selected in the same way as on the Pentagon, using port 7FFD bits 0-2, 5, 6 and 7. 1MB mode can be disabled for compatibility, re-enabling it can be used to re-enable paging if locked in 48K mode.
- ZX Prism has 64K of video memory split into 8 x 8K segments. Which segment(s) the video circuitry used depends on which screen data decode method and which screen resolution is selected. As on the Spectrum, the CPU sees video memory between 0x4000 and 0x7FFFx, but unlike the Spectrum, it is possible to choose which 8K segment the CPU sees at 0x4000 and which 8K segment it sees at 0x6000. Of course in BASIC crashes will occur if the segment at 0x6000 is changed, so this is discouraged....
- To reduce CPU overhead when using one of the "Planar" screen modes, it is possible to tell the hardware that writes to 0x4000 - 0x7FFF write to one, two, three or four planes (segments of video memory) at once.
ZXPrism hardware control is done via 16 x 4 bit registers. These are modified by writing to IO port 8E3B. The most significant nibble of the data writen to the port selects which register you are writing to, the least significant nibble is the data to be written to the register.
OUT 8E3B, 0000xxxx - CPU speed control, where xxxx is:
0000 – Slow (3.5MHz) DEFAULT
0001 – Double (7MHz) if supported, else 3.5MHz
0010 – Triple (10.5MHz) if
supported, else 7MHz
0011 – Quadruple speed (14MHz) if
supported, else 10.5MHz
0100 – 6x speed (21MHz) if
supported, else 14MHz
0101 – 8x speed (28 Mhz) if
supported, else 21MHz
. . .
1111 – Fastest supported speed
(currently 21MHz)
OUT 8E3B, 0001xxxx - Misc options
0000 -
xxx1 - Enable Spectrum 48K style video memory contention
xx1x - Allow read/write to port xxFF (enable Timex mode)
x1xx - Enable "Bright Black"
1xxx - Disable 1024K mode/Enable 48K mode lock
Other hardware control registers will be covered in more detail in future posts:
OUT 8E3B, 0010xxxx - Screen resolution, attribute size, enable hardware "gigascreen" mode
OUT 8E3B, 0011xxxx - Screen/Attribute data decode method
OUT 8E3B, 0100xxxx - Colour decode method (hardcoded, ULAplus palette, PRISM palette)
OUT 8E3B, 0101xxxx - CPUside Video Memory Control: Planar mode write options
OUT 8E3B, 01100xxx - CPUside Video Memory Control: segment at 0x4000
OUT 8E3B, 01101xxx - CPUside Video Memory Control: segment at 0x6000
Hope that wets your whistle - more to come at a later date.
No comments:
Post a Comment