Information wants to be free...

CP/M on the GR-SAKURA

I have ported my "kaytil" Z80 CP/M 2.2 emulator to the Gadget Renesas GR-SAKURA reference board. This means it's possible to run all kinds of off-the shelf CP/M games and software on this board.

Even though it's based on the "kaytil" codebase, some heavy modifications have been done. All the trace and debug functions have been removed to reduce the binary size and also to speed up emulation. The Z80 emulation core remains the same but the console and disk emulations have been adapted to the different hardware. The CPM 2.2 and CBIOS binaries are embedded directly into the code to allow for easier standalone operation.

For the floppy disk emulation, the floppy disk images needs to be placed at the root directory on a FAT16 formatted MicroSD card (first partition) and be named "A.IMG", "B.IMG", "C.IMG" and "D.IMG" for each of the four drives. The MicroSD card on the GR-SAKURA is read through SPI and is kind of slow, so a simple caching mechanism has been implemented where the lowest sectors are cached in memory. To get optimal performance the FAT16 partition should be placed as close as possible to the MBR, possibly on sector 3, as this should get the actual FAT table cached into memory. Note that there is only read support, any writes to floppy disk by the CP/M OS are simply ignored. The four on-board LEDs on the GR-SAKURA are used as disk activity indicators.

For the console emulation I was first considering to use Renesas USB-CDC library to provide this over the USB connection, but I could not get it to work properly, as it seemed to get congested by too much traffic and just freeze. Instead, the first UART is used, marked by pins 0 (RX) and pin 1 (TX) on the GR-SAKURA, and it runs on 115200 baud for best performance. Same as the "kaytil" emulator on Linux; conversion between ADM-3A codes to VT100/ANSI codes are done in the emulator already. I wonder if it would have been technically possible to remove this conversion and connect a real Lear Siegler ADM-3A terminal (with a voltage level shifter) directory to the GR-SAKURA...

The RX CPU on the GR-SAKURA runs at 96MHz I believe, and compiling the emulator with -O2 optimization makes the speed nearly similar to a real Kaypro II, which is nice.

You can download the first version here and there is also a branch on the "kaytil" git repo.

Topic: Open Source, by Kjetil @ 04/10-2021, Article Link

Fujitsu FKB8530 Keyboard Repair

I got hold of a strange looking modular keyboard, the Fujitsu FKB8530, which I wanted to refurbish due to its unique construction. Unfortunately I discovered that it had sustained some kind of liquid damage, which in turn had caused corrosion on the membrane. The result was that some of the keys did not work. Measurements showed that the resistance had gotten too high between some of the points on one of the traces on the membrane.

I was able to repair this by gently scraping of the top layer on the membrane trace with a knife, then applying conductive silver paint (Loctite 3863 Circuit +) on top. I used regular Scotch tape to mask off the relevant area:

Silver paint applied


The keyboard after re-assembly:

Re-assembled keyboard


Topic: Repair, by Kjetil @ 22/09-2021, Article Link

Linux System on a Floppy

Referring to my previous project to build a Linux distribution for LOADLIN. It is actually possible to also boot this directly from a 1.44M floppy disk, which can be quite useful. The output from that build should be the Linux kernel "bzImage" and the root filesystem "rootfs.cramfs". I renamed "rootfs.cramfs" to simply "rootfs" to avoid any conflicts with the 8.3 filename format.

SYSLINUX will be used for booting, and it needs "syslinux.cfg" configuration file with the followng contents:

DEFAULT linux
LABEL linux
  KERNEL bzImage
  APPEND initrd=rootfs
          


These are the steps to make the floppy disk image:

dd if=/dev/zero of=floppy.img bs=512 count=2880
mkdosfs floppy.img
syslinux --install floppy.img
mkdir /tmp/floppy
mount -o loop floppy.img /tmp/floppy
cp bzImage /tmp/floppy/
cp rootfs /tmp/floppy/
cp syslinux.cfg /tmp/floppy/
umount /tmp/floppy
          


The floppy disk image can be tested in QEMU with:

qemu-system-i386 -fda floppy.img -boot a
          


Writing the floppy disk image to an actual floppy disk is typically done like so:

dd if=floppy.img of=/dev/fd0 bs=512
          


For convenience, download the floppy disk image here.

Topic: Configuration, by Kjetil @ 05/09-2021, Article Link

