Discovering the Panasonic JR-200U

I had never even seen a Panasonic JR-200U before 2012, but when I did, I became curious. What kind of secrets does this oddball 8-bit contain? This page is a collection of several useful bits and pieces I’ve come across so far. Corrections and additions are most welcome. Some of the findings, such as the timings, might be correct only for the PAL JR-200UP model, since that’s the only one I have at my disposal. Big thanks to Tero Heikkinen for his contributions!

Pretty much all the information you see on this page is based on disassembling the ROM, individual chips’ data sheets, and simply trying things out. So far I’ve been unable to get my hands on the precious Service Manual, which would have saved a lot of time. If you have it, please share :)


The main processor is an MN1800A, a clone of the Motorola MC6802 (which itself is a revision of the MC6800), reputedly running at 0.89 MHz. The most notable difference is that the MN1800A does not have an internal oscillator. Not much to see here:

The MC6800 features quite many addressing modes. Among the most interesting ones is the direct mode, which lets you access the first 256 bytes (the zero page) of the RAM quickly. Most of that area is occupied by system and BASIC variables by default.

I’m trying to solve the actual clock speed of the CPU, as that 0.89 MHz has just been mindlessly repeated here and there. As the display controller generates the clock with some internal divisor, it’d be natural that the CPU gets  something related to the TV standard. Indeed, dividing the NTSC carrier frequency by four would yield 8.94886 MHz. It remains to be seen whether the PAL version (200UP) follows the same convention.

System chips

The following chips can be found on the circuit board:

Tero took some high resolution photos of the guts an put them online. Check out the images here.


JR-200 has only one screen resolution, 256×192 pixels with eight colors, but bit 7 of the character color lets you select an additional blocky low-resolution mode for each character position. There’s two kilos of VRAM plus two more for the character bitmaps. Unfortunately, there’s not enough space for two full pages. The text resolution is 32×24 (768 positions) and the bitmap for each 8×8-pixel character can be redefined. The border color can be set separately. Eight colors are available in a typical three-bit GRB format:

Bits 0–2 of the color table define the fg color of the respective character position, and bits 3–5 the bg color. Bit 6 selects the charset base address, and bit 7 switches the character position in question to lowres mode, where a 8×8 pixel region is split into four 4×4 blocks, effectively yielding a 64×48 resolution where each pixel can be set individually. The upper half gets its colors from the character position table, and the other half from the color table.

When bit 6 is zero, the character bitmaps are read from $D000. Value 1 sets the base address to $C000, which is rather inconvenient, since it overlaps with the character positions and colormap, except at two locations: $C000–$C0FF and $C400–$C4FF. Thus, characters 0–31 and 128–159 can be relocated without overlaps, yielding 320 different possible characters (256+32+32).

So far it’s unknown whether there’s any exact way to sync to the screen refresh. There’s no VBI, and judging by the existing games, there’s no way to read the refresh phase easily. But we’d like to do smooth graphics, right? Luckily, the timer can be reprogrammed to serve as a VBI. For exact 50 Hz PAL sync the values are 3414 for three frames and then 3413 for one. Screen refresh can be — to a certain extent — followed by reading the memory addresses starting from $CA00, which return the last attribute shown on the screen. The timing is a bit tricky, but by drawing a suitable pattern on the screen and setting the clock according to that it’s possible to create a robust VBI. My example solution: vbi.s

The graphical capabilities of the Spectrum computers aren’t that far from the Panasonic and there are truckloads of great pictures available, so I wrote a little converter in Processing to turn 256×192 images into something you can display on the JR-200. This directory contains some converted images — apologies if your hard work was ruined in the process :) 320 blocks aren’t usually enough to reproduce the original exactly. Run them like this:


Sound and timers

According to Wikipedia and there should be three separate square wave channels capable of five octaves. JR-100, on the other hand, only had a simple one-channel beeper. MESS source code implies that JR-200 might contain a good old PSG, AY-3-8910, but on the circuit board there’s no such thing to be found. Some experimenting and ROM disassembly finally revealed the sad state of affairs: there is no sound chip. Instead, it’s the clock and I/O chip, MN1271, that produces the beeps.

