Page 1 of 1

Yet another emulation: libgtemu

Posted: 25 Aug 2019, 13:22
by DavidHK

the Gigatron recently came to my attention and now I am quite fascinated by this project. I do not own a real Gigatron yet but I am already very curious as to which possibilities I would have on this system. As I am using a rather vintage Linux computer for my development at home I decided to write my own emulation with as little overhead as possible to get solid 60 FPS and uninterrupted sound.

In order to still have flexibility for debugging I have written my emulation as a library with bindings to the Lua scripting language. I know that the Gigatron community is primarily writing scripts in Python, but I haven't written any bindings to Python yet, so I first took the more familiar path.

Except for the Lua bindings the library is just using SDL2. A demo main program without any Lua is also available.

For those who might be interested in this, I have placed it on Github: ... f/libgtemu

How significant is the audio out filter that the Gigatron has? Does it sound audibly different to a PC playing the same samples without a filter?

Best regards


Re: Yet another emulation: libgtemu

Posted: 25 Aug 2019, 15:23
by marcelk
Great! Feel free to offer a pull request so we can share your work from the main repo. Don't forget to insert a oneliner in the main/root to describe it. These lines are sorted alphabetically by GitHub user id.

It's wise that you let the GT1 file loading go through the IN port and the Loader application. Some emulators dump the GT1 directly into memory, and that method doesn't work for programs that need the sound channel area for their own purpose (e.g. Microchess, Apple 1 emulation, etc). In ROM v4, Loader detects when this happens and disables these sound channels, so there's no conflict. Phil Thomas' online javascript emulator also works correctly because it follows this route.

Regarding the two audio filters: I'm slightly disappointed about their limited effect, and I can't hear the difference between the emulators and the real hardware myself. Still they nicely bring down the line level to the right voltage and provide AC coupling, but that's about it.

Re: Yet another emulation: libgtemu

Posted: 25 Aug 2019, 19:07
by DavidHK
Getting the loader peripherals to work was actually the biggest challenge for me in this project. Sometimes the timing was off, sometimes I accidentally overwrote data before the Loader had a chance to read it, I missed that a package always needed to be filled to full size, etc. I outputted all read accesses to the IN register by the loader and compared my code with BabbelFish, the Loader and Phil Thomas' emulator. I can only imagine what it would be like to debug something like this on the hardware. ;-)

Re: Yet another emulation: libgtemu

Posted: 29 Aug 2019, 19:39
by DavidHK
I've just pushed a new version, I expanded the stand-alone application a bit, so it can now load GT1 files without needing to be controlled from a Lua script.

The main README file currently mentions that this emulator is for Linux. That is what I have currently tested it on, but I still hope it runs on any system where SDL is running. (But it will probably require writing an own Makefile or including the files in a project in an IDE or so).

Re: Yet another emulation: libgtemu

Posted: 30 Aug 2019, 06:20
by marcelk
It works very well on my MacBook Pro, except for the sound (which is absent). This may very well become my new emulator of choice... It's very snappy, doesn't need nodejs and has a very clean and minimal interface. I like it a lot!

Re: Yet another emulation: libgtemu

Posted: 30 Aug 2019, 14:44
by DavidHK
Thanks! The missing sound is a bit strange. Does at67's emulator output sound on your system? He is also using the sound functions of SDL.

In my working branch ( ... f/libgtemu) I have just committed a change to the sound system; I am now using the older audio callback functions instead of the "newer" (SDL 2.0.4) SDL_QueueAudio function. Maybe QueueAudio wasn't ported to the Mac yet? With my own callback function I could now also solve some issues with clicking noise I sometimes had with QueueAudio when the frame rate wasn't stable.

Re: Yet another emulation: libgtemu

Posted: 30 Aug 2019, 21:24
by marcelk
The build from that branch also doesn't produce sound on my MacBook Pro. I wouldn't know about the at67 system: I just tried and it doesn't work on my Mac any longer due to an SDL error (and figuring out 'cmake' and SDL is out of my league unfortunately). I don't recall if it produced sound before.

Re: Yet another emulation: libgtemu

Posted: 01 Sep 2019, 17:51
by DavidHK
I published version 0.3, with some changes based on feedback from Marcel. Here is a short list:
  • new name for the stand-alone program: gtrun (to avoid confusion with the reference emulation)
  • gtrun sends given GT1 programs on startup
  • Key combination Alt-X to restart and reload a GT1 program
  • option for sending text files
  • handle dropped files (might need some configuration files on a Mac: )
  • further changes to the audio configuration
I have cross-compiled it and got it to run under Windows.

Re: Yet another emulation: libgtemu

Posted: 02 Sep 2019, 08:48
by marcelk
As a command line & printf debugger type of person, I absolutely love it! Thank you so much! Also the sound works fine on my MacBook Pro now.

Re: Yet another emulation: libgtemu

Posted: 11 Sep 2019, 17:57
by DavidHK
Now that I've got a real Gigatron and a real Pluggy McPlugface I realized I needed a further version, as the Pluggy interface handles text keys differently -- it only sends the key for a few frames, even when you hold it longer. As I am writing Piano demo apps it was important for me to get it similar and so there is a new version (0.4) now.

I also optimized the emulator slightly, as there is one instruction that is clearly the most frequently used:

Code: Select all

ora [y,x++], out
I provided a shortcut for it and the two next most frequently used instructions. While testing which number of instructions are useful to provide a shortcut for, I realized I hadn't turned on the optimization of the C compiler -- switching it on made a way huger impact.

Another (minor) change is that ROM files also need to be passed as an option to the stand-alone application instead of being just the first non-option argument. Too often did I accidentally tell it to load a GT1-file as ROM...