Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

ScumSoft

Members
 View Profile  See their activity

  • Content Count

    415

  • Joined

  • Last visited

Posts posted by ScumSoft

  1. Posted · Edited by ScumSoft

    The problem (I think) has a few causes. The first is that I still think the stack is imbalanced (not sure yet if it's bB or the game - jrok hasn't commented on his stack use) and the stack pointer (DF7) was not properly initialized in DPC_startup.asm (DF6 is set instead of DF7 - it's an easy fix.)

    Are you using a bb with a fix for the stack statement bug? I don't think there was a public release for it, though the fix is easy enough from batari's description.

    In DPCstartup.asm change:

     
lda #<USERSTACK
STA DF6LOW
lda #(>USERSTACK) & $0F
STA DF6HI

     

    To:

     
lda #<USERSTACK
STA DF7LOW
lda #(>USERSTACK) & $0F
STA DF7HI

  3. Posted

    Yep the latest build also falls apart, you now get red playfield streaks down the screen then it eventually all turns blue.

     

    Fixing the stack pointer also did not help my EggVenture issues either.

  5. Posted

    Damnit jim I'm a programmer not a math major! Comment all this algebra and call me in the morning.

     

    In otherwords I'd love to help but I can't sit here and decipher what all your code is trying to accomplish.

    dim your variables to proper names and comment your code so we can figure out whats going on.

  7. Posted · Edited by ScumSoft

    I just ran into the issue where everytime VisualbB was started it came up with the "New start wizard" dialog, this crept up on me out of nowhere. I read the bB thread and starting on Page 17 others ran into the same issue but had no real fix for it.

     

    In my case and perhaps everyone elses, XP(SP3) compatibility mode got enabled somehow on the visualbB.exe

    Uncheck this and everything works fine.

     

    Just thought I would share this bit of info.

    • Like 1

  8. Posted · Edited by ScumSoft

    You can easily accomplish this in ASM, however to do color changes in batari Basic you need to set the player colors per scanline which requires you to override the drawscreen function with your own. This way you won't have to setup player0color tables for each scanline color, per frame!

     

    Right now there isn't an easy method for these visual effects that I know of.

     

    [edit]

    I can't find an easy method to do this without replacing routines.

  9. Posted

    There seem to be some inconsistencies in the way Stella and the real Harmony cart handle the DPC+ arm header code.

     

    Stella I think is said to use it's own DPC+ routines and does a pretty good job getting things done, but bring the same DPC+ game onto the harmony and things start falling apart.

     

    Is there a way to have stella ignore it's own internal DPCplus.arm routines and instead read the ones inside the games rom?

    This would make DPC+ developing much nicer for all the new games coming out, as we could track down issues much quicker.

  11. Posted · Edited by ScumSoft

    @batari I've tested with the DPCplus.arm in the DPC+ programming thread and it does the same thing.

     

    @Jrok, all the builds seem to be unstable and bounce the screen like crazy.

    Looking in stella your scanline count is fluctuating quite a bit, your not getting to a drawscreen in time.

  12. Posted · Edited by ScumSoft

    Using the Copy Data to Fetcher feature, and the fact that "bank 6" for it is the original DD ROM, you could do this:

    1) Copy the original, unmasked sprite image from DD ROM to DD RAM

    2) point 2 DataFetchers at the sprite in DD RAM

    3) Do a loop that reads using one of those DataFetchers, masks the value it read, and finally writes the masked value back out using the other DataFetcher.

    Good idea, this calls for some tests!

    I'll see if I can get something similar working.

     

    [edit]

    I've tried a few things, but during compile it names the player0 objects as player(randomID)_0 so I lose my pointer references.

    Otherwise this would update the player0 objects as needed:

     

     
Mask_P0
rem MASK PLAYER0
if player0x <= 17 then goto maskL
if player0x >= 153 then goto maskR
return

maskL
asm
lda #<(pointerplayer0)
sta DF0LOW
lda #>(pointerplayer0)
sta DF0HI
lda player0x
and #7
tay
ldx MaskDataL,y
.applymaskL
sax DF0WRITE
dec player0height
bne .applymaskL
end
return

