Eightball compiler targeting Gigatron - initial thoughts

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice.
Post Reply
Posts: 3
Joined: 05 Jul 2019, 00:03

Eightball compiler targeting Gigatron - initial thoughts

Post by bobbi » 05 Jul 2019, 00:58

Now I have my Gigatron running, I am thinking of some interesting projects. Over the last couple of years I have been hacking on a programming language implementation for a novel language that I ended up calling Eightball (since it targets 8 bit machines.) It lives here: https://github.com/bobbimanners/EightBall

EightBall started out as an interpreter, running on VIC-20, C64 and Apple II. It subsequently evolved into a compiler which emits VM instructions. Eightball provides an implementation of the VM for 6502-based machines. The compiler is part of the interpreter, which means you can fool around with code in the interpreter, just like BASIC, and then compile for the VM. It is rather rough around the edges though! (Patches welcome, provided they don't make the code significantly bigger!)

I don't think it is feasible to port the interpreter to Gigatron right now, since it expects a device with a filesystem on it (floppy disk etc.) However it would be possible to implement the VM on Gigatron without too much effort I think. This would allow programs to be written in Eightball on an Apple II, C64 or a Linux PC and then compiled to create a bytecode file that can be run on the Gigatron.

Which approach makes the most sense:
1) Implement Eightball VM in Gigatron vCPU code.
2) Implement Eightball VM in native Gigatron code so it is a third virtual CPU (after vCPU and v6502)
3) Modify my compiler to emit Gigatron vCPU code (maybe gcl!?)

Any thoughts folks?

User avatar
Posts: 283
Joined: 13 May 2018, 08:26

Re: Eightball compiler targeting Gigatron - initial thoughts

Post by marcelk » 05 Jul 2019, 11:20

Thanks for sharing your build pictures!

My guess is that option 3 gives the quickest results with "OK" performance, and it's not harder than 1. There's no need to go through an external file format first (.vasm, .gcl). Although some recent changes to "gcl0x" make it more suitable as an assembler: it supports simple labels now. But you can just as easy emit a .gt1 file directly, and test in one of the many emulators.

Option 2 can easily become a frustrating experience real quick. I wouldn't encourage it as a starting project.

Then there's option 4: implement/port the VM to v6502.

As of yesterday, the development ROM in GitHub (make dev) also has a 'channelMask' trick to deactivate sound channel 2,3,4. The purpose of this is to end up with less RAM fragmentation for projects like this. I made it for the Apple-1 mockup. It's a hack by repurposing some bits in romType ($21):

Code: Select all

    The low 3 bits of romType are repurposed to select the actively updated
    sound channels. Valid bit combinations are:
     xxxxx011     Default after reset: 4 channels (page 1,2,3,4)
     xxxxx001     2 channels at double update rate (page 1,2)
     xxxxx000     1 channel at quadruple update rate (page 1)
    The main application for this is to free up the high bytes of page 2,3,4.
    For robustness, the critical channel and channelMask bits are restored
    every videoframe. This is an attempt to mitigate memory corruption in
    case these variables get overwritten by accident.
Edit: effectively you get a consecutive block from $200 to $7ff in RAM to play with, or 1.5K.

You still have to be careful with loading into the two high bytes for these pages ($0xFE and $0xFF), because by default all 4 channels are active. Therefore loading there won't work: by the time your program runs and can change the channelMask bits, those high bytes have been modified by the sound loop already.

Post Reply