ZX81 Bus Extender: The Expansion Board Solution

Adding expansion boards to the back of a ZX81 is always a slightly terrifying business, a fear compounded with each consecutive item tacked behind the little wedge.

The wobbly expansion of expansions is a near unsolvable problem when using off the (distant in time and space) shelf products, however, when building our own expansions there's really no need to suffer. What's the answer to the wibbly wobbly's? Why a decently designed Bus Extender board and case of course.

ZX81 Bus Extender with an Assortment of Add-ons

We're not embarking on a wheel-reinventing adventure here. The concept of a Bus Extender isn't a groundbreaking discovery; Over the past four decades, resourceful enthusiasts have crafted their versions for the ZX80 and 81. The only hiccup? Laying your hands on one. But behold the magic of our modern age: securing your very own Bus Extender is a breeze. A simple solution? Just place an order for a PCB at any of the numerous fabrication houses like JLCPCB, PCBWAY or AISLER. Now, of course, you'll need something to order, and lo and behold, we've got you covered with the ZX81 Bus Extender gerber files conveniently linked below. Your expansion dreams are just a click away!

Maplin Bus Extender Interface (available at one point in the UK)

The Extender boasts a well-thought-out design, strategically accommodating up to three expansion cards and further expansion possible behind (Think ZXpand or similar). Its layout incorporates a three row hole arrangement on the printed circuit board, with ZX81 BUS 1a duplicated twice, offering the flexibility to house either two-row expansion headers or card slots – you know, the same kind that snugly attach to your trusty ZX81. This Extender knows how to cater to your every expansion whim. You'll require at least one expansion header to attach the thing to a ZX81 or ZX80, and  additional headers of your own choosing for accomodate the expansion cards.

ZX81 Adventures 3x3 Bus Extender

Naturally, a bus extender isn't fully dressed without its cosy enclosure. Picture it nestled within a polished case, a snug retreat ensures seamless operation, cradling expansion cards of your creation. The case boasts an elegantly simple design, seamlessly complementing your ZX81's rear. Oh, and don't forget those rubber feet (12.5mm*12.5mm*3mm(L*W*H)) – they elevate both style and stability, and some M3 screws to hold it together.

ZX81 Adventures 3x3 Bus Extender in Handy Dany Case with Cards

Project Files

If you find these files useful, flip me coffee or beer etc.

• PCB Gerbers Files for the ZX81 Adventures 3x3 Bus Extender
• Hand Dandy ZX81 Adventures 3x3 Bus Extender Case Files

Read More

Tut-Tut: Tomb Raiding on the Vic-20

A New Version of a Modern Retro Classic

Given the resounding success of my little game of Tut-Tut on platforms such as ZX Spectrum, ZX81, Jupiter ACE, and the commendable port by Tynemouth Software's Dave Curran to the Commodore PET, it was an inevitable progression to broaden the game's horizons and introduce it to the illustrious Vic-20, the "Wonder Computer of the 1980s."

---

New to Tut-Tut? What's this Game About?

As the digging season of 1921 draws to a close in Egypt's Valley of the Kings, it becomes evident that your excavations have yielded disappointing results. Despite your ardent efforts, no traces of the fabled and elusive Pharaohs' tombs have been uncovered. However, as the final weeks approach, intriguing rumours begin to circulate, recounting chilling accounts of vengeful mummies exacting retribution upon local would-be tomb raiders.

These wild stories, though tinged with the supernatural and curses, cannot be ignored. As an Egyptologist and daring adventurer, you find yourself presented with concrete leads and irresistible opportunities. The allure of uncovering long-lost secrets and ancient treasures proves too tempting to resist, even in the face of ominous tales of wrathful spirits.

Screen Shots from the Vic-20 version of TuT-TuT

Now, on the cusp of a new expedition, you stand poised to delve into the unknown depths of the Valley of the Kings, ready to face the mysteries and potential dangers that lie ahead. Will you emerge unscathed from the clutches of ancient curses, or will the vengeful spirits lurking in the shadows prove to be more than mere legends? The answers await, as you embark on a daring quest that will test your courage, knowledge, and perhaps even your beliefs.

Prepare to embark on a journey like no other as Tut-Tut takes you on an adventure through the treacherous Egyptian tombs, with its visually stunning colour scheme and a myriad of intricately woven graphic tile sets that bring the ancient world to life before your very eyes.

The Making of the Vic-20 Version  

