Cannot poke to PMBASE

[Tyrop]

Newbie question here.  I am trying to learn player/missile graphics in assembly language.  I am using Altirra 4.0 and WUDSN IDE.  I am trying to write a simple program for now just to put a player on the screen.  I cannot even get past the initial setup.  I subtracted 8 from RAMTOP, getting a $98 in the accumulator, and I am doing a STA $D407.  However, $D407 remains locked with a $FF.  Even debugging in Altirra, if I use the debugger to write a number to $D407 (for example: e $d407 $98), nothing happens.     Can anyone let me know what I am missing?  Much appreciated!

[danwinslow]

I think that is a write-only location, meaning that there's no point in reading from it. Weird, but true, I think it has something to do with the way the bus interfaces with the antic chip.

https://www.atariarchives.org/mapping/memorymap.php 

look for D407

And

http://user.xmission.com/~trevin/atari/antic_regs.html

 

Edited December 12, 2021 by danwinslow

[matosimi]

$D000-$D7ff is hardware register space.

Most of the addresses are write-only, meaning if you write some value to the address you will not be able to read the value back.

My suggestion is to always have the mapping the atari - memory map page (1st link that @danwinslow posted above) nearby to check what are the options.

Items there have 2 symbols (R) and/or (W) - describing what happens if you write and/or what happens if you read.

 

1. So in order to initialize PMG, you have to set the PMBASE:

mypmbase    equ $1c00

this address points to where player0 data starts, each player data is 256bytes so player1 data starts at $1d00, player2 at $1e00, player3 at $1f00. Missiles start 256bytes earlier, so $1b00.

PMbase has to be specifically aligned, I usually use $xc00 (where x is anything from $1 to $f).

 

2. you have to set gractl $d01d and enable PMG by setting it to #$03

 

3. you can set the priority of PMG vs playfield to prior register $d01b to #$01 (PMG above playfield) - but in this case you should use shadow register $026f because i am pretty sure you are not disabling OS Rom nor using interrupts 

 

4. you have to set dmactl $d400 SDMCTL $22f to enable player/missile direct memory access by setting it to: #2+12+16+32

 

5. you can setup some colors using shadow registers PCOLR0 ($2c0) ...

 

6. you have to set the player horizontal position by setting HPOSP0 to some value like #64 for example

 

sdmctl	equ $022f
gprior	equ $026f
pcolr0	equ $02c0
hposp0	equ $d000
gractl	equ $d01d
dmactl	equ $d400
pmbase	equ $d407

code	equ $2000
mypmbase	equ $1c00

	run code	

	org code
	mva >mypmbase pmbase
	mva #$03 gractl
	mva #$01 gprior
	mva #2+12+16+32 sdmctl ;dmactl
	mva #$0f pcolr0
	mva #64 hposp0
	jmp *
	
	org mypmbase+64
:32	dta :1

		
	

If you are not used to mva, remember it is a macroinstruction lda,sta ... like:

lda #$03

sta gractl

 

 

tyrop.asm

tyrop.xex

 

 

