Showing posts with label RC2014. Show all posts
Showing posts with label RC2014. Show all posts

Monday, November 1, 2021

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:

Saturday, October 2, 2021

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...

Saturday, November 9, 2019

RC2019-10 - A102 project - The end of the month of hacking



The short version is that I was super productive on these projects this past month.  I didn't complete it, but I never realistically thought I would be able to.  I lost a week's worth of time, or so, prepping our yearly Halloween Hack (blog post soon)... not to mention losing some time to work on building my Lego Saab 900... (blog post soon too).
One thing I will say, is that by combining the projects together, I tricked my brain into quite effectively "being okay with" working on one project or another, by them all being part of the same project.  So I would say that the month was quite successful.


So Anyway, I'm going to first go through a bunch of goals for the month, for the RC challenge, and in general, and briefly discuss my progress on them at a meta-level.  Then I'll get more into details about the actual work.

Overview and goals


Raspberry Pi / Emulation

I wanted to get the Pi 3 configured and booting right into an emulated  Amiga/Amibian environment.  I got the pi configured with standard raspian instead of Amibian, since I wanted this to be more of a general use machine.  It'd be nice to be able to use it for firmware development of the LL530 as well as the machine that it's targeted for.

So the target changed on this, but it is complete for now.

LL530 Development

I wanted to have the LL530 (USB Interface to Amiga serial keyboards, Amiga/Atari controllers and mice) fully finished.  Although I did not finish the firmware this month, I got more done on the project this month than I had in the past 6 months.  However, I was able to test the DIN pinout to discover that it's backwards, so I need to rev the board for those...

I didn't fully succeed, but I was successful.... if that makes any sense.

RC2014 Integration

I wanted to have an RC2014 Z80 computer built in as well, that I can connect to via serial port, for doing RC dev work without an emulator.  This aspect sadly got the least amount of attention.  I have an RC2014 mini installed, connected to the serial port on the Pi 3.  I've rewired the connection twice now, and I still cannot get it to connect using this wiring.

I spent time focusing on the other aspects.  So... 25% success.

Integration / Battery / Monitor / Enclosure

Most of the effort this past month was in this area.  I wanted to have the entire thing as a finished unit; to be able to be brought to a coffee shop, pull it out, turn it on and use it wirelessly. I can do all of these things right now with it.

So I would say this aspect was completely successful... although It does need improvements, particularly with the screen.


Installing The Linux

I started with a base Raspian image from their site.  I had the Pi hooked up to a HDMI monitor with USB keyboard and mouse.  After using Balena Etcher to get the image onto an SD card, I booted the  machine up.  I went through the basic setup, and updates.

I launched raspi-config from a terminal window, and went through to  enable ssh, i2c, and serial.

Next I installed some useful software packages:

apt-get install screen fs-uae-launcher stella

I made sure that serial was enabled  in /boot/config.txt,

enable_uart=1

I use screen as my quick and dirty way to connect to the RC2014 which is wired up to the uart on the raspi per the diagram above.  The reset line is wired to GPIO 4, so i use this shell script to "hit the reset button":

#!/usr/bin/python

import RPi.GPIO as GPIO
import time

print "Resetting the RC2014."

# setup GPIO4 as an output
GPIO.setmode(GPIO.BCM)
GPIO.setwarnings(False)
GPIO.setup(4,GPIO.OUT)

# send LOW (reset) for 1 second, then restore HIGH (normal run)
GPIO.output(4,GPIO.LOW)
time.sleep(1)
GPIO.output(4,GPIO.HIGH)

print "Done."
# return to high-z state
GPIO.setup(4,GPIO.IN)

The Red and Green LEDs are wired to GPIO18 and GPIO12, and I can run this script to do a nice fadey display on them:

#!/usr/bin/python

import RPi.GPIO as GPIO
import time

red = 18
green = 12

GPIO.setmode(GPIO.BCM)
GPIO.setup(red,GPIO.OUT)
GPIO.setup(green,GPIO.OUT)

r = GPIO.PWM(red, 100)  # channel=12 frequency=50Hz
g = GPIO.PWM(green, 100)  # channel=12 frequency=50Hz
r.start(0)
g.start(1)
try:
while 1:
for dc in range(0, 101, 5):
r.ChangeDutyCycle(dc)
g.ChangeDutyCycle(100-dc)
time.sleep(0.01)

r.ChangeDutyCycle( 100 )
g.ChangeDutyCycle( 0 )
time.sleep( 1 )

for dc in range(100, -1, -5):
r.ChangeDutyCycle(dc)
g.ChangeDutyCycle(100-dc)
time.sleep(0.01)

r.ChangeDutyCycle( 0 )
g.ChangeDutyCycle( 100 )
time.sleep( 1 )

