Monday, 14 August 2017

ZX81 Video Monitor Perfection?

A while ago now I fitted the very cool and reasonably priced ZXCCB composite video mod into a ZX81, yielding a much improved video experience, yet this is only half the story in the quest for retro ZX81 video perfection.

There is many a web page or YouTube video devoted to video outputs on retro computers and gaming consoles. Mostly these deal with the somewhat later computing or console incarnations such as the Sega Mega Drive, Nintendo NES or Commodore 64s. There are some excellent write ups on the subject, and you can't go past for some solid information well beyond the scope of this article. The ZX81s video demands though are rather less unassuming than most, requiring only the display of a (hopefully) clear black and white image.

What kind of perfection are we after? I say video perfection, this is a perhaps a little misleading, as what I'm really after is a video experience, an experience that captures the heart of ZX81 usage. This is of course a rather esoteric requirement, if perhaps partially at the heart of using the real deal instead of a emulator to start with.

Below are some of the variations on a theme I've tried, this is not an extensive list of every possible configuration available. So this is not a guide, more of a primer before launching your own quest down the rabbit hole of ZX81 monitor selection.

To CRT or LCD?

Back in the 80s the best monitor for a stock ZX81 was a black and white television. The perfect monitor for a ZX81 with a composite mod in 2017 is probably a black and white monitor with composite inputs. Simply put, the ZX81 does not output a chomiance (colour) signal, only a luminance (black and white) signal, any colour induced into the picture is by pure accident. There are not a great deal of black and white monitors available these days, so what easily available monitor options are available in 2017 and beyond?

There are a whole host of options available these days, from old CRTs to video converter boxes and new LCD televisions. The choice is only limited user preferences and in some cases by the constraints of the ZX81s video signal and it's interaction with modern devices. My personal preference varies, on the whole though I'm rather taken by Sony Broadcast monitors as these induce that all important retro feeling.

Option 1: An LCD TV

ZX81 with LCD television as monitor.
Most (I'm not going to say all as there are weird regional variances) LCD TVs still have Composite video ports. The ZXCCB video mod, the ZXVid and others, are designed to take full advantage of the Composite inputs, outputting a stable and clear image to modern LCD TVs. Frankly the clarity of the ZX81s output on a decent TV is astounding, even on low rent LCD TVs the image quality is far sharper anything you've ever experienced on an unmodified ZX81.

At this point, If you're happy with LCD displays you can stop right here, your never going to get a clearer display out of a ZX81, still there are minor issues with the display, and your personal preferences play a part in the ultimate monitor selection.

It's difficult to find an LCD TV with a 4:3 aspect ratio, meaning that text and therefor the underlying pixels are always going to look elongated. This may or many not be a worry, certainly the enhanced video quality more than makes up for the distortion.  Then again anyone after retro video purity may well take some offence at lack of near squareness in the aspect ratio. Of course an LCD monitor may already fall into the abyss of impure horrors for those with high retro tastes.

I have found that some LCD televisions play up a little when loading tape, loading from the ZXpand or going into fast mode. Anytime the Sync signal is dropped by the ZX81 an LCD televisions may revert to a blue or black screen momentarily, where most CRT monitors will retain the greyish background or display the loading bars normally associated with a ZX81.

Option 2: The CRT Colour TV

Late model TV with the ZX81 using RF out.
The best part about these is that they are (at the time of writing) cheap, though a slowly disappearing resource. I was lucky enough to find a late model 32cm (14inch) xxxx on the side of the road a couple of months ago, I was initially quite happy about that. I say initially as while the general image clarity falls in the okay-ish zone, the refresh rate on the monitor is headache inducing.

Refresh rate is probably misleading here as technically speaking all PAL TVs and monitors are refreshed at 50htz. This may really be a phosphor persistence rating problem. The rating of particular coating thi inside particular model seems to be just high enough to mostly maintain an image between refresh cycles. Doubtlessly this is not the only reason for this units headache producing flaws.

On the positive side, the TV has AV inputs for a very clear image, though more interestingly it also has no issues in picking up a ZX81s RF signal, producing one of the clearest images I think I've ever seen RF wise. So if you're not keen on modifying a ZX81 for composite out a late model CRT TV might be the best video output option.

Regardless of the positives, using a standard TV as a computer monitor in 2017 is just plain awful, even if you're after that retro CRT experience. Sitting up close to a standard flickering television is underwhelming, did we really do this 30 years ago?

Option 3: A Professional / Broadcast CRT Video Monitors

Sony 9inch PVMs
Broadcast and Professional monitors are without doubt one of the better go ways to go if you're after an old school CRT feel without compromising high legibility. These monitors are designed for people who's job it is to make, view and breath Television 24 x 7, so the clarity gained, particularly from the high end editions of these monitors is breath taking for CRT.

Presently being discarded by the TV industry, PVMs and BVMs are highly coveted by many a serious retro gamer. Sought after PVMs are typically 20 inches plus, with extensive features including Composite, S-Video, RGB and YCbCr inputs. All this providing an expansive, high quality retro gaming experience suitable for most retro consoles. Of course a ZX81 in no way needs all the higher end features, we're just after a clear picture.

A ZX81 isn't going to be used from the couch or armchair, most likely it'll be desk based, so clarity is probably the foremost factor in choosing the monitor. Sizes over 14 inches aren't going to add much to experience, and RGB and YCbCr are nice to haves but not important unless using you're also planning on using the monitor with more advanced micros.

Nicely I have 2 Sony PVM monitors, a PVM-9040ME a PAL only monitor that has S-Video and Composite ports and a PVM-9042QM monitor with a full spectrum of video inputs available. Both monitors have screen sizes of 9inchs, a small size by today's standards but not so tiny by the standards of the day. These monitors provide a beautiful viewing experience.

Option 4: Video Upscalers and Converter Boxes

Given the vast supply of LCD VGA and HDMI monitors in circulation, video converter boxes seem like an obvious usage case. But, and this is a big but, not all converters are created equal. Finding a converter box that worked with my ZX81 has proven problematic at best, though individual mileage may vary considerably.

The ZX81s video output, even with a ZXCCB installed is dependent on the version of ULA inside. While the signal can be corrected for missing back porch, the underlay signal generation may not be exactly to PAL standards. I'm not am expert on the subject, but given the lack lustre results using various converter boxes which for all intensive purposes work fine other conversion duties I'd guess this is the cause of the problems I've encountered.

The best converter box I've found is a rather ancient one, an Aver Media TV Box 5. It's unfortunate that the maximum resolution this will pump out is 1024x800, somewhat below the capabilities current generation LCD VGA monitors. For this the TV Box suffers, as monitors perform best at their own native resolutions and the resulting image is a little blurry.

I've put up a little video that highlights the problems or successes of various converter boxes at my disposal. The best I can say is buy one at your own risk, and at the end of the day a cheap LCD television seems by far a better option.

What is Monitor Perfection?

The choice of monitor really comes down to personal preferences. If after a clean and sharp emulator like quality, I've found even the least expensive LCD television is capable of delivering a stunning image (for a ZX81). For a that fuzzy feel good retro experience my preference falls defiantly in favour of PVMs and other broadcast monitors. Just remember that most of these video options are only available once the ZX81 is fitted with a composite modification such as the ZXCCB or ZXVid, both of which are regularly obtainable from the Sell My Retro web site.

Thursday, 22 June 2017

Using SD Cards with the TRS-80 Model 100

Most retro-computers have some form of SD or Compact Flash storage options available these days. The TRS-80 Model 100, Tandy 102 and Tandy 200 were no exception, and these micros had such a device not so long ago, the NADSBox. Most unfortunately it appears the NADSBox can no longer be sourced. So what to do now? Well build my own, very cut-down version I suppose is the obvious answer.

Loading files into the Model 100

As an 80's portable computer with limited native storage, the Model 100 came with some nice features for file transfers built right into the standard ROM and hardware. These features allowed for connecting tape drives, a modem, or better for modern needs, a serial RS232 port for computer to computer transfers. The built in TELCOM package allows for some easy ways to transfers files, and nicer still, the built in BASIC also makes it quite easy to load programs directly from the serial port. So all that needs to be done (of course it'll all get much harder later) is to tap into the 100s native abilities and throw some files back and forth over the serial lines.

