DirtyHairy

Already thinking about this 😏

This update is for the original UnoCart firmware, not for the UCA firmware.

Wrong place or not, thanks for the feedback 😏

As a followup to @Dreammary misfortune: I retested multiple updates from SD between v16 -- v18 with downloads fresh from github, and it went without a hitch, so I think the update is safe to apply. However, this is just one sample, so until more people report success, a bit of caution might still be in order

Hm, I just checked the UnoCart source, it does the same as Stella --- watch for an access to 0x01FE, grab bit 5 and use that to select the bank. I also tested Decathlon and RobotTank, both work on the Uno. We'll find out soon enough, but I really think that this is all there is. I also remember that there was a discussion about that scheme and the related patent in 2600 dev forum a few years ago, and as a result we rewrote the implementation in Stella to its current form --- previously, it was a hack that relied on telling reads from writes iirc.

At least for the version of Stella running on the thing I have a meaningful (to me) name: rtstella

As @Thomas Jentzsch says, the bus transitions should be all correctly emulated by Stella at this point. This is definitely a requirement for some carts. Supercharger (for example) is especially finicky as it waits precisely five transitions between scheduling data (by accessing $F0XX) and writing it (by accessing the destination address).

Hm, yesterday I tested the flash via ACE from v17 without issues. Did you see the "update complete" screen? You can always recover with a ST-Link/v2 dongle --- check my first post in this thread for details.

You are the one doing the work, and you know better where your bottlenecks are, but I think this wait is an intrinsic problem. On linux, a scheduler quantum is about 100msec. If the scheduler preempts you and services another thread that's roughly the time you loose, which amounts to ~120000 6502 cycles (since each cycle is a bus access). In the best case, Stella can try to catch up by executing the missed cycles the next time it is scheduled, but that will not work reliably because of the limited speed the cartridge ROM can tolerate (the 770ns wait). It will only be able to execute some 1300000 cycles per second, which is just about 100000 cycles surplus per second on top of the 1200000 cycles that it has to do per second in order to achieve full speed. Catching up a single quantum may already take about one second, which is too much to maintain the illusion of steady full speed. If you miss more quanta during that time, then the "backlog" of cycles will keep growing, and you won't even achieve full speed on average. This is just an order-of-magnitude argument, the details depend on the scheduler, the other processes fighting for the same core, etc., but I think this issue must be addressed in order to get this approach working stable at full speed. In addition, Stella's current scheduling is not designed for this and likely will do a bad job.

Very cool, good job . If you are talking directly to the cartridge, I would assume you have hard real time requirements. If you miss too much time due to scheduling, you won't be able to catch up within the bounds imposed by the cartridge bus. Emulators usually deal with this by emulating a large timeslice as fast as possible and sleeping after that, but this approach requires you to emulate continuously. Stella's threaded model that we introduced for stable audio doesn't necessarily help with that either. Refactoring Stella (specifically the main loop), manually pinning threads to different cores and playing with preemption and scheduling might help a lot (if you haven't already done that). Ping me if you'd like some assistance.

Pitfall II cannot be dumped easily. The DPC contains sprite data in ROM, inaccessible via the VCS bus.

Long time no see 😏 I have release firmware v18. This brings a few updates to the emulated BIOS that fix Survival Island and probably other supercharger games. You can find the release on github. Have fun!

He said he was "pretty sure". I can only judge the technical side, but as part of the Stella team and one of the maintainers of the UnoCart firmware I can assure you: a menu-driven cart would have added considerable cost and complexity to the cart and / or the emulator setup. I should also add that I think that, given the technical constraints, the DIP switches are a perfectly reasonable compromise.

Oh, and a menu-driven multicart would present a challenge for the dumper. Basically, the dumper would have to know about the scheme, fully dump the cart and then run it in Stella. If the scheme is new, then Stella would have to be extended to support this scheme, too.

Cost, I'm pretty sure. With DIP switches you can just use run-of-the-mill ROMs / EEPROMs / whatever that tolerate the VCS bus levels and timings, wire a few address lines to the switches and be done. If you want a menu you need more fancy banking hardware in conjunction with custom 6507 code that draws and drives the menu and that triggers a bankswitch by accessing a hotspot. As @Thomas Jentzsch says, you also need to make sure that the hotspot is disabled for the ROMs that you "chainload" cannot accidentially trigger the same bankswitch. This requires more sophisticated hardware (clever discrete logic, an ASIC, CPLD, FGPA, MCU, whatever you prefer 😏) which is more expensive and requires additional development effort.

