Jump to content

Omegamatrix

Members
  • Posts

    6,816
  • Joined

  • Last visited

  • Days Won

    2

Omegamatrix last won the day on November 15 2015

Omegamatrix had the most liked content!

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Canada
  • Interests
    Atari 2600 collecting, playing, programming
    Watching movies

Recent Profile Visitors

44,715 profile views

Omegamatrix's Achievements

Quadrunner

Quadrunner (9/9)

2.4k

Reputation

  1. 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?
  2. 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
  3. 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.
  4. 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
  5. I linked this earlier in the thread, but I'll post it here again as Eckhard has an explaination of the behaviour.
  6. In theory it would, but first someone with a bad machine must be found.
  7. 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.
  8. Edit: bad information. I don't have any relevant pictures of the test failing.
  9. 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.
  10. 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
  11. In above link it just goes to topic. Scroll down to a reply where I quote @Eckhard Stolberg
  12. 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.
  13. 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.
  14. 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.
  15. @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.
×
×
  • Create New...