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

  2. Posted

    11 hours ago, Stephen said:

    Wow.  This is why I need to not post after such long days at work.  Probably also explains why I have always been too dumb to play chess.

    It's still interesting to see original source code even if it's off topic. The labels and game variable names are so cryptic. I recall seeing coding style like that when I was interning for a company doing work on a VAX. :)

     

  3. Posted

    A few things that helped my video. I wrapped the video cable around a ferret core a few times and tucked it inside the 2600 case. I moved the Atari and CRT further away from my flat screen TV. The CRT itself was putting out some interference, so moving the Atari and cable around helped. I've noticed some of my light bulbs were RF noisy. Try turning off nearby lamps. Turn off any fans. Some of your electronics might be putting out radio noise.

    • Like 1

  5. Posted

    I'm not sure if this is of interest to anyone. Here's the bit layout of my discard pile. You can see why 4 decks fits perfectly in 26 bytes. It's not going to be possible to add more decks, because there's just not enough RAM. It's ASCII because lot of my documentation is in the code.

      

    ; Discard pile format:
;
;   Each byte contains 8 cards, so 1 bit per card. 26x8 = 208 cards or 4 decks.
;   Each nibble selects the deck and suit. Bits 0,1,2 of each nibble selects
;   the deck column. Bit 3 of each nibble selects the deck row.
;
;   Suit:           Spades  Hearts  Clubs   Diamonds
;   Column:         7,3     6,2     5,1     4,0
;
;   Bit values: 1 = discarded, 0 = in play
;
;                high nibble        low nibble
;   suits--->|  S | H | C | D  |  S | H | C | D  |
;   ---------|----|---|---|----|----|---|---|----|------
;   nibble-->|  3 | 2 | 1 | 0  |  3 | 2 | 1 | 0  |
;   byte|rank|  7 | 6 | 5 | 4  |  3 | 2 | 1 | 0  | index
;   ----|----|-----------------------------------|------
;     1    A |    |   |   |    |    |   |   |    |  0
;     2    2 |    |   |   |    |    |   |   |    |  1
;     3    3 |    |   |   |    |    |   |   |    |  2
;     4    4 |    |   |   |    |    |   |   |    |  3
;     5    5 |    |   |   |    |    |   |   |    |  4
;     6    6 |                 |                 |  5
;     7    7 |   Deck 1 (01)   |   Deck 0 (00)   |  6
;     8    8 |                 |                 |  7
;     9    9 |    |   |   |    |    |   |   |    |  8
;    10   10 |    |   |   |    |    |   |   |    |  9
;    11    J |    |   |   |    |    |   |   |    | 10
;    12    Q |    |   |   |    |    |   |   |    | 11
;    13    K |    |   |   |    |    |   |   |    | 12
;   ----|----|----+---+---+----+----+---+---+----|------
;    14    A |    |   |   |    |    |   |   |    | 13
;    15    2 |    |   |   |    |    |   |   |    | 14
;    16    3 |    |   |   |    |    |   |   |    | 15
;    17    4 |    |   |   |    |    |   |   |    | 16
;    18    5 |    |   |   |    |    |   |   |    | 17
;    19    6 |                 |                 | 18
;    20    7 |   Deck 3 (11)   |   Deck 2 (10)   | 19
;    21    8 |                 |                 | 20
;    22    9 |    |   |   |    |    |   |   |    | 21
;    23   10 |    |   |   |    |    |   |   |    | 22
;    24    J |    |   |   |    |    |   |   |    | 23
;    25    Q |    |   |   |    |    |   |   |    | 24
;    26    K |    |   |   |    |    |   |   |    | 25
;   ----|----|-----------------------------------|------
;   nibble-->|  3 | 2 | 1 | 0  |  3 | 2 | 1 | 0  |
;   ---------|----|---|---|----|----|---|---|----|------


     

    • Like 4

  6. Posted

    An update to let people know I'm still around. I freed up 387 bytes in the 3rd bank. I was painted into a corner and running out of space. Bank 3 is where the main game kernel was running. I realized I was relying too much on macros which bloated my codebase. I'm working on freeing up more. I'm also cleaning up all the messy variables, file organization, and sloppy inefficient subroutines.

     

    Also, the kernel to my Rampart inspired game is working very well even to my own surprise. It was the most difficult kernel I've worked on so far. It took months to get basic screen rendering working. I tried different designs until I got one that works. It's currently 4K, no bankswitching, no DPC. I have no idea if it's going to stay that way. I'd really like to release a 4K game at some point. That one is on pause while I work on Blackjack.

     

    No binaries yet. Both kernels aren't presentable at the moment. I need to fix Blackjack's rendering, because all the timings have been changed due to code running more efficiently. And my Rampart style game has no game logic. It's super basic, so it wouldn't look impressive at all. I'm at a point where I need to flesh out how this game is going to work, so I need to do some research. I'm not even settled on whether it's going to be real-time or turn based strategy.

     

    Development is going slow, because I don't have as much spare time as I used to. Although, that may change soon due to the virus situation.

    • Like 2

  7. Posted

    Your last episode got me thinking when you tried to use the Atari Jr switches while playing on Stella. How hard would it be to convert an Atari 2600 shell into a USB controller, so that the physical switches and joystick ports would work in Stella? Essentially, the 2600 would be gutted and converted into a PC game controller. Maybe if the innards of a real PC controller were taken out and wired it up inside the 2600 shell?

  12. Posted

    2 minutes ago, Mehridian Sanders said:

    I forgot how bad a game Raiders was.

     

    I don't think it was bad. It was one of my favorites back in the day. It just requires the manual to play. The 2600 was the only computer in our house throughout the 80's, so our expectations weren't very high. It kept me entertained for hours, since I was really into Indiana Jones as a kid.

    • Like 1

  13. Posted · Edited by azure

    I have question referring to the delay mentioned in the Stella Programmer's Guide:

    Quote

    NOTE : a delay of 400 microseconds is necessary between writing to this port and reading the TIA input ports.

     

    I'm assuming the 400 ms delay is due to how potentiometers work, so they require time to wait for the voltage to settle.

     

    But, if the 3rd column is read by the trigger button INPT4, can the 3rd column buttons ("3", "6", "9", "#") be read without a delay? Could that be a little optimization?

     

  14. Posted

    1 hour ago, SpiceWare said:

    Adding support to Stella for BUS Stuffing was one of the first things we did, you can run the RPG demo in the latest release of Stella:

    I guess I've been really out of the loop.

     

    1 hour ago, SpiceWare said:

    While we were figuring things out the spec for the BUS bankswitch scheme was under constant revision. I only kept RPG up to date with the changes, so if you want to check out the other bus stuffing demos you need to use a Harmony Cart or install Stella 5.0.0-pre6 or pre7. I'd like to eventually update the older demos to the current BUS spec, but it's a low priority.

     

    I did add a section for an eventual BUS tutorial in the Harmony/Melody club.  Do note that AtariAge will not produce games for sale that utilize BUS, and because of that my time is currently focused on the CDFJ tutorial followed by a DPC+ tutorial (though I'm not sure it makes sense to spend time on that as CDFJ supersedes DPC+).

    I didn't realize I needed a specific Stella version the last time I tried some of the demos. I think I got there by the search and didn't notice the 1st post. Oops. The NTSC version you linked now worked fine. I have a Harmony. I'll try the demo out on my two 4-switches and one Jr. I have a 6-switch, but it's not working right for even normal games.

     

  15. Posted

    7 hours ago, batari said:

    If we can get Bus stuffing working, though, that can produce screens that wouldn't be possible on a normal 2600 without special hardware. However, one could even argue here that such hardware was possible back in the day, as the prototype computer addon "the Graduate" used this technique.

    If I remember right, it was a minority of machines that don't work with bus stuffing? Does anyone have a solid idea on what the technical reason was or is it still a mystery?

     

    Also, why not implement bus stuffing in Stella and let developers opt to implement ROM releases? It would emulate the bus stuffing of a working machine. Then anyone could use it in Stella, but if they have a working 2600 and a Harmony or Uno cart they could play it on the real thing also.

  16. Posted

    I've avoided this topic for a while, because I like both design philosophies and it's a hot topic. However, I think maybe 4K game developers ought to consider proudly advertising their games as 4K and unassisted. Wear it like a badge of honor. I haven't been here as long as many of you, and I mostly read the threads and work on my stuff quietly in the background, but I like developing unassisted 6502 games. Galagon and Mappy are amazing accomplishments and inspiring. They're making this community greater because they're attracting attention from Youtube and blogs. They're certain to be drawing new people to the site. People who would have never seen the 4K unassisted games are seeing them because of Galagon and Mappy.

     

    And as for the ARM and co-processor development, I think it needs to go further. A lot further. Let's step on the gas and stuff a Core i9 in the cart. It'd be the first Atari game with it's own external power supply and cooling system. Pedal to the metal.

     

    I've also spent the last few years dreaming of a rebooted 2600 with a normal 6502 chip, 64K memory access, and extra lines to the cart for read/write and clock. All other components being the same. And maybe connect a 3rd button in the joystick port. That's what this is all about. Tinkering and seeing what can be done. This is a laboratory for crazy science experiments. Everyone should be having fun. These are video games after all. They're meant to be fun. We're not filing TPS reports here. If it's not fun, then I think expectations need adjusting. The 1980's are gone and will never come back. We will never again have a game store with all unassisted Atari titles.

    • Like 2

  17. Posted · Edited by azure

    I wasn't sure if and how Batari supports floats. Fixed point integer arithmetic was the old way of doing fast floating point arithmetic on machines without a math co-processor. I was searching for Batari and floats and found a thread talking about using a table lookup with pre-calculated velocities for implementing something similar. It might be conceptually simpler since you can just increment/decrement an index.

     

     

  18. Posted

    You could do it by calculating acceleration and deceleration using fixed point integers to implement fractional motion. In one of my prototypes, I use a byte to represent a fixed point integer. Acceleration gives a slippery feel, because the motion lags. I used 5 bits for the integer portion (0-31) and 3 bits for the fraction (0-7). 

    Bit format: 11111 . 111
ShipXVeloc

     

    If you want only the integer portion, shift right 3 times. 

    ShipXVelocity = ShipXVelocity / 8

     

    You can add fractions between 0.125 (1) to 0.875 (7). 

    ShipXVelocity = ShipXVelocity + 1

     

    Adding an integer 1 is: 

    ShipXVelocity = ShipXVelocity + (1 * 8)

     

    You can go with fewer bits for the fraction if you need more than 32 values for velocity, but that makes the acceleration more coarse grained. It can be extended to 2+ bytes if you want, but there's a performance penalty.

     

     

  19. Posted

    On 12/15/2019 at 2:21 PM, GoldLeader said:

    Even though I hated Intellivision back then, I Really liked certain M-Network games...Dark Cavern and Tron Deadly Discs absolutely rule!...

    I didn't have Dark Cavern back then, but have it now. It's such a great game. I also really liked Burger Time.

    • Like 1

  21. Posted

    22 hours ago, ZeroPage Homebrew said:

    I didn't know if people would want to watch the longer single game shows

     

    I think you could play Combat for 3 hours and we'd still watch. A big part of your show is the personality you put into it (and the personalities of your guests.) There is nothing else like it.

     

    I like shows that mix things up. Themed shows and segments make it more like a magazine. So far you've had these segments: general news and updates, new homebrews, homebrew replays, game hacks, Activision patch attempts, holiday themes, awards, and a few ad-hoc broadcasts. Single game long plays would be another segment. I usually put on the show when I work, so I'm not bored by long plays. You usually do news and updates on the first 20 minutes. You could expand on news for single game shows to balance things out. If the long play is too much for some, they can just watch the first half and then bounce.

    • Like 1

  25. Posted

    A quick update on what I'm working on. I don't have a binary this time.

     

    I spent several weeks on an experimental intermission kernel that didn't really pan out. I'll see later if I can reuse it for another game, because I like the strategy.

     

    I finished the intermission screen of the ship landing. Afterward, I took a step back from the code. Over the course of the last few weeks I thought about what could be done better. I came up with a bunch of things. Since this is my first game and I know considerably more about the peculiarities of the machine today than I did when I started, there's a bit of questionable code going back to my 1st version.

     

    I'm dealing with some design decisions that didn't account for an idle screen. The event flow has to handle being interrupted on the game screens and title screen. I'm working on a new design to redo the flow of game state. I'll be moving kernels around in the banks.

     

    The game was bouncing during screen transitions on real hardware, which wasn't showing up on Stella. That's fixed; however, I'm still trying to figure out a strange rendering problem on the play screen. When the dealer has 3 cards the screen expands in height (top and bottom margins). It renders normally when the dealer has any other number of cards. It doesn't happen in Stella--only real hardware. It resembles a timer issue, but that doesn't explain why the top margin expands upward. It's probably an amalgamation of bugs with the timer. It was not happening in older versions.

     

    I'm redoing parts of the game to free up more RAM. I can free up about 4 bytes by just being smarter with variables. I'm also redesigning my memory layout to formalize the reuse of temporary memory, because right now it's a bit of a hodgepodge. The layout will follow this format: 

    [global memory] [local memory] [stack memory]

    Local memory is local to the bank. For example, I have a block of memory (12 bytes) that's not being used efficiently. It's reserved for the graphics of the 2nd split hand. It's only used on one screen, so it should be made available for the other banks.

     

    I'm redoing the joystick and switch handling, because it's wasting 2 bytes. It reads the joystick in the vertical blank and then makes its joystick decision making in the overscan. It's all being moved to the overscan to avoid storing state.

     

    Finishing these changes will greatly expand what I can do with the features, because I'm a bit boxed in at the moment. I think I should spend some time analyzing the ROM usage as well.

    • Like 5
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...