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.

I found the original topic where Eckhard was discussing this. There are a few more posts after it that are relevant too: https://forums.atariage.com/topic/72308-hunchy-ii/?do=findComment&comment=903045 Here is a test rom I made years ago for an unreleased game. It auto-detects the HMOVE values at start up before you see the AA logo, but stops checking the values after that. After the AA logo it goes to a screen that displays the values found at power on. On that display screen the white blocks are both P1. The top block is positioned with a cycle 74 HMOVE using the values found at power on. The bottom block is positioned with a regular HMOVE. Pushing left on the joystick slows down the speed of the blocks, and eventually stops them. Ideally the blocks will always line up, but if not then you can at least see which positions they don't. DHmoveValues(rev2).zip

In above link it just goes to topic. Scroll down to a reply where I quote @Eckhard Stolberg

Here is a link I found: I remember going down a path of trying to dynamically find values that work. There was an issue doing that as the value required had a dependency on the position of the object. It would need exploring to see if that could be made to work, and then see if Movie Cart could be made to support it.

Do you mean an early HMOVE to go left by 8? Many PAL Atari Jr's and some PAL 7800's don't work with early HMOVE's.

I looked at the rom and it is clearly intentional and deliberate as the code inserts it into the graphics section when needed. I believe it is the spider spraying web silk at you. Agree that the manual makes no mention of it and it probably should have. If you really don't like it just zero out the two bytes noted in the picture below.

@Thomas Jentzsch just wanted to mention you could save a byte in your code by using an ASL on the first AND, and adjusting the AND and CMP operands that follow. That will reduce it to 25 bytes same cycles. .doInc inc frameCounter lda frameCounter cmp #%01010011 ; 83 (1x) beq .doInc asl cmp #%0100110 ; 19, 147 (2x) beq .doInc and #%111110 cmp #%000110 ; 3, 35, 67... (8x) beq .doInc and #%1110 cmp #%1110 ; 7, 15, 23... (32x) beq .doInc For the updates that happen every frame I don't imagine you would need to check the framecounter at all unless I am missing something.

@Albert congratulations on the sale. Just wondering if the arrangement for AtariAge to provide homebrewers lunch by private jets every second Thursday will still be honored, and if you have been provided with a legit Atari employee number and badge!

Version 4 of the delay macros: DelayMacros(Ver4).zip I considered a few more sceranios. The first was moving the left over bytes ahead of the delay loop to try and deliberately force a page crossing, and then evaluate overall bytes needed. I also considered 3, 5, and 6 extra cycle delays in the loop. At that point the macro was pretty much unmanageable so I combined the main portions of the code for DELAY_X and DELAY_Y, and refactored it all. It is a lot cleaner now, and is easier to follow and maintain. Overall routine selection has increased for the better as many more instances of the delay got a byte or two shaved off. Code is still generic and will work on any 6502 system whether it's an 2600 or not.

Here is version 3 of the Delay Macros: DelayMacros(Ver3).zip This version does better byte optimization when page boundaries are involved. The algorithm continues to look for which routine saves the most bytes, but now a few more scenarios are considered. Overall the routine is essentially just a delay loop with some extra bytes outside of the loop to make up any remaining cycles. In version 3 a scenario of having the extra bytes before or after the loop is now considered, where as version 2 just had them after the loop. Allowing this new scenario potentially prevents the page boundary crossing from happening. Sometimes it uses less bytes when the delay loop does not have a page crossing, and sometimes it doesn't. Other times no matter where the routine goes a particular delay will always use the same amount of bytes (although the routines for page boundary and non-page boundary have to be different to make the same delay, obviously!). Therefore, a given delay has to have every scenario checked and total bytes considered to find the best solution. I've included an excel sheet to show the total bytes for all delays with and without page boundary crossings. The range of the algorithm is now 14 instead of 8, because that is where the routine takes its first branch to do a loop. It was very inefficient for byte usage when delays were less than 14. I'm not saying it is the most efficient routine for a 14 byte delay (it is general purpose after all), but it is hard to justify having a routine with a delay loop in it unless it does at least one loop. One more thing... If a page boundary is not encountered then the delay always takes 5-8 bytes which IMHO is not too bad. Only when a page boundary is encountered are 9 bytes occasionally needed. However, version 3 of the delay routines negates using some these 9 byte delays by finding other versions that work. I'm pretty happy with it overall.

Here is version 2 of the delay macros (DELAY_X and DELAY_Y): DelayMacros.h I woke up yesterday and realized it would be real easy to implement the alternate versions of the routine. All I had to do was produce each version of the routine for the desired delay and compare how many bytes each used. As simple as that sounds I had my face too far into the book and was going down rabbit holes of trying to recompare each routine based on certain delays, and if they crossed page boundaries which caused recursive checks. Just by running each routine to the end and then comparing the results eliminated all of that. I did wrap the routines into a loop though to condense the code. Summary of DELAY_X. DELAY_Y is similar of course: ; DELAY_X ; By Omegamatrix ; Version 2 (Aug 26, 2023) ; - Version 2 searches through versions of the delay routine to find ; which one uses the least bytes, and then chooses it. ; - Version 2 still follows all the critera from Version 1, listed in the summary below. ; ; Summary: ; - works for any delay from 8 to 1280 cycles ; - only uses 5-9 bytes ; - no illegal opcodes ; - immune to crossing page boundaries ; - does not affect the state of A,Y,SP, or V/B/D/I/C flags ; - always finishes with X=0, Zero flag set, and Negative flag clear