Testing "8-bit readiness" with an emulator or pre-packaged kit

Question

I'm working on a project that intends to implement a dynamically typed language on 8-bit systems. (That is, a CPU with 16-bit pointers and a maximum of 64 kB of RAM. Some language tricks are involved, which I can explain in more detail if you want. Development is at https://git.sr.ht/~jpivarski/zippy)

I'd like to test it in some realistic way during development, either by running (for example) a Z80 system in emulation or by connecting a hobby kit to my Linux computer (USB?), downloading compiled code to it, running it, and seeing the results in a window or little screen.

I've done enough research to know that SDCC is a good compiler—if I compile my no-libraries, no-malloc C code with that, then I'll find out if I'm using C features that are incompatible with these small systems. I've also found hundreds of emulators and hardware kits online, some do-it-yourself, others more pre-packaged (I'd want the latter).

However, I'm still confused about how to get started on a runtime system, in some basic ways. I've seen a lot of references to a CP/M operating system, but I don't think the device would need to have an operating system. I assume that my compiled C code would go into real or emulated ROM, and I'd have unrestricted 64 kB of address space to play with.

I understand that this depends on the whole architecture, not just the CPU, but any generic/reasonable architecture would be sufficient to determine whether I'm writing realistic code or not.

I guess I'm imagining a situation that's more like GP-GPU development: there's a device that I can load code into, that code computes something, using its RAM as a scratch-pad, and then returns results somehow, possibly as an emulated screen in a window, possibly a real screen that I look at.

What kinds of tools should I be looking for to get this kind of development experience (for both the emulated and real-hardware cases)? Do you have any suggestions of where to start?

Answer 1

Your computer needs input and output. You can provide this in a great number of ways, but emulating an entire screen is probably too much work. One of the simplest approaches is an asynchronous serial port. This is what is done on most CP/M machines, and the basic RC2014, and lots of other single-board computers too.

For an emulated system, you connect your (emulated) serial port to standard I/O. There are tons of preexisting emulators for this purpose, so you don’t need to write an emulator (unless you want to, but that’s a different kind of fun!). Using a serial port on standard in/standard out means you can connect test harnesses directly to the emulator, greatly speeding your development cycle.

For physical hardware, you connect your physical Zilog SIO chip (or DART, MC6850, 16550, or whatever UART you have chosen) to a cheap-o USB-TTL serial adapter, and connect from your host machine to the physical hardware via (e.g.) screen or minicom. You can even get a RS232 adapter to use a physical terminal, though those are very bulky and rare these days! Or use the built-in serial port on an older PC, though that will require an additional chip and two extra voltages (+/- 12V usually) on your computer for level shifting.

With a simple boot loader, you can even use the same serial port to load programs into your 8-bit system. In fact, this is what many preexisting development boards do.

---

However, if you really want to be extremely simple, just use RAM as your input and output! An emulator can easily write and read to RAM. There is a physical type of “EPROM Emulator” board that can do this too, but you’re venturing deep into higher costs at that point.

Answer 2

Ever thought about using an 8086?

Wait, hear me out:

The 8086 is exactly what your requirements seem to be:

• 8 Bit registers
• (and 8 bit bus in case of an 8088)
• 16 bit pointers
• 64 KiB address space

That is if you set all segment registers to the same value. Which is the Tiny programming model used for COM programs under DOS - an environment especially made for (often) automatic translation of 8-bit code from 8080 systems to 8086. Even better DOS offers since 1.0 calls equivalent to CP/M nicely fitting 8 bit code.

After all, the 8086 was developed as an almost direct replacement in terms of hard and software. While the hardware is very close to the 8085 bus, the 8086 ISA set is essentially an extended 8080. All 8080 registers (and thus all basic Z80 registers (*1)) have direct counter parts:

• AL is A as the general purpose 8 bit accumulator,
• CH/CL is B/C as these were the general purpose pair and counter
• DH/DL is D/E, second general purpose 16 bit pair,
• BH/BL is H/L as the primary pointer register.

Also, almost all instruction are available with the same addressing mode (*2). Exceptions are:

• PUSH/POP PSW which on the 8080 pushes Flags and A while the 8086 handles them separate - might even simplify design
• LDAX/STAX - to be replaced by moving CX or DX to SI or DI first
• All conditional CALL - to be replaced by conditional JMP around a CALL
• All conditional RETURN- to be replaced by conditional JMP around a RET

Either of these may not be important at all in your project.

Going with the 8086 as 8 bit platform provides several advantages:

• No need to start to build hardware - any modern (or old) PC will do it
• No need to write an emulator - there are several - like DOSBox - availible for many modern OS
• No need to learn the quirks of some 80s computer
• No need to learn a new OS (*3)
• Seem less integration in file system and environment of your OS
• Use the computer right in front of you
• Use the many tools you're familiar with

By restricting yourself to only 8080 type instructions a backport to real 8 bit hardware will be a no-brainer, as all 8086 (and DOS) specifica can be handled by a very slim wraper.

And in case you're using a C supporting DOS, all you have to do is switch for COM generation.

---

P.S.: Maybe I'm just not familiar with that repository, but I had a hard time to find any spec for that language...

---

*1 - Ignoring the second register set, which is in most programming situations not helpful anyway.

*2 - Rather easy as the 8080 doesn't know many

*3 - Well, maybe relearning DOS :)

Answer 3

I would definitely go for an emulated ZX Spectrum 48K because:

1. There are tons of free emulators for it

2. No need for injection of code

   You simply create and load *.tap file with your code into emulator (I did not see any that would not support tap files) and on ZX side simply type this in BASIC:

   LOAD ""
   

   or

   LOAD "" CODE
   

   If you encode your .tap file as code starting at some address like 32768 then you can run your code from BASIC like this:

   RANDOMIZE USR 32768
   

   If not you can do it from BASIC too IIRC:

   LOAD "" CODE 32768 
   RANDOMIZE USR 32768
   

3. Input/output

   You can use ZX keyboard (matrix), repro (1bit digital sound) and screen (direct VRAM access at 16384 of 256*192 dots and 32*24 color attributes ... 6912 Bytes total) so either you write your own handlers or use BASIC ROM subroutines (there are lots of docs describing them)

4. ZX is notoriously known so there are tons of docs for it

   You can find commented ROM disassembly listings, source for "any" subroutine or examples you can think of ... which might be compiled with any Z80 cross compiler and then you just use that as binary ...

5. Many emulators have build in debuggers

   So debugging your runtime/language engine code will be much easier...

which means no work on the 8bit machine side is needed and very little work on runtime stuff...

Answer 4

If you want to use a Z80 emulator under Linux I am currently looking at RunCPM for doing some hobby work in assembly where the plan is ending up with a Github Action (but that is another story!)

The reason why I ended up with it is because it can simulate floppies from Unix directories, so you generate your binary on your host in the appropriate directory, and then launch the emulator where it can immediately be seen and run (this can be automated).