“Now Go Bang!” is named after a source comment in Spacewar!, the first digital video game.
It marks the very instance, when a spaceship which has been dragged into the gravitational star starts to explode. What follows, is impressionist pixel-dust floating along the ship’s former trajectory in a sparkling bloom of phosphor activation.
RSS feed: Subscribe.
Posts so far: 100, view as comprehensive list.
If you like what I’m doing, you can buy me a coffee: Buy me a coffee
For all those cases, we haven’t covered yet.
There are several ways to bring your key presses to the PET 2001 emulator, and, let’s face it, neither is perfect for all occasions. So, there’s another one, “Games: Remapped”, featuring user-definable key mappings, especially for use with games. And it wasn’t as easy as first thought…
A curious Easter egg found in the mass:werk vaults.
Last Sunday, something quite astonishing happened at the mass:werk office: I found a tiny app, named “img2atascii”, or more verbosely, “Image to ATASCII Parser”, on my server, dating from 2020. What makes this a curious case, or in any way remarkable, or a find, at all, is that I have no recollection of doing it, while it was, no question about it, indeed written by me. It’s a tiny app that accepts images of Atari 8-bit screens and parses the input to ATASCII codes in hex. I still don’t know what the context may have been, or what purpose this may/should have served. While I do find them fascinating, I can’t even claim to know my way around the Atari 8-bits that came after the VCS. Maybe this was answering some kind of request?
This is even more remarkable, even vexing, since I’ve usually a rather good memory. (At least, I do claim so.) But there’s no broader context, no project, nothing this would link to or which may provide some meaning to this that might transcend the rather restricted scope. — So, what a surprise and what an Easter egg, right on my own server!
Since you have to celebrate Easter, when it finds you (disclaimer: mind that there were times, you may have been sentenced to death for doing so, celebrating Easter on the wrong day, also a time tested way of not paying any wages to the crew after a circumnavigation), I made this a somewhat more useful app: it still does “screen OCR” for Atari 8-bit screenshots, but it now matches glyphs much more robustly and scans and converts any images to ATASCII codes.
In order to appropriately welcome this to the family of assorted little apps, there’s also a link on the “Lounge” page, where all those more or less useful programs live.
Try it here:
A quite literal look into a curious duplication.
Continuing on a theme form a previous post, we risk a closer look into two cartridges of the same game, running both on the C64.
The PET 2001 online emulator enjoyed some TLC.
Some news on the PET 2001 online emulator:
Loading hex-dump files
You may now load a hex-dump (a text-file with extension ".hex", ".hd", ".hdp" or ".dump") in place of any binary files (in prg-format). As these files require a start address, this is either extracted from the first address label (if your hex-dump has this) or the first two bytes are used for this (low-byte, high-byte). Whatever comes first takes precedence. Otherwise any address labels, comments or annotations (e.g., blocks of ASCII/PETSCII representations) are ignored.
Valid hex-dumps are at a minumum space- or comma-separated lists of groups of hexadecimal numbers representing byte-values, and at a maximum most of the usual hex-dump formats.
E.g., the short BASIC program “10 PRINT"HELLO"” (at start address $401) may be represented as
0401: 0E 04 0A 00 99 22 48 ....."H 0408: 45 4C 4C 4F 22 00 00 00 ELLO"...
or as (mind the start address $0401 in the first two bytes)
01 04 0E 04 0A 00 99 22 48 45 4C 4C 4F 22 00 00 00
Notably, this includes the format of the hex-dumps exported by the emulator itself.
Improved for local ".SAV" or ".LOCAL"
There are moments, when you want to save a file locally from a program, e.g., for a user save state or some other file generated by your program, in order to load them later again. This is what local files are for. Files with file extensions ".sav", ".s" or ".local" are exported to the users local downloads folder. If you attempt to load a file with such a file extension, the emulator automatically issues a prompt dialog to let the user select a file to load. (This works both in BASIC and using the Kernal routines directly in a machine language program. Use device 8, the usual floppy-drive, for load and save.)
Since LOAD and SAVE work with binary files in prg-format and the user may actually pick any file, regardless of the name, you may use hex-dumps here as well.
As an important feature of this is, these local files are also loaded to a temporary mount-point, meaning, the main mount-point containing the original program or media image will remain undisturbed.
Mind that there are less checks implied with this loading method than usually. In the end, we have to supply some file to the emulated machine, otherwise it will be stuck. Because of this, if the user closes the dialog without having selected anything, and there are no other options left (like re-using a previously mounted local file), the emulator will generate an empty BASIC file (start address $0401 and a payload of two zero-bytes. Moreover, there’s an unobstrusive flag set at the very top of the video RAM for developers to check the state. (Consult the help file for details.)
This all enjoyes now better (and hopefully more robust) integration, with the additional support of ".local" files.
Update (2026-06-02)
The debugger has now a new breakpoint type for tracking read/write access in a given range.
(Ranges/brackets may now consist of a single address, as well, just leave the “To” address field empty or set it to the same value.)
This may sound like a minor feature (we just divert the access to the address space to a proxy function while using the debugger, easy), but actually required major rewrites, regarding how things are instantiated and interconnect. (JS and when exactly the properties of the ‘this’ object become externally available, you know…) Phew!
— And that’s about it. —
Maybe, if the bubble doesn’t burst, can we have a new round of RLHF training for basic phrasing every year or so?
/s
The sad story of an adorable little program and its looming demise.
Lately, we’ve seen a number of disturbing variants of the famous “10 PRINT” program for Commodore BASIC (and, with a slight modification, for any machine running BASIC). These are all about “speed”, i.e. runtime performance, but, as we’re going to argue, they are all missing the point. Even worse, they are apt to ruin it. Entirely.
A deep dive into the font of the “Dead Test” diagnostic cartridge of the C64, including an Easter egg, a look into the implementation, and, finally, some Commodore 8-bit character ROMs for download.
We’re back with some classic Commodore 8-bit content, but this time, it’s about the C64 and some of its diagnostic cartridges. But do not despair, there are also downloads, not just for the C64, but also for the VIC-20 and the PET/CBM.
A little tool to test and explore the keyboard matrix of any Commodore PET.
Complementing the previous post on PETs and their keyboard layouts, there’s now a program for visual exploration.
