SvOlli

Would it be? What you do about audio? The big problem with RGBtoHDMI is that there is no way have audio in the HDMI data stream except for an external HDMI audio mixer.

I never coded a game. Just demos.

I can't offer code for games. But for my demos, the full source code is always available. Either as tarballs at https://xayax.net/ or in my git repo at https://git.h8u.de/Atari_2600_Prods. So I don't have any game logic there, but show some nice stuff that you can do with the hardware of the 2600.

There are four sprites that will be problematic: - the dragon with mouth open (22 lines) - the brige (being enlarged in hardware, and the C64 can only do "double", which I need to use as default) - the "torch" lighting up the dark mazes (32 lines) - the "signature" of Warren Robinett (96 lines) Right now I'm thinking about replacing the "Warren Robinett" sprite with PETSCII graphics (works fine, as it is static), for the other three, I don't need to have an instant answer. Everything else can just be a single sprite.

Yes, that idea also came to mind (sprites are 24x21). But still this needs to be implemented. It would be also nice to have no flickering any more (or at least, less). The missile sprites for the left and right barriers will be implemented using charset instead.

Because it's only a small piece in the puzzle. The project is intended to be released on a demo party in 2023 or 2024 (they have not decided, when the next will be). Once of the next things to code will be a sprite converter. Also I need to implement a parser for the full room data, not only the graphics. Edit: also as of now, I'm using self modifying code, to compensate for the lack of having STA (zp),X. Since I'd like to have it on the C64 as a ROM cart as well (8k or 16k), this is something that needs to be addressed as well.

I think I found a nice on the fly conversion routine. This screenshot is from VICE/x64 (note the READY. prompt). Bits are taken from VCS code using copy/paste, color is hardcoded as of now.

Neat! Do you plan to open source your efforts? I've got also building my own slightly enhanced 2600 on my todo list, and would take any shortcut available. No need reinventing the wheel more than necessary.

Damn, I missed the updates here... Well it will be not the first platform I want to port to, because you can just insert the 2600 cartridge in the 7800 and play "Adventure". I think, I'll go for the C64 and use a "converter" for the graphics data, so I can still use the original game data. In fact I'm going two ways right now. The C64 port is step 3. Step 1 is to strip down the original source code. I'm now at 229 bytes of unused ROM. This was done by removing the black/white option, which I'm sure no-one needs in 2022, as well as some unused code. I did some minor optimizations, for example the routines for collision detection were masking out the bits using AND instead of using the negative and overflow status bits. Step 2 will be an extended kingdom with (hopefully) an extra castle and labyrinth, while still using only 4k and also without changing any graphics. For me Adventure has to look exactly that way, duck-dragons included. This looks like a low hanging fruit compared to the C64 port. Then I want to go for the C64 port. C64 is rather good, since I can convert the playfield graphics to text mode graphics. 40 characters for width matches, for height, I can convert the 7 lines of data to a height of 3 characters each, giving me 21 lines of 25 lines available on the screen. Most of the sprites can be converted with no or minimal changes. The dragon is 22 lines high, while the C64 sprites are 21 lines high. The "easter-egg message" will be needed to split into more than one sprite, or changed completely.

It was some kind of tech demo that I saw once like more than ten years ago. I vaguely remember that did some rather nice stuff, displaying an animation, also remembering it being something like ship of the game Elite, but I might mix that up with something else.

I also might be wrong, but I think it was very similar to what Shadow did in his demo: using the 256 bytes as a framebuffer for 48x something graphics, rendering something from Elite. But it was already not new, when I started VCS coding in 2011.

I totally agree to that, except for the SARA chip, since everyone who uses RAM on a cartridge does not use the original SARA chip anymore, but a reimplementation without the limitation. You can even the latest Perifractic Retro recipes, even Atari branded carts don't do this. Maybe one could think about using the term "SARA+" for the ones that allow code execution. Nevertheless, I'm also outraged on bad sync stuff and hoping for an initialized system. I'm maintaining a collection of all scene demos released on the 2600. Stuff that only works in an emulator does not get included there. I always ask myself: don't they have any pride in their work?

I agree to that. There is no benefit from implementing the restrictions artificially. For the ones who want to code "historically correct", they can still take it into consideration. I did this with "Bang!" and it worked out well, when building a cartridge with an original SARA. There is at least one demoscene production. And I can remember seeing a techdemo done by Andrew Davie.

I'm using four tables, 256 bytes each: sinewave, color table, flash effect, decoded XAYAX logo for speed access. With some overlapping those can be wrestled down to 768 bytes, leaving 256 for the code running. It might be possible to overwrite some generation code after it's been used. But I'm not interested in optimizing the code that way, it was enough effort to shrink the code to 512 bytes. You've got the code, feel free. You're right. It was outstanding for it's time. But with the arrival of the SuperCharger (and makewav), the Magicard became somewhat obsolete as a tool for a hobbyist. Also, thanks for your details about the CBS carts. Very interesting to read, also realizing that emulation (Stella/Harmony/Uno2600) is a bit simplified, as with the SARA chip.

