RSA

Hi @scorpio_ny. I don't have them at hand right now but they are simple cabled ones, no bluetooth.

Edit 2: I found elsewhere that the Uno has a 5V power pin.

@TGB1718 Can you share more details or links? I don't have experience with arduinos or much on electronics but it seems like a good project. For the Atari side, I see that the Uno has 6 analog I/O pins. I suppose that covers the up, down, right, left directions plus triggers as per the schematics (ignoring paddles) but how do you provide the 5V line? For the USB input, it looks like the Uno has one USB port and it's for power. Is the USB HAT (hub) you mentioned meant to extend it to connect both a power supply and devices/controllers? Edit: the Uno has other power sources too. I wonder why you need the hub then.

I've been searching here and the internet in general without any luck. I've seen posts about using an 8bitdo Genesis receiver with an extra soldered wire for bluetooth controllers, but how about connecting USB cabled controllers to the Atari 8 bit? I have a couple of retro looking ones that I'd I'll Iike to connect to my 800XL. Any leads or ideas? Or is the market is too small for this specific need?

Ha, true. It's part of the fun, of course. But I'd still try to reuse existing code for speed of development, or at least look at examples to find out about any tricks or pitfalls I might not be aware of. Are you using pre-shifted copies of each animation frame to speed up the drawing? Or is it simply due to the large number of frames? For PoP or fighting games, sure, but other kinds of games can have a larger number of smaller animations, like platformers or shooters, and the technique needed is the same, right? Assuming the sprites move around freely, or else the code can be further optimized to restricted forms of animation. Nice pointer, will look into it. Thanks @rensoup.

Ha, yes. Unless we draw on the TV screen with a sharpie ?! Yeah, apparently people have done it, and some of you have even survived it Thanks @popmilo for those insights. I did notice that needing 40 bytes per line wastes 16 bytes at the end of the 4K block, but using an address table for line starts as you mention takes care of that and also of the y multiplication by 40 (simpler than doing ASL by 3 and 2 more to achieve the same result). Drawing and animating on character sets is even more complicated. I did that to draw variable-width text on background tiles for the GameBoy 20+ years ago, but it wasn't animated. Your animations are impressive. Have you published the code for those examples?

I see, thanks. Many examples there. In https://github.com/tebe6502/Mad-Assembler/tree/master/examples/LIBRARIES/graphics/lib I see a procedure for plotting a single point and others to draw lines and circles using it. The plotter seems to use a precalculated table to access the y^th line in screen memory, which is what I had in mind to avoid multiplying y by 40 at runtime and jumping the 4K boundary. It seems a good starting point. To draw an image efficiently, of course, the logic would have to be smarter than calling plot for every pixel; it would have to draw each horizontal line inside it.

There are probably many titles using soft sprites in mode E when P/Ms are not enough. Considering that we have multiple pixels per byte, though, the logic needs shifting and masking, so it's not as simple to draw in assembly in this mode as with more modern hardware with 1+ bytes per pixel. One example is Prince of Persia 8-bit which combines both for wide animations (especially when jumping) with nice coloring. But I can't find any library available for doing this or even plotting dots or lines efficiently. I would rather avoid slow OS routines. Do folks really re-invent the wheel for their own games? Or are implementations too optimized for specific needs to be reusable? At least in PoP it seems that it's a classic case of animating images on top of the background with transparency. I don't see special cases at play there, so that code would be usable in general. I wanted to check before I go ahead and write my own 6502 implementation or try to reverse engineer the code from PoP 8-bit (or maybe from the Apple II code if it's close enough).

Thanks @zbyti for those examples and the documentation. From a first read, it looks like K65 is essentially a powerful assembler rather than what would be considered a traditional programming language (typically something more abstract and portable, like C). It has many features that make coding in assembly much more efficient. Have you found any limitations using it compared to other assemblers? I wonder if K65 should be regarded now as the main tool for coding directly on the 6502.

Volcanic eruption = Too much hot sauce in the sandwich? Reminds me of https://theoddbodsshow.fandom.com/wiki/Hotheads . Sounds like a fun idea for a game in any case. I do think there is a lot of value in throwing around ideas. As pointed out above, they are especially valuable when they are more than half baked and also realistic for the time and resource constraints. That is essentially the role of a game designer, which is a job on its own for a good reason.

Well, it's at least some plasma https://github.com/pfusik/numen/tree/master/tiplazma

Are there any games using TIP or GTIA 9++ or any other enhanced mode beyond the "hardware" ones? For instance, it sounds a bit cumbersome to draw things on TIP based on the docs and other comments (e.g. https://atariage.com/forums/topic/312618-large-memory-demosgames/?do=findComment&comment=4685732). I wonder what parts of Numen use TIP.

Doesn't Altirra run on Linux using Wine?

Pretty neat resources. Thanks @MrFish.

Does anyone have or know of a complete list of ANTIC/GTIA graphics modes, in one place, to help developers make the right choice for a particular project? One that includes not only the "originals" (as in http://gury.atari8.info/ref/graphics_modes.php for example) but also the special ones discovered over time such as APAC, HIP, RIP, TIP and whatever else. Ideally including which color registers are used, limitations, tips, and any other pros and cons of each mode.

How funny. Recently, when I realized I didn't have a clear enough game design in my mind while working in assembler, I started too playing around with pygame on PC so I could more quickly iterate on designs. But my goal is to then implement that in Atari with assembler. I haven't gone far enough this route to see how well this approach will work, but I'm hoping to get good results if I can put in the time.

Zaxxon: 22100 around my 10th game

Love the slimey character. The video made me think of Frogger. Maybe that could give some ideas on game goals, such as avoiding monsters just fill up a slime well.

Are you WillySoft? http://www.atarimania.com/game-atari-400-800-xl-xe-draconus-iv_1708.html

The big stores thought they were selling originals because they got these nicely produced tapes from Mexico. That's what they would tell me. But then around 1988 they realized they were pirated haha

Hola! Given how important Atari was in Chile and the outsize presence of Chileans in the community, it occurred to me to Google "Atari Chile" and found this thread I'm Chilean too, grew up in Santiago and had an Atari 2600 since 1984 and 800XL since 1986. Nothing defined my young years more than these machines. I migrated to Atlanta, US in 2005. Saludos! Raul

I see now, thanks. I just couldn't find it on github or by googling for it. Is there any public code repository online to look at current progress, history, and even contributing?

Altirra is a fenomenal piece of work. Even the reference manual is gold. Any chance of open sourcing the code?