To start some hardware is needed for some initial testing, I used a Arduino UNO, an SD Card Shield and a MAX232 IC. The MAX232 is required to convert RS232 level signals to TTL serial suitable for interfacing with the Arduino board. There is not much to it, all that needs to be done is to connect the Arduinos TTL lines to the serial port on the Model 100 via the MAX232. There are a load of examples for wiring up the MAX232, this guide at StackExchange is the one I quickly referred to.

On the software side I wrote up a quick program for the Arduino to send some files from an SD card to the Model 100 (Note the SD and SP Atduino libraries are required). The Ardunio waits for the Model 100 to request a transfer and will then upload a file. On the Model 100 side of things a couple of lines of BASIC is need to first OPEN the COM port, send a request, then download / run the files sent by the Arduino.

In the tests I found a baud rate of 1200 is about the best that can be expected when loading BASIC files via the serial connection. The Model 100 tokenises the text being loaded directly into BASIC, and faster baud rates give errors during this process, I guess there is only so much a 2.4 MHz 80C85 CPU can handle.

Content that the serial SD card loading was quite successful, I'll move along with this project further and see how far I can get with it.

Saturday, 10 June 2017

USB Mouse For The ZX81 And ZXpand (Part 2)

It's been a while since the first part of this article, some exciting developments happened to the ZXpand in between and I wanted to test the interfaces functionality out on the brand new ZXpand+ hardware before posting. I've also given the interface a little moniker, "ZeaMouse". Anyway, enough fluffing around, down to the specifics.

As previously mentioned (in Part 1: USB Mouse For The ZX81 And ZXpand), the USB mouse interface relies on normal Atari digital joystick inputs as found on the ZXpand. Since that time, Charlie Robson unleashed the new ZXpand+ into the ZX81 world. With this comes some potential options, in particular a TTL serial port has been included on the ZXpand+ IDC header, this may be of use for sending proportional mouse data, promising true mouse functionality.

For now though, the Mouse interface maintains full compatibility with the original ZXpand while also making allowances for serial connection to the ZXpand+, connections  that will be used at a later date. Of note for those intending to use the interface on other Micro computers, the serial tracks on the ZeaMouse interfaces IDC header may need to be cut (or removed) in order to avoid potential damage to that Micro or the Interface itself.

ZeaMouse Firmware

Some things end up being a lot less complicated than you'd imagined they would be. The coding behind reading the mouse and passing directions to the ZXpands digital joystick port was one of those things. That's definitely a credit to those behind the USB host shield.

