10 REM"_(C2SLFF4

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.

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

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.

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!

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!!

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

> I find the pseudo-ness of the RNG infinitely resourceful in that regard

I can't remember how the ORIC BASIC does it but a cool property of LFSRs as PRNGs is that if you pick the right taps and length they must cycle through every possible number from 1 to (2^length)-1 exactly once, excluding zero. That's how the Wolfenstein "Fizzle Fade" effect worked - set up an LFSR long enough that every possible pixel can be visited once, with a few left over, and then throw away any that don't fit.

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!

> I find the pseudo-ness of the RNG infinitely resourceful in that regard

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.

I managed to get that easter egg into libvirt - it listens on ports 16509 and 16514 (https://libvirt.org/remote.html).

Sorry, I’m lost after looking at that page. Can you explain your comment?

Libvirt listens on ports 16509 and 16514 out of the box, in reference to ZX81 BASIC where the program starts at (address) 16509 and the first byte in a REM statement (commonly used to store machine code) is 16514.

That was a wild ride!

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 was fascinating and a most enjoyable read - thank you for writing it all down!

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

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

On an Apple ][, you couldn’t necessarily assume your BASIC code was going to start from the same location, thanks to the LOMEM command. I remember one of the things I wrote back in the day was a relocatable Assembly loader that would allow a bit of assembly code to be loaded to an arbitrary address in available memory and all the internal addresses (for, e.g., JSR or JMP or even some LD* commands, as I recall) would be rewritten to the correct location. I don’t really want to go back to writing code for 8-bit computers, but the challenges were certainly fun.

It always feels a bit like lost magic.

I sometimes wonder if there is still a lot of that magic in the tech world, but were so used to having everything abstracted away from us in multiple layers that we've lost the ability to look for it.

I think about the TLA hackers who do seemingly impossible things. Surely they must operate on this level.

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!

And in assembler and machine code before that!

I'm persuaded that just about every language is "homoiconic" and that _bicameral syntax_ is the actually-interesting thing about Lisps : https://parentheticallyspeaking.org/articles/bicameral-not-h...

BASIC is older than most people realize, but it's still half a decade younger than Lisp.

Lisp predates BASIC. And ITS too.

The thing is in Lisp, data with a nice structure that you can easily work with is evaluatable as code; and all the code that runs has a nice structure and is easy to work with! You cannot easily manipulate and transform BASIC programs from within BASIC, and you cannot easily do anything in machine code.

But maybe this is part of what Gerald Sussman was talking about when he called Lisp a "low level language": like machine code, Lisp has the nice property that its default data representation is used for building directly executable programs.

“code is data and data is code” is a fact of computing. What LISP does is to make it an official feature of the language and provide nice abstraction for it. A lot of languages want you to use some cumbersome reflection library, a dangerous eval function, or a crippled macro mechanism. With LISP, you just use the language mechanism in order to write code that process code.

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]

