ZXIO Interface for the ZX81: Part 3

Testing ZXIO Boards with a Variety of ZX81 and Minstrel Hardware Options

We're finally at the point where I go over the actual test ZXIO boards, test the addressing changes and learn why I mentioned in the first article that memory address 16507 is the "perfect location for an Output Board, and an interesting, possibly flawed location for an Input Board"

Boards as Envisaged?

After some simple initial testing I had prototype ZXIO boards produced. The core board along with breadboard friendly breakout boards, these components are designed to connect via a 20 pin IDC cable for easy IO experimentation. This arrangement also made testing the boards a relatively simple process.

While building the device I'd noticed I'd not connected the +9v power rail to the voltage rectifier, which needed fixing with some bodge wire. Somehow I'd left the line off on the schematic. I caught this issue out after noticing some odd voltage drops on the input / output lines. Interestingly the whole board was being powered by vampire voltages sourced from the ZX81's Address lines up until this point. 

ZXIO Test Board with Accessories

With power problems sorted, testing the Output lines was a simple matter of POKE-ing address 16507,  data lines checked individually with their corresponding decimal value, 1,2,4,8,16,32,64 and 128. This test checked out fine. The next step, writing a  up a 'traditional' counting application cycling for 0 to 255, POKE-ing the  numbers and watching the LED's flash accordingly. A delightfully flash result was produced.

Input testing was a not to dissimilar process, only in reverse. With the breakout PCB mounted on a breadboard, I tested each input with a 220 ohm  resistor from +5v (included in the breakout pins) routed to each of the input data lines in turn. The ZX81 was set to PEEK at address 16507 and each of the lines read back correctly. All good so far.

Last major test was to cycle values through the Output and Inputs at the same time. If everything was working as expected I should be getting different values in to what I was sending out. If I was POKE-ing 255 out and had the inputs setup for say 15, I should see 255 on the LED display (which is output only), but be getting a value of 15 when conducting a read / PEEK-ing at address 16507.