I'm pretty sure it isn't implemented in Stella. Also because other solutions mimicking the SARA chip, like the Harmony and Uno 2600, do not have this limitation. There calling into SARA RAM just works like the CommaVid (only less RAM). About other carts with RAM besides from the ones mentioned above (CBS comes to mind), testing will be rather problematic, because I haven't seen any option so far to run custom code on them.

It comes as a deal package: advantages with disadvantages. pro: 1k is the largest I've seen so far with "direct access" via STA. (SuperCharger offers 6k, but the way data is written to RAM is strange and definitely due to a simple hardware design.) pro: you can execute code in it (the original SARA chip does not allow that, it's too slow.) con: only 2k of ROM, no switching in/out of RAM, no ROM banks to choose from. Nope, because my code needs to reside in the ROM using the RAM for data. Also have you ever tried the CommaVid interface. Yes, it's better than nothing, but everything else is better than that CommaVid. If you want to type something in using the CommaVid interface, I suggest to go for the 32 byte demos implemented using my dipswitch board. See hard2632 for details. Those should be easy to type in, being only 32 bytes in size, and you might also skip the initialization code, since the hardware is already set up properly.

Back in the days, the CommaVid bankswitching has only been used in two carts. One is an implementation of Conway's Game of Life, the other one implements a very simple interface to type in your own code and run it. I used it, because instead of dumping tables into ROM, I can use the RAM to create those tables there. So without the CommaVid RAM, this same demo needed to be implemented in 1K of tables + ~256 bytes of code. And if you like 2600 demos, you might want to take a look at the Atari VCS section on pouet.

Hello everyone, just wanted to let you know that I released another 512 bytes demo. This time the focus is on getting a lot of raster splits while still displaying some logo (which hasn't been done before, as far as I can tell). The platform used is CommaVid, so I can pre-calculate some data. There is also a version running on SuperCharger available, but since RAM access there requires more effort, so that version is more that 512 bytes in size. It won a forth place in the 512 bytes compo competing with systems like Amiga and TIC80. The homepage of the demo is https://xayax.net/gar_nix/. You can also watch the demo in the browser thanks to Stellerator.

You might want to take a look at ISO by JAC! who does the same thing in a really nice way: https://www.pouet.net/prod.php?which=58044 This works with a lot of cartridges containing RAM like CommaVid and SuperCharger. It does NOT work with SARA aka SuperChip. I don't know about CBS, though. (They all work within microcontroller simulated bankswitching.)

Thanks for the kind words. On the web page, you'll also find some "behind the scenes" commentary. There it's also stated when SARA is used, and for what. That might help you finding examples. I still need to add photos of the "original SARA version" cartridge. Because a game is more complicated and you mostly have quite some corner cases to consider. While a demo part, once it's running, it's always running. Take the circular sprite multiplexer for example (the one in the C64 part): while that routine works quite well, but only if it's used like in the demo. If the sprites move more to the right or left, I'll get graphics errors. Also the list of sprites to display has to be sorted along with the additional data. While getting this done is doable, it's quite some work to do it well. And at some point, I just wanted to have it done. (The coding of that multiplexer took me 2 full weeks "after work" hacking and 4 failed attempts.) So I rather keep hacking on the hardware than on game logic. But I'm still keen on porting "Adventure" to a platform like the C64, or so. Or rather, to get the code in a way that it's easy to port to any platform running on a 6502.

@Ecernosoft I had some good experiences using SARA aka SuperChip for development. you can't put generated code in there for execution you can combine it with 4K as well as F8, F6, F4 bankswiching it "only" costs you 256 bytes of ROM per bank it's possible to build a cartridge using the original SARA chip for authenticity I did a demo running on a PAL 2600 using the SARA chip Webpage: https://xayax.net/bang!/ (contains source code as archive as well as version running using Stellarator) Sourcecode as repository: https://git.h8u.de/Atari_2600_Prods/bang/ Sourcecode might be interesting, since I'm using "bankjsr/bankjmp/bankrts"-macros to jump between banks.

There is something you might have missed: the dumper works without a 2600. So the PAL/NTSC does not matter for dumping. I was just asking because I'm using PAL 99% of the time, so buying an NTSC cart does not make much sense.

So, the dumper is implemented and committed. I can't test it with an original CBS cartridge, but I can tell you, what will happen as I've implemented it with the SuperChip cart: I'm doing a write of $FF to $F000. This will result in the value on the bus being $FF, if no-one writes to it. Since the write-port starts first, the $FF will be written to RAM, as they are one the bus and on-one else if pulling them low. When the read-port of the RAM is reached, the RAM already contains $FF. That is what I'd also write to the (E)PROM at that position, so it doesn't interfere, when (E)PROM and RAM are selected both at once.

Done. So what I learned: flathub updates the images when the flatpak-repo gets updated.

You might want to update the launcher screenshot on https://stella-emu.github.io/screenshots.html then, because there where all screenshots are taken from. I don't know if the images are linked directly on the flathub page, or if they are copied over during the build process, or if its something in between, though.