Omegamatrix

Mine at Last! HAA HAA, MUAHAHAHA For me it was getting Scuba Diver to complete my boxed Zellers set. Loose is not hard but some of those boxes don't show up for years.

This makes me imagine adding more rows for multiplayer games. Be good for tournaments with 4 players competing. Crazy idea but it also makes me imagine having multiple types of games in susequent rows, like Pac-Man at the top, then a row for Mario Bros, then a row for Donkey Kong, etc... I don't know how it would work but seeing that all on one screen and independent games would be something special. Alternatively if you had multiple games (rows) on the screen then for one player action you could simply select the game you want and then start it while still seeing the other games. Nice for eye candy to see other game characters on the screen and you could also have an attract mode for those.

I've always liked Frogger. Really love seeing re-makes too! @splendidnut Do you enjoy writing in C more than ASM?

I'm very confident that the issue is simply with the setup routine. The desired result is P0 should be at 48, and P1 at 64. The original routine did this but by an incorrect method (HMOVE ending at cycle 66 instead of 3). Putting a WSYNC before the issue is only half the fix though. You have to adjust the routine so that it gets to the desired position by a normal HMOVE (ending on cycle 3). Doing that will allow the position to be consistent on both normal Atari's and the Faulty Kool-Aid Man TIA version. Change this: sta NUSIZ0 lda #$02 ;2 copies medium sta NUSIZ1 lda #$10 sta HMP0 lda #$00 sta HMP1 sta HMOVE ldx #15 wait_cnt dex bne wait_cnt sta HMCLR nop line0 To this: sta NUSIZ0 lda #$02 ;2 copies medium sta NUSIZ1 lda #$30 ; <--- Changed to LEFT 3 sta HMP0 lda #$20 ; <--- Changed to LEFT 2 sta HMP1 sta WSYNC ; <--- Added the STA WSYNC sta HMOVE ldx #15 wait_cnt dex bne wait_cnt sta HMCLR nop line0

Yes, you can make a PAL-60 rom and run it but the color signal would not work. I'm really hoping the system you get replicates the problem. Did you buy the Jr from the person who reported the problem? That would be ideal of course.

Thanks for the affirmation JetSetIlly. I wasn't sure anyone was pay attention when I kept pointing out that HMOVE at cycle 66 and linking it to what Eckhard was saying. The fix should be real easy. What I am more curious about at this point is not to do with the MovieCart, but rather if the full range of player position's 0-159 will always work on these consoles for cycle 73/74 HMOVE's. The ultimate check is running through a test rom that runs through setting a players postion (0-159) with a normal HMOVE, and then repositions it with a cycle 73/74 HMOVE. It is important to set the "previous" player position to do this test.

Do you mean a line of code in Stella or the MVC file? I just tried some of the MVC files and they crash in the debugger for me too and I would like to poke around. If it is a Stella change would you mind posting or sending me a windows 64 bit executable?

Firmware C looks like it has the same issue mentioned above of the HMOVE not starting on cycle 0 and ending on cycle 3. g0x2f: SET_DATA(0x20); EMULATE_DONE g0x30: SET_DATA(0xa9); // lda #$00 EMULATE_DONE g0x31: SET_DATA(0x00); EMULATE_DONE g0x32: SET_DATA(0x85); // sta HMP1 EMULATE_DONE g0x33: SET_DATA(0x21); EMULATE_DONE g0x34: SET_DATA(0x85); // sta HMOVE <----- Check what cycle this executes on. Looks like it starts on cycle 63 and ends on cylce 66. EMULATE_DONE g0x35: SET_DATA(0x2a); EMULATE_DONE g0x36: SET_DATA(0xa2); // ldx #15 EMULATE_DONE g0x37: SET_DATA(0x0f); EMULATE_DONE

I think we are on the same page. I am making a lot of assumptions here but it seems like the positioning of the players gets done one time during startup (at least for the title screen). After that the players position just get shifted +/- 8 pixels during the kernel. The original positioning does not seem like it is hitting HMOVE at the correct cycle which may in turn cause the position to be set up wrong. I hope that is it as it should be an easy fix. If it is still off by a few pixels after that then maybe the value for HMPx during the kernel needs to change as @SpiceWare was noting.

I looked at the startup routine for the Movie Cart in GitHub, and I think the issue is HMOVE is used after RESP0 and RESP1, but it has no WSYNC before it. I think the HMOVE is starting at cycle 63 and ending at cycle 66. main_start sei cld ldx #$FF txs ;zero memory lda #0 ClearMem sta 0,X dex bne ClearMem lda #1 sta VDELP1 lda #$CF sta PF0 lda #$33 sta PF1 lda #$CC sta PF2 nop sta RESP0 nop sta RESP1 lda #$06 ;3 copies medium sta NUSIZ0 lda #$02 ;2 copies medium sta NUSIZ1 lda #$10 sta HMP0 lda #$00 sta HMP1 sta HMOVE ; <---- Is this ending @66 ? ldx #15 wait_cnt dex bne wait_cnt sta HMCLR nop line0

I linked this earlier in the thread, but I'll post it here again as Eckhard has an explaination of the behaviour.

In theory it would, but first someone with a bad machine must be found.

In re-reading Eckhard's I am not sure now if graphics ever become garbled, and I am leaning towards the players graphics are just shifted to the wrong position. I have hope that this issue is solvable for the Movie Cart simply because the position of the player graphics will always be the same before the early HMOVE so it is deterministic.

Edit: bad information. I don't have any relevant pictures of the test failing.

It might be possible to fix the positions with auto-detection, but there might be a secondary issue with corrupt graphics even with proper positioning. The value to use has a dependency on the position of the object previously, so the auto-detection routine should be customized to position the the object as it would in the kernel leading up to the HMOVE. The corrupt graphics would need to be evaluated to see if it happens or not.