azure

Love seeing original code. We don't often get to see the programmer's original comments and variable naming.

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.

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.

Jordan Mechner talks about the technical challenges making Prince of Persia for the Apple II. Programmers doing game development, particularly on 1980s microcomputers, may also find it interesting.

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 | ; ---------|----|---|---|----|----|---|---|----|------

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.

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?

A port is going to be a full or nearly full rewrite. Some non-graphics routines could copied over such as simple utility subroutines, but if they rely on large data structures in RAM those will be a rewrite too.

That's when you're having fun.

That's why I use Google to search. Example: site:atariage.com/forums 2600 defender

The screen transition is incredible. Very SNES-like.

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.

I have question referring to the delay mentioned in the Stella Programmer's Guide: 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?

I guess I've been really out of the loop. 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.

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.

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.

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.

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.

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

I would make a little character sprite and make him be the one who is drinking. It's a player avatar I suppose. You could put the sprite in that section below the score.

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.

I haven't heard of this single 3-in-1 chip before. Has there been much research on it?

I caught the ZPH episode on this. I was thinking it would be more intense gameplay if there's an alarm claxon after the money is taken. I used to play Splinter Cell years ago and that would happen when you got spotted.

The bird chewed up the cable. I'd like to replace the cable without destroying a good set of paddles.