Tut-Tut initially originated as a BASIC type-in game, designed specifically for the ZX Spectrum and published in Paleotronic Magazine. Further versions of the game for the ZX81, Enhanced 2020 Spectrum Edition and Jupiter Ace, the latest version was one ported to the Commodore PET by Dave Curran. All varieties have all kept the core structure and mechanics as outlined there.

After witnessing the success of Dave's PET version, I couldn't help but ponder the possibility of bringing Tut-Tut to the Vic-20. While considering the similarities between the two machines, I became aware of the numerous disparities that needed to be addressed, particularly in terms of screen real-estate and the Vic-20's unconventional memory management scheme. Luckily i raised the conversion idea with Dave, and he was up to a joint challenge, as I'm in no way sure I'd have got there without our joint efforts.

Screen Real-Estate and Luck by Design

Due to Tut-Tut's origin as a ZX BASIC game, one that need to run quickly, lead to the adoption of a 26x17 character grid for the game board layout (excluding score bars etc). The ZX Spectrum's character resolution is 32x24, constraining the board size to a smaller grid made for more time efficient code in the very orriginal ZX BASIC version. These dimensions sunsiquently stuck for all future conversions.

However, while the grid size was suitable for the ZX line, it posed a challenge when porting Tut-Tut to the Vic-20. Those familiar with the Vic-20 immediately noticed the issue: the Vic-20's screen width is only 22 characters wide (and 23 high). This presented a hurdle that needed to be addressed in order to adapt the game for the Vic-20.

A possible solution could have been to reconfigure the game's levels to fit within the Vic-20's 22x23 screen limitations. This would have been easily achievable code wise, but level design wise it would come at a cost to the overall feel and immersion. A particular issue, as the existing levels are heavily constructed around the games mechanics and already small(ish) screen size.

PAL vs NTSC Geometry Comparison

As luck would have it, the Vic-20's screen sizes can be redefined to an extent. Values in memory location 36864 to 36867 can be POKED to set screen geometry and centring. The results of doing so yielded just the right amount screen width to fit the existing level structure.

Yet another obstacle presented itself: the disparities in screen geometry between PAL and NTSC standards. NTSC, in particular, occupies a wider physical width on a display (not pixels) compared to PAL. However, by a stroke of luck, the constraints imposed by the level width inadvertently resulted in an image that delicately brushes the very edge of an NTSC display. This serendipitous alignment allowed Tut-Tut to make the most of the available screen space on both PAL and NTSC systems.

Graphics Updates

The Vic-20 is perhaps renowned for its vibrant and colourful display, you'd think this would be directly comparable to the ZX Spectrum in terms of its rich palette. However, an intriguing aspect arises when considering the variation in colour appearance based on factors such as the age, make, and region (PAL/NTSC) of the Vic Chip utilised on any given machine. Then there is the screen fuzziness / blurriness, which again varies. 

The diversity in colour appearance on different Vic-20 machines prompted us to reevaluate tile design and colour choices for Tut-Tut. In the Spectrum version, the game employed various palettes that cycled based on the level number, creating a dynamic and ever-changing visual experience. However, for the Vic-20 version, we've opted for a different approach. Instead of cycling palettes, we focused on expanding the selection of available thematic tiles while exercising tighter control over the colour schemes. (A good approach, and If I hadn't mentioned it, would probably gone unnoticed.)

We're pretty confident we reached the required level of ancient Egyptian cinematic charm / ham.

Memory for Mummies?

Another challenge we faced was determining how much memory we could allocate to the game on the Vic-20. By default, the Vic-20 only had a modest 3k of onboard memory, which was insufficient to accommodate even the most streamlined versions of Tut. The issue was further compounded by the lack of a standardised expansion memory layout and location of that memory on a Vic-20. This variability made it difficult to rely on expanded memory for larger games, often leading to the reliance on cartridges for larger game titles.

Ultimately, we proceeded with the assumption that modern enthusiasts would likely possess a contemporary memory solution, such as the Penultimate+, offering a generous 32k of memory. This assumption gave us the confidence that the game could be released on cassette. Little did we know at the time of developing the game that Tut-Tut would eventually become a pack-in title on the Penultimate+2 Cart from TFW8b.com.

Pharaohs' (Pen)Ultimate Enhancements

The Vic-20 version of Tut-Tut comes packed with all 36 levels from the ZX Spectrum 2020 Edition. In addition, we have incorporated 6 exciting new levels (bringing the total to 40) that are carefully integrated throughout the game, providing fresh challenges and surprises.

