By default, yes. This can be kludged but, in essence, if you change MODE then HIMEM is set to the location where screen memory starts, and the stack grows down from there.So is the actual screen display using the memory which starts at HIMEM? For example, if I am in MODE 1 and I get back $3000 from OSYBYTE &74 (X:$00, Y:$30), does that mean that the screen pixel RAM starts at $3000?
Yes; MODE 7 uses 1K of memory. Sure, 40*25 is only 1000 so there's an extra 24 bytes to account for, but this is, in some ways, a weird mode. I works differently to every other mode (character mapped rather than pixel mapped) and hardware scrolling changes the start address and it wraps around, so all 1024 bytes do get used.But... how come I get back $7C00 for the initial bootup mode? MODE 7?
Only in MODE 7, and only if the screen hasn't scrolled.I see this puts ASCII 'A' at the top left of the screen for MODE 7.. so I guess the BBC is similar to the Vic20/C64 for screen character RAM.Code:
M=&7C00?M=65
MODE 0,1,2 take 20K so HIMEM is set to &3000; MODE 3 is 16K, so &4000; MODE 4, 5 take 10K, so &5800. MODE 6 takes 8K, so &6000 and MODE 7 takes 1K, so &7C00.I'm still confused as to why the screen addresses/HIMEM values vary so much - $3000, $4000, $7c00 etc
Screen memory always ends at &7FFF ('cos &8000 is the beginning of ROM) so you count backwards from there.
https://www.stairwaytohell.com/articles ... fig3-L.jpg isn't a bad picture.
All modes are pixel based, except mode 7 (which is teletext character based) but the pixel mapping changes depending on the mode. In MODE 2, for example, 'cos it's 16 colours, each byte only covers 2 pixels. But 2 colour modes (eg 0, 3, 6) each byte covers 8 pixels.Next I'll be wanting to know how the character colours work and how bitmap graphics work - from a memory perspective. I see writing 255 into $4000 for MODE 3 prints a flat line - so maybe MODE 7 is character based and MODE 3 is bitmap based? (excuse my choice of terminology)
)Statistics: Posted by sweh — Sat Feb 17, 2024 11:16 am