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

azure

Members
 View Profile  See their activity

  • Content Count

    173

  • Joined

  • Last visited

Posts posted by azure

  9. Posted · Edited by azure

    First, are you using the very latest version? The most recent version(s) have improved debugger support for many different areas.

     

    I'm using the latest stable version.

     

    Stella 5.1.3
  Features: Sound Joystick Debugger Cheats
  Build 4152, using SDL 2.0.5 [x86_64]

     

    I get different results based on when and where I break into the code and whether or not the code gets stepped into. I wasn't seeing a pattern earlier, because some subroutines were disassembled and others weren't. It seems to work better if I let it step through the code and don't mess with manually changing the bank in the UI. Doing that gives weird results.

  10. Posted

    I'm using F8 bankswitching, which is working fine, but I have an issue with Stella when it's in debug mode. It's not showing the right labels for the 1st bank nor is it showing consistent disassembled source code. For example: if you have these banks:

     

    ; bank 0

    ORG $1000
    RORG $d000
    ; bank 1
    ORG $2000
    RORG $f000
    See attached images.
    It works fine when running from the 2nd bank, but switching to the 1st bank shows labels from 2nd bank. This is hampering testing, so is there is there a way make Stella show the right labels and disassembled source when it's running on the 1st bank?

     

    post-63102-0-26489000-1538530909.png

    post-63102-0-80412900-1538530919.png

  11. Posted

    Finally! A ROM of Choplifter! (after 3 other programmers attempted it)

     

    One of the things that keeps me digging through old threads is the lore of "Atari programming" particularly the trials and tribulations. Has anyone made a project out of curating all the fascinating homebrew stories?

     

    And it's not just the successfully released games, it's also the failures, the grandiose claims, the evolution of the algorithms, and the struggle to understand the platform. Documenting the notable failures might be embarrassing to some, but it's also an interesting part of the record.

    • Like 1

  14. Posted

    My only suggestion (as you mentioned above) would be the solid black and red suites for the cards. Would really like to see that.

     

    I don't think it's possible without going to a 2 line kernel or skipping frames, because there aren't enough cycles to alternate colors that fast. I think it's more important to stay with a higher resolution and avoid flicker, so I don't plan to implement suit colors.

  15. Posted · Edited by azure

    - Selecting 1- 4- 6- or 8-deck?

    In Vegas I've seen single deck, and I think the regular uses 6.

    Atlantic City used 8 decks.

    Keeping track of 6 or 8 decks may be too many cards to track.

    Single deck should be easy.

    I wanted to go with 8 decks, but I won't have enough RAM once I implement the remaining features. I would have to cut game play, which I really don't want to do. I track the dealt cards in a 26 byte data structure. One bit represents one unique card. Going to 6 or 8 decks would require another 26 bytes of RAM. I have 28 bytes free, so while it is technically possible now, I would still need to re-think (or combine) some of the other variables to reclaim more RAM. I've already been through a few rounds of optimizing for space, so I've done the easy optimizations.

     

    I'll revisit the 6 & 8 decks after I've implemented more features, but right now I consider it less important, because it doesn't affect the player's experience.

     

    I also have a plan to add an option to select the number of decks, so single deck play will be in the game.

     

     

    - Suggestion to add red / black suits.

    If the green/green is the playfield, you could use horizontal background red lines and offset the cards the height of the suit, and clear the playfield under the card suit and place the diamond and the heart over the red, and the spade and club over the black.

    (To me as a beginning programmer that sounds easier than mid-line background color updates, but maybe that technique is easier and it will keep the cards horizontal? Also there may be no cycles left to do any of this. That's okay too.)

     

    I can see this working technically, but I really like the horizontal layout. If I went with a staggered or vertical layout, it wouldn't resemble a blackjack table very much. Suits and colors don't matter in blackjack, so I figure it's not worth making compromises on the layout.

     

    I can't think of any way it's possible with the horizontal layout without introducing flicker or reduced vertical resolution. There aren't enough cycles, and I really don't want to introduce flicker. Flicker is a lot more annoying for fixed position sprites.

  17. Posted

    Blackjack Theta VIII

     

    You're an astronaut stranded on the planet Theta VIII living out the rest of your days in a hotel casino. There is no exit and Blackjack is your only entertainment.

     

    This game uses the joystick:

     

    Betting Screen
    • Up or Down to increase or decrease the bet
    • Left or Right to select bet amount
    • Fire starts a new game
    Game Screen
    • Up to stand
    • Down to hit
    • Fire starts a new game

    This game is still a work in progress, so this version is a beta. The core functionality is working, but I have plans for many more features including double down, surrender, insurance, splitting hands, difficulty modes, more graphics touches, and sound. My goals were accurate casino play and better graphics compared to Atari's Blackjack game.

     

    The current features are:

    • true 4 deck card game
    • dealt cards are tracked to prevent dealing duplicates
    • 6 on-screen cards
    • unlimited off-screen cards, which are tracked as a point total

     

    I'm running out of ROM space, so I'll have to increase the ROM size to 8K in the next version. I don't have enough space for the title screen, so I placed it into a separate demo.

     

    Let me know if you find any bugs or have any game play suggestions.

    BlackJackThetaVIII-beta-0-3.bin

    Title-beta-0-3.bin

    post-63102-0-90800000-1535254925_thumb.png

    post-63102-0-14253900-1535255049_thumb.png

    post-63102-0-00797100-1535255078_thumb.png

    post-63102-0-78723100-1535255084_thumb.png

    post-63102-0-96300100-1535255087_thumb.png

    post-63102-0-62321800-1535255090_thumb.png

    • Like 5

  18. Posted · Edited by azure

    So, I understand that when you draw to the screen during the visible portion, some shearing/distortion of objects can happen. I was wondering if there was more information as to when it would or would not happen, and any ways to avoid it (apart from the obvious of avoiding drawing to the screen during the visible portion).

     

    Artifacts happen when your kernel doesn't write to the graphics registers on time. When the beam is running across the visible part of the screen, the kernel has little time to do much else, because its busy shuffling data to the graphics registers.

     

    The kernel is like a passenger trying to catch a moving train. If you're late you've missed your chance, so your sprite doesn't get displayed. If you're on time it gets displayed. If you're early, it's okay in the simple case when you only have 2 sprites on the same line (e.g. Combat).

     

    However, if you're dynamically repeating sprites with NUSIZ0/NUSIZ1, such as using the 48 pixel trick, writing registers early doesn't work. Each write must occur precisely within a narrow window of time, because the kernel is playing a shell game with the GRP0 and GRP1 registers. That's the cost of using two sprite registers to simulate six sprites. This is why cycle counting matters so much. The timing of each write depends on which cycle count it lands on.

     

     

    It doesn't seem to happen e.g. when doing the updates to the screen for the 48 pixel sprite trick

     

    That's because the timing has already been worked out. If you insert a nop in the middle of the 48-pixel sprite algorithm, you'll see rendering artifacts, because it will shift the timing of the writes.

     

     

    nor does it seem to happen when changing the playfield registers for an asymmetric playfield

     

     

    It can happen with the playfield if the kernel is trying to do asymmetric playfields (e.g. Ms Pac-Man) and it gets the timing wrong. But, if your playfield remains static for the duration of a line (e.g. Combat), it's a set and forget situation. You can write the patterns early to PF0, PF1, PF2 at the start of the line while the beam is in the horizontal bank and then sleep for the rest of the line.

     

    I really recommend Andrew's tutorials. They get into specific details explaining how things work.

    • Like 1

  19. Posted

    I figured I over paid last year spending $100 on 2600A last year. I think now it was a fair price, because it was in absolutely pristine condition. It was a craigslist purchase, so no shipping & handling. The owner said he used it 3 or 4 times total and sat in storage since the 1980's. It came with a pristine copy of Combat and Pac-Man with manuals. No box unfortunately. I asked. Everything is spotless: manuals, carts, console, controllers, and power supply. The paddles move as smooth as silk. There's not a single spot, scratch, or blemish on any of it. It looks brand new, so I keep it wrapped up in plastic. I also have the original purchase receipt.

     

    It's my favorite. I won't ever sell it.

    • Like 1

  22. Posted · Edited by azure

    I had weird spray on stuff like that on my Sega Genesis. It was like black textured paint. I still don't really know what it was, but it completely covered the top half of the plastic shell. It was either a bad attempt to "mod" the console or an accident. On a whim, I soaked it in vinegar for several days. The stuff came off pretty easily on the tub. The rest came off with a tooth brush. I used Heinz cleaning vinegar, which is stronger than normal. How it looks now. Came across it cheap so figured I'd try to salvage it.

  25. Posted

    I bought a joystick from the Goodwill. The joystick wasn't working right, so I opened it up and found a broken tab on the stick's grommet. It looks very different from my other joysticks, so I'm wondering which model this is. There are no part numbers anywhere.

     

    https://imgur.com/a/9bMtJ

     

    Notes:

    • Atari branded joystick and D plug.
    • Grid contacts on the PCB.
    • No branding or part numbers on the PCB.
    • Rubber springs for joystick and button.
    • Solid plastic stick.
    • Sold plastic grommet screws on to the stick.

    Is it worth the effort fixing this? I could use the cable for another joystick though. My other joystick's wire has rip in the rubber cladding.

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...