Epson HX-20 Emulator Sound Support

I have added piezo speaker sound support to my hex20 Epson HX-20 emulator and increased the version number to "0.2". On the real hardware the speaker is controlled by an I/O pin from the slave MCU and timed to produce a square wave pulse with different frequencies. I tried some different approaches to emulation but ended up with simply sampling this I/O pin and writing the value into a FIFO at the MCU clock frequency of 612900 Hz. The FIFO is then read by the SDL audio callback 14 times and averaged for each sample to closely match the 44100 Hz audio sample rate. Not exactly Hi-Fi but it is simple and it works.

The main goal with this update was to the able to run the "Attack of the Sine Wave from Outer Space" game in the emulator. In addition to producing a lot of sound, this game also relies on the POINT() instruction in Epson BASIC which reads data from the LCD display. Reading the uPD7227 LCD display controllers happens through a clocked serial interface which has been partially implemented.

The game can be found in the pjspot collection. Here is a video from 10 years ago running it on real hardware, and here is a video running it on the the updated emulator.

Version 0.2 can be downloaded here but the GitHub repository has also been updated.

Terminal Mode Commodore 64 Emulator SID Support

I have added SID sound support to my tmce64 emulator and bumped the version number to "0.4". The SID is quite complicated so instead of trying to emulate it myself I have added a wrapper around the excellent reSID implementation, which is also used by the VICE emulator I believe.

I have based my wrapper around reSID version 0.16 which can be found here. There seems to be a newer experimental version available also, but I have not tried it.

I did not install reSID system wide, but instead just compiled it:

tar -xvzf resid-0.16.tar.gz
cd resid-0.16
./configure
make
          

This will result in a static "libresid.a" library being built in the hidden ".libs" sub-directory which needs to be pointed to in the tmce64 Makefile along with the reSID header files.

The tmce64 0.4 release also contains some other improvements and bug-fixes, but most notably a simple implementation of the VIC-II raster interrupt which is used by a lot of demos. However the accuracy is far from perfect so expect many demos to fail, especially later ones that rely on very precise timings. Support for undocumented 6502 opcodes was merged from the ASCII Atari 2600 Emulator project. A joystick handled by SDL2 is now also supported, but only plugged in the C64 port 2.

A challenge with reSID and SDL2 audio is to keep them in sync, so that reSID writes audio data at approximately the same speed as the SDL2 audio callback can read it. I have solved this by letting reSID directly control the overall emulation speed to catch up or let go if one or the other falls behind. There is still some problems if "warp mode" is activated where the sync is lost which will cause bad audio while attempting to catch up.

Version 0.4 can be downloaded here but the GitHub repository has also been updated.

I have uploaded some videos to YouTube that shows the reSID sound implementation:
* Late 80's "Future Composer 2.0 Intro" demo.
* Late 80's "In Full Gear" demo in monochrome mode.
* Modern "Digioi" game with heavy PETSCII graphics.

ASCII Atari 2600 Emulator

Here is another emulator called "atarascii" that can run in a Linux terminal using curses, this time targeting the Atari 2600 system. Much inspiration and code is based on my earlier work on the lazyboNES emulator. Compared to the NES graphics handled by it's PPU, the Atari 2600 and it's TIA graphics chip is quite different. The NES PPU is based around a tile-set that is updated each frame, but the TIA uses some simple registers that are updated for every scanline.

The Atari 2600 TIA can output 228 visible scanlines of video, so this emulator uses some approximation to fit this into lines/rows on the terminal. A classic terminal has only 24 lines/rows, but by using an X terminal the font size can be reduced and the window size increased to fit everything if needed. To improve a little bit on the possibly reduced screen real estate, the vertical blankling scanlines are also filtered out by default. Wether or not high graphics fidelity is needed depends entirely on the game. Make sure to run with a 256-color supported terminal for the best experience. The color palette should match well with the default "xterm-256color" and "rxvt-unicode-256color" types at least.

The emulator also depends on SDL2 for audio and input support. It is highly recommended to use a joystick/gamepad through SDL2 to play, since the keyboard input on the terminal is sketchy and not possible to emulate fully. Audio is supported but not entirely accurate since part of the implementation has been simplified. Video output on SDL is also possible and is shown in parallel with the terminal output. A CSV file can be used for TAS input as well.

ROM cartridge support is currently limited to the most common 2K, 4K and 8K sizes. I have only tested a handful of games and have no idea about the extent of compatibility. Pressing Ctrl+C in the terminal will break into a debugger where various data can be dumped, including a CPU trace.

