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.
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.
Yes, I'd be happy if you did so! I tried adding a reply but since I don't yet have a Mastodon account (hopefully soon to be resolved), I resorted to just posting here instead.
Here's the decode script I used to produce the table above:
rom = open('exsb1.dat', 'rb').read()
ptr = 0xf6
for i in range(128, 256):
out = bytearray([rom[ptr] - 0x80])
while rom[ptr+1] < 0x80:
out.append(rom[ptr+1])
ptr += 1
ptr += 1
print(i, hex(i), bytes(out))
The format of the tokens packed into the BASIC ROM is quite simple: the first byte in each token is ORed with 0x80 and the tokens are concatenated without any other separators. Tokens end when the next byte has 0x80 set (indicating the start of the next token).
> 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.
The technique of putting machine code behind a REM was common in the Microbee (another Z80 machine). Often used for sound effects in games as the standard PLAY basic statement only did tones.
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!
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.
> “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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.)"
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.
> 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.
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.
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.
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.
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!
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:
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.Bonus: Here's what all of the tokens >= 0x80 render as, including the corrupt ones:
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.Excellent!! Mind if I add all this into to the post with credit?
Yes, I'd be happy if you did so! I tried adding a reply but since I don't yet have a Mastodon account (hopefully soon to be resolved), I resorted to just posting here instead.
Here's the decode script I used to produce the table above:
The format of the tokens packed into the BASIC ROM is quite simple: the first byte in each token is ORed with 0x80 and the tokens are concatenated without any other separators. Tokens end when the next byte has 0x80 set (indicating the start of the next token).> 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.
The technique of putting machine code behind a REM was common in the Microbee (another Z80 machine). Often used for sound effects in games as the standard PLAY basic statement only did tones.
It is definitely possible on the C64. Here's a video exploring the technique: https://www.youtube.com/watch?v=KX3rVIIaVQk.
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!
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.
Lisp shares with Forth a great feature, you only need to implement a few building blocks in Assembly, and then everything else can be built from them.
Too many get lost in the concept that using something like C is the only way to build languages.
“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.
> “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.
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.
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.
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.
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.
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.
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 ;(
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.
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.
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.
> 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.
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.
I managed to get that easter egg into libvirt - it listens on ports 16509 and 16514 (https://libvirt.org/remote.html).
I noticed that :-)
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.
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 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!