ScumSoft

I see, alright then. About the copy and fill functions, I didn't see those defined in the header.

I didn't know bB could do that pretty cool and much better than repetitive tables.

When RESPx is used only the last 2 copies are shown on the scanline RESPx was hit, so if there are no copies then there are none that get shown. So it only works in 2/3 copy modes.

I would just predefine sequences in a table and randomly select a starting position in that table.

Would it be possible to make the DataFetchers access more than just Bank 6?

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.

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

Just got home and gave it a test, everything looks good so far thanks for the update.

Very nice! Hopefully you can adapt this kernal for games and slap it into batari basic

@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

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

There was also mention of the DPC+ DataFetchers being set in a HI/LOW fashion causing pointer errors, however in my latest test program build the issue cropped back up and all the DataFetchers are set in a LOW/HI fashion. I'll post the source here that works fine in stella but not on the Harmony cart. DPCerror.zip

Very interesting, I'll definitely offload some things to the ARM now. I look forward to seeing your completed project.

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 I can probably still make it do these things with some custom ARM code.

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?

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.

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.

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 DPCtest2.zip

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

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

Since I've switched over to using the DPC+ for now, I've run into a whole slew of new issues 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?

Okay, I rewrote the display kernal to update in a linear fashion (needed to start thinking DPC+ style) and it looks correct now. However I still have that display corruption issue past scanline 190(stella counts vsync+vblank), so it starts on Playfield Scanline 153 to 192. This would place it at pointer offset #1836, so this is 468 bytes that aren't being parsed correctly. 00-DPCtest.zip

Not really, those extra cycles don't matter as that is all the drawing that needs done. Unless there is a way to cram more P0 and P1's into the scanline that would expand the drawing field. I do appreciate the assistance once again.