Whoa, this thread is as busy as a bee hive. To reiterate, because our point seems to get lost in translation every few pages: I accept that Atari is using GPLed software without compensation to create the 2600+, that's just what corporations do all the time, it is the cheapest way to get development done, and it is explicitly permitted by the license. What I don't like is the we're-dfferent-it's-all-for-the-fans vibe in their communication around the acquisition of AAge that people are trying to buy, despite them acting precisely like any other company building low-cost emulation hardware. If they cared about the community, I would at least expect credit to Stella in their communication, and a donation for using the project definitely would be appreciated. Imo they're milking their IP for profit and that's OK for me, but that's it --- don't try to sell it as anything else. As for any communication that might have happened with the Stella team during development, I would have promised to not give any details, and I won't. However, I can say that any communication would have been respectful and constructive. By the way, the same goes for Hyperkin during the development of the R77.

This is not true. Changing the license requires explicit permission permission from everybody who has contributed to the codebase, or removal of those pieces. With a project with a history so long as Stella's, this is simply not realistically possible. That said, to reiterate, as this seems to be implied by some comments: Atari's use of the GPL is technically perfectly valid as long as they point to the source and release their changes under the GPL once they ship, and I am not whining about it. What Thomas and me are pointing at is the obvious mismatch between the all-for-the-fans attitude that we perceive in their public communication regarding the acquisition of AAge and fact that they are neither mentioning Stella anywhere in their presales announcement nor contributing to the project.

I am not complaining about GPLed code being used in commercial products, I underlined multiple times that I accept this as a side product of the license. But this is business, and it has nothing to do with caring about the community that evolved around the products that the new Atari is trying to montetarize again. And that's the whole reason why I keep insisting on that issue: if there was anything other than business behind the motives of Atari, then I would expect them to act differently.

Sorry, that does not compute for me. I take pride in all the people in the community that enjoy using my work for free, as I intended. When it comes to companies that are using my work to increase their profit by selling it without having to pay: why should I be proud of that? I merely accept that as it is a byproduct of the license that I choose. I much rather had if they were paying us. And if they don't even publicly acknowledge that it is our work that is powering their product and earning them money, then I don't take pride, but offense.

Amen 😏 The only more even more reasonable alternative imo would be (not financially, but morally, if they indeed cared about the community as they claim): use Stella, give proper credits to it and provide financial appreciation of the effort that was invested into building it by making a donation to the project.

It is safe to say that Stella is one of the most accurate VCS emulators out there --- to my knowledge, Gopher2600 ans 6502.ts are the only other emulators that have the same level of accuracy. Stella and 6502.ts have soaked up countless hours of my work, and the level of quality of my work there is not different from the one I apply to professional work --- I am a professional software engineer. The only difference is that I am doing this work as a hobby in spare time, and that I give the result to the community for free. If I alone were to bill the hours invested into Stella alone as freelance work, that'd be easily a high 5-digit number, probably more, and I am just a contributor to the current core. The same goes for the other members of the Stella team (and in particular Stephen wo has invested much, much more over decades of maintenance), and for all other developers of high-quality open source software. Developing a similar emulator with the same level of quality from scratch would easily cost Atari several 100k, which would reduce the potential revenue of the project. That's the reason 😏

I can 100% confirm they are using Stella.

Afaik this is only the case for GPLv3, and Stella is GPLv2.

As long as they are not shipping the current situation (no acknowledgement, no source) is fine. Once they ship their product they will have to disclose that they are using Stella so that customers have access to the source, and any changes they may have made to Stella have to be equally disclosed and licensed under the GPL. The same goes for any other GPLed software that may be part of the firmware. I am pretty sure they are aware of this.

As a member of the Stella team, I am less than thrilled by this news. Atari is using Stella to power the 2600+, and they certainly ain't paying for it, and they aren't exactly upfront about what emulator is powering their product either. Now, I am not saying this because I want to complain, I licensed my code as GPL when I contributed it to Stella, they have every right to do so, but the point is that this is a company. They have a business plan, their goal is earning money, they won't give away anything for free if it can be monetarized and if they need resources they will try to get them as cheaply as possible. That's how companies have to work as part of our economic system, and I am fine with it. However, I absolutely don't like it when people try to whitewash this as idealism. Up to now I have been thinking about a community driven place that was about preservation, enthusiasm and passion. If I invest time I do it for myself and for the community. Now AtariAge is owned by Atari, and while I am happy for Al for this opportunity, the mere fact changes the game. Now, if I invest time I am at least partially giving it a company without getting anything back in compensation. While I wish this place all the best, I am almost sure that, sooner or later, the need for return-of-invest will seep through and change it.