Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

cd-w

Members
 View Profile  See their activity

  • Content Count

    2,433

  • Joined

  • Last visited

  • Days Won

    2

Posts posted by cd-w

  2. Posted

    11 hours ago, Thomas Jentzsch said:

    But the overall conclusion is that you cannot replicate the Zeviouz kernel even theoretically using pure 6507 assembler.

     

    If the kernel is executed from RAM then self-modifying code could be used to achieve the same effect in pure 6507.   This would require a lot of RAM for a full screen display, and the cost of all the writes would be prohibitive.   However, if DCP/DPC+ is permitted then I believe it becomes feasible with pure 6507 assembler?

     

    For me, I'm comfortable using CDFJ and other techniques(e.g. bus stuffing)  to push the TIA to the limit :)

     

    Chris

    • Like 1

  5. Posted

    9 hours ago, Thomas Jentzsch said:

    Yes, it is similar. Boulder Dash uses three PF colors and a fixed black background color, Zeviouz uses two PF and two background colors for the mix. In both games the colors used are fixed per area/cave (Boulder Dash changes them for each cave). And they do not flicker.

     

    I didn't consider the similarity to Boubder Dash until now, but it is essentially the same technique.   I got the original idea from this thread, though it isn't actually necessary to flicker the colors - the scrolling also helps to blend the colors together.

     

    Chris

  8. Posted

    14 minutes ago, D Train said:

    congrats @cd-w!  I was checking out the show from work earlier today, and watching this was nuts.  You and @Nathan Strum have really outdone yourselves.   I was wondering, how many lines was the original source code and how long do you expect it to be when you've finished?  any idea of how *much* of the original code will remain when you're done?   fascinating project and tremendous result!

    It is difficult to compare lines because the 7800 version is 6502 assembly and the 2600 version is denser C code.    However, I translated around 7000 lines of code from the 7800 version into around 5000 lines in the 2600 version.   Approximately 50% of the logic from the 7800 version will remain in the final game.

     

    Chris

    • Like 1
    • Thanks 1

  9. Posted

    2 minutes ago, Clint Thompson said:

    I'm not sure which one I'm more blown away with, the sound/music that sounds amazing considering it matches the original sounds very well and is being produced on the 2600 or the graphics, which feels like an entirely different (more capable) console, maybe in an interlaced/scanline mode. The scrolling, flipping panels, speed at which the ship moves... really impressive stuff!

     

    The sounds come directly from the Atari 7800 version so I can't take credit for that, but I will take credit for the smooth scrolling and sprite engine!

     

    Chris

    • Like 2

  10. Posted

    39 minutes ago, ZeroPage Homebrew said:

    Thank you for making this game @cd-w! It was such an incredible surprise to turn it the 2600 on the stream and have the game be Zeviouz! Thank you for having us premiere it live on ZeroPage Homebrew, it's so much fun doing these types of reveals!

     

     

    Thanks for featuring Zeviouz on your show today!   I really enjoyed watching the big reveal, and seeing you and Arelan having fun with the game.   This is the reason that I write these games, so that others can enjoy playing them!

     

    Cheers,

    Chris

    • Like 6

  13. Posted

    Zeviouz for the Atari 2600 was unveiled today on Zero Page Homebrew channel - I highly recommend watching the show if you have not seen it already!

     

    Here is the binary version for everyone to playtest - it is around 80% complete, with the following features missing:

    1. Andor-Genesis Motherships.

    2. PAL60 support.

    3. High-score table.

    4. Atarivox support (not sure about including speech?).

    5. Attract mode.

    6. Two-Player Support (turn-based, not simultaneous).

     

    The game is a direct port from the 7800 source code, with lots of optimizations and tweaks to make it work on the 2600.    The main differences from the 7800 version are:

    1. The scrolling background uses the playfield instead of tiles.

    2. The sprites (by Nathan Strum) are based on the arcade version.

    3. The ground enemies are animated, e.g. buildings open-up to fire.

    4. The level layouts are modified to reduce flicker.

     

    Note that it is a CDFJ/ARM game and will only work on a recent version of Stella or a real Atari 2600 with a Harmony cart.  

     

    Let me know if you find any bugs, or have any suggestions!

     

    Chris

    zeviouz00_NTSC.bin

    • Like 35
    • Thanks 5

  16. Posted

    Two small requests for Stella:

     

    1) Is there any way to prevent Stella from toggling Pause when the window loses focus (on Linux with XFCE)?    When developing, I often slow down the emulation and use Pause to pinpoint the exact frame containing an issue.   The I click on the editor window, and annoyingly the emulator un-pauses and the issue is lost!

     

    2) It would be great if the emulation speed could be controlled via keypresses, so that you can easily speed up/slow down the emulation.   I am aware of the turbo mode, which is handy in some situations, but more fine control would be very useful.

     

    Thanks,

    Chris

  17. Posted · Edited by cd-w

    21 hours ago, SpiceWare said:

    One thing to be aware of is RAM_SINT references the RAM as signed integer values, which are 2 bytes in size, while the offsets of _BUF_JUMP1 and _BUF_JUMP1_EXIT are based on byte values.  So we must divide them by 2 when using RAM_SINT.

     

    Is that correct - signed int values are 4 bytes (32-bit) in length, while the jump addresses are 2 bytes (16 bits)? 

     

    EDIT: I see #define RAM_SINT ((unsigned short int*)DDR), so they are indeed 16 bit, but I'm still unsure why the /2 is needed?


    Chris

  18. Posted

    It is probably a power problem - the Harmony cart requires more power than a regular cart and this can cause problems when the PSU or voltage regulator is marginal.   Are you using the same power supply with each console?   If not, try swapping them around and seeing if that helps.    However, to fix it properly you will probably need to replace the voltage regulator and capacitors inside the Atari console:

     

    https://console5.com/store/atari-2600-total-refresh-tune-up-cap-kit-new-capacitors-and-more.html

     

    Chris

  19. Posted

    39 minutes ago, Dionoid said:

    Thanks for explaining the kernel code, Thomas! The RESP trick is on my 'have to look into'-list for a few months, and this helps understanding this cool little TIA quirk. I think it first appeared in Galaxian, right?

     

    Yes - I believe Galaxian was the first game to use the RESPx trick.   There is a great explanation in this thread.   The TIA notes by Andrew Towers also provide a lot of detail, but can be a little hard to follow.

     

    Chris

    • Like 1

  21. Posted · Edited by cd-w

    The screen rolls on real hardware because it is using 286 screen lines - it needs to be reduced to 262 lines for 60Hz NTSC.

     

    I have defined the following macros to get the timings accurate:

      

    VBLANKDELAY = 44               ; 60Hz - (37*76)/64 ~ 44
