Calculator Community > ASM
83+/84+ Free Ram Areas
Runer112:
I found out that parsingPtrs is not safe the hard way. It took me a good hour or so to debug that overwriting basic_start, nextParseByte, and possibly basic_end causes errors to be thrown when the program exits, despite the program not being a BASIC program.
ZippyDee:
Just for clarification, are the large spans of unlabeled RAM such as at $843F or $89EC all untouchable? Or just unknown?
thepenguin77:
If it's not labelled, it probably has a 1 star in both categories. Don't even try to mess with those areas unless you are going to restore them afterwards and aren't going to use any bcalls.
Xeda112358:
--- Quote from: ZippyDee on January 05, 2014, 06:33:17 pm ---Just for clarification, are the large spans of unlabeled RAM such as at $843F or $89EC all untouchable? Or just unknown?
--- End quote ---
I believe 843Fh is where the OS interrupt handles key presses and such. If I remember correctly, 843Fh holds the current key press, 8445h holds the last registered key press, and the other in between are counters. Specifically, 8442h is used for repeating keys, starting with a value of 50, counting down to zero. If it reaches 0 and it is a repeating key (arrows or [del]) it repeats the key press, and resets the counter to 10. This is why the initial delay is longer after pressing arrows and such. I read these RAM areas because it is much faster than a silly bcall :P You do need interrupts enabled, though.
EDIT: Actually, rereading your post, ZippyDee, I think you read the values like "1087" and "1434" as the size of the gap. instead, if you subtract 8000h from the address and convert to decimal, you will see these are just the offset into RAM :P
c4ooo:
What exactly are "lFont_record" and "sFont_record"?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version