There is nothing overly complex in the code. Mouse movement tracked by time, if XY mouse movement is detected the appropriate joystick pin is set to OUTPUT, a debounce timeout then set to 15, milliseconds providing enough time for a 'button press' to be registered by the ZXpand. While mouse movement continues in the same direction the debounce timings are updated. Mouse button 1 and 2 are both setup to work as a standard joystick button press.

A regular Atari Joystick can be attached to the semi-pass-though port. Joystick movement is given priority and should override incidental mouse movements while using a joystick. The exception to this is where a mouse button is pressed as tracking mouse presses relies on the button being released again to clear the OUTPUT.

A large scope exists for future additions to the code. Provisions for USB joysticks and keyboards (with limited functionality) could also be added with minimal effort. As it is possible to attach the USB shield to a USB hub, allowances for multiple devices to be connected at the same time could also be made. Depending on updates to the ZXpand+ itself, and how the TTL serial lines are read, all manner of interfacing options could become available.

The Arduino Code Files can be found here: ZeaMouse_Arduino.tar.gz

ZeaMouse plugged into the ZXpand+ using a (delightful rainbow (thanks Charlie)) IDC cable, with USB mouse and Digital Joystick connected.

Programing the ATmega328P  / Arduino

Ideally it's easiest to purchase an ATmega328P IC with the Arduino boot loader pre-installed, these can be sourced quite easily. I recommend purchasing a kit that comes with the required crystal, such as this kit from Jaycar: ATMEGA328P MCU IC with Arduino UNO Bootloader and 16MHz Crystal (or a cheaper version from your favourite Chinese supplier).

The ATmega328P chip (with boot loader) will require sketch / code / firmware, this must be programmed outside of the USB joystick interface. To do this an Arduino UNO can be used, simply swap out the existing IC in the UNO, insert and program the new one, then transferring that to the interface.

Required Components

All components should be easily obtainable, there is nothing remotely exotic required to build the ZeaMouse. In addition to the construction components listed in the Main Contruction Shopping List, you will also need a USB host Shield.  Along with a 10 pin IDC cable (which may be split from a larger cable), cut to the length you require, proably not shorter that 10cm. 1 or 2 10 pin IDC sockets and or a 9 Pin D-SUB DB9 Female IDC Connector. The configuration of these cables is dependent on variant of ZXpand being used.
IDC Cables: Top Cable for ZXpand+, Bottom Cable for ZXpand.

You may be able to purchase IDC cables pre-made, however if manufacturing at home there is a nice video on how to make IDC (ribbon) cables over on YouTube thanks to The University of Manchester. The main thing to remember when building a cable is that pin 1 on 1 socket should always go to pin 1 on socket 2.

All parts required to build the actual ZeaMouse interface are listed in the table below.

Main Contruction Shopping List (Excluding the PCB & USB Shield)

Amount Part Type Properties
2 Capacitor variant pth2; package cap-pth-small2
1 Ceramic Capacitor package 200 mil [THT, multilayer]; capacitance 100nF; voltage 6.3V
1 Capacitor Polarized variant pth2; package cpol-radial-10uf-25v
1 Capacitor Polarized variant pth1; package cpol-radial-100uf-25v
5 Diode variant pth; package diode-1n4001
1 MICROCONTROLLER variant kit; package dil28-3-simon-kit; chip atmega8
1 AVR ISP 6 Pin variant pth; package 2x3; pins 6
1 10 Pin IDC Header variant variant 2; row double; package THT; pins 10; form ♂ (shrouded male); pin spacing 0.1in (2.54mm); hole size 1.0mm,0.508mm
1 Ardunio_Power_Header_8_Pins variant variant 3; row single; package THT; pins 8; form ♀ (female); pin spacing 0.1in (2.54mm); hole size 1.0mm,0.508mm
1 Ardunio_Analog_Header_6_Pins variant variant 4; row single; package THT; pins 6; form ♀ (female); pin spacing 0.1in (2.54mm); hole size 1.0mm,0.508mm
1 Ardunio_Digital_Header_10_Pins variant variant 5; row single; package THT; pins 10; form ♀ (female); pin spacing 0.1in (2.54mm); hole size 1.0mm,0.508mm
1 Ardunio_Digital_Header_8_Pins variant variant 6; row single; package THT; pins 8; form ♀ (female); pin spacing 0.1in (2.54mm); hole size 1.0mm,0.508mm
1Bucket DB9 Solder Bucket DB9
1 Red (633nm) LED package 3 mm [THT]; color Red (633nm); leg yes
1 10kΩ Resistor package THT; tolerance ±5%; bands 4; pin spacing 400 mil; resistance 10kΩ
1 220Ω Resistor package THT; tolerance ±5%; bands 4; pin spacing 400 mil; resistance 220Ω
1 Voltage Regulator - 3.3V package TO220 [THT]; voltage 3.3V; part # LM2936
1 Crystal package THT; frequency 16 Mhz; pin spacing 5.08mm; type crystal
1 Crystal package THT; frequency 16 Mhz; pin spacing 5.08mm; type crystal

ZeaMouse Board Assembly

ZeaMouse PCB Layout
All the files required files for ordering a PCB from a fabrication house, or for rolling your own board are contained in the ZeaMouse_Fritzing.tar.gz file. 

As mentioned in Part 1 of the USB Mouse For The ZX81 And ZXpand blog post, the mouse interface PCB is designed to allow easy one sided home fabrication, as well as double sided construction for the more adventurous, or ordering from fabrication houses.

The underside of the PCB is all that needs to be printed, with the top side consisting of only straight tracks and vias that can be linked with copper wire if you choose the one sided method. Linking wires are highlighted in red on the PCB layout figure / image.

