Jig-Ulator

Sometimes an RC2014 has just one job. This one is to go Beep Whoop, Beep Beep Whoop, Beep Beep Beep Whoop! whenever a working Why Em-Ulator Sound Module PCB is put on the jig.

Jig-Ulator

Before we get to that, though, lets go back to the start and consider the Why Em-Ulator Sound Module. This is supplied to RC2014 Towers with the surface mount components assembled and the PCBs panelised. The panelisation is needed so that they will go through the assembly process at the fab house. So the first thing to do is remove the rails and separate the pair of boards.

Removing the rails is made easy with a slot cut in to a wooden box. The rails are put in to the slot and a quick bend up and down detaches them from the main PCB. The discarded rails are then collected in the box. Breaking the two PCBs apart is also a simple process.

Next the micro controller needs to be programmed. The PCB has a TC2030 Tag Connect compatible programming header next to the micro controller. The programming cable has spring loaded pogo pins and some locating pins that protrude through the board. To accommodate this, a small jig (Jiglett) is used.

The programmer is a stand alone device which has the flash hex file, eprom hex file and fuse settings for the default Why Em-Ulator settings (YM2149 at 1.7734MHz). Other settings can be programmed manually from a laptop.

For peace of mind that the firmware has been programmed successfully, and that the assembly process was correct, it needs to be tested. This is where the Jig-Ulator comes in.

At the heart of the Jig-Ulator is an RC2014 Micro. This sits in a Backplane 5 with 3 sockets fitted. One of these sockets has a Digital I/O Module for visual feedback and the other has a Rev 5 YM2149 Sound Module with an AY-3-8910 to AY-3-8912 adapter. This adapter carries all the signals (Power, 8 data lines, Reset, BC1 and BDIR) that the Why Em-Ulator needs to operate, as well as the return path for the sound from Channel A, Channel B and Channel C. The sound module is plugged in to a speaker for audio feedback.

At the front of the Jig-Ulator is a bed of nails test jig made from laser cut Perspex and pogo pins. The Perspex holds the pogo pins in place, and the upper layers have an alignment cutout so that the module under test will line up perfectly with the pins. A little bit of pressure ensures that all signals make good contact.

The RC2014 Micro has some very simple test code in ROM that runs on startup and continues indefinitely. This code isn’t elegant. Nor is it particularly efficient. And it certainly isn’t an example of how to write good Z80 assembly code. However, it has one job, test the module, and it does that well.

All of this only takes up a couple hundred bytes of the 8k ROM. It can surely be optimised to take up less space. Alternatively, the calls can be unrolled to take up more space but without needing any RAM for the stack.

            .ORG    $0000 
REG         EQU     $D8 
DAT         EQU     $D0 
START:               
            NOP      
            NOP      
            DI       ; disable interrupts
            LD      hl,$9000 
            LD      sp,hl ; set up stack
            NOP      
;set mixer reg to enable channel A
            LD      a,7 
            OUT     REG,a 
            LD      a,62 
            OUT     DAT,a 
            LD      a,15 
            OUT     0,a ; set DIO lights right

;set channel A to max volume
            LD      a,8 
            OUT     REG,a 
            LD      a,15 
            OUT     DAT,a 

;output 2 note to channel A
            LD      a,0 
            OUT     REG,a 
            LD      a,128 ;low note
            OUT     DAT,a 
            CALL    delay 
            LD      a,255 ;high note
            OUT     DAT,a 
            CALL    delay 

;decremental tone
            LD      a,0 
            OUT     REG,a 
            LD      b,255 
            CALL    ALOOP 

;set mixer reg to enable channel B
            LD      a,7 
            OUT     REG,a 
            LD      a,61 
            OUT     DAT,a 
            LD      a,$F0 
            OUT     0,a ; set DIO lights left

;set channel B to max volume
            LD      a,9 
            OUT     REG,a 
            LD      a,15 
            OUT     DAT,a 

