ZX Spectrum Games on the RC2014

[Sir Isaac]

This might seem like a really dumb question. What would it take to run ZX Spectrum games on the RC2014?

I'm eagerly waiting on my RC2014 in the mail and researching projects to work on.

[Kipper Klank]

In ZX Spectrum ROM games there's a lot of information in there that has to do with video processing and screen refresh rates. sadly there's not much video processing in the RC 2014 at the moment.

Here's a kit that is basically a completely faithful reproduction of the ZX Spectrum. ( except that it uses composite out instead of radio frequency.)

https://www.tindie.com/products/tynemouthsw/minstrel-zx80-clone/?pt=full_prod_search

If you look at how this thing is put together and the integrated circuits being used, you could possibly use what materials you have already of the RC 2014 and work from there.

Point being ROMs for a ZX Spectrum are very specific about the architecture of the computer itself if it's not exactly the same it probably won't work

[Kipper Klank]

Someone please correct me on any mistakes I have made for the sake of legitimacy!

*I'm still learning aka a noob*

[Spencer Owen]

Just to clarify;

On 4 March 2017 at 18:30, Kipper Klank <delph...@gmail.com> wrote:

In ZX Spectrum ROM games there's a lot of information in there that has to do with video processing and screen refresh rates. sadly there's not much video processing in the RC 2014 at the moment.

With the exception of about 10 games, ZX Spectrum games are loaded from tape in to RAM, not ROM 

Here's a kit that is basically a completely faithful reproduction of the ZX Spectrum. ( except that it uses composite out instead of radio frequency.)

https://www.tindie.com/products/tynemouthsw/minstrel-zx80-clone/?pt=full_prod_search

That is not a ZX Spectrum.  It's a ZX80.  The clue is in the name.  They are different machines and a game from one will not load on the other. 

If you look at how this thing is put together and the integrated circuits being used, you could possibly use what materials you have already of the RC 2014 and work from there.

Yeah, the CPU is the same.  That's about it. 

Point being ROMs for a ZX Spectrum are very specific about the architecture of the computer itself if it's not exactly the same it probably won't work

Fundamentally, though, the answer about the video processing being different is close.  The rest of the architecture, such as keyboard interaction, memory allocation, sound, and the specific ZX Spectrum ROM are different between that and an RC2014.  However, the CPU is the same, so any raw machine code written for the Spectrum will run on the RC2014 - although if it behaves the same will depend if it relies on the Spectrum hardware or not.  Also, the Spectrum has Sinclair BASIC in ROM, and the RC2014 has Microsoft BASIC in ROM.  These are fundamentally a similar thing, so if there are BASIC programs in a magazine listing, for example, they will probably work or can be adapted to work on a RC2014 - although, again, the caveat about relying on Spectrum hardware stands.  

So, if your goal is to play Manic Miner on your RC2014 then you are sadly out of luck.  But if you want to run simple machine code routines or BASIC programs for the Spectrum on your RC2014 then you stand a fair chance.

Hope that helps :-)

Spencer

[Kipper Klank]

One word, ZORK.

[Sir Isaac]

Awesome, Thanks for such quick replies. I figured the video processing would be one of the biggest issues.  Are there any plans for implementing video processing of any kind?  

[A A]

On Saturday, March 4, 2017 at 11:30:08 AM UTC-7, Kipper Klank wrote:

Point being ROMs for a ZX Spectrum are very specific about the architecture of the computer itself if it's not exactly the same it probably won't work

If you want to run actual spectrum games you will have to match the spectrum display hardware exactly or as a subset of whatever the complete project is.

The spectrum's display is really simple.  The display file that holds pixel and colour information is mapped into the cpu's memory space so that the z80 can read and write directly to it with fast instructions.  The device that generates the picture reads the same memory area simultaneously as the picture is drawn.  Arbitration is performed by giving the display device priority over the z80 and pausing the z80 whenever there is a conflict.

The good thing about having a display file in the cpu's memory space is that this is the fastest way for the z80 to manipulate the display.  The bad thing is a region of memory can't be used for programs or data so you have < 64k available.  Someone may opt to have several memory banks available in which case the display file can be put in a bank so that the z80 can swap it in whenever it wants to.

