PET 2001 Emulator — V. 1.0
Proudly announcing version 1.0 of the PET 2001 online emulator.
Recently, I’ve been posting on Commodore BASIC and more specifically about the PET 2001 quite a bit. While not the sole reason, this was partly because I was adding a few features to the PET 2001 online emulator behind the scenes. I even endeavored into a major reorganization of some of the source code in order to facilitate this and future work. And, last but not least, there’s now even a suitable help file / documentation. — Reason enough to promote the emulator from its previous beta state to version 1.0!
(Pre)History
The core emulation was written by © Thomas Skibo in 2014 — all credit for this goes to him. Tom had previously implemented a PET 2001 in FPGA and (as it appears from traces in the scource code) in C, as well, so the emulation is robust and building on these experiences. Great!
It took a while, until I stumbled upon this, and somehwat fell in love it. I never had a chance to play around with a real PET 2001, but have been always somewhat partial to this machine. What a chance to finally play with it! First, I added a bit of enhanced keyboard support to facilitate this and — since I care about such things — a less digital appearance for the emulated screen.
One of the reasons, I loved this, was that modern devices, like an iPad, don’t even come with a calculator. So, why not do it in style, on an emulated PET 2001, which also provides an easy scripting environment, still sufficiently capable of tackling smaller problems? So convinient touch support became also important. If you find the controls between the emulated screen and the virtual keyboard a bit cramped, this is why, so that it fits on an iPad screen.
About this time, in 2017, I put my version online (with kind permission by Tom Skibo). But still this was more of a beginning of a journey, as more things followed in order to provide one or the other convenience.
Certainly, we want to get things out of the emulator. Especially any results. Maybe a screenshot? What about the displayed screen text for copy and paste? Also, let’s have convenient upload by drag & drop. At that time, I did a game in assembler, so I added an option to export the video RAM as a hex-dump, to be used directly in the assembler code.
As everyone who has ever used 8-bit computers knows, sketching up things was fun and also an important part of the game. Especially, since this was the only way to do it, either on paper or directly on the screen. However, once we’re happy with what we’ve done, how could we actually use it? How could we bring it onto the screen again to add or to change a few bits? What, if we could generate a BASIC program that would reproduce the contents of the screen? By this, we could import it and edit it again, maybe even re-edit the BASIC code. — Think Photoshop in BASIC.
Editing the source code conviniently in a text editor may also be nice. And, of course, directly importing BASIC source code from a text file. This involved investigating, what BASIC and the Kernal did, disassembling the ROM and re-implementing it in JavaScript. While we’re at it, we may impelement a facility to freely position the cursor by clicking/tapping onto the screen. (Which, of course, requires investigations into how the operating system implements and moves the cursor.) And, since inspecting memory content and disassembly is a requirement for these kind of things, why not add those tools to the emulator as well?
While all these enhancements for productivity are fine and nice to have, an emulator is about exploring vintage programs. Let’s add a program library with a few examples and means to load them directly into the emulator by a simple link. With support for both binary PRG files and BASIC source text in place, we still lack means to access disk and tape archives, without having to resort to external resources to extract individual PRG files. So support was added for D64 floppy disk archives, T64 tape archives, and, since some PET programs are found in this format, for P00 files, as well. And, for those archives, we certainly need a file browser…
Further, as we’re configuring and loading by URLs already, why not add support for loading arbitrary BASIC source code from URL-data? By then, the various enhancements and glue logic had grown quite a bit. And while those bits grew, the respective source code became kind of ugly. (All the import and export functions were contained nicely in a library of their own, but the glue logic, which binds this to the interface… better not to speak of what is not meant to be spoken of.)
Towards Version 1.0
So — and this is probably, which makes this revision 1.0 worthy, — all the glue logic was organized into a single, compact module/object. No more membra disiecta in the global name space. Moreover, all stuff relating to UI-things and how they are named, are now maintained in a central place. (So, what may have become a bit wet before, became finally DRY.) For which, there is now even a conclusive naming scheme, both in JS and in the HTML/CSS parts. Even some of Tom Skibo’s original things were moved a bit, especially so that we may now start from a configuration object, where we may adjust settings before we actually start the virtual machines. (Prior to this, we had to reset/restart the machine, first, in order to apply some of the more crucial setup values, like the ROM version or the amount of RAM.) Providing that I wasn’t moving too fast and haven’t broken too many things, operations should be now more smooth.
On the more functional, user-facing side, there have been also some features added in the last few days. E.g., there’s now a utility to change the character set (this requires POKEs to hardware adddresses on the PET 2001, which the emulator can now do for you, as well) and there’s even a brand new context menu for the virtual screen, from where you may call this along with some other screen related options.
Another new feature is PETSCII escape markup for BASIC sources. You may use this everywhere, where the emulator handles source text, like in text files or data-URLs, and the emulator provides options to use them (or the more portable CHR$()
sequences, which we had previously) everywhere, where it exports BASIC text. Escapes are expressions in curly braces, either embracing a decimal or hexadecimal number, or a label, like “{147}
”, “{$93}
” or “{CLEAR}
”. Labels and hexadecimal numbers are case insensitive and any white space and punctuations are ignored. I implemented almost every label, I have ever seen in a listing, maybe even more than that, so anything you are used to, should work out of the box.
Namley these are (white space and punctuations ignored, case insensitive):
HOME
HOM
HM
CRSR HOME
CHOME
CH
CLEAR
CLEAR SCREEN
CLEAR SCR
CLS
CS
CLEAR HOME
CLRHM
CLRH
CLR
CLH
SC
DOWN
CRSR DOWN
CRSR DWN
DWN
DN
CD
UP
CRSR UP
CU
RVS ON
RVS
RV ON
RON
RVS OFF
RV OFF
ROFF
ROF
INSERT
INST
INS
PI
SPACE
SPC
SP
BLANK
BL
The emulator uses the first label in each of the lists, wherever exporting source text with an option set to use labeled escapes. Pi (π) and SPACE
are escaped, as these are considered printable characters. Where there are no labels, like for PETSCII graphics characters, numeric escapes in a chosen format will be used. This will provide listings like this:
10 REM TOTALLY INADEQUATELY EMOJI INFESTED SAMPLE PROGRAM 20 PRINT "{CLEAR}{RVS ON}H{RVS OFF}ELLO {RVS ON}W{RVS OFF}ORLD! {211}{211}{211}"
Run it here from a data URL.
Moreover, there’s now a utility to renumber BASIC text in memory to further enhance productivity. This utility not only renumbers lines, it also fixes jump targets in statements like THEN
, GOTO
, GOSUB
, ON … GOTO
, and ON … GOSUB
.
Minor things were also fixed and/or improved, like keyboard support for → and ↑, which where previously available by the TAB key and modifiers only, or RVS ON and RVS OFF, which should be mapped to whatever “®” is on your keyboard, with a bit of luck it’s ALT/Option + R….
And, since all these nice features are not of much use, if nobody knows about them, there’s now a suitable (inline) help. You may even link to it already opened as a dialog, like in www.masswerk.at/pet/?help or www.masswerk.at/pet/?help=FileFormats to specify a particular topic.
There are probably still some typos in this, if you spot one, drop me a line.
BTW, you may now use both hashes/fragments and query-strings to link and/or bookmark any configurations and/or settings. This way, you should also be able to link a program in a data-URL without leaking any data. (Well, this was available for data-URLs already, but now all other parameters are supported as well. Moreover, any linked program is now displayed in the document title and there’s also a mechanism to add such links to the browser history, when loading programs from the program library from inside the emulator. A hard reset (SHIFT + Reset Button) to default configurations will also create a new history item.
What’s Next?
By now, we have productivity covered quite fairly. Maybe an assembler would be nice, so that we could load assembler code directly on drag & drop. Maybe integrated with the disassembler an an interactive monitor (instead of the static hex-dump). BTW, did you know that the PET 2001 has a built-in monitor that you can call by “SYS 1024
”?
Actually, calling any address, where there is a binary zero (the 6502 instruction BRK
), since the monitor is what the interrupt vector points to.)
Also, the various dialogs which have accumulated over the years may profit from a unified design.
Most of the other things nice to have require modifications of the emulation core itself. Let’s see… This is what I can think of at the moment:
- Integrated 6502 assembler.
- Sound support.
- Loading files from mounted images or prompt for a file in order to support multi-part programs or programs that require data files, like some text adventures.
- Maybe support for ROM 4.0 (which is available for the PET 2001N)
Sound mabe be interesting, in particular. While the PET 2001 hasn’t any sound generator or sound output of its own, there was a well known hack to get some sound out of the user port, which is also supported by a number of games. However, this would be also the most complicated task on the list, since it requires not only the emulation of the respective bits of hardware, but also the transformation of the state of counters over time into wav-file buffers or other means of playing back wave forms. (Native emulators, like VICE, use ready-made libraries for this, but we would have to hook this up to the Web Audio API, which is another kind of beast.)
Again, let’s see. And in the meantime…
— That’s all, folks! —
Norbert Landsteiner,
Vienna, 2020-03-17