All components are of the through hole variety for easy assembly, and there are not a great many of them. The only really tricky part in the whole process is attaching the solder bucket DB9 joystick socket. I used this particular part to save space and keep the interface an acceptable size. In attaching the DB9 connector to the PCB, I first soldered pin cutoffs from the long Ardunio Headers to the solder pads / buckets of the DB9, then inserted the pins through the PCB for soldering to the board. You could also use Generic male header pins in a similar fashion.

Assembly List

Label Part Type Properties
C1 Capacitor variant pth2; package cap-pth-small2
C2 Capacitor variant pth2; package cap-pth-small2
C3 Ceramic Capacitor package 200 mil [THT, multilayer]; capacitance 100nF; voltage 6.3V
C4 Capacitor Polarized variant pth2; package cpol-radial-10uf-25v
C5 Capacitor Polarized variant pth1; package cpol-radial-100uf-25v
D1 Diode variant pth; package diode-1n4001
D2 Diode variant pth; package diode-1n4001
D3 Diode variant pth; package diode-1n4001
D4 Diode variant pth; package diode-1n4001
D5 Diode variant pth; package diode-1n4001
IC1 MICROCONTROLLER variant kit; package dil28-3-simon-kit; chip atmega8
J1 AVR ISP 6 Pin variant pth; package 2x3; pins 6
J2 Atari Joystick IDC variant variant 2; row double; package THT; pins 10; form ♂ (shrouded male); pin spacing 0.1in (2.54mm); hole size 1.0mm,0.508mm
J3 Ardunio_Power_Header_8_Pins variant variant 3; row single; package THT; pins 8; form ♀ (female); pin spacing 0.1in (2.54mm); hole size 1.0mm,0.508mm
J5 Ardunio_Analog_Header_6_Pins variant variant 4; row single; package THT; pins 6; form ♀ (female); pin spacing 0.1in (2.54mm); hole size 1.0mm,0.508mm
J6 Ardunio_Digital_Header_10_Pins variant variant 5; row single; package THT; pins 10; form ♀ (female); pin spacing 0.1in (2.54mm); hole size 1.0mm,0.508mm
J7 Ardunio_Digital_Header_8_Pins variant variant 6; row single; package THT; pins 8; form ♀ (female); pin spacing 0.1in (2.54mm); hole size 1.0mm,0.508mm
J8 Generic male header - 5 pins Solder Bucket DB9, top row: See article for attachment guide
J9 Generic male header - 4 pins Solder Bucket DB9, bottom row: See article for attachment guide
LED1 Red (633nm) LED package 3 mm [THT]; color Red (633nm); leg yes
R1 10kΩ Resistor package THT; tolerance ±5%; bands 4; pin spacing 400 mil; resistance 10kΩ
R2 220Ω Resistor package THT; tolerance ±5%; bands 4; pin spacing 400 mil; resistance 220Ω
U1 Voltage Regulator - 3.3V package TO220 [THT]; voltage 3.3V; part # LM2936
XTAL1 Crystal package THT; frequency 16 Mhz; pin spacing 5.08mm; type crystal

Go Forth and Build

That's it for the moment, so go forth and build the ZeaMouse. I'll be updating and adding features to the firmware over the coming months, and hopefully some specifically ZXpand+ only enhancements that take advantage of the new hardware, so come back every now and again to check for that. As always feedback and suggestions are more than welcomed.

Friday, 9 June 2017

Think Different, the TRS-80 Model 100

And now for something completely different, the first articles (along side the usual stuff) based around the portable computing powers of the TRS-80 Model 100. Yes I'm jumping to the right for a look into something not Sinclair related, though not I think not without some correlation. On first glance there is not a lot to connect the cheep yet stylish Sinclair home micros to what could best be described as an 'American Design' (baring that internals are all Japanese) beige business mans machine.

TRS-80 Model 100 With the Full Kit.

Yet, initial target audience aside, the Model 100 seems to be something outside the a strict business box, it feels more like a portable home computer, with its Micosoft Basic interpreter and built in rudimentary applications. This is not a computer designed to run CPM and Visicalc, not straight from the factory at least, this is a computer that if one ignores initial hefty sales price tag, would have appealed to any home enthusiast of the period. One just has to glance at the included manuals to see that, in particular the Technical Reference Manual.

Yes the Technical Reference Manual, a 127 page thesis on the entire design and construction of the Model-100, this is an 80's hardware hackers dream. The guide presents the full schematics, lists every single part used in construction (with catalogue numbers) and even goes right down to LCD screen design.

The hardware itself is by no means shabby, the Model 100 packs in a modem, full serial and parallel ports, a very clear LCD display and a fantastic full sized mechanical ALPS keyboard. All these features of course contributed to the high price point of the little portable back in 1983. Equally, these features make the model 100 a very interesting and usable(?) machine today. The Model 100 is the perfect kind of micro for some modern experimentation.

All good stuff, however I need to get down to some quickly required (non business) business.

A little Leaking Battery Work Required

I picked a Model 100 very recently, one in excellent condition, this machine seemed well loved (and used) by its former single owner, and included where all the original manuals and documentation. What it did need was a good clean and a new internal battery. Yes is the old leaky soldered-in NiCd battery curse of old computers. 

The Model 100 uses a NiCd battery to keep 32K of static RAM juiced up when the computer is powered down. The battery is rather important as the static RAM is the internal storage medium, there are no flash drives in thid machine. While the battery was still holding charge, it had began it's decay, and had started leaking ever so slightly. Time for a replacement.