Bonus: Here's what all of the tokens >= 0x80 render as, including the corrupt ones:

  128 0x80 b'END'
  129 0x81 b'FOR'
  130 0x82 b'NEXT'
  131 0x83 b'DATA'
  132 0x84 b'BYE'
  133 0x85 b'INPUT'
  134 0x86 b'DIM'
  135 0x87 b'READ'
  136 0x88 b'LET'
  137 0x89 b'GOTO'
  138 0x8a b'RUN'
  139 0x8b b'IF'
  140 0x8c b'RESTORE'
  141 0x8d b'GOSUB'
  142 0x8e b'RETURN'
  143 0x8f b'REM'
  144 0x90 b'STOP'
  145 0x91 b'OUT'
  146 0x92 b'ON'
  147 0x93 b'NULL'
  148 0x94 b'WAIT'
  149 0x95 b'DEF'
  150 0x96 b'POKE'
  151 0x97 b'PRINT'
  152 0x98 b'CONT'
  153 0x99 b'LIST'
  154 0x9a b'CLEAR'
  155 0x9b b'CLOAD'
  156 0x9c b'CSAVE'
  157 0x9d b'NEW'
  158 0x9e b'TAB('
  159 0x9f b'TO'
  160 0xa0 b'FN'
  161 0xa1 b'SPC('
  162 0xa2 b'THEN'
  163 0xa3 b'NOT'
  164 0xa4 b'STEP'
  165 0xa5 b'+'
  166 0xa6 b'-'
  167 0xa7 b'*'
  168 0xa8 b'/'
  169 0xa9 b'^'
  170 0xaa b'AND'
  171 0xab b'OR'
  172 0xac b'>'
  173 0xad b'='
  174 0xae b'<'
  175 0xaf b'SGN'
  176 0xb0 b'INT'
  177 0xb1 b'ABS'
  178 0xb2 b'USR'
  179 0xb3 b'FRE'
  180 0xb4 b'INP'
  181 0xb5 b'POS'
  182 0xb6 b'SQR'
  183 0xb7 b'RND'
  184 0xb8 b'LOG'
  185 0xb9 b'EXP'
  186 0xba b'COS'
  187 0xbb b'SIN'
  188 0xbc b'TAN'
  189 0xbd b'ATN'
  190 0xbe b'PEEK'
  191 0xbf b'LEN'
  192 0xc0 b'STR$'
  193 0xc1 b'VAL'
  194 0xc2 b'ASC'
  195 0xc3 b'CHR$'
  196 0xc4 b'LEFT$'
  197 0xc5 b'RIGHT$'
  198 0xc6 b'MID$'
  199 0xc7 b'\x00\t'
  200 0xc8 b'G.'
  201 0xc9 b'F4'
  202 0xca b'K'
  203 0xcb b'5'
  204 0xcc b'H\x03'
  205 0xcd b'`C'
  206 0xce b'JO'
  207 0xcf b'Mr'
  208 0xd0 b'J'
  209 0xd1 b'L'
  210 0xd2 b'Hr'
  211 0xd3 b'HU'
  212 0xd4 b'HD'
  213 0xd5 b'I'
  214 0xd6 b']'
  215 0xd7 b'Fa'
  216 0xd8 b'H'
  217 0xd9 b'\x10'
  218 0xda b'H'
  219 0xdb b'7'
  220 0xdc b'H\x07'
  221 0xdd b'GV'
  222 0xde b'R&'
  223 0xdf b'IH'
  224 0xe0 b'G\\'
  225 0xe1 b'R\x1f'
  226 0xe2 b'O\x05'
  227 0xe3 b'Wh'
  228 0xe4 b'I5'
  229 0xe5 b'G'
  230 0xe6 b'F'
  231 0xe7 b'E\x0f'
  232 0xe8 b'HA'
  233 0xe9 b'S'
  234 0xea b'I'
  235 0xeb b'R\x1a'
  236 0xec b'Dy'
  237 0xed b'"'
  238 0xee b'Wy'
  239 0xef b'*'
  240 0xf0 b'S|'
  241 0xf1 b'j'
  242 0xf2 b'T|K'
  243 0xf3 b'U\x7f'
  244 0xf4 b'C'
  245 0xf5 b'XP'
  246 0xf6 b'('
  247 0xf7 b'LF'
  248 0xf8 b"'"
  249 0xf9 b'LNFSNRGODFCOVOMULBSDD/0IDTMOSLSSTCNUFMO'
  250 0xfa b'Ck'
  251 0xfb b'@'
  252 0xfc b'C'
  253 0xfd b'e'
  254 0xfe b'G'
  255 0xff b'S\x00'

This is based on a simple decoding of the token table starting at 0xf6 in the BASIC ROM; it matches the observed output for 201, 247, 252, and 255 so I expect that it is generally correct. Indeed, with `10 REMX; POKE 474, 249; LIST` in the emulator, I get `10 REMLNFSNRGODFCOVOMULBSDD/0IDTMOSLSSTCNUFMO` printed out, which further confirms this decoding.

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.

Indeed, even though I’ve never done this, when I saw a REM statement at the head of the file with random characters in it, I immediately assumed it was a bit of in-line assembly.

My technophile uncle gave me one in the late 80s when he upgraded, even came with a monster of a daisy wheel printer. Can't remember what the WP was, but I remember being amused with V1.0 Microsoft Basic which came on a cartridge.

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

It is definitely possible on the C64. Here's a video exploring the technique: https://www.youtube.com/watch?v=KX3rVIIaVQk.

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

IIRC it was something like "hexagrams" which printed the I Ching hexagrams[0]

[0] https://www.iching-online.com/hexagrams/

Lisp predates BASIC. And ITS too.

Indeed, even though I’ve never done this, when I saw a REM statement at the head of the file with random characters in it, I immediately assumed it was a bit of in-line assembly.