We have also included the convenient pause option from the PET version, allowing intrepid Archaeologists to take much needed meal and rest breaks. Furthermore, one of the most highly requested features we have implemented is the inclusion of level codes: Enter specific codes to access the harder levels previously reached.

All very good reasons to call this Vic-20 version, the Ultimate Tut-Tut.

 

Playing Tut-Tut Vic-20 as included on the Penultimate+2 Cart

Special Thanks

I Can't end this post without thanking Dave Curran for sharing in the creation of the Vic-20 conversion, he'd paved much of the ground work during his PET efforts.

Additionally, thanks very much to Rob Hull for including the game in the Penultimate+2 games lineup. Very happy indeed to have it listed alongside the other TFW8b titles.

Fancey Delving Deeper into the Vic-20 Conversion?

Further Readings  unraveling the mysteries of Tut-Tut Tomb's and the Vic-20 conversion are now available on the Illustrious Tynemouth Software Blog.

---

Raid the Pyramids for a Copy of TuT-TuT

Commodore Vic-20

• Find Tut-Tut on the PENULTIMATE+2 CARTRIDGE from the Future was 8bit
• Coming in the not to distant future will be a Digital Release 

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

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

TRS80 MC-10

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

Read More

ZXIO Interface for the ZX81: Part 5

IO Boards Comparison, Featuring Hitachi LCDs

Now that we have 2 differing IO boards, why not put them in a side by side comparison. I figured a good test of the board would involve a simple communications project, such as writing out to a character based HD44780 compatible LCD screen.

An HD44780 LCD panel is a character-based liquid crystal display that can display 16 characters per line and up to 2 lines of text. It is widely used in embedded systems and DIY projects because of its low cost, low power consumption, and ease of use. The HD44780 LCD panel is compatible with a wide range of microcontrollers and can be interfaced using a 4-bit or 8-bit command set. We really couldn't ask for a more amiable device for testing ZXIO board differences with.

HD44780 LCD Module Pin out 

Pin	Signal	Function
1	VSS	Ground
2	VCC	+5 Volts
3	VEE	Contrast adjustment 0V: High Contrast
4	RS	Register Select 0: Command, 1:  Data
5	R/W	Read/Write 0: Write, 1: Read
6	EN	Enable. Falling edge triggered
7	DB0	Data Bit 0 (Not used in 4-bit Mode)
8	DB1	Data Bit 1 (Not used in 4-bit Mode)
9	DB2	Data Bit 2 (Not used in 4-bit Mode)
10	DB3	Data Bit 2 (Not used in 4-bit Mode)
11	DB4	Data Bit 4
12	DB5	Data Bit 5
13	DB6	Data Bit 6
14	DB7	Data Bit 7
15	LED A+	Anode Back light +
16	LED K-	Cathode Back light -

Configuring for the ZXIO V1 Board

Connecting the LCD module to the ZXIO is a straightforward process. The output pins O0 to O3 of ZXIO should be paired with DB4 to DB7 on the LCD board to send data from ZX81 to the module. In addition, the output line 6 of ZXIO must be linked to Register Select, while the output line 7 should be connected to the Enable Pin.

The lines responsible for controlling the power to the LCD module and screen contrast are as follows: VSS is linked to the ground, VCC is linked to +5 volts, and VEE is connected to the ground through a variable resistor (across the +5v line). To adjust the screen brightness, connect the LED+ pin to +5 volts and the LED-pin to the ground through a 220 ohm resistor (resistor is optional as some of these Module clones have the required resistor built in).

ZXIO V1 to LCD Module

That's the hardware out of the way, the rest is all down to some BASIC programming on the ZX81 targeting the ZXIO and LCD display module.

HD44780 LCD Commands (Examples)

Code (HEX)	Code (DEC)	Command to LCD
0x01	1	Clear the display screen
0x02	2	Set to 4 Bit Mode
0x0e	14	Set Underline Cursor

The below program connects the HD44780 to the ZX81 / ZXIO V1 at address 16507. It initializes the HD44780 by sending a sequence of control codes to set the display mode, enable the display, clear the display, and set the cursor to the home position. To send each byte, it needs to be split into 2 * 4 bits and sent consecutively. The Enable line must be brought high and then low to signal each 4 bit segment sent.

