Pipe dream projects – part 1

Debunking Microsoft Extended BASIC for C64 (part 1)

So apparently the author wants to convert Microsoft Extended BASIC to the C64… or doesn’t depending on the paragraph we examine. Either way, he doesn’t appear to understand what that will actually entail!

As you read in a recent article, I’ve decided to look into and attempt to put together an implementation of “Microsoft Extended BASIC” which will run on the Commodore 64 platform, including emulators and the C128 in C64 mode.

I think that this kind of BASIC is exactly what was desperately needed on the Commodore 64, but wasn’t provided, due to Jack Tramiel’s miserly, penny pinching ways.

“What was desperately needed” in this case meaning “what the author personally wanted” of course because, if it really were desperately needed, that demand would have been met by a developer and the resulting package used more frequently than BASIC V2 – this didn’t happen.

I’ve decided to make a start by at least making plans for how to create an implementation of “Microsoft Extended BASIC” for the Commodore 64. This would obviously require making various flowcharts showing how it’s supposed to work.

Ah, good old flowcharts… it’ll actually be amusing to see them because their usefulness tends to break well before projects of this size.

What’s involved is that a computer is constantly scanning its keyboard to detect when a key has been pressed, as well as if any numbers are typed at the beginning of a line.

There are a few exceptions, but most 8-bit BASIC interpreters deal with complete lines when the return/enter key is pressed, they aren’t constantly scanning the input in the way the author described.

Unfortunately, Commodore BASIC V2 starts its list of tokens at 128, wasting half of the possible available entries for commands.

Tokens start at 128 for a reason, it’s so they can be differentiated from plain text and if the author doesn’t understand why that’s a necessity his project is going to get messy rather quickly. Tokenisation is quite easy to expand, merely assign one token to mean “the next byte is a second level token” and you get another 256 to play with, albeit at the cost of memory for those longer two byte tokens[1].

I’ve also got an ATR Atari disk image file which contains Atari Microsoft BASIC, so I may be able to load that into the Atari Assembler/Editor and examine the source code.

There almost certainly won’t be source code on that disk image unless it “escaped”; disassembling code isn’t the same as looking at the source and is much harder to read.

The main things to look out for would be any memory locations or ROM calls which are different on the Commodore 64. I think these would all be JSR instructions, but that not all the JSR instructions would be calls to the Atari ROM. I could refer to the book “Mapping The Atari” to find out which calls are actually to the Atari ROM. I don’t think I’d have to understand all the source code. At least that’s what I hope, anyway.

This is a ridiculous approach and no, it’s not possible to pull something complicated like a BASIC interpreter apart to repurpose it without properly understanding the code even if the source were available.

Of course, various activities described above would probably infringe Microsoft Copyright and/or intellectual property rights, but I’m not doing this to make money, so I suggest that this software will be shareware and if you use it, then you should send some money to Microsoft.

This doesn’t absolve the author legally; it’s still an infringement of Microsoft’s rights as would trying to declare a derivative work as shareware without their consent be. Your correspondent sincerely doubts that they’d care this far down the line of course, but there’s enough manure out there about the legalities of such things and it would help everybody if the author wasn’t adding to the pile.

I believe anything’s possible! Unless people believe this, then it holds them back.

Your correspondent would stop short of declaring anything to be possible because no, that just isn’t true. And although quite a few difficult things are possible, it doesn’t follow that they can actually be achieved without years if not decades of experience regardless of how often someone tries to reassure themselves with sweeping, ridiculous statements.

I think the best way for me to start on this project is to develop each command as a separate routine, then make them into yet another extended BASIC for the Commodore 64.

This isn’t going to lead to a conversion of Microsoft Extended BASIC though and potentially generates a lot more work in the long run. A more viable approach would be to pull apart another rendition of the Microsoft Extended BASIC interpreter, disassemble it to source, document every subroutine and then bludgeon the whole thing mercilessly until it assembles to and runs from RAM on the C64. This would be, your correspondent hastens to add, a difficult coding feat to pull off even for someone experienced with the two platforms involved and the author can’t claim that level of knowledge about even one of the machines at this point.

Other possible locations are 16384-32767/$4000-$7FFF, 32768-36863/$8000-$8FFF, 40960-49151/$A000-$BFFF, and 49152-65535/$C000-$FFFF.

All of the spaces from $0801 to $8FFF suffer from the same problem; they’re within the space where the BASIC interpreter keeps the user’s program.[2] Spaces from $9000 onwards have issues too in that they exist under the various ROM and I/O spaces so, whilst they’re available to assembly language programmers who don’t need the ROMs, getting to them from BASIC isn’t possible without quite a bit of rewriting and an understanding of what is going on.

The most optimal place to use would be $E000 onwards (with the colour RAM at $CC00) because it exists outside of the BASIC RAM, but that involves modifying the BASIC interpreter to disable the Kernel ROM when it needs to deal with the display.

In the case of C64 graphics screens, I think the whole 8K has to be filled with zero bytes.

Only 8,000 bytes are used for bitmap data.

Computers from this period had separate screens for text and graphics just to save memory. This concept was abolished on the Amstrad CPC, though.

Not all computers did, the Spectrum and Oric for example only offer bitmapped modes. And it isn’t necessarily a good thing to not have the option either because, along with memory efficiency, using a text-based mode is always quicker than having to refresh a bitmapped display.

[1] Having two bytes per token instead of one might not sound problematic, but with a larger BASIC program needing hundreds if not thousands of commands, if the new ones are being used a lot it will chomp through memory at an alarming rate.

[2] The same is true of the Atari 8-bit or C128, they both take memory away from the BASIC program for bitmapped displays when invoked but deal with it differently.

Advertisements
This entry was posted in Debunking and tagged , , , . Bookmark the permalink.