;output 4 note to channel B
            LD      a,2 
            OUT     REG,a 
            LD      a,255 ;low note
            OUT     DAT,a 
            CALL    delay 
            LD      a,128 ;high note
            OUT     DAT,a 
            CALL    delay 
            LD      a,255 ;low note
            OUT     DAT,a 
            CALL    delay 
            LD      a,128 ;high note
            OUT     DAT,a 
;decremental tone
            LD      a,2 
            OUT     REG,a 
            LD      b,255 
            CALL    ALOOP 

;set mixer reg to enable channel C
            LD      a,7 
            OUT     REG,a 
            LD      a,59 
            OUT     DAT,a 
            LD      a,60 
            OUT     0,a ; set DIO lights middle

;set channel C to max volume
            LD      a,10 
            OUT     REG,a 
            LD      a,15 
            OUT     DAT,a 

;output 6 note to channel C
            LD      a,4 
            OUT     REG,a 
            LD      a,128 ;low note
            OUT     DAT,a 
            CALL    delay 
            LD      a,255 ;high note
            OUT     DAT,a 
            CALL    delay 
            LD      a,128 ;low note
            OUT     DAT,a 
            CALL    delay 
            LD      a,255 ;high note
            OUT     DAT,a 
            CALL    delay 
            LD      a,128 ;low note
            OUT     DAT,a 
            CALL    delay 
            LD      a,255 ;high note
            OUT     DAT,a 
;decremental tone
            LD      a,4 
            OUT     REG,a 
            LD      b,255 
            CALL    ALOOP 


;turn sound off
            LD      a,7 
            OUT     REG,a 
            LD      a,63 
            OUT     DAT,a 
            LD      a,0 
            OUT     0,a 
            CALL    DELAY ; wait....
            CALL    DELAY 
            CALL    DELAY 
            CALL    DELAY 
            CALL    DELAY 
            CALL    DELAY 
            CALL    DELAY 
            CALL    DELAY 
            CALL    DELAY 
            CALL    DELAY 
            CALL    DELAY 
            CALL    DELAY 
            JP      START ; and start all over again


            EI       ; enable interrupts
            RET      ; which will never get to. But helpful for debugging RAM based versions of the code
SHORTDELAY:          
            PUSH    hl 
            PUSH    af 
            LD      hl,1000 
            JP      DELLOOP 

DELAY:               
            PUSH    hl 
            PUSH    af 
            LD      hl,$ffff 
DELLOOP:             
            DEC     l 
            JP      nz,DELLOOP 
            DEC     h 
            JP      nz,DELLOOP 
            POP     af 
            POP     hl 
            RET      

ALOOP:               
            LD      a,b 
            OUT     DAT,a 
            CALL    SHORTDELAY 
            DEC     b 
            JP      nz,ALOOP 
            RET      


After starting up, interrupts are disabled and a stack area is defined. Then it makes a Beep-Boob on channel A, whilst turning on the right 4 LEDs on the DIO module, then plays a Whoop noise. It then does this again on Channel B, but with a Beep-Boop-Beep-Boop and illuminating the left 4 LEDs. And finally, it does this again on Channel C, but with a Beep-Boop-Beep-Boop-Beep-Boop and the middle 4 LEDs. Slight pause and back to the start.

The whole thing only takes a few seconds to confirm that everything is working as it should.

The modular nature of the RC2014 Pro, along with the vast array of colours that PCBs are available in these days has made me consider building a kit with all the colours of the Pride flag for quite some time. When it came down to it though, the colour choices were actually too limited. So I could either give up, or make the Pride Flag with the wrong colours… or find another solution.

Skip ahead to the tl;dr section if you want to jump past the theory, testing, and reasoning, and just want to see the process and settings I settled on.

Visit z80kits.com during June 2023 to buy an RC2014 Pro Pride or an RC2014 Zed Pro Pride. They are limited edition and raise money for two great Trans and LGBTIQ charities.

I started to search for different printing techniques and dye sublimation kept on cropping up, but mostly for things like mouse mats, t-shirts and mugs. After looking closer, I wondered if it was possible to use for PCBs. There are a few articles that seem to cover this, but they generally revolve around dye sublimation to make the mask to etch a PCB – and I didn’t want to go down that route! I eventually found an article by Ben Everard in Hackspace magazine which has a proof of concept. That was enough for me to dive deeper.