MN1271 contains two 16-bit timers (E and F) plus four 8-bit counters (A–D). Timer A controls serial communications speed and B is the obscure “bpm timer”. E is used as the system clock and generates an IRQ every 0.1 seconds, whereas C, D and F are connected to the speaker and used for square wave generation. That’s three channels, but C and D can only produce a narrow range of different frequencies, being 8-bit. No noise, volume settings, envelopes or filters, just three square waves out of which two are very limited. With low frequencies the output starts to look more like saw wave, since the level fades towards zero.

Each timer has a control byte and a 8-bit or 16-bit counter. The three lowest control bits must contain $6 in order to keep the timer running. Any other value will stop the timer. The higher bits define the operation mode of the timer (see below). Under normal conditions the control byte of E contains $4E. The beeper timers’ control byte depends on the octave that is being played back or zero if the channel is off. All the timers can generate an IRQ, so in that sense E is not special at all. Known control bits so far:

To reprogram the timer speed all that is needed is a new counter value. My best guess on the base frequency at the moment is 1.3655 MHz – probably off– which you divide by the desired divisor and frequency to get the counter value. Note that 1 is the smallest possible value, since 0 is considered to be 256. For 16-bit counters poke the hi byte and then the lo byte to their respective addresses. See the memory map below for the memory locations of each timer. For square waves you need to divide by 2*frequency, since a full wave requires two changes. Here’s a list of the closest 16-bit counter values for notes using divisor 8: jr200notes.txt (might be revised later).

Since there were apparently no existing tools for creating music I spent one weekend writing a little music converter and a player routine that let you convert XM tunes to Panasonic beeps. The composer needs to be aware of the harsh limitations imposed both by the simple routine and the less-than-stellar sound chip, but at least this is a bit easier than typing hex into assembler data statements. Without further ado, go ahead and download Musagi.

Keyboard and joysticks

The keyboard and joysticks are connected to the MN1544, which checks their status and interrupts the main CPU when there’s activity. Normally the system doesn’t read the joysticks at all, just the keyboard (see memory map below for the locations of the related buffers). The last keypress can be read from $C801, but it’s not enough for games, since you can’t tell whether the key is still pressed or not.

Even the BASIC interpreter features a function called STICK, which lets you read the keyboard and joysticks as directly as possible. From assembly the same subroutine can be called at $E8CB (slowjoy.s). It’s still impossible to read whether a particular key is pressed or not, but at least the joysticks work perfectly. The biggest problem with the approach is that it takes about 1/4th of a frame to complete the call, since the subroutine needs to wait for three interrupts coming from the 1544. Direct communication with the 1544 is kind of hairy business, but luckily the joysticks can be read fast by first setting the correct mode, doing something useful while the three interrupts take place, and reading the result only then (fastjoy.s).

Memory map

First a general view (click to see full size). A similar chart is available on the Operation Instructions, page 51.


Know addresses in more detail:

Still missing quite a lot of relevant stuff and details. I’ll add more after testing on real equipment. These things are not that well documented at all.

File transfer

I don’t know if there ever was a floppy drive available for JR-200. I very much doubt it, but even if there was, practically nobody would own it, so we’re stuck with cassettes. A very typical approach these days is to emulate a tape drive by playing back sound files from a modern host computer to the cassette port. For an in-depth description of the tape format and the associated CJR emulator files check the Old Machinery blog (see below). Credits go to Tero Heikkinen for documenting the format.

I made an attempt at writing a binary to CJR converter that turns compiled programs into tape image files. Source here: bin2cjr.c. Seems to work. To play back the generated CJR to the real machine, use cjr2wav.c. Appears to work well with 2400 baud files, but not 600 at the moment. For easy development, here’s a Makefile that puts it all together. If you’re using a Mac, replace the playsound command with afplay. On Linux you might use aplay, too. On the Panasonic do something like this:


Raw wav files tend to be a bit on the big side — a tiny 7k CJR turns into a 2 MB wav with the above converter. Gzipping the wav makes it way smaller, just 55k. Lossy formats, such as mp3, might distort the waveform too much, but at least 128kbit files seemed to work just fine. The file size decreased to 763k, but the resulting mp3 can’t be effectively compressed any longer. YMMV.

The concept is still under development, but here’s an LZSS compressor and a 6800 machine language decompressor routine for your enjoyment. Need to consider them a bit further, but especially for sparse files the gains could be significant.