You can download version 0.1 here or check the GitHub repository which might be updated.

Some screenshots:

Here are some video demos of "Dragster", "Tennis" and "River Raid".

lazyboNES Emulator TAS Support

I have made some updates to the lazyboNES emulator which is used to run Super Mario Bros in a Linux terminal.

Some updates were made a while ago actually, in the GitHub repository, tagged as version 0.2. The main feature then was support for 8 ANSI colors, as well as various bugfixes and minor improvements that was found during play testing.

Now I present version 0.3. (An update has also been made to the GitHub repo.) The main feature is support for Tool-assisted speedruns by reading controller inputs from a FM2 file.

Some critical changes were needed in order to get this to work properly, if not the controller input would not be correctly aligned with the video frames. The first requirement was better synchronization between the CPU and the PPU (video) where the clock cycles for each needed to be more accurate and similar to a real NES. The second requirement was that the PPU needs to run a few frames by itself before the CPU is started.

Here is a screenshot of the color mode:

For a full TAS playthrough in lazyboNES check this YouTube video.

More CP/M Emulator Ports

I decided to port my "kaytil" Z80 CP/M 2.2 emulator to even more platforms to see if it could be done. It can now be compiled for DOS by using the DJGPP toolchain or Windows by using the MinGW toolchain. In order to support Windows, I needed to make a curses based implementation of the console interface and this can also be used to compile an alternative Linux version based on (n)curses instead.

Since DJGPP is actually a 32-bit environment the DOS version also requires a 32-bit CPU to run and will use the CWSDPMI.EXE extender. The CPU needs to be fast as well, at least a Pentium II, to get acceptable speeds. But in order to not run too fast, a slowdown mechanism exists in the emulator as well. This slowdown mechanism is just a busy-wait since DOS has no multitasking concept and will just keeps the entire CPU to itself anyway.

I ran a simple benchmark for the DOS version by using "BASIC-80 Rev. 5.21" and the following BASIC program:

10 FOR I=0 TO 10000 STEP 1
20 PRINT I
30 NEXT I
          

Here are the results:

|----------------------|---------------------|
|                      |      Slowdown       |
|System                | Enabled    Disabled |
|----------------------|----------|----------|
|QEMU (AMD Ryzen 9)    | 1m11s    | 0m21s    |
|DOSBox (AMD Ryzen 9)  | 1m11s    | -        |        
|Pentium 166MHz        | 2m01s    | 1m59s    |        
|486SX 25MHz           | 19m16s   | -        |
|----------------------|----------|----------|
          

So it is possible to run it on a 486 CPU but it will be very slow.

The updated source code can be found here or at the Git repo here. Instructions for building is on the README.md within, but for convenience, here is a binary of the DOS version and Windows version.

Epson HX-20 Emulator

I have made an emulator called "hex20" that emulates the Epson HX-20 Portable Computer in a Linux terminal, similar to my other Z80 CP/M, NES and C64 emulators.

The HX-20 system uses two Hitachi HD6301 CPUs (based on the Motorola 6800 family) which communicate with each other over a internal serial link. This emulator needs the ROM files for both of these to function. A CRC32 check is performed on startup to make sure that the correct version 1.0 or version 1.1 ROM files are used.

One of the main features is the emulation of the LCD panel by using curses to display each individual pixel as a '#' (or '%') on a large 120x32 terminal window. It is also possible to force a smaller 20x4 window, but then only ASCII will be displayed and none of the special pixel drawing functions will work. Most of the keyboard keys are supported and multiple international character sets can be selected.

Another feature is auto-loading of BASIC program text files. This is achieved through clever use of the HX-20 ROM software ability to do automatic key input. A '2' is injected to enter BASIC from the menu, then all the text from the file is sent, and finally a BASIC RUN command is issued to start execution. On a real HX-20 a "Ctrl/@" initialization is usually needed on a cold start, but all the necessary data is already initialized automatically by the emulator itself. The RTC is also mapped directly to the host system clock so it does not need to be set.

The initial version can be downloaded here but the code is also available in this Git repository for further development. Note that at this point several features are still missing like sound support, TF-20 floppy drive and micro-cassette emulation.

Some screenshots from the emulator running in xterm:

Development of the emulator would have been impossible without the excellent Epson HX-20 resources from F. J. Kraan's web pages.