(I'm not used to have OSRom on so using shadow registers is kind of weird to me... but using shadow registers is the way to learn and understand the behavior for beginners)

Edited December 12, 2021 by matosimi
shadow register for dmactl

[TGB1718]

1 hour ago, matosimi said:

each player data is 256bytes so player1 data starts at $1d00, player2 at $1e00, player3 at $1f00.

Not quite, depends on the resolution chosen:- see below

 

[Tyrop]

Thank you all for the help, and thank you Matosimi for taking the time to make some code for me!  But now I am confused about something.  Matosimi's example does not match the instructions in the various books, but it works.  I don't know why.  The books say that you have to add 1024 to PMBASE to get to the beginning of the player 0 bitmap.  But Matosimi didn't do that.  Matosimi placed #$1C into PMBASE, and then simply placed the bitmap 64 bytes up from $1C00 (i.e. $1C40) .  How is this able to work?  If I follow the books, and if I put #$1C in PMBASE, then my bitmap for player 0 would need to start at $1C00 + 1024 (i.e. $2000). 

 

Incidentally, I am not using BASIC at all, this will all be machine language.  Don't know if that makes a difference.  

Edited December 12, 2021 by Tyrop

[TGB1718]

Doesn't matter what language you use, just easier to put any movement routines into a VBI routine

[glurk]

1 hour ago, Tyrop said:

Matosimi placed #$1C into PMBASE, and then simply placed the bitmap 64 bytes up from $1C00 (i.e. $1C40) .  How is this able to work?  If I follow the books, and if I put #$1C in PMBASE, then my bitmap for player 0 would need to start at $1C00 + 1024 (i.e. $2000). 

 

 

PMBASE ignores the last 3 bits of the value.  So by using $1C (%00011100) you are "really" setting it to $18 (%00011000).

 

[danwinslow]

I am not an expert on PMBASE, but if glurk is correct above, then this is a general feature you run into when writing to control ports of dedicated chips. They often are only using specific bits for information and will ignore any other bits set in the number. Why he was using $1C in this case I don't know.

[danwinslow]

1 hour ago, TGB1718 said:

Doesn't matter what language you use, just easier to put any movement routines into a VBI routine

True, but you don't need to worry about that now. When you get things more or less working, you can start putting stuff into a VBI/VBD interrupt.

[glurk]

Actually, I think what I said is incorrect.  It ignores the last 2 bits, so $1C is valid.  And I don't know how matosimi's code works either(?)

 

I never code in mads assembler, it confuses me, but it doesn't LOOK like he's putting the PLAYER0 data at PMBASE+1024?  It looks like it's going into the UNUSED area.

 

[matosimi]

I'm using $1c00, because that is the way how I like it , it is easier for me to realize where the pm data actually are stored.

 

As mentioned in my reply to your original post I simply like to set pmbase to address which equals player0 data.. then missile data is -$100 and other player data are +$100,+$200,+$300.

@glurk wrote... lower 3 bits are ignored so it does not matter if you set pmbase to: $18,$19,$1a,$1b,$1c,$1d,$1e or $1f ... missile data will for any of these values start at $1b00 and player0 data at $1c00, player1 at $1d00 .. and so on.

Just remember if you would like to stick to PMBASE set to beginning of 8page region ($18) then you have to change the place where the pmdata are saved (last 2 lines of my code) to:

	org mypmbase+$400+64    ;which has to point to $1c00+64
:32	dta :1

 

Different topic, but similar situation: if you use your own character set, it has length of 1024 bytes = 4 pages ... and it has to be aligned by 4 pages in the memory. So if you set CHBASE to $22 it is anyway setting the address to the $20 ($2000) ... in this case 2 lower bits are ignored.

 

 

4 minutes ago, glurk said:

Actually, I think what I said is incorrect.  It ignores the last 2 bits, so $1C is valid.  And I don't know how matosimi's code works either(?)

 

I never code in mads assembler, it confuses me, but it doesn't LOOK like he's putting the PLAYER0 data at PMBASE+1024?  It looks like it's going into the UNUSED area.

 

your first answer was correct, it ignores 3bits  (I'm not sure, but it maybe ignores 2bits in case of half PMG resolution - fat square pixels)

Edited December 12, 2021 by matosimi
bit stuff

[Tyrop]

Thank you all.  Now I understand.  That's a nifty shortcut using $1C00 as pmbase for player 0.  Kills 2 birds with 1 stone.  I now see that STA #>MYPMBASE to pmbase actually results in ANTIC seeing a $18 there.  Simultaneously, MYPMBASE is already 1024 bytes after PMBASE.  There is so much for me to learn ...  

[phaeron]

To clarify the hardware behavior: PMBASE stores 6 bits (bits 2-7), but bit 2 is not used in single-line resolution mode. Thus, writing $1C to PMBASE really does set it to $1C, but it acts the same as $18 unless two-line resolution is used.