Thursday, 20 July 2017

Commodore Amiga 600 and 1200 USB keyboard kit

I have had few requests for USB keyboard kits for Amiga 600s and 1200s, so here they are.
The A600 and A1200 are very different from the Amiga 500. The A500 had a keyboard controller board on the back of the keyboard, and a serial interface to the mainboard. The Amiga 500 USB keyboard controller I built for that was a lot simpler in hardware terms, but a bit more effort to implement the serial protocol in the microcontroller.
The A600 and A1200 have no keyboard controller, and just a simple membrane connection to the mainboard. These have more connections and a smaller pitch than any of my previous USB keyboard controllers, so I have made a custom board.
The A600 cable is 30 way and the A1200 is 31 way, with a slightly different pinout. I found matching 30 way sockets for the A600, but I have not been able to get 31 way sockets, so I have used 32 way sockets for the A1200, just make sure the cable is aligned to the left of the connector.
The board mounts on the back of the keyboard using some self adhesive pillars. The cable on the LED board is not long enough to reach, so I supply a short extension cable.
The power LED is lit whenever the keyboard is plugged in. I have set the floppy and disk activity LEDs to act as scroll lock and num lock. You could drive these from software if you wanted to use them for another purpose.
They keyboard has a built in caps lock LED which shows the current state.
As usual the kit does not include an Amiga or keyboard, you need to provide those yourself, and please try to use a broken one.
The kit does include the USB keyboard controller, the LED cable, mounting pillars and a USB lead, and is available to buy from my Tindie Store.

I also have various single and dual 9 way D to USB joystick adapters that would fit nicely in the A600 or A1200 cases. These allow you to use original 9 way D joysticks (like Zip Stik or Competition Pro etc.) as USB joystick devices, contact me for more info.

Sunday, 16 July 2017

RC2014 Modular Z80 System

I'm sure you've all heard of the RC2014, it's a modular Z80 computer system available from seller 'Semachthemonkey' on Tindie. A great little system that makes it easy to build and expand a Z80 based system. (or even a 6502 system as the base is very adaptable).
I've just bought some new boards to add to my RC2014 system, so I thought it would be a good time to revisit the current system and go through all the boards on there before I add the new ones.


The system is based on a backplane with a common bus, 40 pins wide, carrying most of the Z80 lines. It uses 40 way 0.1" sockets for the modules to plug into. This is the 'back plane - 8' model where slots 1 and 2 and slots 7 and 8 can have their address and databusses isolated from the main slots, 3-6. This will allow some protection on the bus via resistors or to use split address and databusses for some cards to create ZX81 or ZX Spectrum type systems where the busses are isolated to simplify the screen generation process.
Into the backplane plug a selection of modules. Most are less than the full 40 pin width, and all align with the top of the backplane, pin 1, with the exception of the clock / reset module which hovers around the middle. Full details of the backplane and other modules can be found on the website.

Z80 CPU Module

The heart of the system is the Z80 CPU board. This has little else on there, other than a pullup resistor on the INT line. This is an older board, with inputs not passed to the backplane such as NMI, WAIT and BUSRQ tied high, the later versions have an option to tap these off or tie them high. Full details here. Like all of the other modules here, there is no decoupling on the boards, only on the backplane. I'd like to see the traditional 100nF on each chip, I think that has happened on the later modules.

Clock Module

The clock generator comes on a small separate board. This generates a buffered 7.3728MHz clock. I would have thought it logical to place this on the Z80 board, but I guess there are reasons to separate them. There is also a position for a reset switch, but I deviated from the normal build here and added instead an RC circuit to give a power on reset. There is a reset button on the backplane anyway. Here I found a 74LS04 wasn't up to the job, but a 74HCT04 was fine. Full details here.

8K ROM Module

The Z80 needs some code to run, so it gets that from the 8K ROM module. This has a 27C512 EPROM split into 8 banks of 8K, selected by jumpers. Full details here. As supplied, it came with a version of BASIC adapted from the NASCOM computer by Grant Searle - more details on his site. This is fixed 8K ROM decoded to the address range 0x0000 - 1FFF. There is a later module which allows bank paging, which is one of the new ones I have ready to install.

32K RAM Module

BASIC needs some RAM to run in, so here is 32K of RAM, mapped as 0x8000-FFFF. Again, this is a fixed mapping and a newer board has up to 64K and paging capabilities. Full details of the 32K RAM board here. If I remember correctly, this is another one of the boards where I started with a 74LS32 and changed to a 74HCT32 as I found some RAM chips (the Alliance AS6C62256 shown) didn't work with the LS chip, but other 62256 chips were fine.

Serial IO Module