This was also all good on my initial testing as conducted using a ZX Minstrel Issue 3 (Tynemouth Software's ZX81 Clone) with the its ZXpand attached. Then I moved the experiments over to a real ZX81 and things were not quite as rosy there.

Tales of RAM Packs and Modern Expansions

ZX81 and ZX Minstrel 3 Expansion Options

Over on a 'real' ZX81 with a period correct 16k RAM pack, attempting to write out and read in would produce an accumulation, for example if POKE-ing out 1 and setting up the input lines to be 2, you end up with a value of 3, Essentially the combination of bits. So what's going on, why the difference? In hindsight I really should have expected the results I'm getting from the ZX81, but to understand why we'll need to look at how memory packs work on the 81.

To use external ZX81 RAM packs, the internal 1k RAM of the machine must be disabled first. This can be done by raising the RAMCS line on the expansion bus to +5v. Once a 16k expansion is added, the memory map will follow the layout as described in Part 2, with the additional 16k of memory appearing between addresses 16384 and 32767. l was expected when laying out the idea of the ZXIO and placing our memory mapping at address 16507 in an unused location in the system variable table. What I hadn't calculated for was the inability to disable the external RAM in a similar fashion.

ZXIO Schematic for 16507 Addressing as Tested. (Note RAMCS mostly, wouldn't recommend building)

It appears that both the Minstrel and modern RAM expansions for the ZX81, such as the ZXpand+, are keeping a watch on the ROMCS and RAMCS lines for any other activity. The purpose of this is would be to enable the functioning of any devices that utilise memory mapping and that may be mapped to areas occupied by the additional 32k of memory provided by these modern expansions.

Older period memory packs are not functioning in the same manor. Most if not all would be anticipating memory mapped devices to be located in the ROM mirror areas. To this end all my setting RAMCS to high is doing is affirming that yes the ZX81 should be using external RAM.

This is precisely what I meant earlier when I suggesting that memory address 16507 would be the ideal location for an Output Board. It is an area of RAM that is otherwise not utilised, making it perfect for setting up external devices to read from. However, if old RAM pack hardware is connected and data is written back to this address, it is likely to result in confusion at the bit or byte level.

So that's where we're at for the moment, we have an IO board that works perfectly with modern ZX81 hardware, not so much with period pieces. Next step I'm guessing is to move the memory mapping to somewhere the shadow ROMS are expected to be. Much like the original design from ETI Canada only a little more targeted like we tried out this time around. It might also be tempting to try out another design of IO board entirely, but all this is for the next set of posts in the series.

Until then see all the other entries for this project:  Part 1, Part 2, Part 3

Read More

ZX81 Expansion Bus Cheat Sheet

While designing or reverse engineering external interfaces for the ZX81 it's usually advantageous to have some quick reference materials to hand. This is for me as much as anyone, may it be of some use to all.

ZX81 Expansion Bus Connector

ZX81 Expansion Bus Connector, Viewed from Rear of Machine

Pinout Functions and Properties Summary Table

A quick summary of the Signal and Functions of each Pin / Pad available on the Expansion BUS. This is not an extensive description, for that I'd highly recommend reading the 1983 Melbourne House book "The Ins And Outs Of The TIMEX TS 1000 & ZX81" by Don Thomasson, in particular chapter "The External Interface"

TOP ROW
Pin	Lable	Function	Properties
1A	D7	Data Line	Active High - Bidirectional
2A	RAM C.S.	RAM Chip Select	Active Low - Pull high to disable onboard RAM
3A	Slot	Cutout / Keyed
4A	D0	Data Line	Active High - Bidirectional
5A	D1	Data Line	Active High - Bidirectional
6A	D2	Data Line	Active High - Bidirectional
7A	D6	Data Line	Active High - Bidirectional
8A	D5	Data Line	Active High - Bidirectional
9A	D3	Data Line	Active High - Bidirectional
10A	D4	Data Line	Active High - Bidirectional
11A	INT	Interrupt	Active Low - Input
12A	NMI	Non-Maskable Interrupt	Active Low - Input
13A	HALT	Halt CPU Sate	Active Low - Output
14A	MREQ	Memory Request	Active Low - Output
15A	IORQ	Input/Output Request	Active Low - Output
16A	RD	Read Request	Active Low
17A	WR	Write Request	Active Low
18A	BUSAK	Bus Acknowledge	Active Low - Output
19A	WAIT	Force CPU Idle	Active Low - Input
20A	BUSRQ	Bus Acknowledge	Active Low - Input
21A	RESET	Reset / Restart	Active Low
22A	M1	Machine Cycle	Active Low - Output
23A	RFSH	Refresh (dynamic RAM)	Active Low - Output
BOTTOM ROW
Pin	Lable	Function	Properties
1B	+5v	+5 Volts Regulated	Internal
2B	+9v	+9 Volts Un-Regulated	External Supply Voltage
3B	Slot	Cutout / Keyed
4B	GND	Ground 0 Volts	Shared Ground
5B	GND	Ground 0 Volts	Shared Ground
6B	Ø	Clock 3.25 Mhz	Active Low - Output
7B	A0	Address Line	Active High - Output
8B	A1	Address Line	Active High - Output
9B	A2	Address Line	Active High - Output
10B	A3	Address Line	Active High - Output
11B	A15	Address Line	Active High - Output
12B	A14	Address Line	Active High - Output
13B	A13	Address Line	Active High - Output
14B	A12	Address Line	Active High - Output
15B	A11	Address Line	Active High - Output
16B	A10	Address Line	Active High - Output
17B	A9	Address Line	Active High - Output
18B	A8	Address Line	Active High - Output
19B	A7	Address Line	Active High - Output
20B	A6	Address Line	Active High - Output
21B	A5	Address Line	Active High - Output
22B	A4	Address Line	Active High - Output
23B	ROM C.S.	ROM Chip Select	Active Low - Pull high to disable ROM mirrors

Read More

ZXIO Interface for the ZX81: Part 2

 

Last post I mentioned that the ZXIO add-on is memory mapped to location 16507. So this time I go over why 16507 and dig into Memory Mapping at little.

Let's Talk about Memory Mapping

The main problem with mapping an IO device to a memory location is that it can remove that location from the ZX81's physical memory. Meaning that you can potentially poke black holes right into a location crucial for executing your applications. Not so good but avoidable.

To understand where to locate a memory mapped device let's first cover the basics: The first 8k is always devoted to ROM, the second 8k is by default is a shadow copy of ROM. This is then followed by a block of RAM either a 1k block followed subsequently by 16 shadow 1k copies of the first on a stock machine; or on a 16k expanded ZX81, an entire 16k block. In both a 1k and 16k machines, RAM addressing tops out at address 32767. Then we find 2 shadow copies of ROM taking up a 16k slot and finally shadow copies of RAM identical to those located between addresses 16384 and 32767.

ZX81 Memory Map in Standard 16k and an Example 32k Configuration
Block	Add Dec	Add Hex	16K RAM Map	32K ZXpand (Low Map)
0 - 8k	00000-08191	0000-1FFF	ROM	ROM
8 - 16k	08192-16383	2000-3FFF	ROM (Copy 0000-08191)	RAM
16 - 24k	16384-20479	4000-4FFF	RAM	RAM
24- 32k	20480-32767	6000-7FFF	RAM	RAM
32 - 40k	32768-40959	8000-9FFF	ROM (Copy 0000-08191)	RAM
40 - 48k	40960-49151	A000-BFFF	ROM (Copy 0000-08191)	ROM (Copy 0000-08191)
48 - 56k	49152-57343	C000-DFFF	RAM (Copy 4000-4FFF)	RAM (During M1)
56 - 64k	57344-65535	E000-FFFF	RAM (Copy 6000-7FFF)	RAM (During M1)

That's the basic 1k to 16k out of the way. If we have more memory the map changes. Each of the shadow copies of ROM can be switched out to accommodate extra RAM in 8k blocks (I'll post-fix that statement with normally). For example a 32k machine might switch out the first and second copies of the ROM located at 2000 to 3FFF and 8000 and 9FFF. This would give the ZX81 32k of contiguous RAM to play with. However it's worth noting that BASIC programs can only be located within a 16k area between 16384 and 32767, exactly the same 16k area as in the original memory map. That's not to say that the extra RAM is inaccessible to BASIC, you can PEEK and POKE the entire memory configuration. This ability is fortunate as memory mapping additional hardware requires this same functionality.

Memory Mapping Hardware Devices (Somewhere)

Much like swapping in RAM, add-ons can assume the memory location designated for shadow ROM, additionally we can claim areas of RAM. All well a good but where would we want to locate our devices in the memory map. This of course is not a new discussion, Nick Lambert of Quicksilva proposed a Memory Map standard for Peripherals all the way back in 1982, where he lays out where exactly he feels certain types of peripherals should live.

The below table is taken from SQ Quarterly Issue Volume 1, Issue 1, where you'll find quite an extensive article on the ZX80 & 81's Memory Maps, well worth reading, and it covers quite some ground that I won't go into here.

Nick Lambert of Quicksilva's Proposed Memory Map for Peripherals (SQ Quarterly 1-1 1982) 

Of course Nick's standard probably saw very little traction, and by the time anybody cared enough to follow a 'standard' they'd most likely moved onto squabbling around similar issues with the ZX Spectrum. Regardless, he does highlight the 2 most common areas where manufacturers and purveyors of DIY kits would naturally choose to locate their add-ons, the shadow ROM areas.

Now as mentioned in Part 1, in order to save wads of cash, address mapping was normally keep to a minimum, with large areas mapped to reduce IC counts. Now of course if you're playing around with a ZX81 you're going to want to maximise your RAM (just because you can, plus there really are applications the use it all), and all that RAM is already likely to be occupying the shadow ROM areas. This of course pretty much rules out every location (exaggerating a bit for effect). In reality we can get very specific on addressing, right down to the byte, a good scheme might be to map to the upmost ROM/RAM area unused by BASIC, say 16383. But if we're going to get that specific there is another creative option open to us.

16507 and Friends

The bytes in memory, 16384 to 16508 hold the ZX81 System Variables. Of the 124 bytes set aside for System Variables, there are 3 listed as not used in the ZX81 BASIC Programming Manual. (Why is this? Steven Vickers might know, personally, I haven't a clue) These unused bytes are 16417, 16507 and 16508, they are perfect for our purposes.

The major catch with mapping a peripheral into the unused System Variables space is that any programmer looking to claw free space (particularly those building 1k apps) is going to hunt these down and use them. Doing so will prevent our prospective IO device and such memory scrounging programs from running correctly. As with pretty much all memory mapping issues, this is easily solved by removing the offending device. Still it's both worth both pointing out and remembering in those cases where something odd happens, say when running that special copy of "1k Monkey Clown Car Mega Racer Game TM".

In Theory

For the first iterations of the ZXIO board I've chosen address 16507 as it affords the opportunity in latter revisions in claiming 16508, giving 2 adjoining addresses and some really interesting possibilities. Of course this is well into the future, first priorities are / were getting the initial prototype up and running.

Next Up  

We'll get onto designing and building the ZXIO, plus issues and I encountered along the way. Pretty much what you'd expect from a write up. 

See all entries for this project:  Part 1, Part 2, Part 3

Read More

ZXIO Interface for the ZX81: Part 1

Testing a Prototype ZXIO interface

This is the first in a new series of articles where I explore building an Input / Output board for the ZX81 (and clones), where I start with the idea of keeping it simple and probably fail at the simple part. 

Didn't You Already Make an IO Board?

Um, yes, yes I did, way back in 2018 I Build an IO board based on the a design found in the book Easy Add-On Projects for the Spectrum, ZX81 & Ace, this worked as intended and fun was had. Having used the Add-On Projects board for a while, I came to the conclusion that it was a overly complicated to engage with as a platform for experimentation. This applies physical and when paired with a ZX81 digitally. 

The Add-On Projects board has plenty of input/output pins, but I find them to be arranged in a slightly non-intuitive way, one that makes it difficult to expand / breakout from. That's my fault to an extent, the original design has the use of crocodile clips in mind, when I made my version I tailored towards dupont connections, dupont wires will only stretch so far from the computer. Still, I kept the layout and that's sub-optimal from today's perspective where we're used to breakout boards, hats and shields and the like for extended tinkering. 

The other main issue I have with the Add-On Projects board is that it's I/O Port mapped, meaning you can't access the device natively in ZX81 BASIC and must load a Binary program to access the hardware. Again, this is not a real obstacle, more of an annoyance, a limiting factor. A better approach (for BASIC use) is to memory map an IO board.  It's worth noting that that's a ZX81 problem, if using the Add-On Projects board with a ZX Spectrum you can query any available port.

What do I Want in a ZX81 IO Board?

The main thing I'm after on a new IO board is simplicity; easy to build, easy to connect and interface with, and accessible from BASIC.  All in all a not to complicated shopping list. To make this happen I could modify the Add-On Projects schematic, but since I'm looking at building something new, why not take some other examples out there as inspiration.

So it was off to the various fantastic archive sites for some research. Emerging some time latter, having trawled through period books and many a magazines, I found pretty much exactly what I was after in ETI Canada, Issue April 1983. There presented within the dusty digital pages a perfectly simple IO board. Interestingly once again it's a board designed for both the ZX81 and the ZX Spectrum. This time though there was an option to map it to Memory Addresses rather than ports. 

ZX IO Interface as published in the April 1983 Edition of ETI Canada

Of course just about any device can be mapped to a memory address, I guess the main reason this interface sticks out is because it implicitly does so and that the IO meat of the circuit is a simple as simple can be. To directly quote the original article in ETI:

"The eight board outputs are via PL1 and PL2 from the outputs of the 8-bit latch, IC1. The eight inputs to IC1 are connected to the ZX data bus lines DO -D7, so that when IC3b pin 6 pulses low the data present on DO-D7 is clocked into the latches. It will be held there until another ZX 'write' operation, to a suitable memory or I/O address, updates it.

IC2 contains 8 'tri-state' buffers. The inputs to these buffers are connected to the I/O board input points on PL3 and PL4. The output of each buffer is connected to one of the ZX data bus lines, but normally has no effect because the IC2 outputs are held open-circuit by a 'high' input to pins 1 and 19. When, however, the ZX does a 'read' operation from a suitable memory or I/O address, so that pin 3 of IC3a goes low, the output circuits of the buffers are enabled, transferring the information present at IC2 inputs to the ZX data bus lines."

In a nutshell IC1 and IC2 are handling the input / output, the remaining IC's are performing the address decoding, read and write detecting and ROM disabling. All pretty clear from the circuit diagram (and explanation in the article, which you should read).

Now about that memory mapping, The ETI IO board is mapped to 'All' addresses between 8192 and 16383 (8192 to 16383), that's an entire 8k Area, one normally reserved on a stock ZX81 as a ROM mirror. This broad approach in address mapping is quite normal, as is knocking out the ROM mirror and a good way to reduce costs by keeping IC costs / counts low. But cost is not a factor these days, so for my prototype IO board I decided I'd rather map an individual address, and made the necessary changes to the schematic (among some other minor changes). I chose address 16507.

Now 16507 is actually an unused address in the System Variable table. A very convenient free space, perfect for locating an IO board right?  Of course nothing comes for free, still short answer is yes it makes the perfect locations for an Output Board, and an interesting, possibly flawed location for an Input Board. 

The Board Worked... But.. Next Time?

Bit of a cliff hanger and no real explanation, and a rather sudden slightly disjointed end to Part 1. Next time I'll get into some details about the prototype and why I'm a fair way from done with this 'Simple' project. I did mention I wanted a simple project at the beginning of the article right? Seems I lied to myself.

See all entries for this project:  Part 1, Part 2, Part 3

Read More

Tut-Tut on the Commodore PET

For a game that started out as type-in program for Paleotronic Magazine, Tut-Tut has received a load of love. I'm constantly surprised at Tuts success throughout all the versions I and others have released. 

The various Spectrum versions feature in YouTube videos, the ZX81 version made the review pages of Retro Gamer, George Becketts' Jupiter Ace port has become quite the hit in Forth Circles and the original type in version even made it to the TRS-80 MC-10 courtesy of Jim Gerrie. Yes for a game that I wrote initially to prove Sinclair BASIC games didn't have to be a slow boring mess, Tut-Tut found it's mummified legs and ran with them.

All of which brings us around to the latest port, Dave Currans' 2021 Commodore PET release of Tut-Tut.  

Pharaohs' 6502 Tomb of PETs

Ostensibly the PET port is based on the source code from the ZX81 version of the game. Considering the graphical limitations of Commodores first line of computers, the ZX81 version provides the perfect starting point.  Of course the source code is only the beginning, there are many challenges in transposing  games from system to system. 

Dave has done a brilliant job of porting and preserving the overall feeling of the game. Game play is smooth and crisp, and you certainly don't ever feel cheated when caught out by Pharaohs' treasure guardians.

Tut-Tut on the Commodore Pet

In the PETs favour, the limited music and sound effects from the Spectrum and Ace versions have been incorporated, along with the ability to pause the game. All features that lend to your immersion into the game world. (Why I forgot to include 'pause' in the ZX81 release I've been meaning to ask myself for ages.)

I'm not going to dive any deeper into reviewing the game, I feel that's best left to others, after all I've got quite a stake in this title in general. What I will say however is that PET Tut-Tut is every bit Tut-Tut, and if you've enjoyed the other varieties then you're sure to love this one as well.

The game is now available from The Future was 8bit on Cassette as part of their £4.99 range or digitally at Itch.io. I strongly recommend loading up ASAP, Pharaohs' treasures await.

One again, great Job Dave!

---

Raid the Pyramids for a Copy of TuT-TuT

ZX81 Versions

• A Digital copy at Itch.io
• Get the Cassette from Cronosoft
• Play it on you iPad or iPhone, get a copy of ZX81 for IOS

ZX Spectrum Versions

• Tut-Tut 2020 Edition at Itch.io: Based on the ZX81 version with extra levels (and glorious colour).
• Get the Cassette from Cronosoft
• Classic BASIC: Physical Paper type-in release and Digital Copies will be available from Paleotronic Magazine

Jupiter Ace

• Tut-tut for the Jupiter, Ace Digital Copy: Based on the ZX81 version, with enhancements, by George Beckett
• Get the Cassette from Cronosoft

Commodore PET

• Tut-Tut for the PET Digital Copy: Based on the ZX81 version, with enhancements, by Dave Curran
• Get the Cassette from The Future was 8bit

TRS80 MC-10

• Classic BASIC Digital Copy: conversion to Tandys MC-10 by Jim Gerrie

Love the Game?

• Why not buy me a Coffee, I needed quite a few writing it, and with more there could be a TuT-TuT II.

Read More

Mini PET 40/80 Build & Review

 

The New Tynemouth & TFW8b.com Mini PET

Back in 2020 Tynemouth Software released the Mini PET onto a largely unsuspecting retro computer kit appreciating public. 2021 sees the release of a significant update to the standalone kit in the form of the Mini PET 40/80. What's it like? How easy is it to build? How usable is it? Lets find out.

A new PET in a Kit

At first the Commodore Personal Electronic Transactor (PET) seems an unlikely choice for a computer kit, being possibly the least widely used of the classic Commodore computer lines. Then again PETs are the raison d'être for all subsequent Commodores and for that reason alone places the PET line in a very special place.

Now there were quite a variety PETs produced, the the first being the 2001 series, going all the way up to SuperPET 9000s. But what type of PET is a Tynemouth Mini PET 40/80? Well, it's most of them and none of them all at the same time (well kind of). Internally the Mini PET 40/80, as the name suggests is a 32k PET 4000 series / CBM 8000 series clone, yet it takes the stylised keyboard from the original 2001.

Unlike Commodore PETs, Tynemouth / TFW8b PETs come unassembled, and in that state it's pretty damn impressive. Mr Tynemouth aka Dave Currans' kits are normally impressive enough, but with the powers of TFW8b & Tynemouth combined something special awaits the keen kit builder this time around. 

The kit comes in quite the box; A light blue Commodore Pin Stripping cover sleeve cloaks the contents, imparting that essential Commodore-ish-ness of what lays within. Once opened our container reveals an equally special spiral bound assembly booklet, a PCB, the required ICs and other components neatly arranged out on build trays, plus a host of laser cut perspex sheeting that will go on to form the computers case.

The Opened PET kit ready to roll.

Thanks to all the hard work that's gone into first impressions, there's no sense of dread to be had before embarking on the build, quite the opposite, you can't wait to get the PET together.

Build a PET

As alluded to earlier, the build manual is a kit highlight, not only striking in it's design references, it is perhaps more importantly for the purposes of kit building a very clear and well laid out reference. Being spiral bound the manual is easy to lay flat during the step by step kit building processes and each stage of the build is presented at the appropriate time. (with the possible exception of step 3, the Crystal and Transistor mounting, which I'd recommend swapping with step 4.)

Building the PET is a breeze, well more of a long gust, there's a lot to solder after all. The PCB is cleanly laid out with part placement quickly referenced in the manual. Conveniently all the IC's / Sockets are laid parallel and facing the same direction, a trait shared with other matched components such as diodes, a nice touch that makes it quite difficult to solder polarised parts incorrectly rotated.

One thing to note while building up the PCB; the solder pads around the IC's are on the smaller side, I found the use of a flux pen greatly improved my soldering experience. 

Key Craft - Cut & Place

Perhaps the weakest point of the original Mini PET was its 'tack switch' based keyboard. Not having an example of the previous model I can't reliably comment fully, still I think we can all intuitively 'feel' the issue. The Mini PET 40/80 has addressed all concerns while managing to keep a satisfying retro feel. Omron B3f Series switches underpin the keyboard this time around, Cherry MX (or 9mm Guy Preferred) they are not, though they are rather pleasant to use and should serve extremely well. In situ surrounded by a bezel the keyboard looks the part, really completing out that retro PET styling. This keyboard gets an A+ from me for effort and details (and even feel).

Once at the keyboard legend decal stage you'll have quite the arts and craft session ahead of you. 87 legend cutouts required for placement under clear keycap tops. Thankfully the kit comes equipt with several copies of the keyboard decal sheets should you make a mistake.

That leaves us with the final case assembly, and what a fine bit of work that is. Held firm on a dark base plate, the white circuit board and bezel plates all topped off with a clear laser cut etched panel, completed and all together the Mini Pet 40/80 is gorgeous.

PET Handling

Of course the most exciting part of any kit is powering it on for the first time. I was instantly greeted with the "*** MINI PET BASIC 4.1 ***" header; for what must be a first for me it all worked straight out of the gate. Good omens!.

One Mini Pet 40/80 All Together on the Workbench

Next, to test some software, I'd grabbed some PET software off the Net and loaded all manner of things up, and no issues at all. The Mini PET seems perfectly compatible with all the software I'd tried in 40 and 80 column modes. 

I'd definitely recommend purchasing the "SD2PET Future" interface alongside the PET kit if you don't already have one, particularly if you don't a Commodore Datasette (or Disk Drive), else you'll need to load manually via person on keyboard entry, all old school like.

PET Video

We have a number of video modes to choose from, some of which are quite exciting if you happen to have the correct monitor. There are the usual composite PAL and NTSC, real PET Monitor Specific modes, of more interest to some are the options for RGBI/CGA and MDA/Hercules.

Composite video quality is crystal clear when viewed on a CRT in either NTSC or PAL, and no less stunning through the my cheep and cheerful HD Video Converter. With the clarity available from composite there's not a lot of need fort RGBI or MDA except that it gives you the choice of switching on a retro green screen mode.

Close up of Composite Video on an LCD screen

I found CGA/RGBI mode is a mixed bag, although I believe that with a genuine CGA capable monitor (including the infamous Commodore 1024s series) RGBI would be quite stunning, however I have don't have an RGBI monitor to test with. What I do have are a number of CGA to VGA converters, and the picture from these was a touch disappointing, with colour ghosting and artefacting as if the phase was out. I couldn't find a way to rectify this easily. Your millage with video converters may vary significantly. On the other Hand MDA/Hercules I was able to convert perfectly. 

Similar image through RGBI with colour bleeding (note this most likely an issue with the conversion process not the actual video output)

Regardless of RGBI issues, as stated above the Composite is so crystal clear that it's no major loss if you can't get a particular RGBI converter to work as expected, or if you don't have a CGA/RGBI monitor to hand.

---

An Update on CGA / RGBI Video Output

Not being satisfied with the CGA to VGA converter result, I dug out an RGBI to RGBS converter I had in a draw and married that up to a SCART to HDMI converter.  The results are much clearer than I'd achieved with the CGA box. I think we can say definitively that the Mini PET puts out a pretty decent RGBI image (which would look brilliant on a CGA monitor).

 

RGBI converted to RGBS and run through a SCART to HDMI Converter. A much better Image.

For sharpest results with minimal fuss I'd still recommend simply upping the Composite video to VGA or HDMI, or maybe going straight to a TV depending.

---

Should You Adopt a PET?

In short YES! 

If you're interested in Commodore computers and kits, then this kit is for you. All in all this was a fun build and I'm certainly looking forward to experiencing the PET for what it is and was. The Mini Pet 40/80 is quite simply a brilliant kit computer, by far one of the most enjoyable kits I've ever built.

Adopt your own PET today from Tynemouth Software & TFW8b.com

Read More

ZX-Key: New Lite Version

Introducing the new ZX-Key Lite: A mechanical keyboard for the ZX81 that's very similar to the classic ZX-Key.

The original ZX-Key has been available for some time now, and won't be going away anytime soon. However various requests have come my way asking about kit versions, versions that don't really need the Arduino for PC connectivity and similar, the Lite version should be the answer to many of these needs.

The ZX-Key Lite, ready for use with a ZX81

Fundamentally there are only very minor differences between the PCB of the Lite and Original; what changes there are afford the ability to provide options for selling differing levels of kits, or provide assembled units designed purely for use with a ZX81.

The most noticeable difference between the Lite and Classic ZX-Keys is the now optional Arduino Pro Micro. (In reality the Pro Micro was an option on the Classic boards as well, however the LEDS in particular then have zero purpose without modification.) The presence of an Arduino allows the keyboard to be used with a regular PC, a function mainly intended for use in emulators. A great feature that isn't required if you're only intending to use the keyboard with a real ZX81.

ZX-Key Lite: Complete Unit fit for a ZX81

The ZX-Key Lite version can always be updated to a Full /  Classic at a latter stage by installing the missing components and switching a jumper wire. The new board is more about providing choices, more than a fundamental redesign.

ZX-Key Lite: Board Upgraded to Classic and attached to a Minstrel ZX81 Clone

Housing the ZX-Key Lite Keyboard in an attractive case is just as simple as previously. There are 3 components available on Shapeways

1. ZX-KEY Keyboard 'Starter' Case
2. ZX-KEY Keyboard Case 'Top Plate' - Lite Version
3. ZX-KEY Keyboard Case 'Bottom Plate'

The starter case and bottom plate are the same parts as used for the Full / Classic ZX-Keys. A 'Top-Plate' - Lite Version has been designed specifically to house a non upgraded ZX-Key Lite, and comes without the redundant Serial Expansion slot and now un-required extra LED indicator holes.

ZX-Keys Lite Case Top Available at Shapeways

Limited stocks of the ZX-Keys Lite are now available at Sell My Retro. It's predicted that kit versions will be available early in the new year, after supply chains and shipping times have returned to some normality.

Read More

Commodore Educator 64 Mini: Part 3

Here we are at the final article in the Commodore Educator 64 Mini series and there are a surprising number of loose ends to tie off; very probably the reason why it's taken a while to actually get around to documenting them.

This article more or less sums things up and provides some instruction on how get the project up and running. If you haven't read Part 1 or Part 2, I'd suggest starting from the beginning so that it all makes sense.

All files required to build the Educator Mini are made available at the end of the post.

The Final Product: The Commodore Educator 64 Mini

Fitting the Keyboard and Daughter Board

The keyboard is designed to sit quite firmly in the Educator case, it shouldn't require any glue but you may need to file and / or sand the 3D printed case lightly to gain that perfect fit.

The Raspberry PI Daughter Board and monitor cables should be fitted before placing the Raspberry Pi in it's Educator case, as there is not a lot of height to play with right up the back. Cabling running to the keyboard can be inserted at any time.

Educator Min Keyboard to Raspberry Pi Daughter Board / Interface

When fitting the keyboard you need to pay attention to the labels at the header pins. The numbers and letters correspond with a similar arrangement found on the PI Daughter Board. As a plus, the naming scheme also matches that used on a real 64 keyboard.

Commodore 64 Mini Keyboard fitted Snuggly: Pay attention to the jumper setting.

In addition there is a jumper setting to be made, for use in the Mini. A Jumper should be set across pins 1 & 2. The Jumper determines the behaviour of the Shift Lock key, unfortunately there are not enough free GIPO pins on the PI to take advantage of this feature for now.

Inside the Educator MIni

Finalising Model Styling

You'd have noticed by now that the Educator Mini 64 has a somewhat different set of stickers to Lorenzo's PET (much like the real thing really). I've made up a couple of additional mini replica decals to suit the 64, the most obvious of these being the BASIC reference panel.

The BASIC keyword panel is a fairly good approximation the original full sized version and depending on how good your eyes are and the resolution of the printers used to produce the decal sheet could well come in useful.

I've also included Lorenzo's decals for the back of the monitor and the Serial Number Name Plate for the sake of completeness.

Educator 64 Mini Decal Sheet, Including everything an old computer needs.

Getting the Educator Mini up and Running

RetroPie is normally your friend for an easy Linux retro solution. Disclaimer time, I decided not to use RetroPie for this build and went with a standard versions of Raspberry Pi OS (previously called Raspbian).

There are a number of reasons I'm using Raspbian, the main ones for me being,

1. It's just simpler to get the keyboard working with the Vice emulator.
2. I'm only intending to use Vice and Commodore Emulation on the Mini.

Of course your needs may vary, and what ever I've done is really only a suggestion.

Installing the Vice Emulator

Raspberry Pi OS does not include the Vice Emulator as a standard package, or even an optional downloadable package, so you'll need to install it manually. I simply followed the Installation guide on krystof.io 

Once Vice is installed you'll be wanting to add a configuration file to get the emulator looking and feeling right.

Run the following commands to create a sdl-vicerc config file:

mkdir -p ~/.config/vice
nano ~/.config/vice/sdl-vicerc

[C64SC]
MenuKey=293
MenuKeyUp=273
MenuKeyDown=274
MenuKeyLeft=276
MenuKeyRight=275
MenuKeyPageUp=280
MenuKeyPageDown=281
MenuKeyHome=278
MenuKeyEnd=279
WarpMode=0
Sound=1
SoundDeviceName="sdl"
SoundSampleRate=8000
SoundBufferSize=100
SoundFragmentSize=0
SoundVolume=100
SoundOutput=1
AspectRatio="1.000000"
SDLCustomWidth=480
SDLCustomHeight=320
SDLWindowWidth=480
SDLWindowHeight=320
SDLGLAspectMode=0
VirtualDevices=1
IECReset=1
CIA1Model=0
CIA2Model=0
VICIIVideoCache=1
VICIIDoubleScan=0
VICIIDoubleSize=0
VICIIFilter=0
VICIIModel=0
SidEngine=0
SidModel=0
JoyPort4Device=0
JoyDevice1=4
JoyDevice2=4
AutostartBasicLoad=1
AutostartPrgMode=0
DriveSoundEmulation=0
Drive8Type=1571
GlueLogic=0
ETHERNETCARTBase=56832
Acia1Base=56832
AutostartWarp=1
KeyboardMapping=1

Setting Up the keyboard

There are multiple was to of configuring a keyboard for use with the vice Emulator, I've chosen the path of least resistance. Feel free to delve deeper into the heavy customisation that Vice affords. That said intense configuring is a little above what's really required for what is essentially a very cute desk toy.

For the initial steps, we'll basically be following those documented in PJ Evens's MagPi issue 67 article on page 26, make some changes specifically for the Commodore Educator 64 keyboard.

1) install Libsuinput: From your home directory:

cd
sudo apt install get libudev-dev python-dev python-pip
sudo pip install wiringpi
cd git clone github.com/tuomasjjrasanen/libsuinput
cd libsuinput
./autogen
./configure
make
sudo make install

Add the following line to /etc/modules-load.d/modules.conf

uinput

2) Install Python-uinput: From your home directory:

cd
git clone github.com/
tuomasjjrasanen/pythonuinput
cd python-uinput
sudo python setup.py build
sudo python setup.py install

3) Install cbmscanner python scripts:  Download these scripts and uncompress the file. We'll mimic the original Magi Article and install them in a subdirectory off the home dir.

cd
wget  -P ~ "http://dasteph.com/cgi/pet/files/cbmscanner.tar"
tar -xvf cbmscanner.tar

4) Create a new Service: We need to setup a new service to run keyboard scanner on boot by creating a new config file.

sudo nano /usr/lib/systemd/cbmscanner.service

[Unit]
Description=Commodore 64 Keyboard Scanner
After=multi-user.target
 
[Service]
Type=simple
ExecStart=/usr/bin/python /home/pi/cbmscanner/cbmscanner.py
Restart=on-abort
 
[Install]
WantedBy=multi-user.target

sudo systemctl enable /usr/lib/systemd/cbmscanner.service

5) Configure Keyboard Layout: Edit the keyboard file and ensure we're setup for a US keyboard layout.

sudo nano /etc/default/keyboard

# KEYBOARD CONFIGURATION FILE
# Consult the keyboard(5) manual page.
 
XKBMODEL="pc105"
XKBLAYOUT="us"
XKBVARIANT=""
XKBOPTIONS=""
 
BACKSPACE="guess"

We can the reboot the Raspberry Pi, the keyboard should then work as intended.

All the Educator 64 Files to Download

• The 3D Model Files: Model changed for use with a PI 3A
• The PCB Gerber Files: Keyboard, PI daughter Board, Optional Monitor Plugin
• The Decals Set: Educator 64 Styling
• The Python Code: Keyboard Code (See above for required libraries)

Please be sure to refer back to the official  Commodore PET Mini site for the full build details and project history not covered in this series of blog articles.

See all entries for this project:  Part 1, Part 2 and Part 3

Read More