PET 2001 End-of-May Updates

The PET 2001 online emulator enjoyed some TLC.

Some news on the PET 2001 online emulator:

• Loding hex-dump files
  You may now load a hex-dum (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.

• Fun fact: I managed to recreate a dialog in SVG for use in the help file. :-)

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. —