Panasonic JR-200 emulation

Feeling a bit nostalgic, not only because it's an old computer, but because the early days of this blog was very much about Panasonic JR-200UP.

At that time I had hoped I could code something on the platform, especially as Marq went through the trouble of finding about most of the hardware and I spent time figuring out the tape format.

The lack of an emulator discouraged me, as I tend to code with extremely short build cycles, compiling the code every few seconds almost. The fun and nostalgia of tape loaded binaries fades quite rapidly.

Panyansonic by FIT.

At one point the solution could have been a device that helps transfer the data rapidly to the real computer. Although it showed promise it begun to feel fiddly altogether, and somewhat slow to set up compared to an emulator.

There has been James the Animal Tamer's JR200 emulation that I have never seen running, as it only runs on some Windows version. Also, the scanline/vblank emulation is apparently non-existent. The JR200 quite probably does not have a software-accessible, simple way to track the screen refresh accurately.

The trick is to rig the interrupt to work with the internal timer in that capacity, using an address to catch the currently written attribute, as in the Panyansonic and SR-200 intros made by FIT. I felt the emulator ought to be able to somehow work with this trick.


The Emulator

My emulation project had a few false starts over the years. I had to learn 8-bit assembly more in the meantime and something about how chips work before I begun to have the mindset necessary for building an emulation. Again, I work on Processing/Java.

I did some limited C64 emulation for myself in the recent past, which was a simpler task in the sense that I didn't set the bar very high and there are existing emulators to compare it to. (More about this, maybe, one day).

Left: Incomplete handling of Carry flag at one opcode caused glitching in the SR-200 scrollers. Right: opcode fixed

Here I had to enter the realm of the 6800 processor which is not as familiar to me as the 6502, and hardware that only has been properly documented by Marq, and even that documentation is not entirely complete.

The experience with 6502 was of course very helpful. One early issue was that in 6800, the C flag is treated differently in Subtract with Carry, i.e. the opposite of how it works in 6502. But all in all, the stack commands and how the stack works with JSR, RTS, is quite similar. 6800 stores 16-bit values in HI-LO format instead of LO-HI, which can make things more intuitive.

Over the years I've thought you need to be a genius to write an emulator, but it's not rocket science in the end. To me the key was to make the emulator do something visible in the first hours. So I wrote a few opcodes like INC addr16 and JMP opcode, after which I could already start looking at video emulation.

No joystick yet...

After a preliminary video mode was complete, I made a 256-entry switch-case list that treats each and every opcode as a separate entity. Non-implemented opcodes freeze the emulation and print out the address together with a list of opcodes that have so far been executed. This list can be used to track problems.

As the 6800 is very orthogonal the emulation code could be made much smaller. But it might have resulted in code that either doesn't work at all or works completely, which can be a very frustrating situation. So I guess I'm using an "agile" approach. The downside can be that early errors may be left hanging in some opcodes while rest of the similar instructions work, and these can be difficult to track.

Mind you, the emulation is far, far from complete, which is where the real difficulty lies. For my current purposes it doesn't really have to be complete, as I only wanted to ease the development of JR-200 code, if I ever get interested in that again. So, at least for now, it won't be a public project. I thought if it could run the tiny Nyansonic demo, then all would be well. And it sort of does.