Live data from Hacker News

Code Golfing in Commodore BASIC

imrannazar.com

21–30 of 42 posts

Re: Code Golfing in Commodore BASIC

#21
post #15
post #12

Back in the 80s when type-in program magazines were common, in France we had the wonderful "Hebdogiciel" with a perpetually running BASIC programming contest called "deulignes" -- which means "twolines". "Deulignes" programs could target any platform, but must only take 2 lines of BASIC (most implementations allow only a limited line length, often 255 characters). Some programs were really impressive; I remember one…

In a roundabout way BASIC on those machines is like modern high-level languages. Slow and inefficient for sure, but most of the magic is happening directly at the hardware level (sprites, memory-mapped IO, etc.), so there's a surprisingly large amount of stuff you can do with very acceptable performance.

That's actually really insightful somehow.

Re: Code Golfing in Commodore BASIC

#22
post #17
post #11

Earlier quoted context omitted.

Are they stored as 16 bit words before or after parsing the BASIC code?

The BASIC code is only in it's full textual form on screen. The moment you press return on it, it's tokenized, and it's stored tokenized both in memory and when saved. Unlike modern systems, the full textual representation of the code is never stored anywhere.

It's an accident of history this didn't continue. So many code style wars could have been avoided over the eons.

Re: Code Golfing in Commodore BASIC

#23
post #17

Earlier quoted context omitted.

The BASIC code is only in it's full textual form on screen. The moment you press return on it, it's tokenized, and it's stored tokenized both in memory and when saved. Unlike modern systems, the full textual representation of the code is never stored anywhere.

It's an accident of history this didn't continue. So many code style wars could have been avoided over the eons.

It wasn't that it didn't continue, but that this was unique to a branch of languages that largely were sidelined.

And the tokenization didn't prevent you from style differences anyway - as the article points out it e.g. keeps spaces etc. It only tokenized a few things, like keywords and line numbers.

(EDIT: in the late 90's I worked on a project written in Word BASIC.... It was also tokenized and that was used as an opportunity to translate the keywords in the localised versions of Word. But someone had managed to write a bunch of code in the Danish version and somehow exported it as text and imported it into the Norwegian version - the languages are similar enough that it was really hard to tell (no syntax highlighting, and they'd edited a bunch before realising and I had the fun job of untangling it... Yay...)

Re: Code Golfing in Commodore BASIC

#25
post #19
post #12

Back in the 80s when type-in program magazines were common, in France we had the wonderful "Hebdogiciel" with a perpetually running BASIC programming contest called "deulignes" -- which means "twolines". "Deulignes" programs could target any platform, but must only take 2 lines of BASIC (most implementations allow only a limited line length, often 255 characters). Some programs were really impressive; I remember one…

Do you think you'd be able to find that 2 line breakout? I'm currently doing a breakout implementation on my Commodore 64. In assembly though, so definitely more than two lines ;-) Nevertheless, a two line breakout in Basic would probably give lots of pointers on how to make things more compact.

Well I don't remember in which issue it was, but the whole collection is here:

https://archive.org/details/hebdogiciel-french

I'm pretty sure it's really difficult to convert MSX-BASIC to 6502 assembly though... But there are lots and lots of great C64 deulignes too :)

Re: Code Golfing in Commodore BASIC

#26
post #20

I don't know anything about C64 or C64 BASIC, but would it be possible to intentionally write a shorter binary which will break the interpreter and do what we want instead? For example jump directly to a middle of the kernel ROM routine (akin to ROP in the modern days), or use a bad address in the "next line" offset etc.

In Commodore BASIC there's already SYS, which lets you jump to an arbitrary address anywhere in the 64k address space, including ROM. You can even include raw bytes in a BASIC program and have the CPU execute them as machine code.

however encoding such program in BASIC would take much more amount of commands/bytes than writing it in BASIC itself. You would need DATA statement and POKE FOR LOOP... In case of such a small scenario BASIC wins

Re: Code Golfing in Commodore BASIC

#27
post #12

Back in the 80s when type-in program magazines were common, in France we had the wonderful "Hebdogiciel" with a perpetually running BASIC programming contest called "deulignes" -- which means "twolines". "Deulignes" programs could target any platform, but must only take 2 lines of BASIC (most implementations allow only a limited line length, often 255 characters). Some programs were really impressive; I remember one…

that's a nice amount of code there.

Re: Code Golfing in Commodore BASIC

#30
post #23

Earlier quoted context omitted.

It's an accident of history this didn't continue. So many code style wars could have been avoided over the eons.

It wasn't that it didn't continue, but that this was unique to a branch of languages that largely were sidelined. And the tokenization didn't prevent you from style differences anyway - as the article points out it e.g. keeps spaces etc. It only tokenized a few things, like keywords and line numbers. (EDIT: in the late 90's I worked on a project written in Word BASIC.... It was also tokenized and that was used as an…

I think I read about a tool for the Acorn BBC micros which you could apply to your program to remove unnecessary spaces etc. in the tokenised form and shave off a few bytes.

This had the side-effect that you could still display and (presumably with a bit more mental effort, read) the program listing fine, but re-entering a line as shown in that listing would fail because the computer depended on the spaces to do the parsing, even if they were redundant after the tokenisation happened.

Post reply on HN