Mallard Games

What is the difference between Reflected Serial Output and Normal Serial Output on an asymmetrical playfield?

Are there any plans to provide a preorder option like the TurboGrafx-16 mini?

@SpiceWare How do you calculate the sleep value exactly, i tried every possible combination and why i try altering the playfield in the Stella debugger the bit's don't match what is expected.

You could have the back 9 holes be mirrors of the front 9 holes with a darker green color.

Atari 2600: Mallard Season - 120 min. I Ran - 55 min. Combat - 23 min. Adventure - 9 min.

Game is very difficult, that or I just stink. How do you get past the big red wall with no hole, I keep dying there?

@SpiceWareI can confirm at least based on my limited knowledge of using the Stella debugger that the rest are issues with the right side of pf2 which strangely enough is set to 0. Folder: https://www.dropbox.com/sh/lnzuzeszgsu6flz/AABLl2llKZjm8Z9pusrXeNRKa?dl=0

Thanks for all the help, especially the very helpful Stella debugger tutorial. I read it, and then practice using it by fixing all the inconsistent playfield data. Well most of it at least. The broken D, N with a hole in it, and Siamese AE seem having something to have to do with the missing pf2 data that the playfield editor didn't include. Unfortunately I was working on it for so long that it got very late so I wasn't able to check the last S and date. EDIT: Also thanks to everyone else who was very patient and helped me. I'm still learning the ropes so i'm sorry if I inadvertently frustrated you with my noobie problems. ?

Done but now my scanline count are wrong again at 231 scanlines. Also the right side is still not working as intended but, we'll get to that in time. The other issue is I think my playfield is bleeding cause there are extraneous playfield pixels. As always here is the latest build: Binary: https://www.dropbox.com/s/7oeq13x9vm1u32o/duckgame.bin?dl=1 Listing: https://www.dropbox.com/s/f71kdboquxq0zdh/duckgame.txt?dl=1 Source: https://www.dropbox.com/s/j2hdupudxsfdnmm/source.asm?dl=1

Almost there: I'm using Junkosoft's Playfield Editor which generates 64 bytes of playfield data. I pad the top and bottom of that data with .byte %00000000 .byte %00000000 .byte %00000000 .byte %00000000 .byte %00000000 .byte %00000000 .byte %00000000 .byte %00000000 .byte %00000000 .byte %00000000 .byte %00000000 .byte %00000000 .byte %00000000 .byte %00000000 .byte %00000000 .byte %00000000 to get to 96 bytes of playfield data per pfx. The editor for whatever reason doesn't generate pf2 data for the right side. Seems I am having a lot of issues with this playfield editor. Can anyone recommend any other ones that I won't have as many issues getting the generated code to work? Binrary: https://www.dropbox.com/s/03uebn0n96qnv6z/duckgame.bin?dl=1 Listing: https://www.dropbox.com/s/z1ojdff8p0ecxgn/duckgame.txt?dl=1 Source: https://www.dropbox.com/s/an5p9rjsexxap9k/source.asm?dl=1

Here's the Bankswitch.h header sorry about that. ☹️ Sooooo close, the right side of the playfield is still borked despite removing the extra loop and PF2 call. The loop at the end was to bump the scanlines from 167 to 262 so this wouldn't happen: Notice anything weird? ?

Ok, i added align 256 every 192 bytes(96 bytes * 2 tables) and the problem still persists. I'm running out of ideas. ? Source: https://www.dropbox.com/s/f9blrfgalukm4ax/source.asm?dl=1 Listing: https://www.dropbox.com/s/nsxgenzca72ff93/duckgame.txt?dl=1 Binary: https://www.dropbox.com/s/61o9wc6dy2rl2w4/duckgame.bin?dl=1