So What Is Dye Sublimation?

In scientific terms, Sublimation is the transition of a substance directly from a solid state to a gas state. It does not pass through the usual liquid state and only occurs at specific temperatures and pressures. The ink used for the process has this property, however, most inkjet printers cannot use this ink as they have a small heater on the print head. There are two types of printers that can be used for dye sublimation ink; dedicated printers made by Sawgrass which are really expensive, and Epson cheap crappy ones which can be converted. As Epson printers print cold, their print head won’t prematurely vaporise the ink, and conversion kits are available. Cheap and crappy is within my budget, although once the cheap printer is paired with a conversion kit, special ink, special transfer paper and a heat press, it isn’t all that cheap. All in, it was the best part of £500 investment – but I will be able to make my own mouse mats cheaply, so maybe that isn’t too bad!

The heat press is where the magic happens. With the blank (ie mouse mat, t-shirt or PCB) in contact with the ink on the transfer paper, applying pressure and heat will turn the ink in to a vapour that embeds itself in the blank. Once cool, it remains permanently* in the blank.

Initial tests

The article from Ben Everard said that he got his PCB covered entirely in white silkscreen, and it worked. Before ordering any PCBs, I wanted to try things out with some old scrap boards. I used a colourful printer calibration page to see how things came out. Obviously trying to dye blue boards didn’t work out great with the colour, but it was a lot better than I’d expected.

The thing that I was most relieved about was that the dye does not get absorbed by the metal. Yeah, it makes sense when I think about it, but a worry was that I’d have to mask off every component hole or else design the print around the holes and line it up super precisely. But that wasn’t a worry.

Even more important was that I was able to solder to the board and that the dye wasn’t conductive. More testing and things were looking good.

I had a couple of scrap boards with white solder resists, but the colour didn’t seem to work out too great.

Here a real PCB is compared to a printed image of that board on to white solder resist. It has taken the dye, but really not very deeply. To test things properly, I needed some boards specifically for running tests like this. So I ordered some boards each with white solder mask and no silkscreen and some that were totally covered on both sides by silkscreen. (Fun fact: I paid to have the batch number removed on the one with no silkscreen, but I figured there was no need for that one the one which was 100% silkscreen. Turns out I was wrong!).

After exporting the original silkscreen layer from KiCad in to Inkscape I set up some different colours and tried 8 different variations between the two types of board

This confirmed my suspicions that the solder resist only boards had a sharper image, but they didn’t take the colour anywhere near as well as the ones covered entirely with silkscreen. As the entire motivation behind the RC2014 Pride was colour based I now had a plan. 100% silkscreen coverage for the 4 modules that JLCPCB didn’t offer the colours for; Digital I/O (light blue), Compact Flash (pink), Pi Pico VGA (Orange) and ESP8266 Wifi (brown). Of course, for the full pride flag, there should also be a black module too – however, I was able to source all of my ICs in black, so the representation is there!

To make efficient use of the dye sublimation paper and heat press bed size I decided to panelise the boards in a 2×3 grid. The KiKit plugin for KiCad does a great job of this once you’ve dialled your settings in right (Spoiler: I didn’t quite dial them in right, and there’s a very slight lip on the top where the 45 degree and radiused corner meet the top. Sorry)

The original silkscreen layer and edge cuts from the panels was exported from KiCad in to Inkscape. From here I created a new layer above the imported layer and from here I could trace around the PCB shape and make my own artwork for it without being constrained to a single colour, font or any of the KiCad limitations. The Digital I/O module has the best representation of colour use, indicating which LEDs and switches go where. However, every board got its own bit of design flair.

With the printer set to high quality print, slow speed and mirrored, this is then printed to the transfer paper. The PCB panel needs to be aligned very carefully and held down with Kapton tape before going in the heat press, sandwiched between 2 sheets of Teflon. Trial and error on the settings earlier suggested that 180’C and 180 seconds worked best.

