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

  4. Posted

    Got it I think, but I assume the maximum that can be copied at a time is 256 bytes? and that writing to PARAMETER increments a pointer for a DWORD load?

     

    Example

    lda #<TargetBuffer ;Bank 6
sta DF0LOW
lda #>TargetBuffer ;Bank 6
sta DF0HI

lda #<Source2Copy
sta PARAMETER ;byte pointer increments on write?
lda #>Source2Copy
sta PARAMETER 
lda #0 ;DataFetcher #0
sta PARAMETER 
lda #$FF ;256 bytes to copy max?
sta PARAMETER 
lda #1
sta CALLFUNCTION

  10. Posted

    Considering there aren't any more ORG addresses to fill in the remaining bytes, I use it at the end to pad out the unused bytes of Bank 6 and fill in the rest of the rom. This of course isn't representing an end all solution to rom padding, but it works and you don't have to keep adjusting your sizes as you use more of bank 6.

  11. Posted · Edited by ScumSoft

    Looking at the source just add the following at the end of the file to pad the rom out to 32K if you want:

    Padding ds ($1400 -*)

     

    I like what you've done :)

    Use bank 6 as screen ram and set the data fetchers to access a 2760 byte ScreenBuffer from it. Then you'll have a nice(er) bitmap engine far better than what I've come up with :D

     

    [edit]Almost forgot, I've compiled it here on this end with no issues and it runs on the Harmony cart just fine. Just use the latest DPC+.arm file which fixes the oddity that DataFetchers have on the real thing.

     

    INCBIN "DPC+.arm" works just fine as well.

  14. Posted · Edited by ScumSoft

    @stephena, I believe stella is working the way it should with the DPC+.

     

    The way I store my frameBuffer in bank 6 is in two 1152 byte arrays.

    ScreenRAM1 stores Frame1's data which is interwoven each byte with Frame2's data, which is stored in ScreenRAM2.

     

    Depending on which frame is being displayed I update P0pointer to hold the ScreenRAMx offsets which correspond with the players sprite position.

    The sprites next scanline position will be offset then by 6 bytes. In order to update the sprite in ScreenRAM space, I add 6 to the DFxLOW pointer and only update the HI pointer once the carry is set.

    Because I am constantly writing the DFxLOW pointer a few times before the HI pointer, the HI pointer is getting cleared on each LOW write.

     

    However this works just fine in Stella since it leaves the HI pointer intact like it should.

     

    @batari

    Your update doesn't seem to be working, I get the same error on the harmony.

    DrawSprite:
   lda P0pointer
   sta DF0LOW
   lda P0pointer+1
   sta DF0HI
   
   ldy #15
.GetByte
   lda (SPRpointer),Y ;SPRite pointer, updated elsewhere to point to current sprite.
   sta DF0WRITE
   ;Update to next Scanline
   ;Add 6 bytes
   lda P0pointer    ;Load current LOW pointer address
   clc
   adc #6           ;Add 6 to this
   sta P0pointer    ;Store new LOW pointer
   sta DF0LOW       ;Set DataFetcher LOW
     ;lda P0pointer+1 ;This was added to work around the HI clear issue
     ;sta DF0HI       ;-
   bcc .NegCarry    ;Carry set?
   inc P0pointer+1  ;Update DataFetcher HI +1
   lda P0pointer+1  ;Load new value
   sta DF0HI        ;Set DataFetcher HI
