I think that Atari VCS BASIC was not anywhere near as well known as Star Raiders, which used a single 4x3 keypad and one joystick for control. This was a cut down port of the original Atari 400/800 Star Raiders, but I would guess that far more players played this version than the original.
1 Like
I had access to a time-sharing system - Edinburgh 1978. A TTY 33 with dial-up acoustic modem to the local computing centre (Moray House). I think several schools in Edinburgh had access at the time.
Running BASIC of-course 
-Gordon
I did too, at a state comprehensive in North Staffordshire - I think the head of maths had got a connection to the local university somehow. But it was a matter of an hour or two of access in a term, perhaps, or even in a year, not at all like having access even weekly. I recall some kind of turn-based space combat game, involving grid coordinates and bearings.
Fortunately our school had managed to acquire a couple of PETs and a TRS80 by the time I arrived. They were also very aware of the importance of actual hands-on time so when they got their money to buy a few BBC micros they got the statuatory required single BBC micro and spent the rest on ZX Spectrums to get more actual simultaneous users.
2 Likes
To be fair, this isn’t an issue of the games, it was more the emulator, which just did what was necessary for the standard Commodore keyboard scan routine to work. Meanwhile, I rewrote the entire keyboard routines – and now these games work and shine as they should.
(Hint, if your keyboard lacks a dedicated number pad, you may play these games using the cursor keys and SPACE with the CAPS-LOCK key engaged, which is used as a toggle for this mapping.)
Back to the PET: You can actually poll more than just one key at a time, it’s just that the scan routine doesn’t exactly what you might expect. (It’s not exactly N-key rollover. To play around with this in the emulator, set the keyboard menu to “Games” and click various keys on the graphical keyboard while holding down your physical ALT key to combine multiple key-presses. This also allows you to toggle individual keys on and off by a click.)
On the hardware side of things, the keyboard matrix consists of 10 key rows (0…9), each holding a byte (or 8 signals) as a bit vector for the state of up to 8 keys (active LOW). So there’s a dedicated bit for each of the 73 keys and the matrix can represent any state of the keyboard, including multiple concurrent key-presses. It’s more a question of what amount of code and runtime you invest on the software side to determine the state. Here, the standard, general purpose scan routine targets “good enough” and “minimal time spent”. (The manual is actually a bit proud of the latter.) A game, on the other hand, is concerned with just a handful of key states and may go more into depth by implementing its own, specialized scan routine. (E.g., you can poll and store the state of the 10 rows and then inspect them for the few bits you are actually interested in.)
Regarding, which key wins (with the ROM routine): this is more location based than time based. Roughly speaking, it’s the key furthest down the keyboard and then the one furthest to the right.
In detail, it’s a bit more complicated. To make things a bit more interesting, a logical column runs through two adjacent columns of physical keys with the row property increasing to the right and downwards:
C0 C1
! " # $ … 0 1 0 1
Q W E R … 2 3 2 3
A S D E … => 4 5 4 5
Z X C V … 6 7 6 7
SH RV @ ( … 8 9 8 9
In this special game of Snake a key wins, if its row property is higher than the one of the current winner, and, if there should be a draw, if the column number is higher as well. (And, in case you should be really interested, logical column #5, just left of the number pad, is missing the odd row properties, which is consistent with the spacing in the physical layout.)
So, as the incoming keyboard polls are processed and there is already a key registered with row #7 and column #1, a key must have a row number >= 7 – and, if it is 7, also a column number > 1 – in order to overwrite this.
With respect to the layout already described, when the currently winning key has an odd row property, this is only each second key to the right on the same physical row. On the other hand, if the current winning key has an even row property, the key immediately to the left of it also wins, as does any of the keys to the right of it in the same physical row. Any key further down the physical layout has a higher row number and wins per se.
(Mind that the keyboard matrix is read per row as bit-vectors of columns. So the procedure is simply: if the value is greater or equal than the one we have already, register this as the column and also register the number of the row we’re currently processing.)
2 Likes
Well, I did a blog post going more into the details of what was mentioned before on the PET’s keyboard and keyboard scanning (including a bit of 6502 fun with the scan routine, where we find an actual bug):
2 Likes