Leaking NiCd Battery

A little googling revealed an interesting replacement idea for the battery, suggesting the use of a super-capacitor. This seemed like a perfectly reasonable proposition, and so I took the advice and installed and 1 Frand super-capacitor. If doing this mod yourself, As noted in the original source, insure the 1 Frand super-capacitor used is rated 5 VDC or better.

1 Frand Super-Capacitor Battery Replacement

The replacement procedure it simple, remove the old NiCd battery, solder some wires to the circuit board and attach the capacitor. With Super-capacitors, polarity matters, so be careful to attach the negative anode to the negative wire / solder pad and positive anode to the positive pad. I bent the pins of the capacitor over horizontally before attaching wires, and hot glued (generously) the capacitor to the circuit board to keep it secure.

After putting the case back together I left the capacitor to change for a while, tested that if all external power was removed that yes the 32K static RAM would stay active. No more leaking battery and no more memory worries.

Now it's time to see what else we can do with this beast.

Monday, 24 April 2017

USB Mouse for the ZX81 and ZXpand (Part 1)

A USB mouse on a ZX81 sounds a little mad and yet given the wealth of plug and play electronics available in 2017, it's a comparatively painless task to implement. To be clear I'm talking about a digital mouse, one that uses an Atari style joystick port, where proportional mouse movements are converted to digital signals.

Why a digital mouse? While not being a true proportional mouse implantation, it is a path taken by at least one 8bit computer, the Commodore 64 and it's 1351 Mouse back in the 1980s. As an added bonus this also means the mouse interface should work on all 8bit systems that support the Atari protocol. At the end of the day it's smarter to build on an existing solid and supported base such as Charlie Robsons'  ZXpand with its digital joystick implementation, than it is to implement a non supported (by existing software) standalone proportional mouse interface; at least for now.

So now it's down to how to get this thing to work, and my prototyping weapon of choice is an Arduino UNO armed with a USB host shield. The USB host shield really is the key to the project, it comes with an extensive Arduino / C++ library ready to plug in, leaving the casual developer or hobbiest free to solve other non-USB related hardware and software puzzles.

Stage 1: Getting a Test up and Running

Testing a 4006 IC vs a Diode
As we will be leveraging the ZXpands joystick port for interfacing our mouse (and Adruino) with, we need to trigger all mouse movements by simulating joystick button presses. To achieve this the correct signal lines on the joystick port must be pulled low (pulled to ground). We also need to insure that we don't unduly damage the ZX81 / ZXpand in the process of doing so. Ideally we'd wish to partially electrically separate the Arduino from the ZXpand (partially, as we will eventually be drawing power from the joystick port), so that unintentional voltage are not shot in the wrong direction, particularly during testing phase. There are numerous ways ways to achieve this, I tested 2 options.

Option 1: Use Some Diodes.  Diodes can be placed with the cathode to Arduino output pins, and anodes to the joystick port lines. Our Arduino can then set the input to 0v when we wish to trigger a simulated push button action, and there will be no possibility of feeding +5v back to the ZXpand / ZX81.

Option 2: Use a 4066 IC bilateral Switch. This is the slightly more complicated method, though not by much. A bilateral switch can be used to act as Joystick buttons. Power is applied to the IC switch and 2 connected lines are switched on, much in the same way a relay works. There is an easy to follow tutorial to be found on the subject at Brainy Bits. Th e main downside to this method is that in order to trigger the 5 required buttons on the joystick port (up, down, left, right and fire), we would need 2 ICs and all that extra routing on a PCB that that would require.

I wired up the 4066 IC switch for one input and implemented the diode method on an other, needles to say both of the above variations worked, producing the same results of simulting a button press / movement on the ZXpand Joystick port. I decided to go with the diode method for ease of implementation. If however we were in a position were we might be dealing with different voltage levels, such as a Teensy or Pro Micro with 3.3volts and the ZX81 with 5volts, the switch would be the better option here.

Stage 2: A DIY Cut-down Arduino Clone

If one of the aims of this project is to make something a little more permanent, then using a Uno for the end solution is not the ideal. I could just design a simple shield for the UNO, however the USB host shield will still be required, and with the addition of an extra shield on top, would leave the whole project a little unwieldy for what it actually achieves.

It seems apt to mention here before proceeding, there is such a beast as a Adruino UNO and USB host in one easy to use package. Freetronics makes the USBDroid, this could be a perfect solution for proof of concept stages, however to use this in a semi-permanent ZX81 mouse interface seems a bit of a waste.

Bare-bones Breadboard Arduino (and shiny lights)
Anyways, the last little blurb aside, the intention is to mount a USB shield on a Arduino clone board, one with all the other required elements built in. All parts, from the diodes to connectors for the the joystick port and a through port for an actual digital joystick. As I've never built one of these before, I thought it best to build a bare-bones cut down Arduino on a breadboard first, then hook that up a USB shield for some more testing.

At the risk of sounding like a paid advocate for Freetronics, I used their easy to follow Tutorial - build your own "breadboard Arduino", as the basis for the rest of the design. The rest of the design consisting of connecting to USB host shield and the ZXpands joystick port.

There are a number of Arduino pins that must be connected to the USB shield, INT, SS, SCK, MOSI, MISO and RESET. Also required are  a 5v power source (which we will eventually tap from the ZXpands joystick port) and a 3.3v input. To generate the 3.3v a down voltage regulator circuit needs to be added to the end design.

