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 are 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. Jeff from Vintage Volts was so helpful as to scan the US version of the Service Manual, which helped to clarify some issues. Grab it here. As there’s better info available now, I’ve removed some inaccurate paragraphs from this page altogether. Do note that there are some differences between the NTSC and the PAL versions, esp. in clock pulse generation and rates, so even the Service Manual isn’t always authoritative.

CPU

The main processor is an MN1800A, a clone of the Motorola MC6802 (which itself is a revision of the MC6800). The most notable difference is that the MN1800A does not have an internal oscillator. The A version of the chip can cope with speeds up to 1.5 MHz, whereas the normal one is limited to 1 MHz. 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 still 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 divides the NTSC-derived xtal 14.31818 MHz frequency with some probably 2n counter, it’d be natural that the CPU gets something related to that. Indeed, dividing the standard NTSC carrier frequency by four yields 0.894886 MHz.

However, that is not the processor speed. My current guess, based on code run in VRAM, is 1.366 MHz. On the other hand, the frequency doesn’t quite reveal all there is to it, as the speed is normally constrained by the 1-bit DRAM access. As fetching is exceptionally slow, instructions suffer from various penalties, for example:

Go figure. I’m trying to gain a better understanding of the timings, but as of now it seems kind of random. One of the most exceptional things is that VRAM is 2x as fast as normal memory – kinda logical, though, as it’s 8-bit SRAM unlike the other chips (see below). In practice this means that the most timing critical parts should definitely be stored in VRAM, where instruction timings also match the nominal cycles.

System chips

The following chips can be found on the circuit board:

Another important part is the 44.336 MHz xtal (X1) under the modulator. On an NTSC machine the same oscillator is 14.31818, so the timings are generated differently. Tero took some high resolution photos of the guts an put them online. Check out the images here.

Graphics

The 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. Luckily, the timer can be reprogrammed to serve as a VBI. For an 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 or just some bus traffic in the borders. The timing is a bit tricky, but by drawing a suitable pattern and setting the clock according to that it’s possible to create a usable VBI.

This shiny new routine takes a while to calibrate but is about two row exact: vbinew2.s. The calibration might fail under some rare conditions, when other unrelated bus values happen to match the needed colors. Couldn’t break it with 30 consecutive test runs, but I’ve seen it happen. For the sake of completeness, here’s the old coarse and less reliable version that starts quicker: vbi.s.

Another, more robust solution would require a minimal hardware mod involving a piece of wire that connects the VSYNC signal to for example the user interrupt or just some pin of the printer/expansion port. So far I haven’t tried that, as the software method works well enough on a PAL machine at least.

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:

mload:a=usr($1000)

Sound and timers

According to Wikipedia and Old-Computers.com 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):

That’s three sound 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 an 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 (just speculating here that there are probably some unknown pulse counter and edge triggered modes). The higher bits define other important parameters (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.366 MHz, which you divide by the desired divisor and frequency to get the counter value. According to the Service Manual the frequency is 1.34 MHz for an NTSC machine, but as the timings seem to be quite cursory in it anyway, I wouldn’t trust that number much. 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. 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).

It’s still unknown whether the current status of an individual key can be read at all. Probably not, and even if yes, it would be unusably slow with all the interrupts involved. The keyboard matrix and operation are explained in some detail in the Service Manual, pages 52–55.

It turns out that the joystick ports are identical to those of the MSX: there’s +5V and strobe on the same pins. What that could mean is that an MSX mouse could theoretically work on the Pana, depending on the implementation of the MN1544 keyboard reading code. I’m a bit skeptical, though, as the standard joyport functions are so slow, plus they might not let you control the strobe pin correctly.

Expansion bus

The mapping of the expansion port pins can be found on page 62 of the Service Manual. Some random notes:

  1. Signals such as vma, r/w and phi2 are inverted along the way, so they follow a different logic than the CPU
  2. Phi2s is meant for dividing memory access between the CPU and the video controller. If you output at the wrong moment the screen will flicker.
  3. The !kill signal disables the BASIC ROM at $A000..$BFFF
  4. Data pins are buffered through IC3
  5. Pins A19 and B19 are +5V, but don’t seem to be able to supply a lot of current. Better consider an external PSU for your extensions.

The printer port or the CNIO header found near the TV modulator would be other easy options for moving data about, as they are directly connected to parallel ports of the MN1271. See the memory map below. However, they won’t allow for an autobooting ROM, unlike the expansion port.

Memory map

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

pana-mem

Know addresses in more detail:

Still missing quite a lot of relevant stuff and details.

File transfer and creation

