The multiply code has been done since the 2nd day, but there's something odd going on. I'm going to have to step through the ROM in a debugger to see what is going on. Not sure if it's the wrong address for floating point registers or what. Once that's fixed, I can enable the 2nd optimization (replacing /10 with * 1/10) and finish looking through the ROMs to see if the CHRGET & CHRGOT call patching can be automated or if a list of addresses or exclusions will be needed.
When completed, you should be able to LOADM and EXEC the patch. That's it. A version that works with the DOS command might be in the future, but it's not really necessary.
On another note... someone asked me if changing code that divides by a constant to multiplication by 1/constant causes it to run at a different speed on the original ROMs. Once the initial divide calculation for 1/constant is made, the code should run the same speed as before with standard ROMs, but it will automatically be faster on a machine with an optimized ROM or with the patch I'm working on. There's no reason not to make the change.
When completed, you should be able to LOADM and EXEC the patch. That's it. A version that works with the DOS command might be in the future, but it's not really necessary.
On another note... someone asked me if changing code that divides by a constant to multiplication by 1/constant causes it to run at a different speed on the original ROMs. Once the initial divide calculation for 1/constant is made, the code should run the same speed as before with standard ROMs, but it will automatically be faster on a machine with an optimized ROM or with the patch I'm working on. There's no reason not to make the change.
FWIW, one problem was the OCR of the book with the disassembled ROM made a D look like a 0. The other problem was the BASIC code was designed to deal with $00 and I hadn't removed that feature for testing which didn't need it.
ReplyDeleteThis is binary floating point. 10 can be accurately represented, but 0.1 can't; just as 1/3 is a repeating decimal, 1/10 repeats in binary. You'll want to seriously test whether the change affects the results.
ReplyDeleteSince this is only used to convert from ASCII to floating point, it shouldn't be a problem in most cases, however, it may impact how a few numbers are rounded during conversion.
ReplyDeleteSince floating point numbers can't always be accurate, it's a question of whether or not the error is greater than normal. With a 4 byte mantissa + an extra precision byte during the multiply, it should still be more accurate than using divide on most 6502 versions of Microsoft BASIC.
Still, it may cause a change in behavior on some program out there.