-

Retro Challenge 2024/10 – Schrödinger’s PCB

The ZX81 Module I designed in 2016 has been an example of Schrödinger’s PCB. It has sat around for 8 years in both a state of working and not working. Only when it is observed will the actual state be determined. In this wrap up post we will finally plug it in and find out.

The first step was to finish assembling the board. If you remember back to the start of the month, or indeed 2016, you will have noticed that the PCB was partially assembled with 4 resistors, 2 transistors, crystal, chip socket and header pins. All the values are now on the schematic, so building up the rest of it was straightforward. I don’t know why 2016-Me only fitted 2 of the transistors. They are all the same value and I have a strip of 50 of them. I did find an error with the footprint I used for the composite jack, but this was easily fixed by turning it 90 degrees.

I burned a ROM with the first 8k duplicated in to the second 8k bank. Sadly my pricing gun that I use for ROM labels doesn’t have a Z, so it’ll have to be a 2X81 now :-)

The next big dilemma was about the current limiting resistors – the green blocks on this diagram.

My understanding of what they are for is that they protect the components if there are conflicting values put on the bus. For example, if the Z80 was doing a write with 0xFF on the data bus, and at the same time the ROM was doing a write and put 0xFE on the bus. This situation should never happen, however, if it did, the D0 pin on the Z80 would be 5v and the D0 pin on the ROM would be 0v, so current would flow from the CPU to the ROM faster than the CPU could source it or the ROM could sink it. Having resistors in there will limit the current, and potentially save the parts.

The logic in a stock RC2014 means that there can only be one device writing to the address or data bus at any one time, so this kind of situation couldn’t crop up. However, with something like the original SD Memory Dump Module, the AVR chip was under software control. So any screwup on the software side could mean that both the AVR and another device could write to the bus. So current limiting resistors were important for that.

The ZX81 schematic confused me though. The CPU and RAM sat on one side of the address bus resistors with the ULA and ROM on the other side. But the CPU and ULA were on one side of the data bus resistors with the ROM and RAM on the other side. I do not fully understand exactly what the ULA does, but the implication is that it could mess with either bus in some way. The RC2014 backplane certainly doesn’t allow for that combination of modules with resistors between them. Rightly or wrongly, I decided to separate the ULA from the ROM, RAM and CUP via resistors.

Rather than solder a load of resistors to the backplane though, I put header pins on there and then used sockets with badly soldered surface mount resistors on them. That way I could swap them out or replace them with jumpers if necessary.

So, finally I had a completed module, a programmed ROM, backplane with resistors on it, and no more excuses for not powering it up.

So I did….

And…

Nothing.

Well, nothing with a combination of heat from the ULA. That is probably not good. I only powered it up for a few seconds, but it clearly got hotter than it should. So rather than risk doing any damage, I decided to go back to the schematics and look closely at everything on my module compared to the original ZX81 schematic.

It didn’t take long before I found a discrepancy. The transistor at the top has the emitter connected to the NMI signal on the ZX81, but my module had it connected to the WR signal. I don’t know exactly what the effect of this would be, but I know it isn’t going to give the desired outcome!

Luckily the fix isn’t too difficult. One track needs to be cut, and a wire needs to be added.

So, with that fixed, everything should power up just fine, right? Right? Sadly, no.

The ULA didn’t get hot, though. So that was definitely better. There was also a regular pulse on the composite output that looks a lot like a line sync signal. But there is nothing else.

Time to look closer at what I did in 2016. Whilst there were very few components soldered on to the PCB back then, 2024-Me assumed that those were at least correct. Which turned out to be a mistake! The ZX81 uses a 6.5MHz crystal. However, I had soldered a 7.3MHz crystal on to the board. Why? I really have no idea. I also have no 6.5MHz crystals either. The closest I have is 6MHz.

As video signal is derived from the crystal, the value has to be pretty accurate. Without the right crystal this is never going to generate a white screen with a happy little K cursor in the bottom corner. However, a poke around the data and address lines makes it look to me like the rest of the computer isn’t running either. So even with a picture being generated, I doubt it would include a K cursor on it.