.NegCarry
   dey
   bpl .GetByte
   rts

  15. Posted · Edited by ScumSoft

    Okay I've figured out why LOW/HI works and yet the demo I posted doesn't.

     

    On the Harmony cart you cannot just update the LOW DataFetcher pointer over and over like I do before updating the HI on Carry set, both have to be written to consecutively in the LOW/HI order.

     

    So to patch this for now, I just rewrite the HI pointer after updating the LOW. This adds cycle overhead to my loops which update the sprites since I have to update the pointers to the next scanline in ScreenRAM space.

     

    But at least this mystery has been solved for now :D

     

    @batari, would this be correctable in a firmware update? I am guessing once DFxLOW is written to, the next write expects the HI value? I would much rather update the LOW pointer a few times and retain the HI pointer values till I need them updated, rather than having to write LOW/HI every time LOW needs updated.

  18. Posted

    Speaking of improvements to the 2600, the DPC+ is rather advanced for it as is, however I would love to see dedicated frame-buffer functions for bank 6, and data fetchers that can access all banks not just bank 6 as well. (can be done internally inside the DPC? without bothering the 6507?)

    This way you can do advanced tile mappings of the screen space and have the future DPC++ handle scrolling and masking of sprite data.

    But most of these functions are really just catering it to myself though :D I can probably still make it do these things with some custom ARM code.

  19. Posted · Edited by ScumSoft

    I believe this question falls in the realm of ARM programming, but can the DPC+ be told to work on the internals of bank6 while the CPU does other things?

    Such as rotate a region/entire screen buffer for smooth scrolling?

    I read somewhere around here that while ARM code is being ran, it sends NOP's to the 6507. But this would still finish in a reasonable amount of cycles correct? seeing as the ARM runs at around 70mhz.

     

    Sorry that I am filling this thread with my own questions and issues. Should I post these in my coding tricks thread and rename it to Coding Questions? :D

  20. Posted · Edited by ScumSoft

    Oh thats an odd issue, I just have a habit of setting HI then LOW with all my pointers.

    One Caveat noted! Thanks for the help as always.

     

    [edit]Out of curiosity, how did you manage to identify this being the problem? I'd love to advance my debugging abilities.

  21. Posted · Edited by ScumSoft

    I'm sure the method I use has been done before, but I'm not sure what it would be called.

    My kernal moves 6 columns of P0,P0,P0,P1,P1,P1 each 8 pixels apart back and forth between 2 frames, this way I can load unique graphics in each and it gives a 96x192 playfield where I can set each pixel if desired. It's not flicker blinds or the venetian blinds trick. The kernal is posted in the DPC+ programming thread if you want to see it.

     

    It could also do 32 characters, but not all in one frame. So 16 per frame across two frames at 50% flicker.

  22. Posted · Edited by ScumSoft

    Ok here is the source, I think the Harmony cart is relocating the ScreenRAM offsets.

    I can't watch the ram on the real thing so it's hard to tell how the pointers are behaving.

    It seems to index correctly going down till scanline 44, but then it wraps over to a different offset address.

     

    I am still working on a better way to calculate the pointer logic, so if it looks noobish, thats because it is :D

    DPCtest2.zip

  23. Posted · Edited by ScumSoft

    I got everything looking good in stella, but on the real harmony cart everything gets wonky. I think the pointers are addressing the wrong ram space.

     

    ;********************************
;   [*GRAPHICS ONLY* BANK 6]
;********************************
 ORG $6000
 RORG $0000   
ScreenRAM1:  ;***[1152 bytes]***
 ds 1152
ScreenRAM2:  ;***[1152 bytes]***
 ds 1152
Space ds 2816   ;-  
 ;BANK 6 100% full

     

    I have a pointer setup to access both ScreenRAMs and this works correct in stella, but on the real deal the graphics are restricted to the top of the screen and drawn out of order.

     

    What's going on? I'll check this thread after I wake up (bed time) so forgive me if there is a long delay in my reply.

    I believe all you need to know is that my pointers are set to index from $0000 to $0900, so unless the Harmony cart is placing this someplace else, it should work the same as stella.

     

    [edit]Almost forgot to mention that I make this demo draw random data(deliberately) with the joystick on my 96x192 pixel playfield.

    DPCtest5-2-11.zip

  24. Posted

    Darn I was hoping it wasn't going to be like this. Well what I wanted to do was parse a 2k table I store in another bank that holds index addresses to my framebuffer, which would realign the data linearly and simplify things. But if I have to switch banks to access the data and duplicate the parsing code, then it defeats the purpose of having this table in the first place.

     

    So I'll just sacrifice cycles and avoid the bankswitches for now. When I do bankswitch, your routines will come as a good reference.

     

    Thanks for the help :D

  25. Posted · Edited by ScumSoft

    Since I've switched over to using the DPC+ for now, I've run into a whole slew of new issues :D I mean fun challenges to overcome.

     

    How do I run a subroutine from another bank? I've looked around but don't understand the procedure.

     

    Switch banks then jump to routine you need? and to switch banks I have to just access the $1FFx slot the bank table has it set to?

    Does the bank start at the beginning, or does it continue on the same instruction count as when it was switched, e.g on PC#00E2 -> switch bank -> PC#00E2 ?

    Or will the PC reset to 00 and start at the top of the bank.

     

    I'm confused!

     

    [edit]Hmm found This Link which seems to have explained it pretty well.

     

    So if I wanted to access a 2k table from another bank, how would that work? Would I have to switch banks to read from it?

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...