maskR
asm
lda #<(pointerplayer0)
sta DF0LOW
lda #>(pointerplayer0)
sta DF0HI
lda player0x
and #7
tay
ldx MaskDataR,y
.applymaskR
sax DF0WRITE
dec player0height
bne .applymaskR
end
return

data MaskDataR
       %11111110
       %11111100
       %11111000
       %11110000
       %11100000
       %11000000
       %10000000
       %00000000
end

data MaskDataL 
       %01111111
       %00111111
       %00011111
       %00001111
       %00000111
       %00000011
       %00000001
       %00000000
end

  13. Posted · Edited by ScumSoft

    I've been trying to track down this bug myself. If you find what is really causing it let me know! Like I mentioned in the EggVenture thread, you shouldn't have to rewrite everything every frame, all this does is hide the corruption that's still occurring. I do believe there is a pointer running amuck unseen until it starts writing erroneous data into the Graphics bank. Those that are rewritten every frame stay alive so to speak, but the rest gets a screen wipe.

     

    Those streaks are the playfield, in my game you can fly into them and it causes the collision to register a hit with the PF.

  15. Posted · Edited by ScumSoft

    Seems to work just fine here on my Harmony cart. There is though a screen bouncing issue where you constantly walk into a closed castle gate and the screen shakes up and down. Not sure if this was intentional.

  16. Posted · Edited by ScumSoft

    I'll post the meaningful parts, but essentially what's being done is the data-fetchers are manually altering the bank 6 graphic data.

     

    ;----------------------------------------
; Bank 4 - Data Writer Demo
;----------------------------------------
; - this demo writes sprite data into the 4K Display Data Bank
; - the sprite data is masked to cause the sprite to smoothly
;   go on/off screen.  Normally the Atari sprites would wrap
;   around and show on both sides of the display
; - use joystick to move sprite around screen
; - hit FIRE to use DFxPUSH instead of DFxWRITE to udate
;   the Display Data. This causes the sprite to be upside down.
; - use LEFT DIFFICULT to control how fast the sprite moves
;----------------------------------------

     

    ; Mask Values for smooth on-off scrolling,
; 153 = 1 pixel off the right edge
; 154 = 2
; 155 = 3
; 156 = 4
; 157 = 5
; 158 = 6
; 159 = 7
; 160 = 8 pixels off the right edge
;
; 255 = 1 pixel off the left edge
; 254 = 2
; 253 = 3
; 252 = 4
; 251 = 5
; 250 = 6
; 249 = 7
; 248 - change to 160

MaskDataR:
.byte zzXXXXXXX_
.byte zzXXXXXX__
.byte zzXXXXX___
.byte zzXXXX____
.byte zzXXX_____
.byte zzXX______
.byte zzX_______
.byte zz________

MaskDataL:
.byte zz_XXXXXXX
.byte zz__XXXXXX
.byte zz___XXXXX
.byte zz____XXXX
.byte zz_____XXX
.byte zz______XX
.byte zz_______X
.byte zz________

     

    SetMask4:
lda #$FF
sta OnOffMask
lda FrostyX
cmp #153 ; 152
bcc CopyFrostyData4
cmp #161
bcc OffRightEdge4

OffLeftEdge4: ; Frosty's off the left edge so mask him
eor #$ff	; converts -1 thru -8 to +0 thru +7
tay
ldx FrostyDirection
bne FacingRight4
FacingLeft4:	
lda MaskDataL,y
sta OnOffMask
jmp CopyFrostyData4

OffRightEdge4: ; Frosty's off the right edge, so mask him
sec
sbc #153
tay
ldx FrostyDirection
bne FacingLeft4
FacingRight4:	
lda MaskDataR,y
sta OnOffMask

     

    ; copy Frosty data, masking for smooth on/off if required and flipping
; image if firebutton was down
CopyFrostyData4:	
; read graphics from 0
lda #<FrostyGraphic0
sta DF0LOW
lda #>FrostyGraphic0
sta DF0HI
; read colors from 2
lda #<FrostyColors
sta DF2LOW
lda #>FrostyColors
sta DF2HI

