Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

10 REM"_(C2SLFF4

beej.us

Post reply on HN
Print view View original

31–40 of 52 posts

Re: 10 REM"_(C2SLFF4

#31

Post by beej71 »

nneonneo wrote: post #17
nneonneo wrote: post #16

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 undocum…

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' 1…

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

Re: 10 REM"_(C2SLFF4

#32

Post by mrspuratic »

NetMageSCW wrote: post #14

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.

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.

Re: 10 REM"_(C2SLFF4

#33

Post by skydhash »

Xirdus wrote: post #30
skydhash wrote: post #28

Earlier quoted context omitted.

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, yo…

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.

Re: 10 REM"_(C2SLFF4

#34

Post by Xirdus »

skydhash wrote: post #33
Xirdus wrote: post #30

Earlier quoted context omitted.

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.

Re: 10 REM"_(C2SLFF4

#35

Post by sedatk »

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

Re: 10 REM"_(C2SLFF4

#36

Post by RiverCrochet »

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

Re: 10 REM"_(C2SLFF4

#37

Post by dhosek »

NetMageSCW wrote: post #14

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.

Re: 10 REM"_(C2SLFF4

#38

Post by dhosek »

summa_tech wrote: post #6

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.

Re: 10 REM"_(C2SLFF4

#39

Post by buildsjets »

zimpenfish wrote: post #27
urbandw311er wrote: post #24

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…

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

Re: 10 REM"_(C2SLFF4

#40

Post by ataylor284_ »

RiverCrochet wrote: post #36

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

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