Handheld RC2014 System (RetroChallenge (sorta))

One of the great things about making stuff is that you can make stuff that doesn't yet, or shouldn't exist.  

I honestly didn't get anything done on my RC2014 projects for RetroChallenge this year, other than an idea, and some 3D printed stuff within the final few days of the month.

I've had it in my head for a while to make a gameboy formfactor RasPi system for a while now, even though I already have a portable Pi emulation system in my Atari Lynx enclosure.  So I found a model for the "super retropipod" enclosure on Thingiverse and printed it out, and ordered and then modified a 3.5" lcd and shoved it all into the case.

I decided i didn't want to make a PCB or hack up a perfboard to support tact switches, and I had a bunch of largeish 12mm tact switches, so I modeled and 3d printed mounting boards for those too.

Then I had an awesome-horrible idea.  I would mount a RC2014 inside the enclosure as well!  If I managed to make the enclosure a little thicker (about 1cm) I could easily fit a RC2014 mini or micro inside the case along with the pi and all of its fun stuff.  I could even probably also fit in the TMS9918A video card piggybacked onto it inside the enclosure.  So I modeled and printed out the thickness extension too!

Long story short, I have the beginnings of my ultimate multipurpose Pi/RC2014/Llichen-80 handheld!  And she's a chonky beast too!

I modeled and printed a piece to sandwich between the layers of the "pi-boy" enclosure I printed, and added a space for a nice switch for power on the side.  I still need to wire it all up, but I'm on my way to having this thing be AWESOME!  

Although I still want to make a "tall-boy" at some point... take two GB DMG enclosures, and extend the screen space to be taller, and put in a rotated, vertical monitor in the space there.  eg, use a 4" or 5" lcd in portrait instead of a 3.5" in landscape...

Next actions on this project:

• Wire up the buttons to the GPIO header
• Wire up the LED on the front panel to the GPIO header
• figure out a power solution for the system (batteries, recharging, etc)
• Mounting solution for RC2014 inside the enclosure without it moving around
• Make a 2-board backplane for the RC2014 so I can also have the TMS board internally
• Wire the TMS to the monitor too, and figure out a quick way to switch inputs... perhaps two NC momentary buttons that disconnect the monitor from each of the two inputs, so it will auto-switch to the other input. (or short the input to ground via 75Ω resistor?)

Links:

• Super Retropiepod enclosure
• Retropiepod enclosure extension and tact switch mounts
• GPIOnext (formerly GPIOneer) software to use GPIO inputs as keyboard presses

RetroChallenge 2021-10 intentions (RC2014 Projects Braindump)

Hi all.  So I've decided to settle on working on various RC2014-based projects for this RetroChallenge.  I have a few related projects that I'm kind of in the middle of and have set aside for various reasons... the primary of which being my "ooh... shiny!" reason, where I get pulled off existing projects to start something else thanks to my brain.  ;)

Most of my RC2014 projects are all intertwined so it makes sense to kinda work on all or each of them simultaneously...

Anyway, here's a few things I'd like to work on this month:

"Lego Brick" RC2014

This is my main RC2014 system.  The display on it somehow developed a weird glitch on it that looks like Lichtenberg lightning print.  

I have a spare LCD panel that I can swap into place, i just haven't done it yet.  

Llama Vampire-Storage system (LLVS)

This is my "storage over serial" system that I started working on in the past.  It basically uses something like ANSI escape sequences over your serial console to do disk accesses. It could eventually be used for other devices as well like network and printer access, reatime clock, GPIO, etc.

Eventually, it would be great to have the LLVS "type in" a BASIC program that is a simple bootloader that will load in a custom CP/M kernel with  LLVS routines, so that a super cheap (and slow) CP/M system can be booted without boot roms, CF card module, or any of that expensive stuff.  

Also to be included with this are tools that natively talk the LLVS protocol so that you can retrieve and store content to your host machine from "standard" CP/M systems.

Obviously this also requires a host/terminal side of things too, which is being implemented in python currently, but could easily be reimplemented in C/C++ to be compiled in with the Pi Zero Serial Terminal module, so that you can use the Pi Zero's SD card as your CP/M storage device.

