I remember reading (probably in some issue of the newsletter of the PET Benelux Exchange (PBE)) about a strange effect during tape loading of a PET program. Back in the day, I tried it and it worked. I do not recall if it occurred with "old ROMs" (*** COMMODORE BASIC ***) or "new ROMs" (### COMMODORE BASIC ###).
The thing was that if you would LOAD a program from tape, and while it was searching for a program header, simultaneously kept the < key down, it would slowly print < characters to the screen if it found "something" on the tape. You could use this to check if you're on an empty part of tape or not, and decide if you needed to fast-forward (or rewind).
I have tried to reproduce the behaviour in VICE (xpet), but as I expected, although the emulation is pretty good, it didn't manage to reproduce this one.
One practical difference in emulation is that to press the < key on an emulator you need to press shift as well. To make the emulation closer to reality, I made a special keymap where I swapped , and < so that I could depress < without shift, but this made no difference.
Sometime, I did have an effect (with the "old ROMs" only): on occasion there seemed to be memory corruption somewhere, soon followed by a crash.
Also, after loading was complete, you would expect a single < to be printed after the READY. prompt (due to pressing a key, once). But fairly reliably there would be two.
The PET's keyboard matrix has the STOP, < and RVS keys all on the same scan row. This fact is used to test, during the periodic screen retrace interrupt, for the STOP and RVS keys, to respectively interrupt a program, or slow down text scrolling. Since < is present on the same row and therefore can be detected in the same way, there is some plausibility that something "strange" happens during these checks.
What caused this effect?
