On Tue, Jun 06, 2017 at 08:32:14PM -0700, Michael Hunter via cctalk wrote: [....] > Anyway, the .bas file is not plaintext, but I can see strings in it. Here > are the first few bytes:
That text looks like length-prefixed records: 00000000: f900 00000002: 1b00 3aaf e84f 6e65 2046 7275 636b ....:..One Fruck 00000010: 6564 2075 7020 7069 616e 6f00 00 ed up piano.. 0000001D: 0c 0061 ..a 00000020: 3af8 823a 20f8 8300 00 :..: .... 00000029: 1e 009a 2022 5374 ... "St Whether it's an 8 bit prefix with a spurious NUL byte or 16 bit little-endian, I couldn't say without seeing a longer example. The first line is probably a REM statement, but I'd expect a single-byte token for it and see the two-byte sequence AF E8. There's a spurious colon before it, but that's just the BASIC statement separator and perhaps ": REM" was a popular idiom in that dialect. Maybe AF is REM and the first word in your comment happened to also be a BASIC keyword and was also (accidentally?) tokenised. > I remember watching a documentary saying that source code used to be encoded > / compressed. They are usually *tokenised*, in which BASIC keywords are replaced by a single (typically high-bit-set) character. This both reduces the memory requirements and makes the interpreter faster. Your "fun" job is to figure out which characters map to which tokens. Or just Google it, probably. [...] > begin 644 piano.bas Bizarrely, I don't seem to have a uudecoder installed. I haven't seen a uuencoded file in years. So my comments above are based on your short hexdump.