Terminal Mode Commodore 64 Emulator Disk Support

I have added support for D64 disk images to tmce64 and increased the version number to "0.3". In order to facilitate this several things needed to be added. The CIA emulation has been expanded to include the data ports, which are used to communicate with the disk drives. But the biggest task was to emulate the Commodore IEC serial bus that the KERNAL expects.

The disk and serial bus emulation is by no means complete, and is limited to be able to get a file listing (LOAD"$",8) and loading individual files. Fast loaders will not work and attempting to do anything fancy will probably freeze the emulator.

Stack trace support has also been added to the built-in debugger. There is even support for symbol names, but this is currently just a hardcoded list of certain serial bus functions. Bank switching for the VIC-II chip is also handled in case any programs changes the graphics memory areas.

These changes makes it possible to run the 8-Bit Guy's Attack of the PETSCII Robots in the emulator. Since conversion is done from PETSCII, the reality is closer to "ASCII Robots" though. Since sprites are not supported, use the "C64PETSCII" version of the game.

Some more screenshots:

Version 0.3 can be downloaded here but the GitHub repository has also been updated.

VT100 Terminal Emulator on Raspberry Pi Pico

Here is another Raspberry Pi Pico project, this time a DEC VT100 Terminal emulator. Host communication goes through the "standard" UART, composite video is used for the output and a PS/2 keyboard is used for the input. I have named this program "Terminominal".

Since I'm Norwegian I have made some design choices that reflect this. The first is that the composite video uses the PAL standard at 50 Hz. The keyboard scancode handling expects the Norwegian layout, but this can be changed to US layout with a compile time define. Finally the built-in font/character set is ISO-8859-1 (latin-1) compatible.

The composite video (CVBS) is generated by one of the Pico's PIO cores running at 40 MHz, which in turn creates time slices of 0.05 microseconds that affects a lot of the architecture in this program. After taking care of overscan, there is 880 dots on 240 scanlines remaining for the "visible" picture. First I tried using a standard CGA font at 8x8 which would give 110 columns by 30 rows, but the picture was almost unreadable. Instead I designed my own 11x10 font which fits perfectly for a 80 column by 24 rows picture and is quite readable on a CRT display.

The first ARM core reads the UART for incoming bytes and processes these to emulate the VT100 behaviour. Escape codes are processed and then a "screen" array is updated which represents all the characters currently on the screen. The second ARM core fetches characters from this "screen" array, if they have changed, and converts these to scanline and dot information using the font data and puts this into a "frame" array. DMA is used by the PIO core to fetch the "frame" array and push this out on the GPIO pins.

A 2-bit DAC for the video is created by using two resistors. Since the GPIO voltage is 3.3V and the composite video input impedance (on a TV set) is 75 ohms, good values are 680 ohms and 220 ohms for these resistors. It is also possible to use 1000 ohms and 330 ohms, which gives a slightly dimmer picture. The 2 bits gives four signal levels, where one is sync and the other three shades of: black, grey and white.

The PS/2 keyboard protocol is handled by the second PIO core which generates an interrupt once the required 11 bit frame has been read. The interrupt handler converts the scancode to the appropriate byte and sends it out on the UART. Note that since the PS/2 protocol uses 5V and the Raspberry Pi Pico GPIO pins uses 3.3V a level shifter is needed in between!

The VT100 emulation has been tested with vttest and the most important features are supported. VT52 and VT102 modes are not really supported. It should work fine against a Linux host at least. The UART runs at 115200 baud, but can be changed through re-compilation to other speeds.

Here is a block diagram which shows the architecture:

Here is a connection/function table for the GPIO pins:

|--------|-----------|------------|-------------------------|
| Pin No | Pin Name  | Function   | Connected To            |
|--------|-----------|------------|-------------------------|
| 1      | GP0       | UART TX    |                         |
| 2      | GP1       | UART RX    |                         |
| 6      | GP4       | PS/2 Data  | 3.3V<->5V Level Shifter |
| 7      | GP5       | PS/2 Clock | 3.3V<->5V Level Shifter |
| 21     | GP16      | CVBS DAC   | 680 Ohm Resistor        |
| 22     | GP17      | CVBS DAC   | 220 Ohm Resistor        |
| 36     | 3V3 (OUT) | +3.3V      | 3.3V<->5V Level Shifter |
| 40     | VBUS      | +5V        | 3.3V<->5V Level Shifter |
|--------|-----------|------------|-------------------------|
          