Here is my title screen loop: TitleScreenLoop jsr VerticalSync ; perform vertical sync jsr CheckJoystick ; check for joystick input jsr TitleScreen_Kernal ; jump to title screen kernal jsr OverScan ; (3 13) jump to OverScan Routine jmp TitleScreenLoop Well here's the code that I'm using for the title screen kernal to draw the playfield: TitleScreen_Kernal WaitForVblankEnd_TitleScreen bit TIMINT ; load timer... bpl WaitForVblankEnd_TitleScreen ; killing time if the timer's not yet zero ldy #96 ; Y is going to hold how many lines we have to do ; ...we're going to count scanlines here. theoretically ; since this example is ass simple, we could just repeat ; the timer trick, but often its important to know ; just what scan line we're at. sta WSYNC ; We do a WSYNC just before that so we don't turn on sta VBLANK ; End the VBLANK period with the zero ;*********************** Scan line Loop ScanLoop_TitleScreen sta WSYNC ; (3 3) Wait for the previous line to finish lda pf0dataleft,y ; (4 7) load left pf0 data into the acumulator sta PF0 ; (3 10) and store it lda pf1dataleft,y ; (4 14) load left pf1 data into the acumulator sta PF1 ; (3 17) and store it lda pf2dataleft,y ; (4 21) load left pf2 data into the acumulator sta PF2 ; (3 24) and store it sta PF2 ; (3 27) waste 3 cycles so subsequent writes do not affect left side lda pf0dataright,y ; (4 31) load right pf0 data into the acumulator sta PF0 ; (3 34) and store it lda pf1dataright,y ; (4 38) load right pf1 data into the acumulator sta PF1 ; (3 41) and store it lda pf2dataright,y ; (4 45) load right pf2 data into the acumulator sta PF2 ; (3 48) and store it (right PF2 MUST hit on cycle 48 to avoid writing too soon or too late) ldx #5 EmptyLoop dex bne EmptyLoop dey ; (2 50) subtract one off the line counter thingy bne ScanLoop_TitleScreen ; (2/3 52/53) and repeat if we're not finished with all the scanlines. rts The only literal change I made was these 3 instructions to pad the scanline out to 262. ldx #5 EmptyLoop dex bne EmptyLoop Which is past when the playfield writes are happening anyways.

So I should probably work on trying to get my scanlines from 270 to 262 for the game screen.

What happens if when there's 270, cause my game frames are at 270 scanlines already and I haven't added collision checking or score display yet.

Nope, the issue is somewhere else: Hmmm..... will having 263 scanline instead of 262 have any effect on the playfield?

How do you format a 32gb cart to 8gb and can it be undone at a later time?

Actually the titlescreen playfield code was modified a bit by Nukey Shae for that exact reason. All I did was add an empty loop at the very bottom to get to 262 scanlines. Could I have fubared Nukey's code with my empty loop?

Thank you, the wait is killing me.

Any idea when it will be available for on Amazon? I am currently undecided on if I should wait for the 2019 model or getting the 2018 model for testing my homebrew.

Ok i fliped the data and added an empty loop like you suggested. The issue now is the playfield seems to be all scrambled, with some playfield bits "faded" to put in in words. Source: https://www.dropbox.com/s/r64fr0ymwjwbjp7/source.asm?dl=1 List: https://www.dropbox.com/s/15kim88ckmu65a3/duckgame.txt?dl=1 Binary: https://www.dropbox.com/s/bj4p9kqgeh7lool/duckgame.bin?dl=1

So Bill you never quite answered my question on whither there is going to be a 2019 edition of the portable.

Don't get me wrong, I'm not complaining and I absolutely love your product. I just wish we could have Stella considering we get the same exact emulator every year. Has the dev team considered updating their homegrown emulator this year?

Sooooooo close well beside the titlescreen being upside down and copied which I will fix once i find the correct playfield registers to modify and flip the playfield data, the issue now is I only have 167 scanlines of a frame. I know I'm only using 96 lines of playfield data but, I'm doing the same thing for the playfield for the "game state". what would be the cause of there only being 167 scanlines?

Most? I must of heard wrong then. I heard some games had control issues, others with sound and still other games have graphical glitches. I'm using the first original portable Flashback.