Subsequently, the program transmits the message "HELLO FOUR BITS" to the HD44780 by encoding each character as its corresponding ASCII code. To achieve this, the ZX81 Characters  should to be converted to their ASCII counterparts. As previously mentioned, each byte is then split into two 4-bit segments, with both the Enable and Register Select lines being set high. After transmitting each 4-bit segment, the Enable line is set low once again.

ZX81 Code to drive LCD in 4bit Mode

The program sends data to the LCD screen at a slow but satisfying speed. While this could be accelerated with code optimisation and pre-conversion of the ASCII text, I opted to maintain program similarity between the code directed at the V1 and V2 boards for a more effective side-by-side comparison (see next section).

Output from ZXIO V1 4Bit LCD Program

Configuring for the ZXIO V2 Board

Setting up the V2 interface involves a process similar to that of the V1 version, with the added advantage of utilising the entire 8-bit input lines available on the HD44780 controller board. On the ZXIO V2 board, Port A pins 0 to 7 (facilitated by the 8255A chip) are mapped to the Data pins on the LCD. While, the Register Select and Enable lines are mapped to Port B pins 6 and 7, respectively.

ZXIO V2 to LCD Module

As we're using the full 8-bit input, the configuration commands we need to send to the LCD interface vary slightly as we no longer need to put the device into 4-bit mode. (In both cases we're only using a very small subset of the available command set, just enough to get things moving along.) 

HD44780 LCD Commands (Examples)

Code (HEX)	Code (DEC)	Command to LCD
0x01	1	Clear the display screen
0x0e	14	Set Underline Cursor
0x38	56	Set to 8 Bit Mode, Configure Display

To transmit data to the LCD interface using the V2 version, we must first configure Port A and Port B on the 8255A IC for output mode. This can be done by POKEing the control register at address 49151 with a value of 128. Once complete, we can begin transmitting control codes. The Enable line is set high via Port B pin (address 49149), while the control codes are transmitted through Port A (address 49148). After each code, the Enable lines is brought low.

As in the previous version, we first convert our message "HELLO EIGHT BITS" to ASCII before transmitting it to the LCD. We begin by setting the Enable and Register Select lines to high via Port B. Next, we send a character from our message string to Port A, and after transmission, set the Enable line back to low.

ZX81 Code to drive LCD in 8bit Mode

Using the the ZXIO V2 board, our "HELLO" message is send somewhat more speedily, though still managing a rather 80s sci-fi future computer message output speed (All very MU-TH-UR 6000: Look out Ripply!).

Conclusions Drawn??

The discussion above only scratches the surface of the potential applications for both the V1 and V2 ZXIO boards. Despite its simplicity, the LCD test highlights the greater versatility of the V2 board in the long run. Nonetheless, this does not detract from the ease of use of the V1 board. With a simple address change to mend the issues outlined in previous blog posts, the V1 board is an ideal choice for a wide range of hardware experiments.

That being said, the ZXIO V2 design offers more possibilities for exploration due to the presence of the 8255A PIO chip. Future blog posts in this IO series will delve deeper into these possibilities.

Waiting for more in the IO series? Take a read of:  Part 1, Part 2, Part 3, Part 4, Part 5

Read More

ZXIO Interface for the ZX81: Part 4

 

ZXIO V2 Card with LED Expansion Board

Previously I built a simple Input / Output board for the ZX81, tested it, identified some self induced errors then hinted that it may be worth changing designs completely. Way back in Part 1 I'd already come to the conclusion that I really shouldn't make this a simple project, so of course I went back and stared things again.

Why Change  Now?

Didn't the last design work and only really require some minor addressing changes? Yes, and that would be a perfectly fine end to the IO project. Still I wished to take this further and build a more capable board. Note that the overall aim of building a relatively simple interface is still a primary goal.

The IO version One card has a minor limitation in that it can only support an 8-bit wide addressing, which may not be sufficient for more complex hardware that requires access to at least a partial 16-bit width address space to access control lines while still being able to send and receive 8 bits. There are several ways to address this issue, such as using 4-bit modes or using 7 bits for data and the remaining bit as a control line. However, the feasibility of these solutions depends on the specific interface requirements of the project.

One possible solution is to double the IO options by adding an extra set of latch and buffer ICs. However, this would increase the complexity of building the board, including routing and address decoding. Other options could involve employing a "standard" IO IC.

The 8255A, the IO Chip of Choice (This Time)

