Perihelion tutorial No8

[Redreamer82]

Hi!

I'm new to Atari assembly. I've followed Perihelions tutorials on top of reading Abacus Atari Internals and machine language books. Anyway, in tutorial no8 he explains that the video memory must be on a 256 byte even address, but I dont understand the syntax given in the code.

https://nguillaumin.github.io/perihelion-m68k-tutorials/tutorial-08.html

 

 

Why does the last three rows make sure that we are on a 256byte even address? Yea, ds.b reserves 256 bytes of data but it does not align me to an even address? I hope I didnt miss read anything in the tutorial and everything was there right in front of me...

move.l  #screen1, d0 ; put screen1 address in d0

clr.b  d0 ; put on 256 byte boundary



clr.b  $ffff820d ; clear STe extra bit

lsr.l  #8, d0

move.b  d0, $ffff8203 ; put in mid screen address byte

lsr.w  #8, d0

move.b  d0, $ffff8201 ; put in high screen address byte



section bss

ds.b  256 ; 256 byte clear buffer

screen ds.b  32000 ; the screen

[ggn]

Firstly, that "clr.b d0" does the magic of aligning the address to 256 byte boundary. Since 256 is $100 in hex, it means that if we just make sure that the lower 8 bits of our address are 0 then we're done.

 

So, what's the extra "ds.b 256"? Well, consider this:

 

section bss
label1: ds.w 4
label2: ds.l 1
screen: ds.b 32000

If we take "screen"'s address and clear the lower 8 bits then the address will move up in memory (as an example: if "screen"'s address is $60024, it will become $60000). So it's certain that if we use the modified address, label1 and label2 will get clobbered by screen data. (the exception to this is "screen" already being an address with the 8 lower bits 0)

 

So, to counter that we need to add some dummy bytes before "screen". That's what the "ds.b 256" does. If we knew the address our program will be loaded we could simply reserve as many bytes as needed. But we don't know beforehand the address our program will be loaded so we just put in the maximum amount of bytes we can move back: 256. (well, technically it should be 254 but what's 2 bytes between friends).

 

Hope this makes sense now.

[ParanoidLittleMan]

Code example is flawed.

It should be:

  move.l  #screen1, d0 ; put screen1 address in d0

  clr.b  d0 ; put on 256 byte boundary

  move.l d0,screenBase

  clr.b  $ffff820d ; clear STe extra bit

  lsr.l  #8, d0

  move.b  d0, $ffff8203 ; put in mid screen address byte

  lsr.w  #8, d0

  move.b  d0, $ffff8201 ; put in high screen address byte

*  further code ....

screenBase  dc.l 0



   section bss

   ds.b  256 ; 256 byte clear buffer

screen1 ds.b  32000 ; the screen - not really, it will be lower

MC68000 code is always on even address, so it is assured here. Only if you put some data of even length inside code it will be ruined. Therefore is ASM control statement even .

 

Like:

   moveq #1,d1
   dc.b  "Even",0  * this is actually odd len since 0 terminator

   even

   bsr  huh

Without that even statement you would get error by assembling.

[Redreamer82]

@ggn

Yea, this really helped me to understand. Ive done some C64 assembly but never done it like this.

 

@PLM

What you're saying is that I should put an "Even" after a dc.b/ds.b to be sure that I stay on the "even side" in memory?

[ParanoidLittleMan]

@PLM

What you're saying is that I should put an "Even" after a dc.b/ds.b to be sure that I stay on the "even side" in memory?

Sure, it's easier than counting bytes of text string . In case of ds.b you see is it even or odd ...

C64 - 6502 or Z80 assembly differs pretty much from 68000 ASM. I seen lot of Atari code with traces of 8-bit programming habits.