I don’t know if the floppy drive was ever sold outside of Japan. “Disk BASIC” is mentioned on the Service Manual, but even so practically nobody owns 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. My tools for dealing with CJR files:

When loading your own programs do something like this on the Pana:

mload:a=usr($1000)

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.

Here’s my LZSS compressor and a 6800 machine language decompressor routine for your enjoyment. Together they constitute PanaZ, a simple exe packer that can be used with your plain binary files before turning them into CJRs. See the zip file for further instructions.

Panana 1.0

As there are no realistic emulators available as of now, it’d be mandatory to easily test own programs on a real machine. Beeping the program in through the cassette port gets you started but, honestly, it’s too slow: it takes around a minute and a half to transfer a binary file of a mere 20 kilobytes. Moreover, you need to type the loading commands all the time. To overcome those irritating limitations, I developed an Arduino-based “coder’s cable” with and autobooting ROM that contains the transfer slave. First, here’s some work-in-progress shots for your enjoyment:

viritys pannaani1 lodju

The circuit board in the middle isn’t the final version, so don’t use it as a reference. With the latest improvements I’ve reached transfer speeds up to 8k/s – a whopping 30x speed increase compared to the cassette port. In other words, you can fill the memory up in four seconds. After some final improvements Panana seems to be stable even with a trashy Chinese Arduino Nano clone. There are still several shortcomings, such as the lack of support for multipart or BASIC CJR files (needed for games), but as those are not needed for software development, I’ve had little interest in implementing them at least as of now. Another detail I’m not awfully happy about is the huge 128k EPROM chip that takes a lot of space and is almost empty. Got them really cheap, you see.

And then the schematics. Note that !reset is only needed with a Leonardo or a Micro, as they don’t reset automatically when receiving serial input. On the other hand, it very much improved reliability with the trashy Chinese Nano clone that I used.

panana-fixed

Download the required software here: panana-1.0.zip. Inside the zip you will encounter:

As you can see, this is no turn-key solution, so you may experience hiccups and, all in all, need to have a positive and proactive attitude to get anywhere with it 🙂 It’d be awesome to turn Panana into a real PCB one day, but let’s see if I ever get that far.

When you boot the JR-200 with the Panana and a USB cable connected, you should see letter P in the top right corner. The file transfer host controls whether the CJR will be started automatically or not. If not, after the transfer the machine will jump automatically to BASIC. Other characters you might see are E for error or a heart denoting a succesfully completed operation.

8k SRAM memory  expansion

Something evident on the memory map is that it should be rather straightforward to extend the memory to 40k through the expansion port. Even 48k could be possible, since you can disable the BASIC ROM through the port. I gave it a go one beautiful Saturday and indeed, it is easy to add that 8k by wiring the address and data lines plus some more from the expansion port to a SRAM chip. Three highest bits of the address need to be decoded, too, which is a good job for a GAL.

panamem panamem

A bit lousy schematic it is, but at least it works. Here’s the function needed for the GAL16V8. Compile to .jed with the usual eqn2jed.

CHIP GALLI 16V8

i0=1 i1=2 i2=3 phi2s=4 rw=5 vma=6 a15=7 a14=8 a13=9 gnd=10
i3=11 we=12 oe=13 o0=14 o1=15 o2=16 o3=17 o4=18 o5=19 vcc=20

EQUATIONS

/we = a15 * !a14 * !a13 * !vma * rw * !phi2s
/oe = a15 * !a14 * !a13 * !vma * !rw * !phi2s

The BASIC doesn’t recognize the extra 8k, but you can mload and run code there without problems. Even a timing critical IRQ handler worked just fine. The prototype could be extended to 16k with an optional BASIC on/off switch, or even to several megabytes by introducing a banking scheme of some sort. As my target is the standard machine, such an extension isn’t a priority.

Reset button

A memory-preserving reset button can be useful for a developer, cracker or a cheating gamer, too. Based on p. 29 of the Service Manual it was easy to make a – hopefully – safe reset button. You could ground the processor /HALT pin directly, but this one is safer, as the signal goes through two inverters and there’s a capacitor to filter the noise caused by lousy buttons (like mine). See here:

resetti

First find the capacitor and diode (D1) at the top right corner of the mobo. Solder a wire to the back leg of the diode, add a button and connect the other leg of the button to the ground. For example the screws holding the mobo in place are grounded, so you can wrap the wire under one of them.

Software

There’s not much to talk about, I’m afraid 🙂 I’ll update this section when I’ve taken a closer look at the games that came with the Virtual Panasonic emulator. Here’s some PAL/200UP stuff by my group Fit:

Run with mload:a=usr($1000). Any contributions would be most welcome; just sample the cassette contents and send the files to me. Those rare Disney games would be an interesting find.

Sources