For full details on the USB Host Shield, there is an extensive manual and resources available on the Circuits at Home website. I can't recommend that highly enough.

Stage 3: Build a Prototype Mouse Interface PCB

Mouse PCB. Note the USB Host Shield Mounts on Top.
Lastly on the hardware side of thing I wanted to build a demo PCB board to bring everything together. I employed the help of Fritzing for the PCB design. Fritzing is not the most feature rich of programs, however it is approachable and presents a low learning curve to the casual user, perfect for these small projects.

I wanted the end PCB to be easily producible and assemblable at home. As such I designed the board to be primarily one sided, any tracks that had to be placed on the topside are straight. The final (or ongoing) Fritzing files will be available for download. if anybody plans to make the PCB at home, only the bottom layer needs to be etched and copper wire strands can be used for the linking via's. If preferred, the boards can be fully double sided for usage by PCB fabrication houses or the DIY experts.

I've covered the home PCB making process I use in a previous article way back when I first started this blog. If you're interested refer to Creating A PCB For Mounting The Keyboard Controller.

Next Time: Software and Other Bits

Coming up in Part 2, I'll look into the software side of the project, post the schematics, code and parts list for building the ZX81 USB mouse interface. For now feel free to have one or more views of the teaser video on You Tube.

Thursday, 23 March 2017

Peeking into the ZX81s Screen Maze

While thinking about some possibilities of how to approach various projects in my to-do list, I realised that these were going to need some screen reading elements, or rather I'd need to PEEK into the display file to see what was going on. This lead to some re-research into how the ZX81 handles its screen output. While some excellent information on the subject is not hard to find, I figure a poke into this might be of use to others.

What's being displayed by the ZX81 on a monitor at any given time is not exactly a mystery, nor is how it got there. What  can be mystery is how to retrieve that information for (re)usage in an application. Actually that's not much of a puzzle either, though possibly a little ambiguous at first.

The ZX81 stores screen related information in a area of memory known as the "display file" or DFILE for short, this is outlined briefly in chapters 27 of the ZX81 manual. What's not made quite so clear is how to access that area of memory, or how that area is configured at any given moment by the machine. This last part is particularly crucial if your ZX81 has less than 4k of RAM (Not of any real concern these days I suppose, but you never know.)

The relationship between the ZX81 Display File and D_File system variables laid out for easy reference.

First off we need to know where the DFILE resides. The location is not static (unlike the ZX Spectrum's DFILE) and moves up or down depending on the size the BASIC program listing. Thankfully there is a system variable, D_FILE, which stores this starting location. What we need to do is PEEK the address of the D_FILE variable to ascertain the location of the actual DFILE. Note that address is stored in 2 bytes.

PRINT PEEK 16396 + PEEK 16397 * 256

On a freshly booted system the result of  the above should be 16509. You might notice that this is also the starting address for the "Program" memory area, which indicates that there is currently no program stored.

Next we can determine how large the DFILE is by reading the system variable VARS. This is where a non expanded ZX81 will differ from one with a RAM pack attached. The returned value will give you the starting location of the user Variables memory allocation area. Again note that the returned listed values from PEEKing the VARS system variable assume there in no program loaded.

PRINT PEEK 16400 + PEEK 16401 * 256

Variables starting address on a 1k ZX81 (or 2k Timex 1000) is: 16534
On a ZX81 with 4k or more expanded memory: 17302

If we subtract the value of D_FILE from VARS, the byte allocation or size of the DFILE is revealed. What we notice is that on a 1k ZX81 the default size of the DFILE is 25 bytes, and on a 4k plus system the DFILE is allocated 793 bytes. The massive (overstatement) size difference between an expanded and unexpaned machine comes down to how the ZX81 handles the DFILE. On a 2k or less machine the DFILE is expanded as it is required, while on a 4k plus computer the DFILE is always fully extended.

On a 1k or 2k ZX81, each of those 25 bytes contains a CHR$ 118, the Newline Character. One CHR$ 118 marks the start of the DFILE , and when a line is printed to, the DFILE is expanded to a maximum of 32 characters per line, with each line always being terminated by a Newline.

A ZX81 with 4k or more always has a fully expanded DFILE, containing 25 CHR$ 118, marking the start of the DFILE and end of each line, plus 32 * 24 characters, which are initially CHR$ 0, the space character, yielding a 793 byte total.

Putting the above into practice, two programs below demonstrate how to POKE to the screen directly, instead of PRINTing. The key lines in both applications are 80 (highlighted), where the second PEEK address is adjusted for either the expanded or collapsed DFILE.

1) Program For a 1K ZX81. If using an emulator make sure it's set for 1K
20 PRINT AT 2,8;"+++"
30 PRINT TAB 8;"+ +"
40 PRINT TAB 8;"+++"
80 POKE PEEK 16396+PEEK 16397*256+41,CODE A$
90 GOTO 60

2) Program For a 4K and up ZX81. If using an emulator make sure it's set for 4K or more
20 PRINT AT 2,8;"+++"
30 PRINT TAB 8;"+ +"
40 PRINT TAB 8;"+++"
80 POKE PEEK 16396+PEEK 16397*256+109,CODE A$
90 GOTO 60

The programs above have been modified from listings originally published in the September / October 1981 issue of Sync Magazine, which is available from the Internet Archive. It's well worth trawling through the entire Sync back catalogue for all manner of useful insights.