except KeyboardInterrupt:
pass
r.stop()
g.stop()
GPIO.cleanup()

I may rewire these, or wire up additional LEDs to the ones specified with the Amibian/UAE led indicators, which are defined as GPIO4 for activity, GPIO16 for "Power", and GPIO16 for a clean shutdown button.

LCD Monitor


For a monitor, I'm using a $10 3.5" composite monitor.  I had to do a few things to get it to work however.

I had to hack the power input so that it would run off of 5v.  These are made to be used in cars, so they expect 12v of power.  At the time I did this, there were examples of doing this modification on
other displays, but not this model.  I powered it up using 12v, then probed the outputs in the power supply section for a 5v rail... and I soldered a 5V input there.

Once I had done this, I connected it to the 5v power in the enclosure, and hooked up the video input from the composite output on the Pi 3.

One snag I hit though, is that it wouldn't work right, It would flash on when the Pi booted, but it wouldn't show the desktop. Testing the Pi with HDMI or a known working composite input worked just fine though.

I was trying all sorts of things, and eventually decided upon trying PAL  video modes instead of NTSC, and that worked.  I spent some time tweaking the overscan settings as well, to stretch the screen to fit.  I also noticed that the contrast viewing range was substantially better on the top side of the display, so I ended up mounting it in the enclosure upside down, and I flip the video in the pi's config too.

So the changes that all this amounts to for /boot/config.txt are:

disable_overscan=1
display_rotate=2

overscan_left=0
overscan_right=0
overscan_top=5
overscan_bottom=5

sdtv_mode=2
sdtv_disable_colourburst=0

framebuffer_width=320
framebuffer_height=288

Although, as you can see from the screenshot above, it's basically unreadable.  So I was able to get it to work, but any future development on this will need to be with a different display.  Something with at least 480 rows, so that Amiga emulation can be reasonable on it.

Combining it all, and the Future...

I spent a few evenings rewiring that keyboard which mostly works really well.  I'm using a 5000mAh battery and get an undetermined-but-better-than-my-old-iBook amount of time with it.

The display is garbage.  I'm currently looking into replacing it with an HDMI-based 4" Waveshare IPS display with an 800x480 resolution for about $40.  Surely that will require moving around hardware inside of this enclosure, and since the display is meant to piggyback on the Pi, I will lose my integration board.

Obviously, I'll need to install the Amiga emulator, Tandy 102 emulator, my Model-T-Shell, and the Arduino IDE so that I can continue development on the LL530

In short, I'm super happy with where things are now, it just needs some tweaks to get it to be usable as a primary system. :D

Wednesday, October 2, 2019

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

Friday, April 28, 2017

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.

Monday, December 5, 2016

RC2014/LL Showing ROM/RAM switching, 64k!

So I thought I'd just make a quick post to show how I know that the ROM swap hardware in my RC2014/LL is working. I'll walk through the procedure here...

First, I booted up the RC2014 as usual, which drops me into BASIC.  From there I wrote this short program:
10 FOR A = 0 to 8192
20 B = PEEK( A ) 
30 POKE A, B40 PRINT A 
50 NEXT A
What this does is goes through the lowest 8 kbytes of memory, reads (peek) and then writes (poke) the byte it finds right back to the place it got it from.   For example:
  1. Read from memory address 0
  2. Write to memory address 0
  3. Switch to the next memory address, repeat 
Which seems stupid, that it does nothing.  But if you remember from a previous post, when the ROM is enabled, it's only enabled for reads.  Writes still happen to the RAM in the same addresses.  So the above program copies the BASIC ROM into RAM.


Next, we switch off the ROM by doing this:
 OUT 0,1
The lowest bit, '1' turns off the ROM, and switches to the RAM for read operations.  To confirm we're working out of the RAM, we can poke a 0 in somewhere down there.

PRINT PEEK( 0 )
 243
POKE 0,0
PRINT PEEK( 0 )
 0
So we can see here that memory address 0 has been changed from 243 to 0.


I also went one step further and yanked the ROM board out of my RC2014.  This is not recommended. ;)  But it did continue to run without any problems... until I really tried to muck things up, for fun:

I wrote a program to clear RAM, and then ran it in BASIC.  Here is the listing:


And here's what happened when i typed 'run'.  It completely locked up after it printed the '8'. Starting at memory address 0x0008 is the text output routine, so it cleared out the boot code before that (0x0000-0x0007), erased the beginning of the print handler, then went to print out something to the screen, and crashed.  Well, I assume it crashed. It got an invalid opcode and who knows what it's actually doing. The code there used to be a "jump" which is 3 bytes.  Instead it got a NOP, which does nothing, (0x00)  and then two garbage bytes which map to something incorrect. Boom!



Monday, October 17, 2016

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!

Sunday, October 2, 2016

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.