27 replies to this topic

[Heaven/TQA]

Hi Ladies,

can someone of the coding cracks write i small tiny demo with a vertical moving sprite for 7800??? i know in principle how it works but it would take me ages to figure it how (incl. debugging...) maybe some of you (eckhard? dan?) have coded such a small example in the past?

thanks a lot guys

heaven

[EricBall]

Dan Boris has done a moving sprite sample:
http://atarihq.com/danb/a7800.shtml

[Heaven/TQA]

Thanks! but i know this small demo... it's just left/right movement and this is done very easy... on 7800...

btw. you can download the latest sensodx version now
http://www.s-direktn...og/sensodx3.a78
(please on the link with the right mouse button & press "save link to file")

as V7800 does not run under XP anymore i have downloaded & tested under the latest mess version... i am glad that it assembles fine as the source was lost for more a year because of a harddisc crash... under mess i can not start the game with start/select or fire buttons... can some of you please double check? merci

hve

[Mitch]

I can't help with the vertical movement demo but I did try out the latest version of Sensodx on an NTSC 7800.

First the good news; it's playable and I beat your high score.

Bug report;
-Select button works to select game options but the reset button and the fire buttons don't work. I can start a game by moving the joystick.
-When I beat your high score the high score display got corrupted.
-The colors for the selected squares are still not working. It's white when selected, black when not selected, no color. However, the color bars above and to the right of each square are diplayed correctly.
-The sound works but doesn't sound very good. You may want to talk to Paul Slocum, I think he has a TIA sound editor available.

Also, in case you don't have all of the 7800 dev docs, I now have them on my site here. Most of them are from The Atari Documentation Depot that John allowed me to mirror but there are a few others as well.

Mitch

[Heaven/TQA]

Hi Mitch,

glad to hear that the image is still working even on a real NTSC machine... and thanks for the bug report. I have to search an old email from Eckhard who reported me years ago why the colors are not displayed correctly on real hardware. it's strange as i haven't got the time to touch the code for more than 1 year... and then i lost all sources with a crash... i found the code on a CDR i backuped some stuff... labeled with "Atari stuff" what a expressing label...

well... the TIA sound is ugly as hell but you should hear the 1st version i made... of course it will be updated... can someone post 4 sounds incl. the values i have to poke into the sound registers so i can have proper sounds? i don't want to spend tons of hours just figuring out good base sounds....

why i need vertical movement? on the game modes "normal" onwards you will have an "attack" timer which is counting to zero while thinking & pressing the direction... like in mule & the auctions... so player can't be thinking endless...

what do you guys think?

hve

[Heaven/TQA]

Mitch, just to be sure...

in the "attract" mode of the game... (not playing...) does the bases got highlited correctly or the same error than later in the game?

here is the code from the mainloop... i guess that i can not read the color registeres via LDA (),Y and so the code is writing "WHITE" via ORA#15 into the registerers... am i right?

main_part00
lda #0
sta AUDV0
sta AUDV1
lda #5

jsr wait_sec20
jsr random
jsr randbyte
and #$03
tax

;play sound and lite desired base
lda colortab,x ;get color register adress (hardware)
sta v0
lda #0
sta v0+1
tay
lda soundtab0,x
sta AUDF0
lda soundtab1,x
sta AUDF1
lda #15
sta AUDV0
; sta AUDV1
lda (v0),y ;get base color ---> here is the error on real machine!!!
ora #15 ;hi-light
sta (v0),y

lda $282 ;read console keys
and #2 ;mask out select
bne main_part03 ;not pressed
inc v2 ;increase game_type

main_part03
ldx v2
lda modetabl,x
sta $1960
lda modetabh,x
sta $1962

jsr wait_sec20
ldy #0
lda (v0),y ;switch base off
and #$f7
sta (v0),y
...
colortab dc.b P1C1, P2C1, P3C1, P4C1
soundtab0 dc.b 31,25,21,15
soundtab1 dc.b 15,12,9,7
...

hve

[Heaven/TQA]

if that's the error than it's like needing shadow registeres like on atari 8bit computers...as you will not get the value back which you have written into the register...

hve

ps. have to go to work now...

[Mitch]