SCREENDELAY = 229             ; 60Hz - (192*76)/64 ~ 229
OVERDELAY   = 35                ; 60Hz - (30*76)/64 ~ 35

 

; Start Vertical Blank Macro
    MAC START_VBLANK
    ldx #2                      ; VSYNC enable
    sta WSYNC
    stx VSYNC
    sta WSYNC
    sta WSYNC
    ldx #0                      ; VSYNC disable
    sta WSYNC
    stx VSYNC
    ldx #VBLANKDELAY
    stx TIM64T                  ; Set VBlank Timer
    ENDM

 

; Wait for Vertical Blank End Macro
    MAC WAIT_VBLANK
.WaitVblank
    lda INTIM
    bne .WaitVblank
    sta VBLANK
    sta WSYNC                   ; [0]
    ENDM

 

; Start Screen Macro
    MAC START_SCREEN
    ldx #SCREENDELAY            ; [0] + 2
    stx TIM64T                  ; [2] + 3
    ENDM

 

; Wait for Screen End Macro
    MAC WAIT_SCREEN
.WaitFrame
    lda INTIM
    bne .WaitFrame
    ENDM

; Start Overscan Macro
    MAC START_OVERSCAN
    ldx #2
    ldy #OVERDELAY
    sta WSYNC                   ; [0]
    stx VBLANK                  ; [0] + 3
    sty TIM64T                  ; [3] + 3
    ENDM

 

; Wait for Overscan End Macro
    MAC WAIT_OVERSCAN
.WaitOverscan
    lda INTIM
    bne .WaitOverscan
    ENDM

     

    Then your main code can be done like:

      

    MainLoop:

  START_VBLANK

  ...

  WAIT_VBLANK

  START_SCREEN

  ...

  WAIT_SCREEN

  START_OVERSCAN

  ...

  WAIT_OVERSCAN

  jmp MainLoop


    Chris

    • Like 1
    • Thanks 1

  22. Posted · Edited by cd-w

    13 hours ago, Thomas Jentzsch said:

    If have fixed this in the new RC7 version attached to the first post. 

     

    0 bytes free! :) 

     

    Note: A PAL-60 version is now included too. But it may have slight timing problems. Please let me know if you notice any.

     

    Looking at the binary I can see a lot of NOP instructions at 0x2DF, and $00 values at 0xCE5 (NTSC version)?   The $00s are presumably used for sprite masking, but it looks like the NOPs could be replaced with something more compact?

     

    Chris

     

  23. Posted

    29 minutes ago, devwebcl said:

    I didn't notice that was released this game.

    Which level should I play to get the ending (rocket).

     

    It depends how many points you get:

    100,000 points = Small Rocket

    200,000 points = Large Rocket (Soyuz)

    500,000 points = Shuttle (Buran)


    Chris

    • Thanks 1

  24. Posted

    23 hours ago, stephena said:

    That's entirely possible.  It could just be a coincidence that the code works with the old driver.  My point is that there are too many unknowns at this point.  It may not be Stella at all, and it just as easily could be.

    I have no idea where to get it.  I guess that would come from @batari?  I don't believe it's open source, so I don't think we can even look at the driver code to see how it works?  Someone else that did active development on DPC+ would have to speak up.  Perhaps @SpiceWare or @cd-w??

     

    I think only Fred (batari) has the DPC+ source code - I reverse-engineered parts of it for CDFJ, but don't know the differences between the minor DPC+ revisions.

     

    Chris

    • Like 1
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...