Using the information above you can see how easy it is to read or write to the ZX81s screen, and then take that into more complex programs. For a deeper insights into the ZX81s display, you can't go past Wilf Rigters' extensive write up The ZX81 Video Display System.

Finally, yes you really can do something interesting with this information, the below maze is generated by a program written in C for the Z88DK compiler. The Maze generator relies heavily on being able to read the Screen / DFILE (that and a maze algorithm). Feel free to download The Maze C source and ZX81 P file for perusal.

Output of the ZX81 Maze Program.

Tuesday, 7 March 2017

RAMming in Some External Retrofits

With the internal updates out of the way in the last 2 Retrofitting articles (Simple Start to Retrofitting a ZX81 and Advancing along with the Retrofitting of a ZX81), it's time to add an external RAM pack. Nothing unusual there, after all the first expansion (and possibly the only expansion) any ZX81 owner attaches to the back of their humble 1k micro is a 16k RAM pack. But this is 2017 and a simple 16k RAM expansion just doesn't cut it, and it certainly didn't cut it back in 2011 either, and so enters the amazing ZXpand, bringing RAM packs and ZX81s into the new millennium.

The Amazing ZXpand


The ZXpand created by Charlie Robson is firstly a 32k RAM expansion, nothing odd there, however it's also an SD card reader, provides user configurable memory mapping, hires graphics modes, a reset switch, pads on the circuit board to add a joystick port and optionally (via an extra add on expansion) the ZXpand can accommodate an AY sound interface with a fully built in joystick port. For the moment I'm happy with the base model sans AY.

