Breden’s BASIC is a piece of software I started writing for the Commodore 64 in September 1983 and finished in March 1984 (software + 160 page user guide). The software is written entirely in 6502 assembly language, and extends the existing built-in BASIC interpreter and adds 135+ extra commands related to graphics, sound, programming enhancements etc. I will document the writing of this software in more detail at some later date in other posts. But for now, here is at least something to start with.
Unfortunately I threw away the enormous heap of paper I did all my “working out” on 🙁 However, I still remember quite a lot about it and I don’t think I will have too much trouble recounting some aspects.
When the Commodore 64 computer first appeared on the market (1982?) I took delight in reading the hardware specifications… dedicated graphics processor, dedicated sound processor, special memory controller allowing a full 64K of RAM to be accessible (this was 1982!). What shocked me though, was looking at the BASIC keyword set that was provided in the standard BASIC interpreter — it was exactly the same keyword set as provided for the Commodore PET and Commodore VIC 20 (VC 20 if you lived in Germany ;-)) I asked myself how one could use the new advanced graphics and sound features available in the hardware.
When I looked at sample programs available in the Commodore 64 Programmer’s Reference Guide — I was completely horrified to see heavy use of the POKE keyword — i.e. the book was advocating that you write directly to the hardware registers of these custom chips in order to control their behaviour! And they were not the only ones suggesting this, because that was the only way to achieve this from within a BASIC program on this machine!
I realised that this was a great machine — alongside the greats like the Atari 800, but that it was seriously hampered by the non-existent support from the BASIC interpreter provided. This meant that for the millions of armchair enthusiasts out there, making this machine ‘sing and dance’ was going to remain an elusive dream. I resolved to change all that.
Whilst still at school at around 14 years old I started learning 6502 assembly language the hard way — a resident monitor equipped with assembly/disassembly capabilities. You could try something by entering the assembly address and then entering the mnemonics plus addresses, registers and indexing mode. When you hit enter the tool stored the bytes into memory at the address you specified. Then you could run the code. This, extremely frequently, resulted in the processor freezing and going into Guru meditation mode which resulted in me having to turn the power off and then on again, and then load software tools from a floppy disk all over again (and I was lucky to have a floppy disk drive as a most people just had a cassette deck). When I complained about this tedious write-run-crash-reboot-loadtools process to a friend of mine (Charles Dunford) at school, he made me a nice switch box which allowed me to reboot the Commodore 64 and also connect the machine to either my 1541 (C64’s crappy, slow serial bus-based disk drive) or my 8050 (dual high-density, double-sided, parallel interface floppy disk drive), which was connected to my Commodore 8032 PET which I later started using as a host development machine for Breden’s BASIC.
To cut things short here 😉 I started playing around with the CHRGET routine, which was the piece of code that the kernel used to fetch characters for the interpreter. In their infinite wisdom, Commodore copied this short piece of machine code into RAM in page zero memory so that (1) it was modifiable, and (2) so it would run faster, as page zero memory was faster to access as it used only an 8-bit address to access it instead of the usual 16-bits. What you could do was to:
- overwrite the CHRGET code to point to your own code for determining whether you wanted to handle a keyword or not
- do the default processing if you didn’t want to handle any particular keyword / regular expression
With this capability at your disposal, your only limit was your imagination. For example, if no command existed to play a musical note on the sound processor or move a graphical object around the screen, you could simply (not!) add your own keyword to your own interpreter’s keyword table and when the user invoked this new keyword via command line or program line, your interpreter could recognise the new keyword and call the code in the keyword’s corresponding entry in the address lookup table. That was the theory anyway. In practice there was quite a lot of preparation work to enable this to work, which I will detail later. TODO: Detail tokenisation process.
So, whilst at school, I had managed to hack the CHRGET system routine to enable the processing of new commands via simple 2 letter commands. This worked by simply prefixing all my two-letter commands with a character like ‘]’ or ‘!’ like the command extensions provided by the Commodore PET’s “pic chip”. This worked, but due to the constraint of having to make a new command memorable using only two letters, it had its limitations. I really wanted to be able to have full keywords, just like the standard Commodore BASIC interpreter had. To be continued…
Other fascinating news
If you do a search in Google for “Brendan’s BASIC” (sic) you will find this, where it is described as: “ADVANCED PROGRAMMING LANGUAGE WITH BIG BOOK AND DISC AND CASSETTE VERSIONS” and sells for £9 second-hand. Nice to know I can buy myself a copy of it one day 😉