Here is a breadboard layout created with Fritzing:

Notice that the GPIO pins for the composite video is on the other end of the Pico. This was needed because it generates a lot of noise, so much in fact that it affects the PS/2 signalling. This would result in lost bits and parity errors.

A snapshot of version 0.1 can be downloaded here, or check the Git repository here. Check the included README.md for build instructions. It is also possible to compile an SDL version which is used for testing directly on Linux.

I appreciate the good instructions from Van Hunter Adams on how to use DMA on the Raspberry Pi Pico and Javier Valcarce on how to generate PAL video signals.

Here is a photo of Terminominal running on one Pico and connected to another Pico running the kaytil CP/M emulator:

CP/M on the Raspberry Pi Pico

A new port is available of my "kaytil" Z80 CP/M 2.2 emulator, this time targeting the new Raspberry Pi Pico.

A snapshot of the "Version 0.2" source can be downloaded here, or check out the Git repository here. The GR-SAKURA version has now also been incorporated into the same tarball and Git repo, instead of residing on a branch.

In the same fashion as the GR-SAKURA version, the CP/M 2.2 and CBIOS binaries are embedded directly into the final binary. For the Pico version this is taken even a step further since the disk images are ALSO embedded into the final binary! This means the disk images are in fact hard-coded and needs to be provided/updated before building. The disk images provided with the source code are just dummies and should be replaced with something more useful.

I figured that embedding the disk images was the easiest way to get things up and running considering the constraints of the Raspberry Pi Pico platform. This works nicely since the Pico has 2MB of Flash and can easily hold four IBM 3740 floppy disk images, typically 256KB in size each. Embedding the disk images is done using objcopy and forcefully placed in the ".rodata" section which causes them to reside in the Pico Flash instead of the SRAM.

The console is available on the "standard" UART at pins 1 and 2 and running at 115200 baud. Conversion between ADM-3A codes to VT100/ANSI codes are done in the emulator in the same way as the other versions.

Building requires the ARM GCC toolchain, CMake and the Pico SDK; just follow the official guide on how to set this up. In typical CMake fashion, create a build folder and call cmake pointing to the "pico/" subdirectory containing the CMakeLists.txt file:

mkdir build
cd build
PICO_SDK_PATH=/path/to/pico-sdk cmake /path/to/kaytil/pico/
make
          

The resulting "kaytil.elf" file can be flashed with SWD, or the "kaytil.uf2" file can be copied through USB in the BOOTSEL mode.

Here is a photo showing it in action, using a Commodre 64 as a terminal:

For this to work I used a level shifter between the C64 user port and the Raspberry Pi Pico to convert between +5V and +3.3V. In addition I changed the baudrate to 2400 baud by calling "uart_set_baudrate(uart0, 2400)" in "console_init()".

Terminal Mode Commodore 64 Emulator Update

I have performed a massive overhaul of the proof-of-concept C64 emulator I published about last year. This new version,which I have dubbed "0.2" is much more usable.

A major change in the architecture is that the old version was blocking on input from stdin, which is an interesting concept, but not feasible for more advanced usage. It is now based around curses with non-blocking stdin instead. Moving to curses means there is now a lot better support for graphics, including colors if a 256-color terminal is used. Conversion is done from PETSCII to ASCII and will work best as long as the default character sets are used. There is no sprite emulation.

Pressing Ctrl-C at any time will switch to a (non-curses) debugger. In this mode it is possible to dump memory locations and get a CPU trace. In addition there is support for setting read and write breakpoints on memory addresses which breaks back into this same debugger. In order to properly exit the emulator one must also typically enter the debugger and issue a 'q' from there to quit.

The emulator can be run at close to C64 speed (for games) or in "warp mode" where 100% CPU is used (for raw BASIC programs). I also needed to add support for the timers in the CIA since some games rely on these for random number generation. One unique feature is that getting the TOD (Time of Day) registers from the CIA will return the actual clock from the host system.

As before the emulator needs the ROMs from VICE to run, but the location of these can now be specified on the command line in case they are not at the default location.

There is no Datasette (tape) or 1541 (floppy disk) support, but C64 PRG-style programs may be loaded directly from the command line (or debugger) instead. These are injected directly into memory where they are supposed to be for the BASIC "RUN" command to work. Most BASIC programs should probably work, but machine code programs are hit-and-miss.

The new version can be downloaded here and the GitHub repository has also been updated.

Finally, some color screenshots: