Jump to content
Sign in to follow this  
Redreamer82

Perihelion tutorial No8

Recommended Posts

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

@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?

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...