Three suitable IO ICs come to mind for our purposes: the Z80-PIO (Parallel Input/Output Interface), the 8255A-PPI (Programmable Peripheral Interface) and the W65C22N-VIA (Versatile Interface Adaptor). All three of these chips are period correct for the ZX81, in production and available of the shelf today (at least in 2023).

For Version 2 of the IO board I selected the 8255A, as it's pretty well documented, and as a bonus it made an appearance in a ZX81 IO board designed by A. Daykin for Maplin's 'Project Book 04' from 1983. With some modifications to the Addressing and IO configurations to make it more suitable for experimentation, the Maplin board can be made pretty well perfect for our needs.

Period Inspiration from Maplin Project Book 04 - 1983

The 8255A IC is a chip that serves as a programmable peripheral interface, allowing for parallel input and output. It has three ports: Port A, Port B, and Port C. Each port can be configured as either an input or an output. Port C can be split into upper and lower blocks, each with the option to be programmed as an input or output. The IC also has a control register that is used to set the mode of operation for each port. With these features, the 8255 IC can replicate and even expand upon all the functions that the first version of the ZXIO board was capable of achieving. It can actually do fair bit more, but we may explore that latter on in this series of posts. 

Maplin IN 

The Maplins design is appropriately simple, making it easy to connect the 8255A to the ZX81. Note that 4 contiguous address locations require mapping, this performed partly by the 8255A and then the supporting ICs. The 8255A chip has two address lines on pins 8 and 9, which are directly linked to the ZX81 address lines Al and AO. The 74 series ICs then handle the remaining address decoding, and enabling of the 8255A when pin 6 is set to logic level 0. All data lines from the ZX81 are directly connected to the 8255A, along with write and read signals. The reset line on the 8255A at pin 36 is tied to GND.

The 16 IO pins of the 8255A that make up Ports A and C are directly connected to pin headers at the edge of the Maplin board for external device connection. However, the pins of Port B are linked to IC5 and IC6, which buffer the outputs from the 8255A. In conjunction with a set of 4.7k resistors, this setup offers protection against overload. The purpose of this configuration is to drive potentially higher voltage equipment from Port B. A side affect of the buffering is to limit Port B to output only.

Each IO Port and a Control Port are Memory Address Decoded back to the ZX81, Specifically, Port A corresponds to memory address 16380, Port B corresponds to memory address 16381, Port C corresponds to memory address 16382, and the Control Port corresponds to memory address 16383. These addresses are located at the top of ZX81s 8 to 16k range where a copy of the ROM would normally be shadow mapped. Refer back to Part 2 in this series for details on address ranges and suggested uses.

** For additional details on the Maplin Board I'd recommend Allan Faulds blog page, where he builds up an original Maplin IO Board purchased in the 1980's. **

ZXIO V2 OUT

Although there aren't many modifications needed to transform the Maplin into a ZXIO V2, there are a few adjustments I would like to implement to enhance the design's practicality for contemporary experimentation.

The initial modification I made was to adjust the address mapping to span from 49148 to 49151. This will position the device at the upper end of the 40-48k memory segment, beyond the reach of numerous contemporary and historic memory expansion cards (not all, but many). 

I eliminated the buffering ICs from Port B, if buffering becomes necessary, we can always incorporate that back into external hardware. I also took the opportunity to ground output lines on Ports A to C via 4.7k resistors, this will prevent floating values on the lines when they're not connected to anything. Additionally the Reset line on the 8255A is now tied to the Z80 / ZX81's reset signal, inverted through spare NAND gates from the address decoding ICs.

ZXIO V2 Schematic.

The last functional modification consists of two headers. The first one is an IDC header resembling the ZXIO version 1 board, which includes the IO Lines, Ports A to C, Ground, and +5 Volts. This facilitates the use of IDC cables to connect to external breadboards or built-up external devices. Additionally, I added a female header in parallel, allowing for direct connection to plug-in boards, like the LED "hat" shown in the photo at the top of this post.

ZXIO V2 Test Board

Next Post?

This should mostly cover the essential hardware details of ZXIO V2. In my next blog entry, I plan to conduct a quick comparison between the old and new ZXIO boards. Although I am confident that V2 is a more versatile board, V1 remains a decent option for basic experimentation. Lets see, stay tuned for the next post.

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

Read More

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, Part 4, Part 5

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 the other entries for this project:   Part 1, Part 2, Part 3, Part 4, Part 5

Read More