Tandon TM9362 Data Recovery

I have a Tandon TM9362 hardcard. Such hardcards are notorious for failing, a common problem is that the heads and other mechanical parts get stuck over time. Despite this I managed to fully recover the data from it. The actual hard drive on the card is a Tandon TM362, which is a 21MB MFM drive.

Tandon TM9362 and Bike Oil


The shaft of the motor controlling the heads on these drives are actually accessible, which makes things easer. I managed to turn the shaft manually with my fingers to loosen it. Afterwards I applied 2 drops of "Bike Oil", which is similar to bearing oil, into the motor through the shaft and wiggled it some more. The card was then connected to a 486-class PC. Still, even with this oil applied it would not always power up on startup, but some more wiggling and power cycling made it spin up in the end.

This card contains it's own BIOS routines for accessing the disk, so I removed the existing hard drive on the PC to prevent any interference. It booted up with MS-DOS 3.20 and timestamps from 1990, so it could have been over 30 years since it was last accessed. I think MS-DOS 3.20 has issues with newer 1.44M floppy disks, so I booted DOS 5.0 from a floppy instead, still with the hardcard connected of course.

This PC has a 3Com 3C509 Ethernet card, so I loaded the Crynwr Packet Drivers for this and configured mTCP for TCP/IP networking. I setup the mTCP "ftpsrv" FTP server to host ALL files from the C: drive and used "ncftpget" from a Linux box to recursively download everything.

An additional cool but not really necessary step is to get those files onto a virtual disk image that can be loaded in QEMU. This particular hardcard has a CHS configuration of 615 cylinders, 4 heads and 17 sectors (per cylinder). Multiplying this with the standard sector size of 512 gives 41820, so a blank disk image can be made by:

dd if=/dev/zero of=tandon.img bs=512 count=41820
          


Importantly, in order for QEMU to properly forward the same CHS settings into the emulation, it needs to be specified on startup like so:

qemu-system-i386 -drive file=tandon.img,format=raw,if=none,id=dr0 -device drive=dr0,driver=ide-hd,cyls=615,heads=4,secs=17 -boot c
          


So actually get the files over I booted QEMU with the virtual disk image and another copy of a MS-DOS 3.20 floppy boot disk image that I found online. From the emulated DOS i ran the DOS "fdisk" and "format c: /s" to format the virtual disk in a compatible manner. Then I ran the Linux "fdisk" on the image and noticed the FAT partition was placed on sector 17 and onwards. Multiplying this by 512 gives 8704, so the partition on the virtual disk image can be loopback mounted like so:

sudo mount -o loop,offset=8704 tandon.img /tmp/tandon
          


Afterwards the recovered files can just be copied into the mounted loopback drive. The result is a bootable (in QEMU) virtual disk image with the correct MBR and VBR.

Topic: Repair, by Kjetil @ 07/08-2021, Article Link

Amiga 500 with the Framemeister

Here is how I connected the Amiga 500 to the Micomsoft XRGB-mini Framemeister to be able to get color graphics on a modern display through HDMI.

The tricky part is getting a "DB23" connector, but I ended up using a regular DB25 connector (made from plastic) and shaving off part of it to make it fit into the Amiga 500. The mini-DIN connector on the Framemeister only accepts composite sync (not separate horizontal and vertical which is more common) but this is available on one of the pins on the Amiga. However, it is a 5V TTL level signal which is a little bit too hot so it's recommended to reduce this with a resistor. I ended up using two 360 Ohm resistors in series at 720 Ohm since that is what I found in stock at the moment. Some diagrams I found online claim that ground should be taken from pin 16 from the Amiga, but this did NOT work for me. Pin 19 which is composite video ground worked fine.

Here is the cable pin out:

|----------------|-------|---------|--------------|
|                | Amiga |         | Framemeister |
| Signal         | DB23  |         | Mini-DIN     |
|----------------|-------|---------|--------------|
| Red            | 3     |         | 8            |
| Green          | 4     |         | 7            |
| Blue           | 5     |         | 6            |
| Composite Sync | 10    | 720 Ohm | 3            |
| Ground         | 19    |         | 4            |
|----------------|-------|---------|--------------|
          


When testing the connections with clip leads I got some "jail bars" (faint traces of vertical lines) on the display, but these more or less disappeared when I soldered everything together properly. Not sure if that was caused by general noise or by poor clip lead cables.