In a nut shell the ZXpand does for the ZX81 what the DIVIDE (in all it's incarnations) does for the ZX Spectrum. Coming pre-assembled, the ZXpand plugs right into the back of a ZX81 (or TS1000) and is ready to go. The build quality of the board is exceptional, and there are even little amusing gems of ZX81 lore written on the boards Silk screen layers.

If you need some convincing of the ZXpands merits check out VectrexRoli's typically flamboyant video review on the Youtubes.

The ZXpand is intermittently available on Sell My Retro, normally released in batches. You'll need to watch out for these appearing as they sell very quickly. The AY Sound interfaces seem to go at an even quicker rate.

ZXpand Needs a Case

Now for all it's merits the ZXpand comes without an encasing. The good news is that there are options, firstly if you have an existing Memotech RAM expansion, then you can gut that, make a minor modification, then slide the ZXpand into void.

The Elongated Cube ZXpand Board Enclosure

Alternatively, should the massacre of harmless ancient peripherals disturb your delicate sensibilities, or more likely you find yourself bereft of Memotech devices, then as luck would have it mhudson52 on Sell My Retro, has recently started producing 3D printed enclosures in various form factors. Models include a classic Memotech inspired design or the ever popular elongated cube form factor. Both versions have counterparts that allow for the AY interface. I obtained a rectangular version of the ZXpand Board Enclosure for my purposes.

The Enclosure  is a well designed smart little black case. The ZXpand fits very snugly inside, and the
whole unit nestles perfectly behind a grateful ZX81. Being 3D printed, the board enclosures finish is a little rough, so don't expect molded plastic perfection.

The only minor short coming in the cases design is the slightly diminutive hole at the back for accessing the ZXpands momentary reset / NMI switch. In order to press the switch through the case you require something the width of a knitting needle or a thin tablet stylis.

Wire Soldered to the ZXpands Pads

Adding A Joystick Port 

ZXpand Joystick Solder Pads
Adding a joystick port to the base ZXpand requires a little soldering, a DB9 male connector, and the usual assortment of wires. The location of attachment points / pads are outlined in the ZXpands manual and these can easily be hooked up to a male DB9 solder-able connector. Wiring should follow the standard Atari 2600 joysick pinouts.

As I intended to attach the  joystick port to the ZXpand Enclosure, I figured the best way would be to separate the metal casing on the DB9 connector. This would allow me to attach the connector to the inside of the enclosure and at the same time cover up any defects created when making some necessary holes in the enclosure on the outside.

Atari Joystick Port Pinout
Atari Joystick Port Pinout
DB9, with Metal Surrounds Separated
The two metal halves of the DB9 connector are pressed together, a lip in the bolt / screw holes keeps two halves firmly in place. To separate them you can file away the lip around the bolt holes. Once separated connecting wires from the ZXpand joystick pads can be attached to the back of the DB9 shell.

After some examination and testing, I found the most convenient location on the enclosure to place the DB9 connector was at the bottom right. This placement allows the ZXpand to slide in and out of the case without hindrance from the DB9 connector.

Using the outer metal shell of the connector as a template, the placement of the joystick port can be marked out before cutting into the case. I used a Dremel like tool for cutting into 3D printed case. You need to be careful and take your time, as printed plastic likes to re-melt when heated by friction generating power tools. Regardless of how genteel one is, the process will most likely leave a rough edge that needs to be carefully filed away by hand.

The Back of the ZXpand Enclosure, With Holes for the DB9 Connector and Mounting Bolts Cut Out

Joystick Port Mounted
Mounting the DB9 connector is straight forward, if a little fiddly. The enclosure is a little flexible and the mounting point I chose is rather close to one of the ICs on the ZXpand. For this reason I chose to use plastic bolts and nuts for mounting; I didn't want some accidental short circuiting taking place when inserting a joystick.

As the case is designed to fit the ZXpand snugly, the wires to the joystick port had to be routed via the bottom of the enclosure, not a major issue, as these can still be tucked up inside the case mostly out of sight and definitely out of the way.

Joystick Port as seen from the Rear of the Enclosure.

It should also be noted that there is no standard for Joystick interfaces on the ZX81. So much of the software supported by the ZXpands Joystick port has been adapted by the community. There is a list over at the Sinclair ZX World forum of some of the supported tittles.

Getting to that Reset Button

Fully Sprung Reset Tube
As mentioned earlier, the case design makes is a little challenging to access the reset / NMI switch. With fate on my side and some creative thinking I had the means to bodge up an effective solution to that minor issue.

In my draw of miscellaneous items I found a small aluminium tube with a handy flange on one end. The rim fitted over the momentary switch perfectly and the barrel was the perfect length and width to fit through the reset hole on the ZXpand enclosure.

To complete the switching mechanism, a spring extracted from a donor retractable biro was cut down to size, fitted over the tube, and a perfect rest switch was in place.

Another option for the reset switch length problem would be to de-solder the existing SPST momentary push button, replacing it with a longer stalked equivalent. This one from Altronics would do the job quite nicely, any components vendor should have similar items.

So that's it, a ZX81 fit for use, super charged and in better shape than it was 36 years when rolled off the Sinclair (ok Timex) production line.

ZXpand / Enclosure attached to the ZX81. The Reset Switch is the Perfect Length

For full details of the Retrofit, see See  Part 1 and Part 2 of this guide.

Sunday, 19 February 2017

Lode Runner on the ZX81 - Part 2 (Level Design)

There are going to be numerous challenges facing the design and implementation of Lode Runner on the ZX81, and one of the first I need to consider is level storage.

The original Apple II version of Lode Runner comprised 150 levels, these were loaded from disk when required. The ZX81 doesn't afford us the luxury of being able to load from a disk or tape without clearing the running application and memory. So even if we assume our ZX81 has 32k of RAM (about the maximum for the time), squeezing all 150 levels into the diminutive black box is an insurmountable task.

There are modern storage solutions available such as the ZXpand, that could be used to negate the space restrictions, however there is no common file access method shared across these modern deceives. So regardless of current available solutions, the challenge here is to fit as many levels as possible into the resources we do have at our disposal.

To make the challenge slightly easier I'm going to base the level design on the Apple II version, not the (possibly expected) ZX Spectrum incarnation. The reason for this is a simple matter of level storage space. The Apple II maps are a convenient space saving 28 wide x 16 tiles high, where as the Spectrum versions comes in at 32 wide x 22 tiles high. Or to put it another way, 448 tiles on the Apple version versus 704 tiles on the Spectrum version per level to define.

If we look to any "type in" game from the period as a (bad) example, most defined entire screens in the program listings on a one to one tile basis. This method would uses 1 byte per tile, and clearly there is not enough space in a ZX81 for even 10 levels defined in this manner (and still have a game to play). It's imperative to compress each level down as far as possible.

The solution is to store the tile type and the number of tiles(of the same type)  in succession into 1 byte. To achieve this, we can use two 4 bit numbers. This affords us up to 16 available tile types, and 16 successions of that tile. Wwe add the number of tile repeats, 0 to 15 to the tile type value. The tile type value is bit shifted before the addition, and this will produce an 8bit number we can store.

Lode Runner Map Tiles: 4 bit Number Values Chart
Tile No4 Bit ShitedLevel Starting Position Tile Type
000000Empty: Clear Tile / Background
001016Block: Can't dig through tile
002032Bricks: Can be dug into to create traps
003048Bricks, Fake: Player falls through fake bricks
004064Rope: Player can move horizontally, or jump down
005080Ladder: Visible all game / level
006096Ladder, Escape: Visible only after all gold is collected on a level
007112Gold: Player to collect all gold
008128Guard: Starting position of Guards. After level begins guards fall from the top of screen (after being trapped).
009144Player: The Lode Runner

For example, using the table above, if we require 4 Bircks in a row, we take the value of Bricks, 32 and add it to the number of required repeats 3, for a total of 35. In, in order to produce the entire starting positions of the first level of the Apple II version of Load Runner, each of the 16 rows would be defined as bellow.

01) 15,1,96,8,
02) 3,112,12,96,8,
03) 38,80,38,2,96,8,
04) 6,80,73,96,3,112,3,
05) 6,80,3,33,80,2,38,80,33,
06) 6,80,3,33,80,9,80,1,
07) 4,128,0,80,3,33,80,9,80,1, (missing right guard and gold)
08) 33,80,36,3,39,80,38,
09) 1,80,15,0,80,6,
10) 1,80,10,128,4,80,6,
11) 40,80,41,80,6,
12) 8,80,9,80,6,
13) 6,112,0,80,73,80,2,112,2,
14) 3,80,37,8,38,80,
15) 3,80,8,144,1,112,8,80,
16) 47,43

Lode Runner, Level 1, Apple II Version

After reading the level data as outlined, the ZX81 level would look something like the bellow screen shot (if using standard character set, no hires graphics yet). Notice that the the escape ladder is drawn in with the "S" character.

Lode Runner, Level 1, ZX81 level Map., Starting Position.

Rather than guess the levels layout, I converted directly from the LodeRunner TotalRecall levels, as (re-)implented by Simon Hung. The TotalRecall levels are implemented in ASCII, which makes reading them easy. The ZX81 map is missing the 2nd guard and gold on line 7, I overlooked these items when writting up the test.

That's all for now, be assured I'm still wotking away on the project, it's just going a little slower than anticipated due to some time and life constraints.