Funny Games on a PET 2001N (or B)

A curious case of jumper settings for PETs with the dynamic system board.

Recently, I stumbled over a rather arcane detail, regarding the chip select and jumper settings on Commodore PETs with the dynamic system board. This board is found in earlier PETs (before there was the “universal board”) featuring dynamic video RAM and made its debut with the PET 2001N in 1979 (and the related “B” for “Business” model, featuring the first appearance of the business keyboard.)

These machines (as well as later PETs) were quite configurable — and, if you would know just Commodore’s VIC-20 or C64, in a rather suprising extent. In a nutshell, these jumpers allow you to configure the amount and type of RAM and ROM, they allow to emulate the hardware of older models on the newer ones (but you can’t emulate a 40-column machine on a 80-column one), there’s even a setting for shifting addressing to the higher regions of RAM only, for test purposes. You can read all about this in a document by Commodore, “The Dynamic PET”. However, there are two jumpers, which aren’t described or even mentioned at all in any of the Commodore documentation, namely jumpers ”R” and ”S”. Which are also, what this blog post is about.

It’s an archived answer by William M. Levak to a question on the ROM select logic of the PET 2001, found at zimmers.net, which brought me on the track.

In case you wouldn’t know, the memory layout of the PET 2001 is clear and simple: the first 32K are RAM (to be populated upwards), at $8000–$9FFF are 4K of video RAM (actually 1K mirrored 4 times), and above this are 28K of ROM. (Beginning with the PET 2001N, there are actual ROM sockets for all of the possible ROM.) And, right in the middle of this ROM space, at $E800–$EFFF, sits the I/O section (populated by 2 PIAs 6520 and a VIA 6522), interrupting this continous address space.

 +----------------+
 |                | $0000-$00FF  zero-page (system)
 |                | $0100-$01FF  processor stack
 |                | $0200-$03FF  various system RAM
 +----------------+
 |                | $0400
 |                |
 |                |
 |                |
 |                |
 |                |
 |                |              user RAM area
 |                |
 |                |
 |                |
 |                |
 |                | $7FFF
 +----------------+
 |                | $8000        4K video RAM
 |                | $8FFF        (1K mirrored 4×)
 +----------------+
 |                | $9000
 |                |              ROM (unused, option ROMs)
 |                | $AFFF
 +----------------+
 |                | $B000
 |                |
 |                |              ROM (BASIC 4.0)
 |                |
 |                | $DFFF
 +----------------+
 |                | $E000-$E7FF  ROM (editor)
 +----------------+
 |                | $E800-$EFFF  I/O
 +----------------+
 |                | $F000        ROM (Kernal)
 |                | $FFFF        ($FFFA-$FFFF: system vectors)
 +----------------+

This placement of the I/O section is a flagrant violation of fundamental symmetry (especially since the original PET 2001 had the address range from $9000 to $BFFF entirel unpopulated), suitable to send Hercule Poirot onto the very top of the next tree available. (Well, there are the system vectors at the very top at the address space, so you must have ROM there, but, why not have the I/O section at, say, the lower boundary of the ROM space?) Moreover, at that time, ROM chips had become 4K ones, with one of them sitting at $E000–$EFFF, with just the lower 2K actually used. (This is where the editor lives.) This seems rather wasteful, especially, since this ROM slot features a full complement of address lines, including the upper 2K occupied by the I/O section.

This is also where the anonymous inquiry chimes in: why even bother with address line 17 and the related decoding logic for this particular ROM chip? And the answer given by W. M. Levak is rather surprising: because, he tells us, by setting jumper “R” we can relocate the I/O section to the upper half of the 4K address range where the video RAM lives, at $8800. And, if we do so, we can actually address and use the upper 2K of the ROM slot at $E000. This, however, is an undocumented feature and there is no known use case.

This shows a rather unexpected flexibility of the architecture, and a continous ROM space of 28K should be more than interesting to anyone who wants to roll their own OS on a PET! Especially, since this comes at the quite negligible price of losing the upper 2 of the total 4 mirror images of the video RAM.

Let’s investigate…

Looking up the schematics, there they are, in plain sight, two jumpers “R” and “S”, right in the section describing the address decoding and chip select logic:

And, as suggested by its name, the I/O select signal is routed to the CS2 pins of the PIAs and the VIA, selecting these chips:

Thus, depending on the — mutually exclusive! — setting of these jumpers, the I/O select signal is tied either to $E8xx or to $88xx:

• Jumper R set:  I/O at $88xx
• Jumper S set:  I/O at $E8xx (normal)

