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.