lda FireDown
bne PrepPush4

PrepPush4:
; Fire button held down so we're prepping for PUSH
; push graphics via 1
lda #<(FrostyWrite + FrostyGraphic0Height)
sta DF1LOW
lda #>(FrostyWrite + FrostyGraphic0Height)
sta DF1HI

; push colors via 3
lda #<(ColorWrite + FrostyGraphic0Height)
sta DF3LOW
lda #>(ColorWrite + FrostyGraphic0Height)
sta DF3HI

Write4:	
ldx #FrostyGraphic0Height
WriteLoop4:
lda DF0DATA
and OnOffMask
pha
lda DF2DATA
ldy FireDown
bne PushData4
sta DF3WRITE	; fire button not down so using WRITE
pla
sta DF1WRITE
jmp EndOfLoop4
PushData4:
sta DF3PUSH	; fire button down so using PUSH
pla
sta DF1PUSH
EndOfLoop4:	
dex
bne WriteLoop4

     

     

    So what is happening is the pointers are pointed to where frosty resides in Bank6 ram, and then updated as needed, then rewritten from a non-altered frosty when he needs to be shown again.

     

    This can be done if we could access bank6 in ASM from bB, though I haven't tried doing such a thing yet.

  18. Posted · Edited by ScumSoft

    The demo manually masks the sprite data based on sprite location, so I don't think bB can do this right now without loading prefab'd masked sprites.

     

    I would also love to dynamically alter sprite data such as X = player sprite data index:

     

    player0[X] = $FF

     

    But I don't think anything like this is implemented right now.

  19. Posted · Edited by ScumSoft

    It's nice to wait for a finished dev kit. But having more people use the DPC+ beta right now helps discover and fix unknown bugs faster, they aren't all going to be discovered by batari, he NEEDS people to help find them :) and what better way to discover bugs than to design a game that pushes the DPC+ features.

     

    So I say jump in, get a little dirty and start DPC+ developing like the rest of us :D

    If you want some DPC+ code examples I am sure we can all provide a few.

  22. Posted

    Naming it Adventure III would be a bold move, as your game would then sequel Adventure 2600 classic.

     

    I'm not opposed to people using good names, but now there are some high expectations you need to live up to :D

    Demo is great so far, perhaps once the game is finished and polished up it will be worthy of that title. But for now, Epic Adventure is a good name.

    • Like 1

  24. Posted · Edited by ScumSoft

    I don't have a PAL console to do real hardware testing on, so I am in the dark here. Stella uses it's own DPC+ handlers which is why things seem to run almost perfect on it. The real DPC+ seems to reuse all the pointers for different aspects and overwrites them causing screen corruption. I'm looking into this issue today, so I'll see what I can find.

     

    Thanks for testing. I hope to have some major changes completed in the next release test.

  25. Posted

    Do any of the original atari programmers surface here and do new stuff? or have they almost all faded into the woodwork? I can understand them wanting to be anonymous so not to over-inflate the "ZOMG YOUR (insert name here), I love you!" posts.

    I think it would be REALLY neat to see what they can do with the modern toolkits.

     

    I grew up with classic consoles and love them, but I've never grown knowledgeable of the names in the industry. So forgive my ignorance when you toss out big names I don't recognize. I'll recognize the games, just not those responsible for them :) But I am a quick learner and am loving learning about the neat gaming history we have.

     

    I've watched the David Crane GDC speech and he seems a likable fellow. I've also seen a preview for "Once upon atari", so I have a face now for HSW.

     

    Aside from those two I know little to no one else responsible for the games I grew up playing.

    But don't feel bad for my ignorance, I will watch popular movies and have no idea who the actors are by name (I am learning them though) so this isn't isolated to just gaming history knowledge.

     

    With that, I don't have a personal favorite as I am just now getting introduced to them. But I will choose David Crane for now, since I like Pitfall and it was a part of my childhood favorites.

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...