SteveF wrote: ↑Tue Jan 17, 2023 9:32 am
I do wonder if this is caused by Ozmoo trying to read the screen size via osbyte_read_vdu_variable and getting bad (small) values which cause it to try to use a tiny 1x3 display. It may also have something to do with the use of VDU codes 28 (vdu_define_text_window) and 26 (vdu_reset_text_window) to control the scrolling; I don't know if these are supported on the Atom in this environment. Most of this code is in screenkernal.asm and searching in it for calls to osbyte/oswrch will probably identify possible code for hacking around with.
Hoglet has already indicated that reading screen size via osbyte_read_vdu_variable is not implemented, but I've just had a quick look at the relevant code for reading the screen size and it could easily be hacked to match the Atom screen text resolution - whatever that actually is (edit: 32 x 16, it would appear)! I'm less certain about VDU 26 and 28 calls though.
SteveF wrote: ↑Tue Jan 17, 2023 9:32 am
Edit: Probably not the problem, but just in case: If you converted the "wait for SHIFT" code to "wait for any key", did you remember to remove the loop ("beq -" just above increase_num_rows_done in screen.asm) around it? We need to loop around calls to OSBYTE &81 as it returns even if there's no keypress, but we don't need it for OSRDCH.
I've not changed any code yet, but I understand what you're suggesting I to do here. Initially I might just comment out that section of code altogether, and let it continue scrolling without any user input, just to keep things simple. Once we've got a system that 'works', I can add in the OSRDCH code if that is what's required. I do wonder if I should switch from Hollywood to another game to avoid this initial scrolling issue. I'll probably switch to Calypso, so we're all using the same game - assuming there's no page scrolling on startup with that game.
SteveF wrote: ↑Tue Jan 17, 2023 9:32 am
Edit: I think you're right about the fg/bg colour addresses, sorry! I've patched up my post above now. I never got round to testing that bit properly as I was getting blocked on the "Bad command" problem. Still don't know what's happening there, although it's presumably not causing you guys any problems and it doesn't happen in normal use when the loader runs OZMOO2P, so I guess it's hardly a pressing issue, although it would be nice to know as it may suddenly start manifesting itself in normal use just to be spiteful at some point.
For clarity, this is what I typed into the Atom:
Code: Select all
?&416=6
?&417=0
?&418=7
$&408="OZMOO2P"
*RUN OZMOO2P
I'll probably create a small 'ATOMLOAD' basic file with those minimum commands, so I don't have to keep typing them in - particularly since my 6/& key isn't working, and I'm having to short out springs on the keyboard to get those characters!
I did notice a hard coded entry in the LOADER that I wasn't sure about:
Any idea what that's for?