RC2014 Pro Build

I have most of an RC2014 Pro kit around, and I'd like to build up the various parts of it including the backplane, compact flash storage, and so on, so that I can finally do a native CP/M boot up.  This could be combined with the LLVS above to allow for easy transfers to and from the CP/M system and your "host" system.

I have a few modules that I want to build up and test and experiment with... i've just never really dug in to work on it.

Llichen-80

Llichen-80 is a CP/M kernel-based system that takes my LLVS-based system a step further, and adds in the TMS-9918A video card as its main graphics display.  This could be used simultaneously with the standard terminal, or as a replacement to it.  I haven't quite figured all of that out yet.  

I plan on making a few CP/M programs that configure the TMS and download files from the mass storage device into it, for loading fonts, graphics, etc.  Or just to use it for console output.

For use with a single composite display, I also have an hardware video switcher (simply two relays with a digital gpio input) that could be connected to a digital out from the RC2014 or as a GPIO line from the Pi Zero on the Pi Zero Serial Terminal card.

I have some of the basics of this working, but nothing really solidified.

The Llichen-80 system consists of an RC2014 CPU, Clock, Pi Zero Serial Terminal cards, along with the TMS9918A video card.  The Pi Zero Serial card is set up with a PiZero W, and is not running the standard PiGfx kernel, but instead running linux, so that it can run my python terminal application, so that i can add in all of the LLVS code

RC2014 Mini / Micro Mods for CP/M

It's well known that by removing some components on these boards, you can use them as a standard CPU module when upgrading to a CP/M system... replacing the fixed RAM/ROM for the switchable RAM/ROM and so on.  But it would be nice to be able to simplify this so that the RAM/ROM on the RC2014 Mini or RC2014 Micro could be made to be switchable using a simple jumper to connect to the logic needed to do the switching.  Not sure that this even makes sense being that the Mini CP/M upgrade exists, but I'll be thinking about it...

RC2014 Peripheral and IO Switcher Traffic Cop Thing

This one is more of a musing about a new Z80 system architecture, but it could be prototyped using lightly modified  RC2014 modules.

I feel like a peripheral manager type of card might be useful for a new system... one board that has ALL of the logic for peripherals, to switch them on and off, so that peripheral cards needn't have this logic repeated on all of them.  Then it could be vastly simplified for chip count.  It could handle catching bus requests for reading/writing memory or port based io, and work it out to be a single enable/disable line to be run to your peripherals.  That way peripheral cards could be made much simpler, and more easily moved around in the RC2014 memory and IO space... perhaps even live while the system is running.  It would be easy to make it such that any peripheral could be moved to any address, enabled, disabled, etc. Hmm...

RC2019-10 - The Globbing Of The Projects... Globjects?

Hey.  Long time no post.  How y'all doing?  I'm still here. I've gotten a lot of small things done over the past half year, and a lot of things almost done as well... and some long-standing projects not done too.  So, I've been almost productive...  Anyway, I hope to try something different this month for the RetroChallenge RC2019-10...  Let me explain...

The main projects I've been trying to work on recently are:

LL530 USB interface for Amiga serial keyboards and controllers

I've been poking at it a little over time, and am really damn close to getting the proper firmware done for it, but I just haven't finished it.  Which is stupid because I can actually sell these things once I'm ready!  I have keyboard working for all but my A1000 keyboards, and I have joystick/mouse/paddle working... but not at the same time in a way that I'd be proud of.  I also will eventually need to rev the board to fix three layout issues; a power/ground short, lack of ICSP programming header, and lack of pull-up resistor for VCS paddle sampling.

Llichen-80 Computer (LL80)

Okay, so it's not really a whole other completely new computer... but it is a specific configuration of the RC2014 Z80 computer.  It started out this year as a whole lot of customizations to standard (but old, obsoleted) RC2014 boards to add bank switching, using the 8 bit parallel IO board (the one with all the LEDs and switches!).   Now, I reworked the idea so that I just use the standard "Switching ROM" board and the "64k RAM" board.  That simplifies the design; making it easier to get to the LL80 spec, since just using those two cards replaces two RAM boards, one ROM board, and one IO board... plus no modifications to any of the boards are necessary.