Here you can see an unused printed sheet at the top, a used sheet on the left and the dyed PCBs on the right. The colours on the unused transfer sheet are not representative of the final colour, but a .ics (image correction setting) file specifically for this ink and paper combination takes care of this and prints what is needed to get the colour you expect. You can see that some dye is left on the sheet after it has been used. Printing on to more absorbent items like mouse mats or t-shirts there is almost nothing left on the transfer sheet.

When I did the Compact Flash Module though, I encounter two big problems. When I supply the CF Modules I solder the surface mount socket beforehand as some people struggle with the 50 pin fine pitch connector. I use solder paste and a stencil, then a hot plate and hot air to reflow it.

Because the dye does not penetrate the plated pads, I assumed (wrongly) that this would be fine. However, I found it impossible to get the solder paste to stick to the pads. I don’t know exactly why this is, but I assume that the heat press somehow damages the plating. It may work better with ENIG plating, although I haven’t tested this.

I did find that a strip of Kapton tape fixed this problem, although it does add extra cost an labour to each board.

The other problem is heat. Using a MHP30 hot plate at 250’C under the board will leave a white 30x30mm square on the back where the dye has evaporated! Using hot air from above will evaporate the dye too!

The solution I found was to use a combination of a hot plate set to 125’C to pre-warm the board then the hot air only needs to spend a few seconds from above which is enough to flow the solder but only produces minimal evaporation around the socket. It isn’t ideal, but this part is hidden deep inside the RC2014 so isn’t exactly an eyesore!

The Pi Pico and ESP8266 modules are wide pitch surface mount parts, and although these seem to flow just fine with a regular soldering iron, I have played it safe and Kapton Taped over those connections too before going through the dye sub process. It adds quite a bit of time to the process, but feels important.