When the attract mode first starts the squares are the proper colors. As soon as the demo starts playing and one of the squares is selected it turns white and then black. I hope I explained that OK.
I'm sorry I don't know what your code means, I'm not a programmer. Maybe Dan, Eckhard or one of those smart guys will see this thread and can answer your question.
About the sounds, if you ask that question on Stella list, I'm sure someone can help. If no one responds here first, of course.

Mitch

[Heaven/TQA]

how can i get on the stella list?

hve

mitch... it seems that it will work with the "shadow registers"...

[Eckhard Stolberg]

The colour registers in the MARIA can only be read with absolut indexed addressing. So if you do "lda colortab,x / tay / lda.w $0000,y" you should be able to read the value from the desired colur register.

The stella mailing list can be found at http://www.biglist.com/lists/stella/. Even though the website still says that the list is about the Stella gets a new Brain CD project, it's become a general mailing list for 2600 related programming questions pretty early on. You need to subscribe to the list with your email address to be able to post questions there.


Ciao, Eckhard Stolberg

[EricBall]

Sorry, I haven't looked at Dan's demo. I missed that it didn't include vertical movement. I haven't done any 7800 programming myself (yet), but I have done through the documentation several times. (I think part of the problem is the wording the documentation uses isn't easy to keep straight.)

Okay for vertical movement you have two options. First, if you aren't handling overlapping sprites, you simply change the offset values in the display list list entries (or the zone headers, as I call it). So for one frame you have

offset = 7, dl ptr->blank rasters
offset = 7, dl ptr->sprite rasters
offset = 7, dl ptr->blank rasters

and the next frame you move the sprite up

offset = 6, dl ptr->blank rasters
offset = 7, dl ptr->sprite rasters
offset = 8, dl ptr->blank rasters

Obviously very few games could use such a scheme. Typically there would be one zone header for the number of rasters in the character sprites (or tiles, as I prefer to think of them). So then it is a matter of changing the high address in the display list entries.

zone header offset = 7; sprite header high = $7F ($86xx -> $7Fxx)
zone header offset = 7; sprite header high = $77 ($7Exx -> $77xx)

and the next frame you move the sprite up

zone header offset = 7; sprite header high = $80 ($87xx -> $80xx)
zone header offset = 7; sprite header high = $78 ($7Fxx -> $78xx)

Obviously, this means that each sprite will need to be bordered by a bunch of blank rasters. The "holey DMA" bits in the zone header are supposed to help with this, but I haven't figured out how to use them yet.

[DanBoris]

I am working on modifying my sprite movement demo to include vertical movement. I have it working, I just have to clean it up a bit and I will post it. Hopefully I can get it posted tonight or tomorrow.

The second method decribed in the previous message is the best way I have found to do vertical movement. The problem of having to have blank lines before and after your sprite data is solved by "holey DMA", you just have to be careful how you setup your graphics data so this works right.

Dan

[Heaven/TQA]

Thanks, Eric... have to think about this...seems complicated but i have to think again...

Dan, would be great if you could post the method... if we have an "all in one" sprite routine it is more easy to code on 7800 for beginners... as 7800 is different to 2600 & 5200 & 800... so they might not find any good doc for sprites and sprites are key on 7800...

cheers, hve

[Heaven/TQA]

so... 7800 seems beaving like on PSone with it's display object list...

and ergo i need to build every VBL the complete DLL... aaarg...

hve

[Heaven/TQA]

color bug should be fixed now...

http://www.s-direktn...og/sensodx4.a78


lda (v0),y

changed into

ldy #basenumber
ldx colorreg,y
lda 0,x
ora #15
sta 0,x

for highlitning of the bases...

please check on real hardware if its now working properly.

hve

[DanBoris]

Here is my first attempt at moving a sprite both horizontally and vertically:

http://atarihq.com/d...iles/7800sprt.s

You can compile this with DASM and use my 7800 development framework to add the header and validation signiture. When you run it you can move the sprite around the screen with the joystick. I have tested this with MESS, but not on the real hardware.

Please let me know if anyone has ideas for improvements to this code.

Dan

[EricBall]

Read the documentation again and now understand how holey DMA works. Going back to my previous example, let's assume that the sprite is 8 rasters high. Each raster is stored on a separate page. In order to use holey DMA rather than blank rasters, the sprite is stored at $x0yy -> $x7yy (where x > . If x=$F, then:

zone header offset = 7, H8=1;
sprite header high = $F4 ($FByy -> $F4yy)
zone header offset = 7, H8=1;
sprite header high = $EC ($F3xx -> $ECxx)

Holey DMA H8 means that if A11 is high ($x8yy -> $xFyy) data = 0 (hmm... wonder how that works with Kangaroo mode...), so the sprite is automatically padded. H16 works the same way for 16 raster sprites. The docs also say this only works when A15=1 too, which is why I state x>8 above. Sprites that are not 8 or 16 rasters can still use holey DMA, but must be manually padded to 8 or 16 rasters.

Oh, and my example of varying the size of the zones is usefull when you want to vertically scroll a tiled background.

And yes, it does appear that a bunch of work in a 7800 game is creating the display lists. I almost wonder if it would be a good idea to double buffer the DLL.

[Mitch]

I didn't see much difference in the new SensoDX version, except the high score seems to display OK now.

Dan, when I compiled your program it came up 64 bytes too short. MESS didn't seem to care but I couldn't get it to work on the real thing. Also, was there a reason you made it a 64k ROM? That leaves a lot of empty space in there, unless I am just compiling it wrong.

Mitch

[DanBoris]

Mitch said:

Dan, when I compiled your program it came up 64 bytes too short. MESS didn't seem to care but I couldn't get it to work on the real thing. Also, was there a reason you made it a 64k ROM? That leaves a lot of empty space in there, unless I am just compiling it wrong.

Mitch

My bad, I just uploaded a corrected version. Since I did an ORG $40 to setup the zero page variables the assembler created a binary that ran from $40 to $FFFF, thus the missing 64 bytes. Adding in a few SEG directives corrects this.

Dan

[DanBoris]

EricBall said:

And yes, it does appear that a bunch of work in a 7800 game is creating the display lists.  I almost wonder if it would be a good idea to double buffer the DLL.

I never thought about double buffering the DLs, that's a pretty good idea. This brings up another issue and that is how to manage DL memory. In my sprite demo I create a series of fixed size ares in memory for the DLs, in this case each is 64 bytes long. Doing this makes it fairly easy to fill in the DLs but it wastes a lot of RAM since each DL memory block must be big enough to handle the worse case, thus you will end up with a lot of wasted RAM.

The alternative is to build the DL's in sequence one after the other. This saves a lot of memory, but is much harder to code. You would have to scan through all your sprites to find which ones go in the first DL, then repeat the process to see which ones go in the second DL, etc.

Dan

[Mitch]

DanBoris said:

My bad, I just uploaded a corrected version. Since I did an ORG $40 to setup the zero page variables the assembler created a binary that ran from $40 to $FFFF, thus the missing 64 bytes. Adding in a few SEG directives corrects this.

Dan

OK, it works on the real thing now but there are garbage graphics at the bottom of the screen. The original horizontal sprite demo looks fine.
Also, I seem to remember that the first couple of betas of SensoDX had the same garbage graphics.

Mitch

[Heaven/TQA]

Mitch, thanks... i'll have to change now the color reg indexing into "shadow reg" mode as the changing suggested seems not to work or i have misunderstood that.

where does the garbage appear? as v7800 and mess do not show anything... it seems that it is the pal/ntsc stuff? have to check that either...

hve

ps. thanks dan for the sprite stuff... it seems that building the dll ever vbl is the same like on psone... building every vbl the primitive list (not sure if it's called in that way... can't remember)

[Mitch]

Heaven/TQA said:

where does the garbage appear? as v7800 and mess do not show anything... it seems that it is the pal/ntsc stuff? have to check that either...

hve

The garbage graphics are at the bottom of the display in Dan's demo. It was your early SensoDX demos that had the same garbage on the title screen. The last few have been fine.

Mitch

[Eckhard Stolberg]

Hey Karolj,

why are you constantly insisting on using shadow registers, when you already got it working without them before? What you are doing wrong is that you are using zeropage-indexed addressing to read the colour register instead of absolute-indexed. You need to change the "lda 0,x" into a "lda.w $0000,x" to make it work. Otherwise DASM wouldn't generate the right addressing mode.


Ciao, Eckhard Stolberg

[Heaven/TQA]

"das ist alles?" - that's all??? simple at it is...

do i have to understand the 7800? no... thanks!

i'll post tomorrow the new image...

hve