Other possibilities are using some sort of graphics chip to do the display.  In the 80s one widely available one was the TMS9918 series as used in the msx, sega master system and a number of other systems.  It owns the display file which is not directly accessible to the cpu which is good in that the cpu can have the whole 64k.  It's bad in that the cpu can no longer quickly update the display file itself.  Instead you have to rely on the 9918 functions to do what needs to be done quickly.  This difference in games can be seen in the spectrum and msx, eg.  The spectrum has a number of titles that scroll smoothly where the msx does not as the msx cannot push enough data to do the same thing.  Conversely, the spectrum display file had to be smaller so that the cpu was fast enough to do this which reduced colour resolution relative to the msx.

Philip mentioned another more modern solution which I hadn't looked at before.  It's a few posts back.  This is a graphics processor where again the z80 does not have direct access to the display memory but the graphics processor is structured like an OpenGL implementation with 3d graphics & transformations and whatnot so it is possible to do a lot more than what the z80 could do at 7MHz with direct display file access.

I'll mention that z88dk contains a number of game engines that do software sprites for memory mapped display files.  It might be possible to adapt at least one of them to a hypothetical memory mapped display on the rc2014.

[Kipper Klank]

[Samster]

I recently noticed the surface mount ZX Spectrum Z80/SRAM and ULA replacement modules on eBay and it made me wonder what other components/logic would be needed to make a "Trigger's broom" Spectrum. I figured I could try a similar exercise using RC2014 stock modules and found a few projects to bring together a minimal implementation that will LOAD "" and play a game. There’s an additional challenge of no longer owning a display that supports component, SCART or VGA, but that turned out to make things simpler by combining a couple of projects into the same CPLD.

RC2014 modules:

• Z80 CPU v2.1 [https://rc2014.co.uk/modules/z80-cpu-v2-1/]
  
• 64k RAM [https://rc2014.co.uk/modules/64k-ram/]
  
  • Start address 0x4000, lower 16K not accessible
  • link in place
• Pageable ROM [https://rc2014.co.uk/modules/pageable-rom/]
  
  • ZX Spectrum ROM in page 0
  • 16K window jumpers selected
  • paging defeated by bending RC2014 /IORQ bus pin up and linking with flying lead to 5V on P5 to avoid conflict with Spectrum ROM reserving all even I/O addresses
  • should also work with original 23128 ROM by setting A14 low and other address jumpers as open circuit
• Backplane [https://oshwlab.com/peabody1929/RC2014_8_Slot_DAAS_Backplane_copy-4eaf06ffcc754b45afdb8c4136407840]
  
  • no special requirements for the backplane choice, but I find Tom Szolyga's 8 slot DAAS useful for prototyping due to inter car spacing, reset button and power supply connector options
  • I've assembled a couple of these backplanes with the row adjacent to the bus labels as pins (instead of sockets) for convenience of attaching probes/breadboard. At one point I had RC2014 Z80 cards in one backplane and a RPI2 driving the bus in another via GPIO to generate test patterns

ZX Spectrum projects raided for snippets to combine onto single PCB:

• TK Pie [https://gitlab.com/victor.trucco/TK-Pie]
  
  • Operates similar to Busraider but the RPI Zero only sniffs the VRAM and border bit of I/O port and copies immediately to its framebuffer
  • Implemented on ATF10508 CPLD using Quartus 3.01sp1/pof2jed/ATMISP toolset
  • CPLD powered by 5V but with 3.3V VCCIO logic levels to protect RPI GPIO
  • RPI Zero USB power supply seems capable of supplying both 5V for all RC2014 cards and 3.3V to CPLD via header pins despite doubts on the RPI forum about the current the onboard voltage regulators can provide. I should probably attempt to measure.
  • Whilst he RPI code is straightforward to compile it seems to be targeted for the original zero (tested on Zero v1.2/1.3). My original Pi (non-plus) doesn't have enough GPIO pins and I guess the Broadcom I/O ports may have changed in Pi2/Pi3 as they failed to boot. I don't have a Zero W or A+/B+ to test (I expect those to work), but decided to leave the RPI binary unchanged to aid debugging.
• Verilog ULA [https://github.com/freecores/zx_ula/blob/master/cpld_version/rtl/ula.v]
  
  •  Stripped down ULA to the minimum required capabilities:
  •  Clock divider
  • IRQ generation (based on Vertical and Horizontal video counters)
  • ear/speaker/speaker bits of Spectrum I/O port
•  RC2014 Clock [https://rc2014.co.uk/modules/retired/clock/]
  •  Standard 74HCT04 based circuit using 14 MHz crystal
  • Crystal speed becoming scarce so turned pin socket used instead of soldering
  • Z80 tolerant of 3.3V for all pins except clock, so 3.5MHz 3.3V CPLD output routed into spare 74HCT04 inverter to convert back to 5V levels.
• Reset switch [https://spectrumforeveryone.com/wp-content/uploads/2017/08/ZXSpectrumIssue6a-Schematics.gif]
  
  • Used the RC values from the issue 6a schematic which has an optional reset switch
  • RPI Zero takes longer to boot than Z80 so a hard reset is usually required after power up
• Keyboard interface [http://www.zxdesign.info/docs/interfaces-1.15.pdf]
  
  • Harlequin pull ups and diodes
• Keyboard [https://www.pcbway.com/project/shareproject/ZX_Spectrum_Keyboard.html]
  
  • Superfo mechanical keyboard
  • took a while match row pin order to address lines
• Speaker [http://www.zxdesign.info/docs/interfaces-1.15.pdf]
  
  • Emitter follower circuit (Q7) from Harlequin. I used a 2N3904 and the same resistor divider values which still seem to work ok with 3.3V CPLD logic levels. Line out to the left channel of amplifier/loudspeaker
• Ear [http://projectavr.com/TZXDuino/TZXDuino_Compact_v1.01.pdf]
  
  • TZXDuino Compact output is not buffered so the ATMEGA32 drives the "ear" input on the CPLD directly.
  • I OR'd the ear signal into the speaker signal in the CPLD which makes the TZXDuino screeching audible whilst loading a game, the Harlequin does this in the audio circuitry.

I used an ATF15XX-DK3-U dev board to prototype but this had a few quirks like random keypresses and noisy clock signal (used an 74HC393 clock divider as per stock Dual Clock card as a reference). However, all were resolved when the circuit was laid out onto PCB. 

 

I saved some routing effort by paying five dollars more for a 4 layer PBC which is first time I've used more than double sided. I left routing the decoupling capacitors to last so switched their footprints to 0805 surface mount to avoid rerouting existing traces. This was also my first attempt at soldering SMD components. It's not immediately obvious if decoupling capacitors are working or not but I'm going to assume it was successful even if not the neatest job.

Possible improvements/changes on next revision:

• Make more use of SMT assembly service - one surface of PCB can be populated cheaply with SMT "Basic Components" - seems limited to capacitors/resistors, each semiconductors/connecter part attracts a fee for an operator to change reels on the assembly machine
  
• 2 layer board - CPLD pin choice can better optimise for routing the GPIO and RC2014 headers but this depends on their relative placements on the board, so not something I wanted to invest time on if the first revision was flawed. The JTAG connector is the most inconvenient component - it might be better placed on the reverse side in the centre of the CPLD as an SMD, or just omitted altogether and assume the CPLD is programmed externally
  
• Supervisory circuit IC (which supports a switch) for reset, e.g. DS1813, replaces RC circuit
  
• CPU VRAM contention wait logic - VRAM access timing is not accurate to ZX Spectrum ULA. Currently clock is not suspended and rainbow graphics programs will not run as intended - should be straightforward to re-instate the ULA Verilog
  
• Kempston joystick port - seems a trivial addition since both address and data bus are routed to CPLD, however there may insufficient pins to keep JTAG interface. An octal buffer IC be used as that would only need a single CPLD output pin to its drive output enable.
  

Features that would take more effort:

• RPI Zero could also sniff the speaker bit in the Spectrum I/O port to play audio on the TV speakers - however the audio interface over HDMI seems non-trivial, especially for a bare metal implementation
  
• Some kind of SAVE mechanism, a direct serial line from the CPLD instead of audio circuitry
  
• interface to interface 2 ROM cartridges
  
• DVI interface to replace RPI Zero - I've no idea how complex this would be, but expect it would require an FPGA (apparently this is easy according to https://www.fpga4fun.com/HDMI.html)
  

[Spencer Owen]

That is awesome! I love it!

Spencer 

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/b64f563b-27c4-4966-88a7-e508062cd8fcn%40googlegroups.com.