The finished cable connected:

Amiga to Framemeister connection.


Topic: Configuration, by Kjetil @ 24/07-2021, Article Link

Z80 CP/M 2.2 Emulator

After finishing a prototype of a MOS 6502 emulator I almost immediately started working on another one. This time a Zilog Z80 based one that runs CP/M 2.2 with inspiration taken from the Kaypro II computer, so I named the emulator "Kaytil".

Despite taking inspiration from the Kaypro II, it does not actually emulate any of the Kaypro II specific hardware, with the exception of the Lear Siegler ADM-3A compatible terminal emulation. But I think most Kaypro II software should work as long as it is not hardware specific and only expects the CP/M OS functionality. ADM-3A escape codes are converted directly to ANSI counterparts without going through (n)curses, which should be good enough.

To be able to run CP/M I adapted the skeletal CBIOS from Digital Research's manual to the emulator code, which is using IN/OUT instructions to communicate with each other. This, together with the reverse engineered CP/M 2.2 source from Clark A. Calkins is assembled using Digital Research's MAC macro assembler. Since the assembler is itself a CP/M program, I have run this in YAZE, which is another popular Z80 CP/M emulator.

Note that the Z80 emulation is not complete, but simply good enough, so some functionality is missing. I have made sure that it passes all the ZEXDOC tests for documented instruction flags, but I have made no effort so support the undocumented flags required to pass the ZEXALL tests. I also think the emulator is quite slow compared to others, probably due to ineffective O(n) instruction lookup and passing of data through functions instead of using global variables. In order for some games to run correctly, the speed is also artificially slowed down by using an interval timer, so it kind of matches that of a real Kaypro II. Some of these things can be adjusted by compile time defines though.

For storage, the emulator operates around on IBM 3740 8-inch floppy disk images. These can easily be managed with the Cpmtools package, which can create new images (mkfs.cpm) or copy files to and from them (cpmcp) from the host system. A total of 4 floppy drives (A, B, C & D) are emulated and can each contain its own image. By default the images are "read only" so any changes are not written back to the disk image file, but this can be overridden with the command line arguments.

Here are some games I have been able to run:
* Ladder (Yahoo Software, Kaypro II Version)
* Aliens (Yahoo Software, Kaypro II Version)
* CatChum (Yahoo Software, Kaypro II Version)
* Colossal Cave Adventure (Michael Goetz, Kaypro II Version)
* Sargon Chess (Hayden Books, CP/M Version)
* Deadline (Infocom, CP/M Version)
* Zork I (Infocom, CP/M Version)
* Zork II (Infocom, CP/M Version)
* Zork III (Infocom, CP/M Version)
* Nemesis (SuperSoft, CP/M Version)

The initial version can be gotten here but I have also put the source code on here for possible further development.

Finally, some screenshots of different games:

Aliens

CatChum

Deadline

Ladder

Sargon Chess


Topic: Open Source, by Kjetil @ 04/07-2021, Article Link

Retrobright Experiment

I finally got around to trying the Retrobright technique to remove yellowing. You need UV light, so doing this in Norway is a bit tricky because the weather is quite unpredictable and we do not have a lot of sun. Also, the Hydrogen peroxide (H2O2) needed is expensive and only comes in maximum 6% solution. I have an old computer mouse which was very yellowed and a perfect candidate for this experiment due to its small size.

There are several different methods and recipes to use for Retrobrighting, but I chose the plastic wrap method and using only H2O2 and corn starch. I put the 6% H2O2 into a cup and gradually added corn starch until I thought the mixture was thick enough. Afterwards I poured the mixture on the plastic wrap, put the yellow part of the mouse on the mixture and wrapped it together.

It was supposed to be a sunny day so I put the wrapped mouse outside at 08:30 in the morning, and then retrieved it at 18:30 in the evening, so it got around 10 hours of sunlight in total. All in all I was quite satisfied with the result.

Here is a picture showing the before and after and the different stages, you may notice the small bubbles appearing which is a sign the process is working.

Retrobright steps of Brother Mouse


Topic: Repair, by Kjetil @ 19/06-2021, Article Link

Terminal Mode Commodore 64 Emulator