The other part of the LL80 computer is the "LLSuper" board.  This is an arduino-based supervisor of sorts that sits on the serial console port.  It acts as your usb-serial interface for when you use a desktop computer as a console.  This board used a CH376S USB Drive interface to access any flash drive as mass storage (it's a neat part.. like $2 for a board with a USB A port... it talks TTLRS232, SPI or parallel, and handles all of the disk switching, FAT filesystem etc. So there's very little overhead on a tiny ATmega micro.  I also have an I2C based clock chip board for this.  This sits between your console and the RC, and lets you have a kind of shell access to the disk from the console, as well as from the RC.  The RC side of things also got direct access to virtual disk image files with a sector-based interface, as well as direct fileio...

The next steps would have been to write a CPM BIOS and make the thing boot into that.

But I've come to realize that even the LLSuper board is unnecessary.  I can accomplish near-similar things using the standard  "Pi Serial Console" board.  If i use a RasPi Zero, and boot linux on it (or adapt the code in the PiGFX kernel, I can put in my serial-disk IO stuff, for cheaper, without needing to fab up my own board.  I started to mess around with this using my new RC2014 Micro, a Pi Zero, and a slight hack to attach the reset line of the RC to a GPIO of the Pi, so i can now reset the RC from the Pi.

I do have the protocol all worked out for the serial interface using unused ANSI escape codes, which are made for custom purposes like this.

A102 - Portable Emulated Amiga in a Tandy 102 shell

This is one i've wanted to work on since last year. I was trying to get it done before Rochester MakerFaire last November, but burned out on it.  It essentially is a project that joins together a bunch of parts... all of which I have:

• Raspberry Pi 3, with Amibian... booting right into an emulated Amiga environment
• Tandy 102 shell, rescued from some unrepairable 102's
• Tandy 102 keyboard, also rescued (keys bind as they're pressed though)
• Amiga 500 keyboard interface board, from a long-gone computer
• My LL530 USB serial keyboard interface board
• Amiga mouse
• 3.5" composite LCD panel (new, $10 online!)
• large Power Bank battery pack

This project entailed hacking the keyboard (removing the wiring/traces on the board) to convert the scan matrix to match an Amiga 500 keyboard.  This gets connected to the LL530, which is plugged into the Pi.  All of it gets jammed into the 102 shell, and becomes a portable computer. 

I waffled a bit on this... mainly because the keyboard stuff would be a chore.  I want to remove every key, and clean their travel tubes, to eliminate the keys binding.  Wiping out the traces and rewiring the board seems like it's going to be a tedious process... So i kept thinking that maybe I should make a cherry-mx switch based board to fit the keyboard space instead... and... yeah... i just kept going down that same path of "maybe i should do this other thing" instead... instead of actually moving forward on any of it.

I also pondered putting the entire Llichen 80 computer into this shell... which brings us to...

RC2019-10!

So that's where RC2019-10 comes in.  Why almost fail at three projects when I can almost fail at ONE project! Seems a lot more efficient!

The end result for this month will be to have a working portable laptop computer that runs Amibian (Linux), RC2014 (via serial connection to the Pi) and general Linuxy stuff.

Or, more granularly, here are the tasks as I see them now: (in no particular order)

• Finish the Keyboard + Joystick/Mouse firmware for the LL530
• remove the wires on the 102 keyboard PCB
• clean the travel tubes on the keyboard
• rewire the keyboard to match the Amiga's matrix
• Wire the keyboard to the Amiga 500 interface board
• Connect the RC2014 Micro via the Pi's serial interface pins
• Additional buttons on the device to cleanly shut it all down
• Have it all powered from a 5V/USB powerbank mounted internally
• Serial-console textmode app for Linux that provides the beginnings of a backchannel to 

Stretch goals:

• Full drive interface for the RC2014
• CP/M BIOS for the RC2014 that uses the serial protocol
• Fit the RC2014 Mini + 64k RAM + switching ROM + TMS9918A cards inside the case
• Have the video switchable between the Pi and the TMS9918A video card

Not sure how far i'll get, but it globs together all of the recent projects in a way that I won't feel like I'm neglecting one project by working on the others... since they're all the same project now. :D

Llichen-80 (Retrochallenge 2019-03 Update)

I had originally intended for any time I could devote this month to the 2019-03 Retro Challenge was going to be for a new version of my RC2014 Z80 computer emulator, adding support for the TMS9918A video display chip.  But my plans have changed.  With the recent advancements with The 8-bit Guy's "Commander X16" 6502 computer, I decided to start reviving a project I was considering for a while.  The great thing is that there's so many aspects to it that it's like a grab-bag of things to do.

The original idea was to sit down with a C64, floppy drive, monitor, joystick, mouse and reference books, and start with BASIC, writing a text editor, assembler, IDE, etc and work my way up to having a windowed operating system like GEOS with a few utilities and such.

Except now, the spec of the system is designed by me, and I'm building that too.... Which meshes in perfectly with my original intention to build a RC2014+TMS9918 emulator, which I can use for initial development, and kickstarting the boot rom onto it.

Hardware

I wanted some sort of related name for the project, so I was thinking Llama, TMS, which became Llitmus, like the PH sensitive dye.  I was gonna go with Llitmus-80 with the '80' because it uses a z80, but then once I read that the litmus was made from lichen, I just went with the name Llichen-80.

First, let's get into the Llichen-80 system specification.

• RC2014 backplane/base system
• 7.37 MHz clock speed
• 32k RAM from 8000-FFFF
• 8k BASIC ROM from 0000-1FFF (*)
• 32k RAM from 0000-7FFF (*)
• Digital IO board at port 00
• TMS 9918A video board at port 10,11
• ACIA Serial port at 80
• ACIA Serial port 2 at C0 - connected to CH376S USB drive interface

So (*) Indicates something... there's an overlap of these two items. My existing design piggybacks bit 0 of the output from the digital board to select which of the two of these that memory READs come from.  That is to say that writing 0x00 to the digital out board will select ROM, and 0x01 will select RAM.  Writes to these locations always go to RAM.  So one way I can test this is:

• Start up the computer
• select ROM bank
• Write a basic program to peek from the ROM and write to the RAM
• select the RAM bank
• Yank out the ROM board, and everything still works fine

10 OUT 0,0
20 FOR A=0 TO 8192
30 B = PEEK(A)
40 POKE( A, B)
50 NEXT A
60 OUT 0,1
RUN

This all works great!  One addition I made was to intercept the VCC to the RAM chip and have it also connected to some CR2032 batteries for a backup.  It's not perfect, but it works well enough for my system for now.  I also added a switch to force the use of the ROM, since sometimes the bank switching can get into a messed up state and you need to force reboot off of the ROM.

The other thing I created was a second ACIA serial port, essentially duplicating the circuit of the stock ACIA serial port, but changing it to look at ports C0 and C1 instead of 80 and 81.

The TMS could be configured for anywhere, for the most part, but the ACIA chip IO port mapping is messy so they consume essentially from 80 to FF.  I went with the SORD-M5 configuration of putting it at 10 and 11h.  Although there might be issues with this...

Anyway, more about these modifications and such at the end of the month.

Experiments 

I ended up reassembling my RC2014 system, and started working on testing out the configuration.  I Was able to write a few BASIC programs to output to the video chip and to a TV I had hooked up, as you can see in the photo above.  I was noticing some weirdness though. The LEDs on the IO board were flickering when I was doing writes to the TMS, so I may need to move the port around to another location. I think I'm gonna go with the MSX setting of 98 and 99h.

I also became very aware that I do not yet understand how to get the chip to do what I want.

Emulation

I was going to write the emulator using QT Creator for maximum portability, and also using the Z80 emulation core and frameworks I created for my existing RC2014 emulators.  But recently, after thinking about it for a little bit, I realizes that 90% or the emulator I need is already out there and already very well supported.  MSX.

There was really no need to get a whole video display system working with my existing emulator when I could start with an existing, debugged, well supported emulator, openMSX, and just create a new hardware profile for the RC2014 with my system's configuration... and with some changes to support my bank switching hardware and such.

I made a branch of openMSX on github to handle any/all of the changes I've made for it, which at the moment is just getting it to build on OSX/Darwin 10.14 correctly.

I also was messing around with my good old friend, the Texas Instruments TI-99/4A as it uses the TMS9918 chip. I figured that I could experiment around with how color and graphics look.  I'm not a fan of the TI's font, nor the MSX's font for that matter, but I figured it's a good platform to get reacquainted with the weirdness of the TMS and to see how this all might look in the future, perhaps.

This is of course just a screenshot from the impressive web-javascript TI emulator at js99er.net.

More as it develops...

Building some RC2014 upgrades...

I've been working on upgrading my RC2014 Z80 computer for the past few months, but in a very low-impact-to-my-finances-that-can't-support-it-otherwise way.  This post will just go into explaining a few of the upgrades I have in mind,

First of all, my current hardware scheme, the "RC2014/LL MicroLlama" as I call it, is and has been fully functional in its current state, and is emulated well in my emulator.

I started working on a mass-storage solution for the MicroLlama, which I have slightly back-burnered this month so that I could attempt to focus on the 2017-04 RetroChallenge ("The Andy Project"), but I'll likely pick it up again next month, especially with some of the upgrades I now have in my hands, which I will now briefly talk about...

Dr. Scott M. Baker's Bus Supervisor Board

A ton of chips and a well packed board!

I just received a "kitted" version of Dr. S.M.Baker's RC2014 Bus Supervisor board. Major kudos to Rob Leisenfeld from the RC2014 community...

The short description of this is that it has some I2C I/O Expanders that sit on the entire bus (Data, Address, Control) as well as replaces the system's 7.37 Mhz clock board.  This can be used to snoop on the system, read/write IO, read/write RAM, etc... taken one level above that, you can use SMB's python scripts to upload data right into RAM, thus eliminating the need for a ROM module.

People have successfully used this to run 64k RAM-only RC2014 computers, and upload the program ROM from their Raspberry Pi. (Schematic, GitHub link to software)

It took me about 15 minutes to figure out the orientation of that crystal.
(Pin 1, the pointy corner, is in the bottom right)
Also, I'm not sure the jumper configuration is correct yet.

That's where my personal problem with it comes in.  As it stands, his project uses a RasPi to communicate with the board over I2C.  This is fine, however it does not fit within my workflow.

I do not really have a RasPi to use for dev work, so my solution is to take a tiny Arduino Leonardo clone ("Micro-SS" like this one), with a cable connecting its I2C lines to the Bus Supervisor Board.  Then, I'll make a thin Serial-I2C bit of software and making some desktop tools, perhaps in python to fit with the original from SMB.

My "proof of concept" for USB-I2C communications.
Here it's connected to an RGB color sensor.

The end result is that in my Z80 project makefiles, i can add a target for the generated .HEX files to be downloaded directly to the physical RC2014.

I've made a cable for my Micro-SS and have built my Bus Supervisor Board.  As you can see in the photo, this is it set up on a powered RC2014 backplane with only the standard IO module, and a few LEDs on a few data lines, so that I can test out everything before putting the CPU and RAM on there, potentially damaging them.

Obviously, it would also be possible to include a couple of ROM programs directly into the MicroSS, and possibly store a small one in the ATmega 32u4's EEprom as well.  Some buttons on the MicroSS could be used for injeting these pre-stored programs.  i could even see a program that generates a menu that the arduino can basically farm out to the Z80 to get user responses/menu options, etc.

Additionally, I can make a RC2014 bus - to - pac-man bus adapter, and actually deploy code-in-development directly to the machine from my desktop from the makefile/build scripts.  ... This is a dev tool I've wanted for about 20 years now!

Lots of possibilities!

I will put out another blog post and a github link for the supporting software, when I've got this working. (estimated - mid next month)

64k RAM and Pageable ROM

I also received this past month the boards for these two official RC2014 boards: the 64k RAM and Pageable ROM.  As you can see in the pic, i still need to order quite a bit to make these work.  Now that I have the Bus Supervisor board, the Pageable ROM is less interesting to my needs, although I may still adapt my RC2014/LL design to use these pieces instead.

You can see pics of these in the top of this blog post.

The 64k RAM will definitely work well with the Bus Supervisor board, however the Pageable ROM board has definitely taken a bit of a slip down my plate... Until I can get the parts in for the RAM (sockets, etc) I can use my existing unmodified 32k RAM board for the upper segment of memory ($8000-$FFFF) and my slightly modified second 32k RAM board for the lower segment of memory, I just have to manually enable it for read/write.

State of the RC2016/10

RC2016/10 is a little more than halfway over... so where am I?

Pretty much in the weeds.

I'm almost at the point where I wanted to be at the beginning of the challenge. I'm still working on finishing up the SD loader routines.  Well, I've finished the SD/Micro side of things (in the SSDD1 module - Serial SD Drive) both for the real physical drive as well as for the emulator, for loading only.  The emulation also supports writes now, and both support file/directory manipuations:  Directory listings, make directory, remove directory/file. (For the FAT filesystem anyway.)

I've got a bunch of things on my plate right now, between work, finishing up a contract or two, the animatronic bird project has reappeared a bit, plus time for the family, lack of sleep, and general lack of motivation for anything.

I haven't done any of the sector IO stuff yet, as I want to get regular files working.

In any event, here's a quick bullet summary of the current state of the project:

Done:

• Hardware for SD interface
• Hardware for ROM/RAM switcher
• SSDD1 process design (see image above)
• SD drive (SSDD1) firmware (preliminary)
• SSDD1 emulation for file and directory support
• SSDD1 firmware for directory support and file reading
• CP/M research to figue out what needs to be done, prior work.

ToDo:

• SSDD1 firmware for file writing
• SSDD1 firmware and emulation for simulated sector IO
• Z80 SSDD1 decoder (Hex string+checksum to proper formatter)
• Z80 IHX decoder (stream from SSDD1 to RAM writer

Gameplan tasks (Roughly in order of probable completion):

• Z80 IHX decoder
• Load a ROM from the SD card into RAM, switch off the boot ROM, restart, run from RAM
• Backport emulation into the firmware to get them equal

From here, I can go down one of two paths.  I can completely flesh out the rest of the SSDD1, and get the sector IO code implemented, which is probably the best course of action, just for completeness.  Or I could start working on porting/implementing the CP/M bios ROM, which might give me the "win" kick that I need to get the Sector interface implemented... although once I have the regular file IO stuff done (which it is) the sector IO stuff is the same plus a bit more wrapper implementation... after all it's just a bunch of 128 byte files in subdirectories... so...

• Sector IO SSDD1 emulation
• Backport Sector IO to SSDD1 firmware
• CP/M Bios
• CP/M Bootloader into LLoader ROM
• Burn new LLoader ROM to 27C512 EPROM
• Boot a RC2014 to CP/M!

RC2014/LL and RC2016/10

The RetroChallenge is upon us again!

This time around, I plan on working on my Z80 homebuilt computer, the RC2014.  (Website for RC2014, Order a RC2014) For a few months now, I've had my RC-2014 computer built, and modified to be an RC2014/LL computer. What this means is, is that I have some modified modules using no additional external hardware.

The above picture shows my RC2014/LL system with its extra RAM module, and the C0 Serial expansion board to the left, with the SD card interface board (SSDD1) on it.

The basics of this design:

Unmodified RC2014 modules:

• Z80 CPU module
• Clock module (* see below)
• Serial console interface
• RAM module (for RAM in the range $8000 through $FFFF

Modified RC2014 modules:

• Second RAM module
• ROM module
• Digital IO module

Additional hardware:

• Second ACIA Serial port at $C0
• SSDD1 (Serial SD Drive)

(*) While the clock module is unmodified, it technically is modified. I have added a 10 uF (50V) cap between the reset line and ground to be a quick-and-dirty power-on reset circuit. It works perfectly.  Every time I power on the computer, it "presses the reset button" for me. ;)

The plans to mod these parts are available here.  This is currently fully functional and tested. The modifications use unused gates on the boards, so that it requires no extra additional hardware or boards to implement. The basic theory to the /LL modifications are as follows:

Bit 0 (0x01) of the Digital IO module is tied to one of the extra bus lines on the backplane.  Let's call this "Extra-A".  When you do an "out" to that port of "0x01", it will trigger the Extra-A line.

The ROM module "out of the box" is configured such that if there is a memory access, which is a read from address $0000 through $7FFF, it will enable the ROM, and it will put its data on the bus.  My modification adds in one extra condition to this.  It adds in that only if the Extra-A line is LOW, that the ROM will be enabled.  This means that when Extra-A is 0, the ROM works. When Extra-A is 1, it's as though the ROM doesn't exist.

The RAM module "out of the box" sits at the high half of memory space ($8000-$FFFF), and is always enabled on memory READ or WRITE to those addresses.  The modification to this module is threefold.  First, it sits the RAM at the low half of memory space ($0000-$7FFF). Secondly, it is set up that WRITEs to this memory space will always work, regardless of Extra-A.  Thirdly, it is set up that READs to this memory space will ONLY work when Extra-A is HIGH.

The end result of this is that when Extra-A is low, reads in the low half of memory will come from the ROM.  When it is high, reads will come from RAM.  Writes ALWAYS go to RAM.

This is quirky...

I admit this.  It means that you can (and I will) write a bootloader/monitor ROM that is enabled on power-on, will read from a mass-storage device and write into anywhere in RAM... It can load a 64 k byte memory image into RAM, and then switch off the ROM and it will all work.  The quirkyness is that you cannot verify the loaded-in memory in the low range of ram, since reads will come out of the ROM.   Obviously, you also need to do this routine completely out of registers, as your stack variables will get overwritten if you're not careful.

Anyway....

If you want it to behave like a stock RC2014, remove the jumper from the IO board to Extra-A, and instead add a jumper from ground to Extra-A.  I have added a switch to mine to force this in the case where the IO board comes up in the wrong state.

Additionally, I have added a second serial port, which basically follows the circuit for the first port, but it sits at $C0, and does not have an interrupt line wired to it.  The RX/TX on that one comes out to a FTDI-like pinout header, which is where my SSDD1 module plugs in.  The plans for this serial port are available here, and can be seen as the brown perf-board on the left of the topmost image of this post.

The SSDD1 module...

The Serial SD Drive module is the mass storage module that I've created for my Z80 to interface with. I know that I can push the FAT filesystem support onto the Z80, but that would require substantial effort.  I instead decided to go with the model where I have a smart serial-based device that you tell it "i want this file" and it sends it out.  Like a local BBS. ;)

The use of a serial-driven drive is not unprecedented.  It's somewhat modeled after the Commodore 64/Vic 20's "IEC" serial interface for floppy drives.  It also mirrors it in that the drive has some smarts in it to deal with the drive architecture.

I also went this route for the ultimate form of this computer, which is to run CP/M.  CP/M expects drives with a Drive+128 byte Sector layout.  While other Z80-CP/M computers implement this by having direct interface to the sectors on the spinny disk/cf/sd card, I will do it by having files on the SD card, for the most amount of flexibility.  There will be a "drives" folder on the card containing folders named "A", "B", "C", and so on.  These letters are the drives.  In each of those will be directories for the tracks, named "0000", "0001", etc and in each of those, files named "0000" "0001" "0002" etc. These files are the simulated sectors on the disks.  It will be easy to build virtual drives for other use out of this.  It also means that I won't need some special interface on a modern computer to talk with this.  I won't have to do 'dd' style transfers to get at the data... It's all just sitting on a FAT filesystem.

The implementation of this module is based on an Arduino with a microSD breakout module.  The serial interface communicates directly with it, and it sends the content via serial back to the Z80 host.

The above picture shows the SSDD1 module off of the RC2014/LL expansion board, and instead wired to a breakout board where I have a second FTDI serial-USB interface so that I can debug the hardware more easily.

And that brings me to the current Retro Challenge...

My goals for this month is to do a few things here, to finish up this computer system...

• Finish up the firmware for the SSDD1
• Sector load/save support
• File load/save of intel hex files
• directory create, list, remove
• Write the SSDD1 emulation for the emulator
• Finish up the loader and burn it to a ROM
• Write a CP/M bios that uses the SSDD1 interface
• Build CP/M disk/sector files 
• Play Zork

Stretch goals:

• Extend the NASCOM BASIC to support the SSDD1 for loading and saving.

The RC2014 Computer: 1. Emulation

As you may know, I'm bigtime into Z80 computerey stuff.  For the past 20 years or so, I've been hacking Pac-Man ROMs, been maintaining the Ms Pac Disassembly, and have made my own Z80-Pac based programes over the years.

Fairly recently, I got a Kaypro II from a friend at interlock, and it worked perfectly, and looked brand new.  I felt like I couldn't hold on to it... "it belongs in a museum!" ...so I donated it to ICHEG/Strong Museum of Play.  But it helped whet my appetite for a CP/M computer.

Another project I've been wanting to do was to start with a Commodore 64 (I know it's not Z80, it's 6502ish), a floppy drive, some blank disks and a hardware manual and code up, from scratch, an OS.  Start out by making a text editor, assembler, GEOS-like GUI, etc.

These projects recently had an opportunity to overlap, and they all seem to converge on the RC2014 modular Z80 computer.

The RC2014 computer is a backplane-based modular computer created by Spencer Owen, based on the Z80SBC by Grant Searle.  There are modules for the CPU, RAM, ROM, Serial Terminal interface, and so on.  It is available as a kit from tindie.com.  Once assembled, you hook up a serial terminal to it, power it on, and you get a 1980s-esque BASIC prompt onto which you can write your 32kbytes of program.  This is based on Grant's simplified Z80 computer, so there is no off-line storage.

My general plan for the RC2014 is:

1. Emulation:
1. Create an emulator for the system to aid with rapid development
1. also bring my "bleu-romtools" from Google Code to github
2. Add a serial-based storage solution to the RC2014 emulation to confirm proof-of-concept
3. Add ROM swap out to the emulation
4. Add 32k of ram to give a full flat 64k of ram to the emulation
2. Hardware:
1. Get a RC2014 kit
2. Build the RC2014 kit
3. Make a test ROM to run on real hardware to verify my toolchain is working
4. Create a new serial card that sits at port 0xC0 (second serial)
5. Create the SD Drive firmware for the serial arduino
6. Hack the ROM and Digital IO boards to allow for disabling the ROM
7. Add 32k hacked RAM to the system
3. Name: RC2014/LL
1. At this point, the architecture is different enough and well defined enough that I think a new name for this configuration is in order. I call this configuration "RC2014/LL".
4. Port CP/M
1. Create the BIOS
2. Create the sector-based emulation layer in the SD drive
3. Boot CP/M
4. Play Zork

I started out by making an emulator using the Z80 Pack emulation system.  Once I got this running, I realized the limitations of this emulator and looked around and found another emulator that suited my needs better. (I wanted a way to "swap" memory around, which Z80 Pack would not do in a way that wasn't a major hack.)

I created a layer that adds disableable memory regions, and added emulation of the 6850 ACIA serial chip, and threw the 32k RAM BASIC ROM at it, and it started right up, running BASIC!

I added a second 32k of RAM (easy to do when you're emulating it!), and started creating the SD interface, also using the 6850 ACIA for communications.  I then added a port, emulating the IO card, on which bit 0 (0x01), when set, will disable the ROM... So any reads to the low area of memory will read from the ROM.  Whether this is set or not, all writes to that area of memory will actually happen to the RAM... they will just be hidden from reads until that bit is set.

I now have the basics of the RC2014/LL system emulated in software!  I created a boot/diagnostic ROM which can be used for all RC2014 systems which can probe memory to determine type (ROM, RAM, unpopulated), peek and poke memory, In and out IO, and other utility functions for the SD card interface.

Currently, I'm writing the SD card API which I will port to the Arduino Leonardo and SD breakout board which I have ordered, once those come this weekend, I'll shove them into my own serial board and burn a test ROM and see how it goes....