Schrödinger’s PCB has finally been observed, and it is currently not working :-(

Why? I do not know. There are several aspects that might be playing a part. So for Retro Challenge 2025 I will certainly need to address these

  • 6.5MHz crystal needs to be obtained
  • ULA needs to be checked. I don’t think the few seconds where it got hot killed it, but I cannot assume that it is totally undamaged.
  • Limiting resistors need to be understood better
  • Shadow copies of the ROM might need to be in the upper memory. I don’t think this is necessary, but it is a deviation from the original ZX81 design.

My decision in 2016 to base my module on a ZX81 because of the simplicity of a ULA might be flawed. In hindsight, the ZX80 might have been a much better place to start. There are a lot more chips in that design, but they are all regular 74 series logic, and each part of the circuit can be broken down and understood. That will demystify the Black Box of the ULA at least. I will leave it down to 2025-Me to decide if he wants to carry on with this module, or start afresh with the ZX80 schematic.

-

Retro Challenge 2024/10 – Defeating The Riddler

The schematic for the ZX81 Module I designed in2016 had been designed in a very old version of KiCad, and hadn’t survived all the upgrades too well. This resulted in every component being replaced by a question mark in a box. Luckily I had some photos of the schematic from previous Retro Challenge posts, as well as an expectation as to what should be resistors or capacitors or whatever.

Things now look much better, and actually make some kind of sense.

2016 Me didn’t consider the importance of putting component values on the schematic. Or the PCB. My module was based on the original ZX81 schematic though, so it was pretty much a case of matching up components and updating their values.

The observant amongst you will notice that the ZX81 schematic has a lot more stuff on it than my module. These changes can be categorised in three ways;

  • Components which the RC2014 already have, such as the Z80 CPU, ROM or RAM
  • Components which need to be added, but are not part of the module, such as the keyboard or data/address bus resistors
  • Components which will not need to be included, such as the TV modulator including the USA/French options, or power regulation.

In addition, I noticed my module design had some extra components that were not part of the ZX81 schematic.

More specifically, this is a transistor and resistor. This actually matches the composite mod that the donor machine had. So, well done 2016 me for thinking ahead and including this!

Something which is a bit more concerning though is the way that the keyboard lines all seem to be shorted against the TV Out netlist. I think this might be an artifact of the schematic rescue, as I am sure that 2016 Me would have noticed that. However, I still need to test the PCB in case this fault has made its way through to the board.

So, with a donor ULA, and all the component values, I have everything I need to finish the module. There are other important things that I need to do to the RC2014 though. Firstly, I need to burn a ROM.

You may remember from a recent post that I did a partial ROM dump from the donor machine. This was a simple BASIC program

10 FOR F=1 TO 200
20 PRINT PEEK F;
30 NEXT F

I remember reading that the ROM chips used on old machines were almost, but not identical pin out to the 27C EPROM chips, and that it was a couple of data pins which were swapped over. Or something like that. So my worry was that, for example, D3 and D7 on every byte was swapped. So if I could compare the first 200 bytes or so then I would know if everything matched, or if the difference was consistent.

Luckily, everything matched with the ZX81.ROM file I have.

Although converting decimal to hex becomes less and less fun as you go. But at least I know that I should be able to just burn that image to a ROM and it *should* work.

The memory map on a ZX81 is a ZX81 is interesting. The ROM shows up in 4 locations, and the RAM is mirrored too. A13 is the only line used to decode if ROM or RAM is accessed. Therefor the memory map looks like this;

FFFF
      RAM (Shaddow)
E000
DFFF
      RAM (Shaddow)
C000
BFFF
      ROM (Shaddow)
A000
9FFF
      ROM (Shaddow)
8000
7FFF
      RAM
6000
5FFF
      RAM
4000
3FFF
      ROM (Shaddow)
2000
1FFF
      ROM
0000

As I understand it, Only the 8 ROM from 0x000 to 0x1FFF and the 16k RAM from 0x4000 to 0x7FFF actually matter. However, my plan is to burn two consecutive copies of the ROM and set the Pageable ROM Module to a 16k bank size. I will also use a 64k RAM Module with RAM starting at 0x4000. This will mean that the shaddow ROMs from 0x8000-0xBFFF will actually be RAM. I very much doubt that anything makes calls to that address range expecting it to be ROM, but as long as it isn’t critical to bootup, I can write a routing to fill that RAM with the ROM contents.

So, with all of that sorted out… I just need to solder some components, burn a ROM, and put it all together.

-

Retro Challenge 2024/10 Talking The talk… at 9600

Following on from the failure to get the Portfolio talking directly to the RC2014, I decided to turn my attention to the Cambridge Z88. I already have a custom RS232 to TTL serial adapter for that, and the RC2014 is all set up ready for the Portfolio at 9600 baud, so this should be straightforward…

Well, would you believe it, it was a success! The Z88 is a fantastic machine, with some good built in programs. One of those is a terminal emulator, so it really was just a case of plugging the RS232 adapter in to the RC2014, with Port B set as the primary port set at 9600 baud.

To test it properly, I typed in the test program for the LCD module https://rc2014.co.uk/modules/lcd-driver-module/ (The initial test failed, but after I plugged the LCD in correctly, everything worked fine).

Buoyed on by the success there, I decided to turn my attention back to the Portfolio. Knowing that the Z88 RS232 to TTL serial adapter worked meant I didn’t have to burn my fingers again! The only issue was that the Z88 had an almost but not quite standard pinout on the DB9

I blogged about the Z88 RS232 to TTL Serial adapter back in 2013 https://sowen.com/466/z88-to-ftdi-lead-via-max3232/ The important takeaway from this is that Gnd is on Pin7 on the Z88, although it is Pin5 on the Portfolio. It is also worth noting that Pin1 and Pin9 both carry 5v, and whilst these aren’t used in my adapter, they could break other things they are plugged in to. Pin2 and Pin3 are Tx adn Rx respectively on both the Z88 and Portfolio.

Time for a Frankenconnector to adapt them!

The other bit of unfinished business on the Portfolio was putting some terminal software on there. A copy of xterm2, as supplied on the Portfolio utility card was easy enough to find. In the past I had transferred programs to the Portfolio via the parallel adapter, however, I had recently bought an APF-01 memory card from https://apfram.com/ Whilst I had to use some propriety software on a Windows machine to copy the files on to it, it worked really well.

With everything connected up and Xterm2 started, the Portfolio and RC2014 were talking!

Again, I typed the LCD test program and sent a message to be displayed from the Portfolio to the RC2014

Although, of course, it was only as I type this blog post that I notice the Off-By-Ten error in that message! Ooops!

So, that is the Z88 and the Portfolio both ticked off of the list of computers to talk to the RC2014. Whilst the Portfolio wasn’t a complete failure before, I am really glad I revisited this and got a more satisfying result. And it has reminded me just how good both of those two machines are. I really should use them more.

-

Retro Challenge 2024/10 – Getting my fingers burned

If you read the intro post to this years challenge, I set myself a secondary goal of getting many of my old computers talking to my RC2014. So I decided to kick things off with the Atari Portfolio. This was going to be an easy intro in to things as this little DOS compatible palmtop has a serial port expansion and can run DOS based terminal software. So this would be pretty straightforward, right?

The Portfolio serial port is limited to 9600 baud, so this gives me a couple of options on the RC2014. I could either slow main clock right down, which will slow the CPU, but I will get 9600 baud on serial Port A. Or I could slow down Clock 2 and use Port B as the primary port. Rather than dive in headfirst and make a mess of things, I came up with a simple step by step plan;

  • Power up the RC2014 and check that it is all working
  • Plug in to PC and verify 115200 baud on Port A is working.
  • Connect to Port B and verify this works at115200 baud
  • Change Clock 2 and check the PC can communicate at 9600 baud on Port B
  • Install terminal software on the Portfolio
  • Plug the Portfolio in to a serial to USB adapter and check it can communicate with the PC at 9600
  • Build a simple MAX232 adapter to convert the RS232 on the Portfolio to TTL serial
  • Check this can communicate with PC FTDI
  • And, finally, connect the RC2014 and the Portfolio, via the MAX232 adapter, using Port B at 9600

The first 3 steps went without a hitch. Using Port B as the primary port was as simple as flipping a switch when using the Front Panel. However, when I dropped the RC2014 down to divide Clock 2 by 12, I was unable to communicate at 9600 baud. This didn’t bode well. In case I didn’t get the jumper right, I tried setting the terminal to 4800 and 19200, being the speed just above and below 9600, but to no avail. Anyway, long story short, I wasted an hour before discovering that indeed the jumper was of by one, but it gave 14400 baud, which my terminal software didn’t support! So ok, progress, but slow progress.

On to the Portfolio. I plugged in the Serial Port expansion, connected a RS232 to USB adapter, and plugged it in to the PC. Using the DOS command COPY AUX CON meant that whatever I typed on the PC came out on the Portfolio screen, and COPY CON AUX meant that whatever was typed on the Portfolio appeared on the serial terminal.

Now the easy part. I had a few MAX3232 modules which do the RS232 level shifting/inverting. On the Portfolio side I just need Ground, Tx and Rx. On the RC2014 side, Ground, 5v, Tx and Rx. Soldering was about as easy as things get, and it all looked good. Just to be safe, I decided to add an extra step and connect it to my FTDI adapter plugged in to the PC. A second later I dropped it as I felt burn my fingers!

Quickly unplugged everything and checked the soldering, the pin labels, and made sure I was 100% confident that everything looked fine. Plug it in again, touch the chip… Ouch! This was not good.

Time to bust out the FLIR thermal imaging camera. Wow! This thing gets up to 150’C (or 300’F) before I chicken out and pull the power.

Checking online and social media, people had reported problems with the cheap Chinese MAX232 modules. I had my doubts that the chips were genuine. However, some reports stated that the internal pull-up resistors are too weak, so without an input signal it is bouncing around all over the place and causing it to heat up. Others said that a resistor inline with the 5v power might fix it. Those ideas were certainly worth a try.

I can confirm, for my module at least, pull-up resistors made no difference. A resistor in series with the 5v meant that it didn’t get hot… but it didn’t work either. (although quite possibly the vital parts were already burned out?)

It was also pointed out that the chip is actually a MAX3232, which is a 3v3 chip. This would explain a lot! However, the datasheet says that it can work with Vcc from 3v – 5.5v. The TTL input can also be 5v even with a 3v3 Vcc. So, if it is a genuine chip, it _should_ still work

So I had to accept only a partial success, but mostly a failure on this one. The RC2014 worked at 9600 baud on Port B, and the Portfolio could talk at 9600 baud. It was just that they hadn’t talked to each other.

-

Retro Challenge 2024/10 Update 1 – The Riddler

When I failed to complete the Retro Challenge in 2016 I finished by saying that the dog ate my homework. That sounded like a reasonable enough excuse.

This year any failure to complete is because The Riddler ate my schematic!

One of the first things I wanted to do was familiarise myself with what 2016-me did regarding the ZX81 module I designed for the RC2014. I have 3 PCBs here, and whilst they look great, they lack some info, such as the component values. So I opened up the schematic I created and discovered that all of the components have been replaced by ?? boxes!

To be fair, this isn’t the first time I have seen this situation. This was probably created in Kicad v4 or possibly earlier, and one thing which Kicad was terrible with back then was keeping track of component libraries whenever there was an upgrade. I am now using Kicad v8, so there have been a lot of upgrades.

I might be able to install a fresh copy of an old version and hope that has the right libraries and I can map them in to work with the schematic. I think that most of the components are resistors and capacitors though, so even if that worked, I wouldn’t have the values anyway.

I think it will actually be easier to convert the schematic to the v8 standard and manually change each of the parts to the resistor, capacitor or diode as approprite. I still won’t have the values, but the thing I do have is the original ZX81 schematic that this module was based on, so it should be a case of matching things up.

Mid-blog update

I looked back at the intro post that I made and noticed that the photo I reused from 2016 was a picture of the partially assembled module that was sitting on a schematic printout. The values can be seen too!

So that makes life easier!

Not only that, but another blog post from 2016 also has the full schematic (less component values) so that helps too!

The RC2014 has come along way since this module was conceived 8 years ago. I think some of the stuff that I had learned about the ZX81 back then had guided some of the decisions that I made later, which actually helps this a lot.

Firstly, the Backplane 8 and Backplane Pro both have the ability to add resistors on the data and address bus, as the ZX81 did. There is now an RC2014 keyboard which mimics the ZX81 or Spectrum layout and has the diodes onboard, so that makes things easier too. The Pageable ROM module supports 16k blocks, which will help if anything on the ZX81 needs to access the shadow ROM in 0x2000 – 0x3FFF. And, lastly, the 64k RAM module can be set to start at any address. With the ZX81 having RAM mapped from 0x4000 – 0x8000 this is perfect.

-

Retro Challenge 2024/10 – Intro Post

It has been a while since I entered Retro Challenge, but I think I remember what to do. It goes something along the lines of stating at the start of the month by saying that you are going to design a ZX81 module for the RC2014, and then at the end of the month report back in with minimal progress. Looking back, I seem pretty good at that. Retro Challenge 2016/1 started off like this and ended like this. Then later for Retro Challenge 2016/10 it looked like this.

I hope you will excuse me for using the same image I finished on 8 years ago, but, honestly nothing has changed. The ZX81 module is still in this state.

So, before we get to far ahead of ourselves, lets take a look at how we got to this point. My original goal was to recreate either a ZX Spectrum, ZX81, ZX80 or Jupiter Ace module for the RC2014. They are all fairly similar architecture, although the Jupiter Ace has weird dual port memory RAM. They all have a Z80 CPU, some ROM, some RAM and a clock, the same(ish) as theRC2014, so those parts of the schematic can all be ticked off. The ZX80 does everything else with conventional 74 series logic. The ZX81 is almost identical, except that 74 series logic is all smooshed in to a ULA. The Spectrum is similar except the ULA does more stuff (which can also be done with 74 series logic).

I ended up choosing the ZX81 as a good place to start because it is pretty much just a ULA chip with a little bit of support circuitry. The ULA is no longer manufactured, which will mean taking one from a working ZX81 to get this up and running. There are, however, modern FPGA replacements available, so I might well end up getting one of those to swap in at some point. So in January 2016 I translated the relevant parts of the ZX81 schematic in to KiCad and designed a module around that. I got some boards made, but that was as far as things got. Then later that year I soldered in 9 components.

To get started this year I need to do two things. Firstly, familiarise myself with the ZX81 circuit and the one I designed 8 years ago. I seem to remember being fairly confident it would work, but at this stage I have Schrodingers PCB. It both works and does not work simultaneously, needing a test to clarify the actual state. The second thing is that I need to check my stock of ZX81 and select a donor one that the ULA can be borrowed from. I probably want to make note of some of the pin voltages or signal traces before taking it out so I can check those when it is in the module.

There is a chance that I will end up waiting for parts, so the secondary part of my Retro Challenge challenge is to talk to my RC2014 with as many of my retro computers as possible. This may include but not be limited to;

  • Atari Portfolio
  • Cambridge Z88
  • Psion Organiser II
  • Psion Organiser 3a
  • Sinclair Spectrum (with Interface I)
  • Sinclair Spectrum 128
  • Sinclair Spectrum +2 or +3
  • Sinclair QL
  • Amstrad PPC640
  • Toshiba T1200

I think this will be limited to serial communication, and luckily I have a few MAX232 chips and boards here. I expect it will mainly be using the device as a serial terminal for the RC2014, but it would be nice to maybe send a Spectrum loading screen from the RC2014 to the Spectrum. It might sound trivial, but understanding how the serial ports work on those devices, and finding/writing software to use them could be the challenging part.

-

Retro Challenge 2024/10 Prize

2024 marks the 10 year anniversary since I entered the Retro Challenge in… hmmm… let me see now… that’ll be… 2014! Yes, I remember it well, because Retro Challenge 2014 had a catchy hashtag on Twitter, something like #RC2014.

Well, the good folks behind Retro Challenge approached me and asked if I would consider donating a prize for this years event. There were no prizes back in my day, it was all about likes and subs, and inadvertently starting a new career back then. But, hey, I understand that people like prizes, so I said yes. I said I would like to offer an RC2014 Classic II kit to the winner of the RC2014 category

After thinking about it for a little while, I figured I could come up with something a little bit more special. But before I reveal what that is, and before you skip to the bottom of this post for a sneak peek, I wonder if I should explain what Retro Challenge is. Well, it is a challenge revolving retro computers. The challenge is self-set, and you can do pretty much whatever interests you if it involves a retro computer, and you blog about it to share your knowledge and inspire others. Maybe you want to right software for your old Dragon 32, or get that VIC20 cleaned up, recapped and retrobrited, or scan in the original PDP manuals and upload them to the Internet Archive.

Back in 2013 I had built a Z80 computer on a breadboard that ran BASIC. The challenge I set myself for Retro Challenge 2014 was to make my name appear in lights. More specifically I was going to write Z80 code to do it, using a Z80 computer which I also had to design. You can read more about it here https://rc2014.co.uk/653/retro-challenge-2014/

Part of the challenge was to get the PCBs designed and manufactured. I used OSHPark which meant I had 3 of each board. Luckily the designs worked and no serious modifications were needed (although a hammer was required to fit the header pins). You can read about the boards arriving here https://rc2014.co.uk/791/retro-challenge-pcbs-arrived-and-built/

Of the three sets of PCBs I had made, one set was used to build my original RC2014. Obviously. Another set was traded with John Fletcher for an original unpopulated Jupiter Ace PCB (See https://sowen.com/995/ace-adventures-on-jupiter/), and the feedback from that made me wonder if I should get some more made in case anybody else wanted to build their own RC2014.

So, what about the third set? It could be yours!

That’s right. In addition to the RC2014 Classic II kit, I will be giving away the final set of the original RC2014 PCBs to the lucky winner. Well, the original 32k RAM, Pageable ROM, Serial I/O and clock/reset module. The CPU module is a later one which the PCB manufacturer screwed up and didn’t put the silkscreen on the back! And I will throw in an original Digital I/O PCB too. As well as some stripboard.

Everything needed to complete the build is part of the Classic II kit. So when you receive your prize, you will need to decide if you want to build it as a Classic II, or go old school and make the most authentic RC2014 there is.

Not sure if I should put some legal disclaimer here or whatever. The winner will be chosen by the Retro Challenge organisers. I will post out the Classic II kit along with the original RC2014 PCBs mentioned above to the winner within a month of the winner being announced. This includes free international shipping if you are outside of the UK. No cash alternative is offered. Neither myself or the organisers of Retro Challenge can be held liable if you end up starting a new career based on your competition entry.

-

Etch-a-sketchy

In July 2024 I was exhibiting at Liverpool Makefest again. This is a fantastic family friendly makers event that is open to the public for free. It has always been a great place to show off the various RC2014 kits as well as have something interactive that can keep people entertained.

Normally I have a machine set up running Snake, but this year I was about to launch the Dual Paddle Analogue Module, so I wondered about making something with that. The idea of an Etch-a-sketch came up, and coupled with a NeoPixel Matrix Module I figured this would be a nice self contained demo unit.

I could handle the electronics and the physical build, but I reached out to Shiela at Peacock Media to see if she could help on the software side. As both the Dual Paddle Analogue Module and the NeoPixel Matrix Module were Shielas design she jumped at the idea. it was only 5 days before the event though, so we needed to move quick.

There were some important design considerations. Firstly, it had to be robust. One thing about the audience at Liverpool Makefest is there are quite a few kids and they are not always gentle with the exhibits. It also needs to be intuitive. If people need to read instructions, or things don’t give a satisfying output in the first few seconds they you have lost them. On top of that, it should really be self contained to the point where there is no need for a monitor or keyboard, and it just runs as soon as power is applied.

The first thing I needed to work out was the control mechanism. Two potentiometers, obviously, for X and Y, but how are they going to me mounted. I ran through some gamepad type prototypes but things weren’t quite feeling right. Then I noticed a couple of Pot Noodle pots sitting on my desk. These tapered plastic pots are great for pencil pots or other storage, and they stack really nicely. Two stacked together actually turn really nicely and feel good. But could a Pot Noodle pot house a pot? The Pot Noodle was launched at the same time as the Z80, so it seems like destiny, right?

Off to the laser cutter to knock up a prototype. This consisted of a flat square plate with 3.5mm holes in the corners, and another matching plate that had a 100mm hole. This hole was slightly smaller than the brim of the pot, so when screwed down it holds the pot really really tightly to the base. With another pot on top it rotates really well. Putting 10mm standoffs and another pate with 100mm hole in it still allows it to rotate and it prevents the top pot from coming off.

fixing a 10k linear pot to the lower pot was easy enough. I used these lovely vintage RS pots that have a D-shaft

However, fixing the top pot to the shaft was a challenge. Making a D-hole in the top didn’t sound robust, so I decided to 3D print a couple of parameterised knobs in OpenSCAD. I could then glue these inside the top of top pot.

Dear reader, let me share one thing I now know about gluing PP (Polypropylene) plastic that the pots are made of PLA (polylactide) the 3D print it made of – you cannot! There isn’t a glue or solvent that will work. Trust me, I tried many many things.

However, mechanical fasteners (M3 nuts and bolts) do work! The image above shows some holes drilled in the 3D part. Similar holes were drilled in the pots and they were bolted together. Rugged, child-proof and even repairable if needed!

This could now sit on the D-shaft of the pot, and kept from being removed by the top plate.

Next the question about additional controls. Whilst the original Etch-a-sketch was monochrome, the NeoPixel display didn’t have this limitation. There are a few ways to add a digital button to an RC2014, but when there is already an analogue module plugged in, it would be nice to use that.

To achieve two buttons of input, a 1k resistor was added to the negative side of the pot and a switch on the wiper going to ground. In normal use the 8 bit value from the variable resistor will only go down as low as 23, and as high as 255. When the switch is pushed the value is 0. So the software only needs to map approximately 25-255 to the 8×8 display, and anything less than 10 can be treated as a button press. With two pots, this allows 2 buttons, one for to cycle the colour, the other to clear the screen.

Note that it is tempting to put a 1k resistor and another switch going to the 5v line. This will give an extra two buttons, which would be great. However, if both buttons are pushed at the same time it will be shorting 5v and ground. This is a Bad Thing™ and certainly not something you want on a public facing exhibit. Even with a “do not push both buttons at the same time” sign!

A couple of arcade buttons worked great for this, although a label was put on as an afterthought as they weren’t quite as intuitive as hoped.

Shielas software worked great! Burning this on to ROM meant that it just ran on startup without any faffing at all. And with a t-shaped frame that housed the two pots, the buttons, and an RC2014 Mini with NeoPixel Module as well as the Dual Paddle Analogue Module it was a really nice self contained unit.

Things aren’t quite so neat underneath as the wiring for the pots and switches are all routed to a prototype board held together with Kapton tape. But nobody ever looks underneath, right?

How did it go? Great! As always, Liverpool Makefest was a great day out. The folks in Liverpool seemed to instinctively get it straight away. Some people spent a while creating their own Mona Lisa, and others tried teamwork with one person controlling the X axis and the other controlling the Y axis. Nothing broke down or needed restarting and it is all ready for the next event. If anything, the only failing was that it worked too well that nobody particularly asked how it was working, so I didn’t get to talk about the analogue module too much. But at least I got a blog post out of it :-)

The Dual Paddle Analogue Module and the NeoPixel Module 8×8 Matrix are available now on z80kits.com

-

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.

Pairs of PCBs with rails attached to the side
De-panelised PCBs in front of a wooden box with a slot cut in it and half full of PCB offcuts

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.

Laser cut perspex jig with an RC2014 module shaped cut out along with finger holes to remove the PCB and a hole below the programming pads for the locator pins to go
Programming lead being held in for the 3 seconds it takes to program the micro controller
Fully programmed module ready to be removed and tested

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.

-

Dye Sublimation Printing on PCBs for RC2014 Pride

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.

page 1 of 4