However, if you were doing a modern PCB with all surface mount parts then I don’t think it is feasible to use dye sublimation. Masking off every pad would be a nightmare, and there’s no way it would survive a reflow oven. So this isn’t a miracle solution that will give everybody gloriously colourful PCBs :-(

Another issue I came across was ghosting of the text. If you look at the first CF socket photo you might spot that the text isn’t too clear, although the lines are fine. The artwork was created in Inkscape on a Linux machine, but due to printer driver issues, I printed from Inkscape on a Windows laptop. I’m not exactly sure, but I suspect that there’s some kind of font incompatibility between the two machines. The workaround for this is to export as a PDF on the Linux machine with the “Convert Text To Path” option set. This PDF can then be printed from the laptop from Inkscape and the text is fine. I think this is just an issue with my setup and not anything inherently wrong with dye sublimation.

tl;dr Here’s How _I_ do it

  • Design the PCB in KiCad as normal, then cover the front and back with a filled in rectangle of silkscreen. Send this to JLCPCB to have the boards made
  • Remove the rectangles and export the front and back silkscreen layers with edgecuts to PDF file
  • Import the PDFs in to Inkscape. Add another layer above and use this to trace your board edge, component layout and text as you wish. Different fonts and colours and images can all be added here if required.
  • I exported this to another PDF then used Inkscape on a different machine to print this (this should be a redundant step though). Printed using high quality setting, mirrored and with fast mode turned off. Separate pages are printed for the front and back of the board.
  • Epson W2010 wireless printer has been converted to dye sub printing with a kit from City Ink Express, using their ink and paper
  • The white PCBs are prepared with Kapton tape over surface mount pads. Then the board is laid over the back image, aligned very carefully and held in place with Kapton tape.
  • The pre-heated heat press is set to 180’C. The PCB is set face down with the printed page on top, and a sheet of Teflon over the top. This is then pressed for 3 minutes then removed.
  • When cool, the PCB is removed from paper, flipped over and attached to the front image sheet and the heat process is repeated.

Problems and lilmitations

Whilst this offers a lot of possibilities with PCB design, it is far from perfect. Firstly is the upfront cost of the equipment needed to print and transfer the design. It is a very labour intensive process which uses specialised ink and paper, so these costs need to be taking in to account too. Alignment needs to be accurate too (unless you have a design that doesn’t need to be aligned). The image is not pin sharp, and there is a certain amount of feathering around edges due to the silkscreen, so fine details may not work too well. And lastly, the surface mount limitation is going to make it a non-starter for a lot of projects. But, with all those points in mind, if it works for you, the possibilities are endless.

Retro Challenge 2017/10 Getting Started

So, the idea of streaming the RC2014 to the internet had been rattling around in my head for a while, but I’d never quite worked out how the software side of things would work.  Although the hardware side should be kind of straightforward, with my software skills, I need to find something I can copy & paste.  A couple of days ago I just happened to put the right search terms in to Google and it gave a result that looked like it would do want I wanted.  So, with that, my plan for Retro Challenge took shape!

A couple of years ago I played around with some EPS8266 Wifi Modules, but never really found a use for them.  However, for this, they would be ideal.  The code I had found was a Web Sockets Serial Monitor designed specifically to run on an ESP8266, so I decided to test it out just to check that it did what I expected it would.

Several hours later, it did!  Those hours, however, were spent trying to remember how to program these things.  My desktop machine didn’t have any of the ESP stuff in the Arduino IDE, but luckily, I still have my old laptop that I used a couple of years ago.  Despite getting all the right libraries, it just wouldn’t compile.  So, on to the new laptop, with a fresh Arduino IDE and all the ESP stuff and libraries, and it compiles.  Getting it to upload, however, was another challenge which actually involved burning myself on the USB to serial adapter at one point!  It turns out that of the two I tried, one of them was dead, and the other one spammed my Twitter account ever time it’s turned on (I didn’t know this until checking Twitter later… what!  86 new mentions!).  It also turns out they need more power than the adapter can supply.  And, in order to program them, the ESP needs to be pushed in to the adapter really really really hard!

The programming jig wasn’t really suitable for testing things out, so time to transfer this to a prototype board.  But first, lets work out a circuit!  The programming jig has the necessary support components and minimal connections, so that’s a good start.  The ESP works on 3v3, so I’m going to need a regulator to drop the 5v down.  And the Rx pin is only 3v3 tolerant, so a couple of resistors as a voltage divider will work fine as a level shift here.  The Tx pin won’t be connecting to the RC2014, although even if it was needed, 3v3 is sufficient enough to work.  GPIO0 is used to either put the ESP in to programming mode or run mode.  2 of the other GPIO pins (15 and 2) were tide to ground and 3v3 respectively on the programming jig.  I can’t remember why I did that, but that won’t be needed for this board.

Before hooking up the ESP to the power rails, I checked that the regulator I used (spare one I had lying around) did it’s job.  Yup, 3.299v, close enough!  On with adding the rest of the stuff.

So, from left to right, we’ve got a connector for 3v3 so it can be powered directly if needed (or use 3v3 elsewhere), and an FTDI header for my 3v3 adapter so the ESP can be reprogrammed.  Then there’s a reset button, the 3v3 regulator and caps, then the ESP itself.  There’s a 10k pull up resistor on the reset pin, and a program/run jumper below the ESP.  As yet, the resistor divider for the Rx pin aren’t fitted.  But it should power up and work just as it did in the jig, right?

Ummm… no.  Regardless if I used the power regulator, or fed 3v3 in directly, out of the serial header all I got was gibberish.  It was consistent gibberish, but not something I could make any sense of.  Maybe I damaged the ESP when soldering the wires on?  Hmmmm… maybe I should program another one just in case.  Well, long story short, it needs GPIO15 connected to ground to work!  I can’t see any logic why this would need to be the case, but, whatever, it works now.

I needed to add a rule on the firewall to allow port 81 through to the IP address of the ESP, and after that, I could connect from the outside world and see what my RC2014 was saying!

Things work pretty well, although there’s some kind of issue with carriage returns and/or linefeeds that’s causing some stuff to be dropped, but that’s enough success for one day.  We’ll sort that out tomorrow!

Decoding ROM labels

Back in the earliest days of the RC2014, it came with a pre-programmed 27C512 64k ROM, with Microsoft BASIC on it in the first 8k, and it would work with 32k of RAM and a 68B50 ACIA.  One set up, one ROM, life was simple!

As time has gone on, and more options have become available, other ROM images, such as Microsoft BASIC for 56k RAM, CP/M Monitor, RomWBW and Small Computer Monitor have been introduced.  See this page for a brief overview of each option

Future possibilities, such as other UARTs, different CPUs or other variations will inevitably lead to more ROM images being needed.  So, in order to keep track of what is programmed where, ROMs are now being shipped out with a label on them.

27C512 64k ROM

Every 64k ROM now has an 8 digit code on it.  Each digit, from left to right, refers to an 8k bank from 0x0000 to 0xD000.  This bank can be selected with the A13, A14, A15 jumpers;

AddressA15A14A13ROM Label
0000000 Xooooooo
2000001 oXoooooo
4000010 ooXooooo
6000011 oooXoooo
8000100 ooooXooo
A000101 oooooXoo
C000110 ooooooXo
E000111 oooooooX

The value of the digit represents the ROM image that sits in that particular 8k bank.  Currently, it will be one of the following;

0 – Empty bank, available for user to program

R – Microsoft BASIC, for 32k RAM, 68B50 ACIA, with origin 0x0000

K – Microsoft BASIC, for 56k RAM, 68B50 ACIA, with origin 0x0000

1 – CP/M Monitor, for pageable ROM, 64k RAM, 68B50 ACIA, CF Module at 0x10, with origin at 0x0000

2 – Microsoft BASIC, for 32k RAM, SIO/2, with origin 0x0000

4 – Microsoft BASIC, for 56k RAM, SIO/2, with origin 0x0000

6 – CP/M Monitor, for pageable ROM, 64k RAM, SIO/2, CF Module at 0x10, with origin at 0x0000

88 – Small Computer Monitor for pageable ROM, 64k RAM, SIO/2 or 68B50 ACIA, with Microsoft BASIC and CP/M boot options [Note that this is a 16k image, so Page Size needs to be set to 16k and only A14 and A15 jumpers to select]

9 – Small Computer Monitor for any ROM, any RAM, any UART

Mini II

To further complicate things, the Mini II ships with an ST39SF010 – a 128k Flash RAM which is divided up in to 8 x 16k pages, or 16 x 8k pages, or some combination of those. There are different options for BASIC, SCM CP/M and also FORTH.

Chips are labelled as “M2 1.2”

ST39SF040 512k RomWBW 2.9.1

Version 2.9.1 of RomWBW needed to be compiled differently, based on what peripherals were to be supported.  To indicate which peripherals the ROM had support for, the designation of x.512K is used, where x is the software designation.

1.512k – RomWBW RC_Std.ROM 2.9.0

2.512k – RomWBW RC_Std.ROM 2.9.0 With PPIDE

3.512k – RomWBW RC_Std.ROM 2.9.0 With RTC

4.512k – RomWBW RC_Std.ROM 2.9.0 With PPIDE and RTC

5.512k – RomWBW RC_Std.ROM 2.9.0 With WDC Floppy

6.512k – RomWBW RC_Std.ROM 2.9.0 With WDC Floppy and PPIDE

7.512k – RomWBW RC_Std.ROM 2.9.0 With WDC Floppy and RTC

8.512k – RomWBW RC_Std.ROM 2.9.0 With WDC Floppy, PPIDE and RTC

ST39SF040 512k RomWBW 3.0 onwards

Since the release of RomWBW 3.0.0, peripherals are automatically detected, so there is no need for different builds.  Therefore the label will just indicate the revision programmed.  At the time of writing, as indicated above, the latest stable release is 3.0.2

As more ROM images are added, this list will be updated.

Standard factory ROM images can be downloaded from Github https://github.com/RC2014Z80/RC2014/tree/master/ROMs/Factory

Note that despite having total control over which designation I want to use for whichever ROM image and where that is located on the ROM – I still managed to pick a combination that my label gun was unable to do!  So some people will have a label that starts with an interlocking “n” and “u” character, which is the closest I could do to represent a “2”.  If this is the case, your “¬4006000” is actually “24006000”.  In order to get around this, I have now bought an extra 2 label guns, which have been dismantled to allow the belts to be swapped around, and reassembled.  Normally reassembly of label guns is only possible by a highly skilled and qualified octupus, so I don’t recommend anybody tries doing this themselves!

Iterations of a SD Module

From the very earliest days of the RC2014, back when the whole thing was a bunch of wires and chips on a breadboard and before the RC2014 even had a name I knew that it needed some kind of storage.  The obvious solution to me was via SD card.  I had already made a simple PS2 keyboard and 4 line LCD display interface from an Atmel ATMEGA328, and it was easy enough to add an SD card interface.  The ‘328 was connected to the yet to be named RC2014 via serial, so anything I could type on the keyboard could be passed through to the RC2014.  Likewise, the contents of a text file on the SD card could also be put on the serial port.  Intercepting keystrokes like F1 would send the text file 1.bas to the RC2014.

It kind of worked, but was clunky at best.  The text files had to be created on a PC as there was no way to save anything – although I thought about monitoring the keyboard for SAVE to be typed which would be replaced by LIST and the stream coming back would be saved to SD.  But that was even more clunky and hacky.

Once the RC2014 appeared in PCB form, I returned to the idea of an SD card storage device.  This time it was to load raw machine code from SD to RAM – again, via an ATMEGA328 but this time connected via a Z80 port (Essentially, the same circuit as the Digital I/O Module)

The idea here would be a simple bootloader ROM would run on the RC2014.  This would set one of the bits of port 0 high so the ‘328 would know to load the first byte from a file on the SD card on to the data bus.  Once the Z80 had loaded this in to RAM it would toggle the bit and the next byte would be read until the whole file was loaded.

Although this worked, it wasn’t a solution I was particularly happy with.  The main reason was that it had very limited functionality and relied on a custom ROM image.

What I wanted was a way to fill the RAM without worrying about what’s in the ROM (or even having a ROM), and bypassing the Z80.  An old idea that I had for making an EPROM burner was recycled in the form of this prototype;

This used a couple of 74LS393 counters connected to the address bus via 74LS245 to count from 0 to 65535 (ie the whole Z80 memory address space).  A bus request (BUSRQ) from the ‘328 asked the Z80 to disconnect itself from the bus.  When this is acknowledged (BUSACK) the ‘245s have control of the bus and can increment the address from a pulse from the ‘328.  The prototype proved the concept worked, so time to spin up a simple board to take things further.

The first spin of the board was focused on the Z80 interface with the SD pins and any spare GPIO pins from the ‘328 bought out to headers.  I still hadn’t decided yet how the SD card would actually be fitted.  Every SD card socket I could find was surface mount, and if this was to be made in to a kit, I wanted to avoid surface mount components if possible.

The next spin of the board refined more of the control circuitry.  The spare GPIO pins had been connected to switches, LEDs and some of the bus lines.  Not everything quite worked as planned, as the subtle bodge wires allude to.  In hindsight, using black solder resist for a prototype board wasn’t such a great idea either.  However, I got it to work and was able to get the firmware on the ‘328 doing what I wanted it to do.

I had been using a cheap Chinese SD module to connect the ‘328 to an SD card, and these actually work very well as well as being a kind of standard, so to get around the surface mount issue, I decided to use the whole module in the finished product.  Oh, and as you can see, there really isn’t much spare PCB space for an SD card socket either!

With a bit of swapping around, I managed to free up an analog GPIO pin that I could connect to a potentiometer.  This works as a crude file selector.  The initial firmware I wrote for the ‘328 works, and loads an image from SD card in to RAM, or dumps the whole contents of memory in to a file on the SD card.  Scott Lawrence has updated this to give access to different file images and protects these against accidental overwriting.

So far, this is the best SD card storage for the RC2014 that I’ve made.  I wanted to share this though to give you an idea of how a new module is created, from conception, through prototypes and to final product.

Retro Challenge 2016 – My Dog Ate My Homework

So, all the way back in deepest darkest December, I announced I would enter the Retro Challenge 2016 competition that ran throughout January.  Those of you that followed by blog or Twitter account when I did this in 2014 will know that I blogged and Tweeted relentlessly for the whole month, but, this time around, almost nothing.  Obviously, I’m keeping some secret about an amazing breakthrough or something, right?  Well, truth is, I’ve done almost nothing.

Things started well, and on 1st January, I designed a new backplane for the RC2014.  Although I hadn’t studied the circuit diagrams for the ZX81, Jupiter Ace or ZX Spectrum yet, I knew that there were resistiors between the Z80 CPU and other devices.  The stripboard backplane I’d been using had served me well, but it was time to progress to a better solution, and one that could be adapted better to my needs.  Knowing that PCB delivery times could be against me, I thought it best to crack on and get this  ordered.

Screenshot from 2016-01-31 16:01:00

The basic circuit is very very simple – however, I wanted to get this just right, not only for Retro Challenge 2016, but for other possible RC2014 uses.  Essentially, there are 8 40 way connectors that are linked straight through – however, the data lines and address lines for the leftmost 2 connectors and rightmost 2 connectors are separated by a pair of pads.  These can either be shorted together for up to 8 commoned connectors, or have resistors soldered across them.  I also added a power connector and the option of either running 5v directly in to the board, or regulating a higher voltage down via a LM7805.

(more…)

HDMI and USB Keyboard Support

So, the RC2014 is a great little computer.  We all know that.  However, to communicate with it, it is easiest to use the serial port and hook it up to a laptop or desktop PC.  This makes detracts from the fact that it is small, portable and cheap as well as missing the point of running code on such a basic computer.  So I’ve been looking for a solution to this.

Back when this was still running on a breadboard, I hooked up an Atmel ‘328 that was connected to a keyboard and 4 x 20 LCD display.  It communicated with the RC2014 over the serial port and kind of worked ok, although 4 lines was very restrictive and the Atmel couldn’t really keep the screen running and listening at the same time.   I have thought about using a ‘328 to drive a composite output, or maybe some kind of bigger LCD panel, but nothing really struck me as just right.

That is, until the kind people at Raspberry Pi released a cheap multifunction interface device a couple of weeks ago!

2015-12-18 22.13.44

(more…)

Retro Challenge January 2016 – Preamble

So, you may well remember that I entered Retro Challenge 18 months ago, and what a fun crazy busy time that was!  Well, the January Retro Challenge competition is about to kick off in just over 2 weeks.

If you’re not familiar with Retro Challenge, shame on you!  But you can de-shame yourself by heading over to http://www.retrochallenge.org/ and seeing what it’s all about.  Essentially, it’s a month long bi-annual competition where the entrants set themselves a goal based around old school computing and blog, tweet and share their experiences.  The goals are pretty loose, as long as they are based on something from last centuary (modern emulators of old kit is fine).

The challenge I set myself was to take a breadboard based Z80 computer and bring it to life in modular PCB form in such a way that I could spell out my name on.  Have a look back through my blog to see how I did.  Spoiler —->

IMG_20140730_205950

(more…)

RC2014 SD Bootloader Update

Just a quick update to about the SD Bootloader I designed a few posts ago.  Well, the PCBs have arrived and last week I took a soldering iron to one of them and gave it a quick test

One side of the board is effectively an Arduino, so without plugging it in to the RC2014, I connected up an FTDI lead and uploaded the Arduino Blink sketch.  A quick check with a multimeter and one of the pins was altenating between 5v and 0v.  So far, all good! (more…)

RC2014 Bootloader for SD Cards

So, the RC2014 is great.  I can run Microsoft BASIC and program it from there, and as long as I am using a terminal emulator, I can copy & paste to save and load programs.  Alternatively, I can write Z80 code using an online compiler then download it, copy it to USB stick, move it to my old Windows 2000 laptop (which has a parallel port) so I can burn it on to EPROM to see if it works, make adjustments and repeat with another EPROM.

I will be the first to admit, however, that this is probably not the most efficient workflow.  Not to mention the time and effort involved in wiping the limited stock of aged EPROMS.

So, I am in the process of designing an SD Card based bootloader.

i (2)

(more…)