Hmm, based on the (handwritten!) notes on Table F-2 in http://bitsavers.informatik.uni-stuttgart.de/pdf/exidy/DP500..., it looks like pressing Graphic+key would allow you to enter BASIC tokens from 0x80 to 0xBF, while pressing Graphic+Shift+key would allow you to access 0xC0 to 0xC6. By inference, it seems like Graphic+Shift+key should allow access to the entire 0xC0 to 0xFF space, but most of those keys are undocumented.

Based on this, I wonder if it's worth trying the following:

    10 REM [Graphic+Shift+=] [_] [(] [Graphic+Shift+NumpadPlus] [2] [Graphic+Shift+NumpadEquals] [Graphic+Shift+Numpad6] [Graphic+Shift+0]

Note that you'll probably need an emulator with accurate keyboard emulation - or a real device - in order to type these in. However, with the emulator from http://www.liaquay.co.uk/sorcerer, I was able to confirm that Graphic+Shift+0 produced 201 (rendered as F4), and Graphic+Shift+= produced 255 (rendered as S), so I think this approach will work.

> Would this work on other platforms, I wonder? Or would they just freak out? Someone else can give it a try on the Commodore 64 or something.

I don't remember seeing this on Commodore 64 too much. Most type-in hybrid BASIC-machine language programs would have numerous DATA statements with opcodes and a loop to READ and POKE them (typically in the tape buffer area somewhere in the fist 2K of RAM or in the 4K area at 49152/$C000).

Commodore 64 BASIC's LOAD"WHATEVER",8 command would load a file of any size in the BASIC text area without validation or checking it for any type of format. So much commercial C64 software often had a one line "10 SYS2063" (or similar) stub that would simply jump into the actual code which was tacked on to that BASIC stub. But the LIST command wouldn't display anything after the stub - I guess the "next line" bytes were set to $0000 to indicate end of program.

That's why some computer mags started introducing tools to type in programs without ambiguities.

Here's a recent example I made: an Amstrad CPC program that's both valid BASIC and machine code at the same time, and running it both ways (RUN or CALL &170 -- loading address of the BASIC program) produce the same output: https://github.com/ssg/yello

See this is why I never understood LISP people proudly proclaiming that “code is data and data is code”… we were doing this in BASIC for decades already!

This makes me sad about the history that has been forgotten. I never used a Sorcerer but I knew what the code was for at a glance.

It always feels a bit like lost magic. But at the same time, it's also something that was only enabled by the very high determinism of these old home systems. The design relies on having fixed RAM locations, no multiprocessing, etc.

Incredible to find out that typing the paper program would not have worked, though. And in such a disappointing way no less.

I remember that my ZX Spectrum 48k came with a big orange book of BASIC programs to type in.

One of which was some sort of mystical “reflect on the runes” program that printed ancient symbols to contemplate. It had a written comment in the docs that it would self destruct after three attempts “to guard against frivolous use”. And, sure enough, if you typed it in without understanding it - there was the BASIC command that soft reset your computer on the third iteration! I can’t remember that command now - RANDOMIZE USR 0 perhaps? Happy days.

The Oric Atmos won the 10-line BASIC Programming Competition in 2022 with a 1000-room dungeon crawler named "SNAKE TEMPLE":

https://bunsen.itch.io/the-snake-temple-by-rax

IN 10 LINES OF BASIC!!

I thought it was cute that it used the RND() function to seed things necessary to generate each room .. so I used that technique in my own Oric game, which generates a large blob of graphics data using the RND() seed, meaning I don't have to ship that data in the program itself. I find the pseudo-ness of the RNG infinitely resourceful in that regard ..

Another cute trick on the Oric Atmos is to seed the 14 registers of its synth chip with ROM data .. meaning the Oric Atmos has literally THOUSANDS of onboard sound presets to choose from - once you find them, of course. So I wrote a program to find the most interesting ones and have been accruing a list of "synth presets" that come onboard with the Oric, for use in my game.

Its quite rewarding to go back to these machines and use such techniques to generate nearly-infinite levels/sounds/etc.

back when the Apple II / Applesoft BASIC twitter bot was a thing similar techniques were the best way to inject assembly language into a BASIC program, though we quickly learned there were more compact ways than REM to get a line ignored.

Some examples here, as sadly the apple2twitter bot shut down and deleted their account a while ago.

http://deater.net/weave/vmwprod/appleiibot/part7.html

This is exactly how we used to do machine code on the Sinclair ZX81, too, where there was no way to declare a block of memory as "off limits" to BASIC, and no DATA statements like in the later (and much bigger) ZX Spectrum BASIC.

Then you'd do "RANDOMISE USR 16514" to start it. Actually USR was interesting because it would pass back the contents of BC when your machine code routine returned to BASIC.

This was fascinating and a most enjoyable read - thank you for writing it all down!

Those were the times when programming a computer was an adventure in and of itself, bastardizing BASIC with assembler. Doubtlessly the first Make Your Own Adventure setting!

That was a wild ride!