The CC65 compiler + VICE C128 emulator is a great way to verify pure C code segments within limited hardware for designing compact platform independent embedded applications…

…but what the hell am I going to do with Microsoft BASIC coded in 6502 assembly!

You guys need something better to do with your time, seriously :-)

I was instantly hooked on programming these new fangled computer gizmos. I bought myself an AIM-65 and all the bells and whistles (16kB RAM, extender board, ROM basic and assembler, etc). I bought a suitcase and mounted the entire thing inside so that I had a ‘portable’ computer.

On the KIM-1, in addition to assembler, we also had MS Basic (on tape of course). There was some floating point math that the computer did prior to uploading the data. We wanted to speed this up so we interfaced an AMD9511 Math chip to the KIM-1 and then put hooks into MS Basic to use the chip instead of the FP routines. Worked great!

A couple of years later I did something similar when the 8087 first came out for the IBM-PC. I created an alternate object library for the MS compilers that used the 8087 instead of the FP routines. I had to convert back and forth between MS FP format and IEEE format, but with my experience on the KIM-1 it was no problem. I got my first pre-production 8087 from a company that had given up doing that very thing due to their frustration in trying to convert the FP formats.

Thanks for the memory jog!

What about SYM-1 and AIM-65 Basic? What I have seen of those versions I suppose it somewhere in the 1.1 branch, but much better integrated with the SYM-1 and AIM-65 operatings system.

AIM 65 BASIC V1.1 (C) 1978 MICROSOFT has 9 digit FP,GET, and ROR – but only 2 char error messages. It was shipped in 8K of ROM with the ATN() function left off for users to install to RAM if they wanted it. The message in caps is at the end of the ROM. Only the first part prints on startup.

http://community.livejournal.com/vintagecomputer/66963.html?thread=314771#t314771

But where does $047F get set? The only reference I can find is in a timer tick interrupt in the KC’s 6502-side EXEC, where $047F gets counted down toward zero! Take a look:
C1CB AD 7F 04 LDA $047F ; \
C1CE F0 03 BEQ $C1D3 ; |– If $047F isn’t zero yet, decrement it
C1D0 CE 7F 04 DEC $047F ; /
So what the heck is going on here? I’ve seen lots of references to locations to either side of $047F, but never $047F itself. If this really does get decremented every tick, maybe it gets set to $FF on an error, and the error expires after ~4 seconds???

Clearly, I still haven’t figured out all of the communication paths between the Master Component and the Keyboard Component, nor have I figured out where all the different flags get set from. It’s definitely an adventure reverse engineering an OS that spans two different CPU types, and includes such bizarre things as 10-bit wide RAM shared between them. :-)

I really just ought to publish what I have reverse-engineering-wise and see what more eyes might bring.

It also causes the character 0xFF to list literally whether it is in a string or not. On the Commodore 0xFF is the character for pi and you can use it as a constant. The program
10 PRINT π
will print out 3.14159265 when run. When this program is LISTed we want the character to print literally and not be interpreted as a token (0xFF is not assigned to any token).

The OSI machine seems to have a small picture of a tank pointing up and to the left at 0xFF. The special case may have been included in the OSI due to an oversight. I don’t know if you get 3.14159265 if you try to evaluate it.

program.s:

        lda     ERROR_MESSAGES+1,x
  .ifdef KBD
        and     #$7F
  .endif
        jsr     OUTDO

The “.ifdef KBD” should probably be an “.ifdef CONFIG_2″.

Apart from that: great work!

Here are the MD5s of the original binaries:
applesoft.bin = 84b510725233ce4a9f12894d17c0c056
cbmbasic1.bin = 0aae8577c9e2d78a869f15fe73e3c0db
cbmbasic2.bin = 65fbddc1114c5ca4648cf31d6a9a2891
kb9.bin = 3272e79a92398bfceaab2f8178ce382f
kbdbasic.bin = 639f953ac2eb1d1ceb307eea843f3c27
microtan.bin = b28f19e5947bed5c771990ad0eb3fe36
osi.bin = 1f45d3c8c7e684901b453a443a93f2e9

Commodore BASIC 2 is the PET version and won’t just work on a C64, for several reasons:
* It is compiled for $C000-$E000; the C64 has its own ROM and other parts there.
* It does a memory test by reading/writing memory (without preserving the data) until it hits unassigned memory or ROM – if you link cbmbasic2 to another address in RAM, it will overwrite itself.
* RAMSTART is $0400, while it should be $0800 on the C64.
These items can probably be fix pretty easily, but:
* Zero page layout is different on the PET and the C64: You must make sure that BASIC does not use zero page locations used by KERNAL. After all, BASIC on Commodore computers is not standalone, but requires the services of KERNAL, especially the screen editor.

Please note that the “Commodore BASIC V2″ used in the VIC-20 and the C64 is unrelated to version 2 in the PET: C64 BASIC is based on the PET BASIC 4.0 source code, with all post-2.0 features stripped out again for space reasons. Among other things, C64 BASIC used CR instead of CR/LF everywhere, and it had some better abstractions between BASIC and the KERNAL: For example, on the C64, KERNAL detects the size of memory, and BASIC queries this information through a call into the KERNAL jump table.

So I suggest you replace the BASIC2 ($C000-$E000) ROM and the lower part of EDIT2G ($E000-E1DE) ROM in VICE with your assembled binary. Be careful that you don’t overwrite the screen editor code. This way, your binary will work without changes. Be careful though to configure VICE to emulate the correct version of the PET.