The Japanese character ROM and keyboard come to the PET 2001 emulator.
Another update to the PET 2001 emulator, spefically, a tribute to Japan and its importance to home computing history in general, and its role for Commodore in particular.
A new game for the Commodore PET, also, how to detect keyboards on a Commodore PET.
Rumors that I am might be writing a game (or is it a playable joke?) are not entirey unfounded. Also, another (maybe helpful) note on PET keybords and how to detect them.
As it happens, I recently added a debugger to the PET 2001 emulator, with the expressed purpose of facilitating code reverse engineering. To celebrate this, we’ll risk a glimpse into a peculiar bug — or is it a feature? — of the BASIC flavor found on Commodore’s PET computers. Particularly, it’s about BASIC bailing out into a warm start, whenever an empty string is entered by just pressing RETURN on the INPUT prompt.
A closer inspection of the keyboard(s) of the PET 2001.
Where we investigate the PET keyboard, have a closer look at the keyboard matrix of the various layouts found on the PET 2001 and later PETs, as well, and even have a bit of 6502 fun.
A closer look at the “illegal” opcodes and undocumented instructions of the MOS 6502 MPU.
The instruction table of the MOS 6502 MPU, designed by MOS Technology and introduced in 1975 (the CMOS version, 65C02, was developed by Western Design Center) has some obvious gaps, with just 56 intructions documented in various address modes. This leaves 105 undocumented slots — and the 6502 community has been eager to fill these gaps, ever since.
Still, there’s some mystery left and there are questions unanswered, like, were at least some of them intentional (especially, since some of them are handy for block transfer, something the Z80 has dedicated instructions for) or are they all by accident, how do they behave, and why so? Here, we’ll try to come up with some answers to these questions.
Tales of the early days of the first digital video game.
Sometimes it’s only a short sentence, a few words dropped as an aside, which changes our understanding. A short glimpse, which provides deeper inside and understanding in what is a complex process. As it is here the case regarding how Spacewar!, the first digital video game became this remarkable program that gave birth to an entire industry. As usually, what was intended to be just a brief dump of an idea — at least, this is what a blog post is all about, isn’t it? — became lengthier than expected. Not for the least, as it’s still necessary to establish the subject, even as Spacewar! is rapidly progressing towards its 60th anniversary.
A Software Archeological Approach to the First Video Game.
Over the years, before I started this blog, some rather blog-like formats have accumulated on my website, each dedicated to a certain topic or project. Maybe, as many of us are expected to stay at home on their own, this is also an opportunity to point these series of write-ups out and to include them here as links, over the next few days.
For a beginning, there’s a walk through the code of Spacewar!, which is generally considered the first digital video game. We’ll have a look at every single line of code — no instruction is left behind —, learn about the DEC PDP-1 computer, learn how this game was achieved on this early 1960s machine by some ingenious tricks in software. (There are actually some things to be admired, like early object oriented approaches and a JIT compiler.) We’ll even learn about some of the fundamental intrinsics of digital computing, e.g., how basic operations like multiplications and divisions, or integer square roots were solved on this particular machine. Moreover, we’ll have a look at some of the more arcane versions of the game, including a somewhat first person multiplayer version from 1963. — Already intrigued? Then, have a closer look and follow the link, or, maybe, save it for later…
A closer look at the logic behind Commodore ASCII, AKA “PETSCII”, and the PET 2001.
The flavor of ASCII used by the Commodore 8 bit computers, commonly known as PETSCII, is asking for a bit of an explanation. PETSCII is a peculiar beast, close to ASCII, but not quite, somewhat compatible, but not really, there are duplicate ranges of characters all over the place, and the special characters are lacking any recognizable order… — But look at all these these funny graphics characters!
In order to make sense of this and how the character set is organized, it may be helpful to have a closer look at it with a particular focus on the PET 2001. At least, this is the very machine, this character set originated on and for which it was designed for, with no idea yet that this may become the ancestor of a succesful line of home computers. Here, we may discover logic, in what must remain a puzzling enigma on the more popular and better known machines that followed, like the C64.
Investigations into the memory utilization of Commodore BASIC (PET 2001, VIC-20, C64)
In continuation of our last episode, we return to our investigations into Commodore BASIC memory representations. This time, it’s about variables, arrays, and, especially, strings.
How to thoroughly renumber Commodore BASIC programs (PET 2001, VIC-20, C64)
Renumbering a is popular beginner’s sport for those who dare to venture into the mythical realms of intricacy, which the BASIC interpreter and its storage formats provide. Since it is also a useful utility, there are numerous programs for this, especially it’s a favorite example in the intructory sections of machine language guides. However, as always, there’s an easy way and a thorough one. And we’ll see soon, why this may be.
Investigations into a lesser known bug in Commodore BASIC abbreviations.
There is a well known, special feature of the BASIC implementation of Commodore 8-bit machines, namely abbreviated BASIC commands. While this is probably more a bug than a feature, this bug has a curious bug of its own. Reason enough to start an investigation.
Why are there these abbreviations, how do they work, and, what could possibly go wrong?
Reverse engineering the command and control structure of a Wordpress attack.
Software archeology usually relates to dated programs, like the bit we did on a 1960s graphics demo for the PDP-1. However, the same skill set also applies to reverse engineering more recent bits and bytes. In this case it’s about a Wordpress attack and its command & control structure. Recently, I discovered a new variation of the command & control structure…
Software archeology of an early computer animation (1960s) for the DEC PDP-1
Snowflake (compare the post below) is a small graphics program written for DEC PDP-1 somewhen in the early to mid 1960s. In essence, Snowflake is a kaleidoscopic program, mapping a list of moving points multiple times onto the screen in a starlike manner. It may be the first of these programs, at least, it’s an early specimen of the species.
In order to learn how it does its trick, we engage in a bit of serious software archeology. All the fun is provided: PDP-1 assembler code, intricacies of display instructions, disassemblies, we even provide a little hack of our own to demonstrate the algorithm (which happens to be much like an once original form and isn’t without a beauty of its own). However, strap yourself for a lengthy read…
Recently, I returned my interest to Spacewar!, the first digital video game, particularly to differences between early versions, like Spacewar 2B, and the better known, later versions, like 3.1 and thereafter. One of these differences, particularly of interest here, is in the random number generator, implemented by a macro named "random" (what else?).