With jumper “R” set (and “S” unset) our memory map looks now like this:

 +----------------+
 |                | $0000-$00FF  zero-page
 |                | $0100-$01FF  processor stack
 |                |
 |                |
 |                |
 |                |
 |                |
 |                |              RAM
 |                |
 |                |
 |                |
 |                |
 |                |
 |                | $7FFF
 +----------------+
 |                | $8000-$87FF  2K video RAM (1K mirrored 2×)
 +----------------+
 |                | $8800-$8FFF  I/O
 +----------------+
 |                | $9000
 |                |
 |                |
 |                |
 |                |
 |                |              ROM
 |                |
 |                |
 |                |
 |                |
 |                |
 |                | $FFFF        ($FFFA-$FFFF: system vectors)
 +----------------+

So, where do we find these mysterious jumpers “R” and “S” on the board? Right beside the expansion bus:

The system board layout by Commodore tells us that this is “DIP Shunt SH2”, and that it’s the two jumpers at the very right/far edge. (There’s also a smaller jumper block “DIP Shunt SH1”, jumpers A–F, seen here just at the left edge of the detail crop.)

However, before you start fiddling with the jumpers of your venerable PET, we need some system software to support I/O at $8800. Otherwise, any attempts will remain futile. What we’re going to do, is futile, as well, since there is no reasonable advantage in this, but it is good enough to put the concept to a test. For this, I modified the ROM set for BASIC 4 for the relocated I/O section. I/O addresses are found in the Kernal ($F000–$FFFF), the editor ($E000–$E7FF) and the BASIC 4 ROM at $D000–$DFFF. (Hence, the ROMs at $B000 and $C000 may remain unchanged.)

To do this, I took the ROMs, I’m already using in the PET 2001 emulator (these are for the 60Hz, 40 columns, non-CRTC variant) and dropped them in the virtual 6502 disassembler (output setting “assembler code”), copied the result into a text editor and substituted any I/O addresses by a simple

s/\$E(8[0-9A-F]{2})/\$8$1/g

Then, the resulting text files where re-assembled, using the congruent virtual 6502 assembler, and exported as binaries.

The tricky part here is to align the disassembly, so that any address words actually do show up as words. Meaning, we have to exclude any data sections. In case you want to play along at home, here’s the symbol table used for this:

;basic 4 data sections
.data $b000, $b321
.data $bcf6, $bd18
.data $beA0, $bea4
.data $bf41, $bf8b
.data $c2d9, $c2dc
.data $caf2, $cb1f
.data $cee9, $cf77
.data $d0c7, $d107
.data $d156, $d183
.data $d221, $d228
.data $d2fe, $d32b
.data $d35c, $d398
.data $d381, $d385
.data $d44b, $d471
.data $d544, $d578
.data $d838, $d872
.data $dea4, $dfff
.data $e1e1, $e201
.data $e6d1, $efff
.data $f000, $f0d1
.data $f7ac, $f7ae
.data $fd5d, $ff92
.data $ffed, $ffff

So, we’re nearly good to go. I‘m still lacking a crucial component, namely, a real PET. The next best thing is an emulator, which I have, so I extended this to support relocatable I/O.
(At the moment, this is achieved by a hard-coded config variable and there are no user facing controls for this. But, as there is also no software to support this, besides our own little experiment…)

And, lo and behold, it actually works:

No errors and the keyboard works! Let’s try switching the character set, which is achieved on the PET by POKE-ing to the VIA (with relocated I/O to 34892 or $884C):

And here is the I/O section in the debugger, showing up at $88xx:

So, yes, this seems to work!

However, it must be said, we haven’t achieved much. We just substituted a somewhat motivated gap in our ROM range by a plain hole. To be true, these are funny games, indeed, and not much more — until someone comes up with some impressive piece of software utilizing this.

Here are the resulting ROM images, both for the graphics keyboard and the business keyboard. Mind that this is for PETs with 60Hz, 40 columns no-CRTC video only!. ROMs are identified by their Commodore product code. (For any other hardware, you’d have to replicate the steps described above for an editor ROM image suitable for your machine, as in the particular combination of video hardware and keybaord type.)

• Download: PET2001N-ROM4-io8080.zip (32K)

Disclaimer: as-is, now warranty or liability of any kind, no claims of fitness made, use at your own risk, these are also not original ROMs by Commodore Business Machines, nor were these ROMs authorized by Commodore Business Machines. (See the included “ReadMe.txt” for details.)

Update
And here are actual memory maps (1 bit = 1 pixel, I/O marked in red, bright red pixels are actual I/O chips):

1) BASIC 4.0 with 32K of RAM in standard configuration with I/O at $E800:

2) And here with I/O relocated to $8800:

The editor ROM at $E000 was extended to a full 4K by filling it with $AA (compare the repeating pattern).
The ROM area for option ROMs at $9000-$AFFF is still unpopulated (not connected).

And that’s it, for today.

Norbert Landsteiner,
Vienna, 2024-03-26