This final module for the BASIC system provides serial IO. This is based on the 6850 (although the 6350 can be used, as can 6xA50 and 6xB50 variants). These are the only part in this system that are out of production, so are old parts, the 68B50 I got didn't work, but I had a 6850 and that worked correctly. The system 7.3728MHz clock is divided down to get the serial baud rate. Divide by 64 gives 115200 baud. There is space to install a MAX232 and a 9 way D connector for an RS232 compatible port, but the easiest option is to use the FTDI header to connect to a PC via a USB serial adapter. The jumper above also allows the RC2014 to be powered via this connector. The 6850 is accessed at address 0x80 and 0x81 (but is also mirrored from 0x80 through to 0xBF) . Full details here.

The RC2014 in use

With all of those plugged in, you can see that two face in the opposite direction to the others. This means the central modules are close, so I have some plastic feet stuck on the back of the RAM card to stop it touching the CPU card. Since all my FTDI cables were bricked by FTDI last year, I am using an Arduino module which does the same job, and that is set to power the whole unit (current consumption is under 200mA, and the USB port can in theory supply up to 500mA).
Connecting up via a serial terminal and switching on, we're into BASIC and away. Without adding any storage, the easy way to get programs onto the system is to paste into the terminal Window. I have had mixed results and usually need to get the terminal program to add a 10mS line delay or a 1mS character delay to avoid corruption when transferring large programs, as there is no flow control in place.
You can then transfer some BASIC programs over to test. It is a pretty generic Microsoft BASIC with most of the usual commands supported. The great thing with a system like this is that if you find there is something missing, go and grab the source for the BASIC interpretor and add your own commands.

RC2014 Mini

Something else I should probably mention at this point is the RC2014 Mini. This is basically all of the above on a single board. It can be used standalone, of there is space to fit a 40 pin connector on the side to add a single module, or a backplane full of modules. This one is also driven via FTDI serial cable, or you can use the RC2014 Universal Micro Keyboard.
That is what that keyboard is meant to be used for, even though I keep using them on my Minstrel ZX80 clones.
So that's the existing modules I have covered, next time I'll be replacing several of those with new ones.

If you want to support this blog, you can donate via Patreon or Paypal, or buy something from my store.

Saturday, 1 July 2017

Z80 M1 signals

During testing of the DivMMC future, one of the aims was that it should work with as many ZX Spectrums as possible. In many cases, the clock line was the most problematic, but we managed to resolve that one (more on that in another blog post).
One thing that we have not been able to address is the M1 line on the expansion bus. This is wired directly to the Z80 and is not used by the internal circuitry of the ZX Spectrum, but is required by the DivMMC circuitry.
The Z80 datasheet describes it above, it is used to indicate specific conditions of IO and Memory request cycles. We have all heard various comments about 'weak M1 lines' etc. being the reason some external devices do not work with some Spectrums. Indeed, this affects not only the DivMMC Future, but things like Sinclair's own Interface 1.
In normal operation, M1 is toggling up and down with all the other signals, between 0V and about 4V, which is well with the specification for a digital pin. In all systems where the M1 line has looked like this, we have seen the DivMMC future work correctly.
I have seen several systems where the M1 line does not look like that. Here it is just noise, floating about 1V. I have tried various options to see if there is any signal there, triggering off IORQ and MREQ instead, but it really is just noise. If it were a weak signal, it could be boosted. But this is just no signal.
Adding a pullup does just that, pulls it up, so it's now floating around 3V, still not doing any good.
I have seen this 'missing M1' on various manufacturers versions of the Z80, GSS, NEC, and even an original Zilog.
When this was replaced with another Z80, the M1 signal was present and the board worked fine.
The same Z80 was then tested in another known working machine and the missing M1 signal had transferred with the Z80.
This isn't like the clock signals, where they are at least present on all boards, albeit barely 1V peak to peak in some cases. There just isn't anything there to work with. I'd be interested in anyone has examples of Z80s with 'weak' M1 line, where there is a valid signal, just running at too low a level, rather than just being noise.
Having seen cases of seemingly identical chips, one with a working M1, one with just noise, I don't think this is a case of corner cutting on Z80 clones. It looks more like these were either manufacturing faults, not picked up as the Spectrum does not need the M1 line, or the M1 line has been damaged in the past. I wonder if this is perhaps due to the ZX Spectrum edge connector:
M1 (marked as M1L meaning M1 - active low), is right next to the 12V AC line (a point tapped off the DC-DC converter). I wonder how many misaligned joystick interfaces accidentally shorted the 12V AC into the M1 line and killed it?
Given this signal is important for the operation of the external devices, if it's simply not present, then the external devices are not going to work, so you need a new Z80. In all cases where this has been seen, replacing the Z80 has always resulted in a working system.