progress on BASIC port
Jan. 20th, 2013 01:26 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
unbibiumSo, in order for me to claim that I got the startup screen working, I have to get the CPU to walk through all the same subroutines that it did on the real Commodore 64, to bring up "38911 BASIC BYTES FREE".
Now, I can write a native subroutine that'll take a 16-bit byte and write the decimal equivalent to the screen, but the real Commodore 64 converts the number to a float, and calls the routine to print a floating point number. Since I'll have to get this thing to print numbers eventually, I might as well do it now. It'll be easier to do it before the point where I'm typing in test programs.
So, what I've been doing is setting parallel breakpoints on a Commodore 64 emulator and DTDB, and checking that the CPU and memory are at similar states at various points.
So far, I've gotten the right behavior up to the point where it calls FOUT. On a real Commodore 64, it hits MUL10 at least once, and I need to figure out why.
By the way, the Atari 8-bit version would have been much harder, because its OS stores its digits in BCD format, and the target CPU has no BCD math mode. The Commodore OS uses binary for everything, hence all the multiplying and dividing by 10.
Now, I can write a native subroutine that'll take a 16-bit byte and write the decimal equivalent to the screen, but the real Commodore 64 converts the number to a float, and calls the routine to print a floating point number. Since I'll have to get this thing to print numbers eventually, I might as well do it now. It'll be easier to do it before the point where I'm typing in test programs.
So, what I've been doing is setting parallel breakpoints on a Commodore 64 emulator and DTDB, and checking that the CPU and memory are at similar states at various points.
So far, I've gotten the right behavior up to the point where it calls FOUT. On a real Commodore 64, it hits MUL10 at least once, and I need to figure out why.
By the way, the Atari 8-bit version would have been much harder, because its OS stores its digits in BCD format, and the target CPU has no BCD math mode. The Commodore OS uses binary for everything, hence all the multiplying and dividing by 10.