Just for fun I have made a primitive Commodore 64 emulator, or more correctly mostly a 6502 CPU emulator that happens to run the Commodore 64 ROMs with just a few tweaks. It was mostly to learn about the 6502 CPU itself, so if you actually need a proper emulator, then use VICE instead! The goal was to be able to load and run the Commodore BASIC ROM, which it does, in a Linux terminal.

Anyway, I am releasing the source code under the MIT license and it can be downloaded here.

The 6502 CPU is fully emulated and even supports decimal mode, although only with NMOS (not CMOS) compatibility, so the N, V and Z flags are not set correctly. Nevertheless it passes the excellent test suite made by Klaus Dormann, and even some of the tests made by Wolfgang Lorenz.

To support the C64 architecture, some simple memory bank switching support has been implemented, and hooks are placed when reading and writing to certain memory locations to capture the user input and output. The emulator blocks on input when waiting for a keyboard press, which is hugely beneficial to CPU load. I thought about using curses, but this makes things more complicated so the emulator sets the terminal into canonical mode (with no echo) for the BASIC editor to work instead.

To find the ROMs the emulator assumes that you have VICE installed from before, which puts these at "/usr/lib64/vice/C64/". The location can be changed by editing a #define if they happen to be elsewhere.

Here is what it looks like running in XTerm, and you can also see the CPU disassembly/trace and memory dump functionality embedded into the emulator:

Terminal Mode Commodore 64 Emulator


Topic: Open Source, by Kjetil @ 01/06-2021, Article Link

FreeRTOS support for GR-SAKURA

I have managed to get FreeRTOS running on the GR-SAKURA board. Currently it's just a demo that blinks the LEDs, but maybe I will improve on that later. Anyway, this makes it possible to do multitasking. It is based code from the other FreeRTOS demos and some of the stuff from my earlier GR-SAKURA projects.

I started on this a while ago so the code is built around version 10.0.0 of FreeRTOS, but maybe it will work on newer versions as well.

Download the code from here and unpack the "GR-SAKURA" directory alongside the others into the "Demos" directory of FreeRTOS. Compile it by running "make" from that directory, but you will need the GCC toolchain for the Renesas RX CPU installed first.

I also finally got hold of the excellent Segger J-Link debug probe which makes it possible to use GDB ("rx-elf-gdb" from the RX GCC toolchain) to connect to the GR-SAKURA JTAG port, which I have soldered on:

GR-SAKURA with JTAG connector.


Topic: Open Source, by Kjetil @ 08/05-2021, Article Link

Multiplayer Tank Game

Here is another game project I have had lying around for many years but never finished, until now that is. The idea was to make a graphical multiplayer game and the result is this game which lets up to 6 players drive a tank and shoot at each other. No emphasis on any advanced functionality, I just wanted to get this done and released. Note that a lot of trust is placed on the client here, which makes things simpler, but also makes it pretty easy to cheat by modifying the code.

The game is written in C and uses version 2 of the SDL library for graphics and sound. To make the networked multiplayer portion work, it uses the ENet reliable UDP networking library. It was created to be used on Linux, and I have not tried compiling and running it on other platforms. It probably works best on a local LAN, but I did test it through the Internet as well.

A screenshot:

Tank game screenshot


The map data is stored as a text file that looks like this, easily edited:

################################################################
#      #                                                       #
#      #                                                       #
#      #                                                       #
#   T  #                                                    T  #
#      #                                                       #
#      #                             T                         #
#      #      #########                                 ########
#                                                              #
#                                                              #
#                                                              #
#                                                              #
#             #                                                #
#             #                                                #
#             #                T                               #
#             #                              ###########       #
#             #                              #                 #
#             #                              #                 #
#             #                              #                 #
#             #                              #                 #
#             #            #########                           #
#             #            #########                           #
#             #            #########                           #
#     T       #            #########                           #
#             #            #########              T            #
#             #                                                #
#             #                                                #
#             #                                                #
#             #                                                #
#             #                                                #
#             #                                                #
#             #                T     #                         #
#             #                      #                         #
#             #                      #                         #
#             #                      ###################       #
#             #                                                #
#             #        #######                                 #
#                                                              #
#                                                              #
#                                                              #
########                                                #      #
#                                        T              #      #
#                                                       #      #
#                                                       #      #
#   T                                                   #   T  #
#                                                       #      #
#                                                       #      #
################################################################
          


The source code is released under the MIT license and can be downloaded here.

Topic: Open Source, by Kjetil @ 17/04-2021, Article Link

Older articles