And in assembler and machine code before that!

BASIC is older than most people realize, but it's still half a decade younger than Lisp.

It always feels a bit like lost magic.

I think about the TLA hackers who do seemingly impossible things. Surely they must operate on this level.

I work in "lowest level" kernel development, and we're certainly operating at that layer. As for those kind of hacky solutions, we do try to avoid them, because they are, well, hacky, and therefore often hard to understand, easy to break, etc... but it does happen. Especially in prototyping, were usually anything goes to make something work initially.

Because I started in that era, I sometimes think that’s why I was motivated to learn synthetic programming for the HP 41, write the first disassembler for the HP 48SX’s ROM, why I wrote jailbreak software on the iPhone before the App Store existed. Tiny limited environments most resemble where I first coded.

It certainly tarnishes the shine to have a per-OS-version table of offsets to patch ;(

> “code is data and data is code” is a fact of computing

The general purpose computers we have today all follow that principal, yes. However it's not a fundamental fact of computing. Turing machines, cellular automata provide other paradigms. And if those aren't practical enough for you, ASIC programming is Turing complete but cannot access its code as data.

It is definitely possible on the C64. Here's a video exploring the technique: https://www.youtube.com/watch?v=KX3rVIIaVQk.

Bonus: Here's what all of the tokens >= 0x80 render as, including the corrupt ones:

  128 0x80 b'END'
  129 0x81 b'FOR'
  130 0x82 b'NEXT'
  131 0x83 b'DATA'
  132 0x84 b'BYE'
  133 0x85 b'INPUT'
  134 0x86 b'DIM'
  135 0x87 b'READ'
  136 0x88 b'LET'
  137 0x89 b'GOTO'
  138 0x8a b'RUN'
  139 0x8b b'IF'
  140 0x8c b'RESTORE'
  141 0x8d b'GOSUB'
  142 0x8e b'RETURN'
  143 0x8f b'REM'
  144 0x90 b'STOP'
  145 0x91 b'OUT'
  146 0x92 b'ON'
  147 0x93 b'NULL'
  148 0x94 b'WAIT'
  149 0x95 b'DEF'
  150 0x96 b'POKE'
  151 0x97 b'PRINT'
  152 0x98 b'CONT'
  153 0x99 b'LIST'
  154 0x9a b'CLEAR'
  155 0x9b b'CLOAD'
  156 0x9c b'CSAVE'
  157 0x9d b'NEW'
  158 0x9e b'TAB('
  159 0x9f b'TO'
  160 0xa0 b'FN'
  161 0xa1 b'SPC('
  162 0xa2 b'THEN'
  163 0xa3 b'NOT'
  164 0xa4 b'STEP'
  165 0xa5 b'+'
  166 0xa6 b'-'
  167 0xa7 b'*'
  168 0xa8 b'/'
  169 0xa9 b'^'
  170 0xaa b'AND'
  171 0xab b'OR'
  172 0xac b'>'
  173 0xad b'='
  174 0xae b'<'
  175 0xaf b'SGN'
  176 0xb0 b'INT'
  177 0xb1 b'ABS'
  178 0xb2 b'USR'
  179 0xb3 b'FRE'
  180 0xb4 b'INP'
  181 0xb5 b'POS'
  182 0xb6 b'SQR'
  183 0xb7 b'RND'
  184 0xb8 b'LOG'
  185 0xb9 b'EXP'
  186 0xba b'COS'
  187 0xbb b'SIN'
  188 0xbc b'TAN'
  189 0xbd b'ATN'
  190 0xbe b'PEEK'
  191 0xbf b'LEN'
  192 0xc0 b'STR$'
  193 0xc1 b'VAL'
  194 0xc2 b'ASC'
  195 0xc3 b'CHR$'
  196 0xc4 b'LEFT$'
  197 0xc5 b'RIGHT$'
  198 0xc6 b'MID$'
  199 0xc7 b'\x00\t'
  200 0xc8 b'G.'
  201 0xc9 b'F4'
  202 0xca b'K'
  203 0xcb b'5'
  204 0xcc b'H\x03'
  205 0xcd b'`C'
  206 0xce b'JO'
  207 0xcf b'Mr'
  208 0xd0 b'J'
  209 0xd1 b'L'
  210 0xd2 b'Hr'
  211 0xd3 b'HU'
  212 0xd4 b'HD'
  213 0xd5 b'I'
  214 0xd6 b']'
  215 0xd7 b'Fa'
  216 0xd8 b'H'
  217 0xd9 b'\x10'
  218 0xda b'H'
  219 0xdb b'7'
  220 0xdc b'H\x07'
  221 0xdd b'GV'
  222 0xde b'R&'
  223 0xdf b'IH'
  224 0xe0 b'G\\'
  225 0xe1 b'R\x1f'
  226 0xe2 b'O\x05'
  227 0xe3 b'Wh'
  228 0xe4 b'I5'
  229 0xe5 b'G'
  230 0xe6 b'F'
  231 0xe7 b'E\x0f'
  232 0xe8 b'HA'
  233 0xe9 b'S'
  234 0xea b'I'
  235 0xeb b'R\x1a'
  236 0xec b'Dy'
  237 0xed b'"'
  238 0xee b'Wy'
  239 0xef b'*'
  240 0xf0 b'S|'
  241 0xf1 b'j'
  242 0xf2 b'T|K'
  243 0xf3 b'U\x7f'
  244 0xf4 b'C'
  245 0xf5 b'XP'
  246 0xf6 b'('
  247 0xf7 b'LF'
  248 0xf8 b"'"
  249 0xf9 b'LNFSNRGODFCOVOMULBSDD/0IDTMOSLSSTCNUFMO'
  250 0xfa b'Ck'
  251 0xfb b'@'
  252 0xfc b'C'
  253 0xfd b'e'
  254 0xfe b'G'
  255 0xff b'S\x00'

IIRC it was something like "hexagrams" which printed the I Ching hexagrams[0]

[0] https://www.iching-online.com/hexagrams/

And from a recent Show HN: I Ching simulator with accurate Yarrow Stalk probabilities

https://news.ycombinator.com/item?id=46261942

Looks like.

https://zx.tr/basinc/help/topics/manual_appd.html, scroll down. "Here is a program to throw coins for the I Ching. (Unfortunately it produces the patterns upside down. but you might not worry about this.)"

Last statement: NEW.

Excellent!! Mind if I add all this into to the post with credit?

It certainly tarnishes the shine to have a per-OS-version table of offsets to patch ;(

> “code is data and data is code” is a fact of computing

State transition in the turing machine are not modifiable, but one of the core advantages of the TM is that it's powerful enough to emulate state transition. So you can model the states of the new machine as data, add the transition mechanism as code, feed those to the TM and you have a new machine that can interpret input that was unrecognizable by the previous one. That's how programming languages works.

So yes, you can't modify the actual embodiment of the state transition if it does not offer you the capability to do so. But as long as it interprets data in a TM manner (input and output are colocated and the alphabet is the same), you can write code that will interpret data as code and manipulate code as data. Not by modifying the base substrate, but by adding a virtualization layer on top.

2026-07-21

Let's dive into The Wizard's Castle (source code)!

10 REM"_(C2SLFF4

That is the first line of the 80s microcomputer BASIC game The Wizard's Castle initially written for the Exidy Sorcerer platform.

It's a REMark statement, a comment in that particular language. 10 is the line number, if you're unfamiliar with languages that had such things.

But the interesting part was this "_(C2SLFF4 mess. A typo or garbage? No. It appears verbatim in the source code as originally published in the July, 1980 issue of Recreational Computing.

What the heck is it?

Note: I'm going to jump back and forth between decimal (which is BASIC-friendly) and hex (which is programmer-friendly). Hex will be prefixed with 0x, suffixed with h, or will obviously have digits A-F in it.

Note: Thanks to Josh and Chris, my hacking buddies, for doing tons of the emulator and research work on this. It took hours, but they were good hours. It would have taken me 10x as long without their help.

Suspicions

Here's more of the source in context, but with irrelevant pieces removed and some spaces added:

10 REM"_(C2SLFF4
40 POKE 260,218: POKE 261,1: T = USR(0): T = PEEK(-2049)
80 Q = RND(-(2*T+1))

In BASIC, a : is a command separator. POKE writes a byte value to the specified memory location. PEEK reads from one. Sorcerer BASIC used signed 16-bit numbers, apparently, so address -2049 is 65536-2049 or 0xF7FF in hex. We'll revisit that address later.

Calling the pseudo-random number generator (PRNG) RND() with a negative number seeds it. Old PRNGs liked to be seeded with odd numbers, thus the 2*T+1 expression forcing it odd.

And the USR() function calls a machine code routine.

And line 80 is the first use of T after it is initialized from the PEEK().

The proximity of these things makes it seem like they're all related to seeding the PRNG. Sorcerer BASIC didn't have a RANDOMIZE command, so the only options of the day were:

Ask the user to enter a random seed.
Run an increment loop until the user hits a key (or some user-driven thing like that) and use that for the seed.
Get the seed for some kind of randomish-thing from the existing software and/or hardware.

Wizard's Castle didn't do the first two. So it must be the last one.

Could it be that the REM statement has machine code that happens to encode to ASCII text? The Sorcerer did use ASCII encoding.

But it seems nuts that you could get useful Z80 machine code just from ASCII characters. Right?

Nevertheless, this seemed like a reasonable-enough crazy assumption to run with and see what we could find.

The `USR()` Function

The USR() call is interesting—this calls a machine code function, but the details are system-dependent. But luckily the Internet has tons of technical manuals in various places and we were able to figure it out.

Address 259 has a JP instruction (unconditional jump) to a 16-bit little-endian absolute address.

And the POKEs were for addresses 260 and 261. This was the trampoline for the USR() function. You POKE the address of the start of your machine code into addresses 260 and 261, and then run USR() to call it.

40 POKE 260,218: POKE 261,1: T = USR(0): T = PEEK(-2049)

Reversing them for little-endian, this means we're looking at address (1 << 8) | 218 which is 474. When we run USR(0), it jumps to the machine code at address 474 that should end in a RET instruction.

The argument for USR() (the 0) is stored as a 4-byte float elsewhere in RAM so the machine code can look at it if it needs to. It turns out not to be relevant for this use case. Also we're assigning the return value from USR() into T, but it's unclear to me what this return value is. However, it is irrelevant as we immediately overwrite T with the next assignment.

So... What's at address 474?

BASIC RAM

When you enter a line of Sorcerer BASIC, the interpreter tokenizes it and replaces commands like PRINT with single byte values:

PRINT is tokenized to 0x97
REM is tokenized to 0xC3
etc.

And then it is stored like a linked list in memory where each row is a "node".

The node format is:

2 bytes of "next" pointer
2 bytes for the line number
Bytes representing the tokenized line of code
1 byte of null terminator (a 0x00 byte)

And the start of this linked list in RAM is at address 469 on the Sorcerer.

Let's see the mystery line again:

10 REM"_(C2SLFF4

That means the node for that line consists of the following addresses and bytes:

469  Low byte of the next pointer
470  High byte of the next pointer
471  Low byte of the line number
472  High byte of the line number
473  `REM` token (0xc3)
474  First byte of REM text, the `"` character!!

and 474 is where the USR() function gets us! It is literally calling the text of the REM statement as Z80 machine code!

Disassembly, Attempt One

Could it be true? Let's try it out!

Here are the hex values for the ASCII characters:

There's the 0x00 terminator at the end, but that's just a NOP in Z80, so we'll ignore it.

Disassembling, we get:

22 5F 28   LD   (285Fh),HL  ; " _ (
43         LD   B,E         ; C  
32 53 4C   LD   (4C53h),A   ; 2 S L
46         LD   B,(HL)      ; F
46         LD   B,(HL)      ; F
34         INC  (HL)        ; 4

Now, I don't want to get into the details of Z80 assembly here, but take my word for it that this code makes no sense. The addresses don't seem to point to anything in particular, who knows what HL has in it at the beginning, B is never read, the duplicated LD B is pointless, and there's no RET to get us back to BASIC.

It's garbage. And running it in an emulator results in Weird Things happening (like soft resets), as expected.

This was a dead-end for the time being. We speculated that maybe it was a printing error, that the printer didn't have the glyphs for the actual bytes, so it substituted other ones. But that wasn't super-satisfying.

The `PEEK(-2049)`

Let's switch gears, then, and continue on to the PEEK:

40 POKE 260,218: POKE 261,1: T = USR(0): T = PEEK(-2049)

What's at address -2049? Unsigning this makes it equivalent to 0xF7FF. According to the docs, this is the last byte of memory-mapped screen text, representing the current character in the lower right of the screen.

We then immediately use this value to seed the PRNG:

40 [ ... ] T = PEEK(-2049)
80 Q = RND(-(2*T+1))

I'm going to use my magical powers now to look at one of your open terminal windows and read the character in the lower right of the screen. It's fuzzy, but if I concentrate... it's... yes, it's a space character, isn't it!

Am I right? That'll be $200.

Now, the space is 32, so seeding the PRNG with -(2*32+1) every game would make for bad replayability in this randomly-generated dungeon, so the USR() function must have something to do with it. Like it puts something on the screen at address 0xF7FF and then the PEEK() reads it. The screen is cleared not-long thereafter, so the player might not notice the blip of a character temporarily placed in the lower right.

RTFM

Wizard's Castle source code The source code in its original dot-matrix glory

So we had strong suspicions that all this was part of the PRNG seed process. If only there were some way to prove it!

It was at this point that Josh noticed this line in the magazine where the program was published: "The first remark is a machine language routine to simulate the RANDOM function."

Sheesh. That'll teach me not to read things.

In BASIC, RND(), not RANDOM, is the random function, used with a negative argument to seed the PRNG, and a positive argument to get the next random number, which was historically a random floating point result between 0 and 1.

So what the author probably meant was RANDOMIZE which was popular in Microsoft BASIC for setting the random number seed to a specific value or prompting the user to enter one.

In short, it was supposed to be doing what we thought, but the machine code didn't seem to be doing that at all.

A Breakthrough

Josh and I had been running Sorcerer emulators in MAME (thanks to Josh for sharing the ROMs with me to get going) and Chris had another Java-based one that he'd gotten working.

In MAME, we'd entered the REM statement and looked in memory, and it had the nonsensical bytes and machine code as disassembled, above. And it didn't run properly.

But Chris found a tape image of the game and loaded that up in his emulator. And the first two lines of source looked like this:

10 REM"_(C2SLFF4F4F4 
15 REM ED 5F 28 FC 32 FF F7 C9 (in O1DA)

WOW! Another(?) author has annotated the source with the hex of the machine code! Not only does it end in 0xC9 which is Z80 RET, but it has that lower-right screen corner address 0xF7FF right there!

How on Earth does the REM text map to that? Things like 0xED are clearly non-ASCII. But wait, some of the characters are, and their positions match what we see in the REM!

   "
5F _
28 (
   C
32 2
   S
   L
   F

What actual values are there? Chris loaded the program and looked:

FOR I=474 TO 489: PRINT PEEK(I): NEXT I
 237
 95
 40
 252
 50
 255
 247
 201
 70
 52
 70
 52
 32
 0
 18
 2
READY

You can see the 0x00 null terminator down there. And a hidden space at the end of the line. And 237 is 0xED, and 95 is 0x5F... it matches the line 15 comment!

Let's get ready to disassembbbllllllllllleeee! I'll convert the numbers to hex and go for it.

ed 5f     LD A,R         " _
28 fc     JR Z,-4        ( C
32 ff f7  LD (F7FF),A    2 S L
c9        RET            F
46        LD B,(HL)      F
34        INC (HL)       4
46        LD B,(HL)      F
34        INC (HL)       4
20 00     JR NZ,0        space null

Later, I'll find out that the part after the RET is disassembled incorrectly and that my annotation of which REM characters mapped to which hex values was wrong, but who cares for now! Everything is over at the RET anyway.

And the code is exactly what we were looking for! Let's look at the first assembly instructions:

LD A,R       ; copy R register to accumulator
JR Z,-4      ; if result is 0, jump back to previous instruction
LD (F7FF),A  ; copy accumulator into address F7FFh
RET          ; return

What's it do? The R register is interesting on the Z80 in that it is incremented every instruction fetch. Maybe? Depends on which resource you ask. In any case, it is incremented very, very frequently relative to human timescales. And the Sorcerer busy-waits for input, so when you finally run the game, it effectively has a random-ish value in it.

But seeding many lesser PRNGs with 0 is a bad idea (they tend to just produce 0 after that), so the code retries if it happens to get a 0 in R. But if it is non-zero, it stores that value in address 0xF7FF, the lower right corner of the screen! And then the PEEK() picks it up and uses it to seed the PRNG!

The R register only increments the low 7 bits, though, meaning it can only be 128 different values. And we discard 0, so really this means on the Sorcerer, there were only 127 different randomly-generated dungeons that you could play. Bummer!

So the glyphs we see simply aren't ASCII. Our first disassembly was doomed to fail because the REM violates the assumption that all listing text was ASCII.

For verification, I made a new program that was just a REM followed by a bunch of spaces (to give me room to work before the null terminator). Then I POKEd in the right values and got a listing.

10 REM               
POKE 474,237
READY
POKE 475,95
READY
POKE 476,40
READY
LIST

10 REM"_(
READY

It worked! Those values gave me the "_( glyphs that were in the original source listing!

Could You Type It In?

The whole idea in the 80s with magazines like this was that you'd get it in the mail or from the newsstand and you'd painstakingly spend hours typing them in and getting them right.

It wasn't easy. Here's another excerpt from The Wizard's Castle:

1070 IFFL=0THENPRINT:PRINT"** HEY BRIGHT ONE, YOU'RE OUT OF FLARES":GOTO620
1080 PRINT:PRINT:FL=FL-1:A=X:B=Y:FORQ1=A-1TOA+1:X=FNB(Q1):FORQ2=B-1TOB+1:Y=FNB(Q2)
1090 Q=FNE(PEEK(FND(Z))):POKEFND(Z),Q:PRINTI$(Q);"  ";:NEXTQ2:PRINT:PRINT:NEXTQ1:X=A:Y=B
1100 GOSUB 3400:GOTO620
1110 IFLF=0THENPRINT:PRINT"** YOU DON'T HAVE A LAMP, ";R$(RC):GOTO620
1120 PRINT:PRINT"WHERE DO YOU SHINE THE LAMP (N,S,E, OR W) ";:GOSUB3290
1130 A=X:B=Y:X=FNB(X+(O$="N")-(O$="S")):Y=FNB(Y+(O$="W")-(O$="E"))
1140 IFA-X+B-Y=0THENPRINT:PRINT"** TURKEY! THAT'S NOT A DIRECTION":GOTO620

Just pure codevomit. But those of us who typed this stuff in were pretty practiced at getting it right. So when we saw something like this:

10 REM"_(C2SLFF4

you can bet we typed it in exactly.

But now we know this wouldn't have worked if you assumed those were ASCII-encoded glyphs.

Perhaps there was some lore well-known to Sorcerer programmers where they knew the magic incantations to make it go.

Or maybe he just wrote this to get some space to work:

10 REMF4F4F4F4F4

And then manually POKEd the machine code in like I did, above, to get this:

10 REM"_(C2SLFF4

And then never mentioned how to do it, forgot about it in the excitement of getting it published, and out the door it went.

But what is the deal with that F4 thing? It's really bugging me.

The `F4`s

An F-4 Phantom. It's an aviation/programming pun. I hereby indemnify myself against lawsuits.

In my version, we had:

10 REM"_(C2SLFF4

Chris's version had some extra F4s:

10 REM"_(C2SLFF4F4F4

And we did a memory dump of Chris's version and got the following:

Notice anything weird? About the F4s? I didn't either. There are three of them in the REM, but only two of them in the memory dump (the 70,52 pairs)!

And that's not all—where's the L? Something's wrong. Earlier, I'd tried a sanity check by POKEing in the first three characters by hand, but let's try the others.

I'm going to recreate the entire machine code here and see what pops up.

10 REMXXXXXXXXXXXXXX
20 FOR I=474 TO 481: READ X: POKE I,X: NEXT I
30 DATA 237, 95, 40, 252, 50, 255, 247, 201

Then I run that, and list it. I get:

10 REM"_(C2SLFF4XXXXXX
20 FOR I=474 TO 481: READ X: POKE I,X: NEXT I
30 DATA 237, 95, 40, 252, 50, 255, 247, 201

Wait! My Xs shifted right by two characters! What's up with that? You can't just insert characters like that. It's like there are two extra characters in the output. I poked eight values, but there are 10 characters printed before the Xs!

Let's dump RAM and see what's there. I'm going to annotate the output, but—spoilers—my annotation is wrong:

237    "
95     _
40     (
252    C
50     2
255    S
247    L
201    F
88     X ← No additional Fs or 4s!
88     X
88     X
88     X

No Fs or 4s. It goes directly from my last 201 (in the DATA) straight to a bunch of Xs (the 88s). So why do I see them in the listing?

Let's get specific. I'm going to manually plug in the 255, the 247, and the 201 in the REM and see what we get out of it.

10 REMX
POKE 474,255
LIST

10 REMS

Okay, it's the S, as expected.

POKE 474,247
LIST

10 REMLF

Whoa—what? LF? Two characters? And suspiciously like "linefeed", but who knows. But that matches the REM!

POKE 474,201
LIST

10 REMF4

And there's the F4. So the last two bytes are being printed as LFF4. That's where the extra two characters are coming from in the output.

So fixing my memory dump annotation, it would look like this:

And now that's matching what we're seeing in the listing:

10 REM"_(C2SLFF4XXXXXX

But that's not all. The bytes with values 128 and just over actually map to BASIC keywords! Check this out:

POKE 474,137
LIST

10 REMGOTO

When BASIC is printing its lines, we speculate that if the high bit is set, it looks up the symbol name and prints that instead. The weird symbol names we get up higher (random-seeming) might be (again, we speculate) mapping into garbage past the end of that table.

But wait just a second. In Chris's memory dump, there were bona fide ASCII Fs and 4s in there

237   "
95    _
40    (
252   C
50    2
255   S
247   LF
201   F4  ← RET
70    F   ← what's all this, then?
52    4
70    F
52    4
32
0
18
2

Why were they added when they have no effect on the machine code? I think we'll just have to let that one go as being lost to the mists of time. Or maybe you can try gazing into an orb until you find the answer. Just don't overdo it.

Wrap Up

The only point of all this, since I basically knew up front it was seeding the PRNG, was to feed hacker curiosity. What a luxury!

What did we learn?

You can cram machine code into a REM statement on the Exidy Sorcerer, but don't expect a sensible print-out.
The code when typed in from the magazine probably didn't work.
The author likely POKEd the machine code in directly, or perhaps the Sorcerer had some kind of graphics shift key that would let those characters be typed.
We now know, with more certainty than was ever required, the answer to that age old question, "What the frick is that comment doing at the beginning of The Wizard's Castle?"

How much money did we make?

$zero!

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.

If you want to know more about The Wizard's Castle and even play this bit of history, I have a collection of documents and information on GitHub.

Comments

View Comments Reply

Looks like.

Last statement: NEW.

And from a recent Show HN: I Ching simulator with accurate Yarrow Stalk probabilities

https://news.ycombinator.com/item?id=46261942

Excellent!! Mind if I add all this into to the post with credit?

That's less "code is data is a fact of computing" and more "if you ignore the part of code that's not data then all code is data".

At the base of it, the TM is an abstraction built with sets and relations. Just like most computers are merely signals flowing around a circuit that get generated from other physical phenomena and will be transformed to other physical phenomenas. You can't hack around physical laws, or ignore the axiomatical rules in mathematics. The code that is not data are those things.

Everything else is data.

You are redefining both the term "code" and the term "data" in ways that I don't think most people would agree with - and more importantly, in ways that make it impossible to talk about von Neumann architecture.

Because code and data as well as the von Neumann architecture are derived things, not fundamental stuff. The Turing Machine and Lambda Calculus are pure invention thats are logically sound. Almost everything else is downstream of that.

By the time you get to programming language like C and LISP, and software like vim or firefox, everything is abstracted away and the only limits are self-imposed (or imposed by others that have done the work). They are not laws of nature.

So yes there’s a definition of code and data. But for the Turing machine, there’s only the tape and its content.

The pure logical concept of a Turing machine is a tuple of states, symbols and a transition function. These all very much do exist, and they're very much not written on the tape. So no, there isn't "only the tape and its content".

I do not agree data is a derived term in computation theory. Code, maybe I can be convinced. But absolutely not data.

Hacker Times

Hacker Times

10 REM"_(C2SLFF4

Discussion

Discussion

Suspicions

The `USR()` Function

BASIC RAM

Disassembly, Attempt One

The `PEEK(-2049)`

RTFM

A Breakthrough

Could You Type It In?

The `F4`s

Wrap Up

Comments

Hacker Times

Hacker Times

10 REM"_(C2SLFF4

Discussion

Discussion

Suspicions

The USR() Function

BASIC RAM

Disassembly, Attempt One

The PEEK(-2049)

RTFM

A Breakthrough

Could You Type It In?

The F4s

Wrap Up

Comments

The `USR()` Function

The `PEEK(-2049)`

The `F4`s