DirtyHairy

Yeah, I have not done an in-depth analysis, but the timing is different --- the retail has more scanlines delay between reading the rows of the matrix. This gives the cap more time to charge, hence the difference.

What Al_Nafuur says: large ROMs are split between RAM and flash. The Uno firmware currently lacks support for the banking scheme; I'll add it if I can get my hands on a test ROM. I also still have to release a v18 with Al_Nafuur's PR for UA banking.

Nailed the bug ? Here's an explanation for the curious. Paddle I/O on the 2600 works by polling a capacitor that is charged over the paddle pot. Once the charge on the cap hits a threshold the input flips, and the time between the beginning of the charge cycle and the trip point is used to determine the paddle position. The cap is connected to ground and discharged, and the next measurement cycle starts. The keyboard controllers work by configuring the PIA pins connected to the joystick as output. These are connected to the rows of the key matrix, and the cols are connected to the paddle I/Os (and the fire button). In order to read the controller the caps are discharged and the output is configured to select the desired row. The code then waits for some time (in order to give the caps time to charge) and then the inputs are read in order to determine whether the keys in the selected row have been pressed. This delay is important; if it is too small the caps will not charge long enough, and the readout will fail. Since version 5.0 Stella has been correctly emulating the charge buildup of the capacitor (the readout was more of a hack before that). In 5.0 the resistance of the resistors in the keyboard controller was 0Ohms, while it was changed to a finite value in 5.0.1. With the correct value in place the delay used by the Alpha Beam proto is too small, and the readout fails. However, what was missing from Stella was a simulation of the discharge of the cap; the charge was just set to zero. In reality discharging the cap needs time, and if you don't wait long enough a residual charge will be left. The residual charge allows the readout to succeed in Alpha Beam even if the delay is not long enough. Long story short: with a correct description of the discharge the proto works. So, emulation of analog input since Stella 5.0 *is* more precise, but it lacks a minor but crucial part.

Note that the amount of blurriness with aspect ratio correction enabled very much depends on your window size and resolution. If you run in fullscreen at a decent resolution there shouldn't be much to notice but, of course, tastes differ, and what is acceptable to someone might be totally irritating to someone else.

And now with a proper UI that works as a mobile app when you add it to the Android or iOS homescreen. Also, the emulator has moved to a github organization (in order to get a proper github.io domain). The new URLs are App: https://cloudpilot-emu.github.io/app Source: https://github.com/cloudpilot-emu/cloudpilot Web page: https://cloudpilot-emu.github.io

To my understanding but this trick works by shaping the TV signal using timed VSYNC and RSYNC writes. If we really wanted to emulate this we would have to simulate a good deal of the TV signal generation and decoding. I don't think we should go down that rabbit hole just for this purpose.

I don't have an affected 2600 to test, but that video looks weird. If this option makes a difference, then that means (barring a bug in Stella) that the ROM triggers HMOVE during the visible part of the scanline (either by strobing the register or by putting the chip into "starfield mode"). As a result, the sprite will receive less clocks, causing a shift. I fail to see how that can cause the effects seen on the video --- I'll have to investigate, maybe this is a bug.

Now with Palm m515 support (evidently, you need a m515 ROM to use it):

If the paddles work but jitter, then there is not much that can be done. The R77‘s paddle readout is crappy, and some consoles seem to be worse than others. Have you tried to adjust the dejitter settings?

And another release... touch controls got broken in 1.0.3, fixed in 1.0.4 https://github.com/6502ts/6502.ts/releases/tag/1.0.4

I have finally released an update of Stellerator embedded: https://github.com/6502ts/6502.ts/releases/tag/1.0.3 The main change is video output: it now supports high quality scaling, better phosphor emulation, TV emulation and scanlines . EDIT: Oh, and I am now loading the ROM via fetch instead of base64 encoding it in the example ?

I know you shouldn't feed the troll, but... what a reflected and qualified statement. Thanks for shitting on (not only) my work. The browser is an application platform like many others, and javascript applications have the advantage of being platform independent. If done well they run on mobile devices and desktops alike, they work offline, you can distribute them without bothering about the App Store and Apple's review policies, and they update without you ever having to do anything. If you worry about them going away, just download a copy --- and most of them are open source anyway. Of course, they have their drawbacks --- among other things they are slightly slower, and timing guarantees are weaker. If you don't like them, just don't use them.

And another follow up: acutally, we have a setting in Stella to switch the phase I was talking about to the other extreme (same width, positioned between two regular pulse). This option lurks on the "TIA" tab of the developer settings. If you check out the screenshot below, you can see that the result is pretty close to your Jrs. I'll open a ticket to investigate the phase of the players a bit more closely, but I don't think it makes much sense to invest more time in to more "accurate" emulation here. The behavior is unstable, and we already cover two "benchmark" cases. The exact shapes of the player starfield is a different issue, I want to investigate that one. However, that's potentially a lot of work as there are many combinations of GRPx and NUSIZ, so no estimates ?

Apart from the position right-of-centre this is pretty much what I would have expected. What is going on is that in "starfield mode" the sprite counters keep getting movement pulses from the HMOVE logic every four clocks in addition to their regular pulses every clock. The phase and shape of those two pulses depends on the TIA revision, temperature (and probably moon phase and karma ?). Depending on this the extra pulses are either not counted at all (same phase), gobble up a regular pulse (same width, positioned between two regular pulses) or generate extra counter increments. What Stella emulates is the case where they overlap exactly.

For reference: https://github.com/stella-emu/stella/issues/246 That one has a lot of screenshots and images of the differences between various TIA revisions for missiles in "starfield mode" and explains the issue. https://github.com/stella-emu/stella/issues/19 This is the original starfield issue. It is still open as the details of the player substructure are not emulated yet.

I think two things are going on here: 1. The starfield effect has a substructure that is not easily explained by the interaction of the sprite counters. This is emulated on a heuristic basis by Stelle for the missiles and ball (the different lengths of the dots on subsequent lines), but not for the players. I believe there is an issue for this somewhere 2. From looking at the debugger, it seems that the HMOVE logic is still in "starfield mode" when RESP0 / REPS1 are strobed, and HMOVE is only strobed after that. The result depends on the revision of the TIA chip and also the temperature of the chip. PAL and NTSC makes no difference --- both are Jr. chips which is the decisive point. It would be nice to have a data point on an older console.

The internet does not forget ? As it declares itself Freeware, I have added it to the post. rally.prc

I just laughed my arse off ? Awesome that it works at all. I guess javascript performance was not exactly top priority when they put together the firmware ? *blushes* Thanks alot! However, I am pretty sure I am quite mortal ?

This is not Atari-related, but as I am active on AAge and as there are enthusiasts for old platforms here, I figured I might post here, too: as a side project I have been working on an emulator for PalmOS (OS4 and earlier) devices that runs on the web. The emulator is based on the old open-source POSE emulator, refactored and compiled to run on a web browser. It runs on Chrome, Safari and Firefox, including Android and iOS. At this point, the emulator is fully working and emulates a Palm V. You can install your own PRC and PDB files into it, and state is saved continuously and restored when the web page reloads. You can also export session images and reload them at a later point. The frontend is very basic and quite ugly, but fully functional. In the future there will a prettier UI that mimics a native app on mobile devices, and I also plan on porting support for more devices from POSE --- at least the m515, and probably also the 3c and a few handspring devices. If you want to give it a spin, here are the links to the emulator and the source code and documentation. I have not mirrored any ROMs in my repository as the legal situation is not quite clear to me (some ROMs at least used to be distributed with POSE, but on propietary licensing terms), but it is not hard to find them on the web --- for example, this github repo contains the ROM images shipped with POSE. Oh, if you're running this on iOS, you might want to add the page to the homescreen; there is a new feature in Safari that might otherwise delete persistent data after a period of inactivity (not loading the page). Have fun, and please forgive the off-topic post!

Of course I recommend my own emulator, too Looking at it, I notice that the last release of the embedded version is from 2019. I am not doing much work on Stellerator at the moment, but have made considerable improvements to video output last year, including GPU-accelerated NTSC simulation. Iirc the embedded version in git already supports the new features, but I haven't documented them yet, that's why I haven't released. I'll see that I release a new build next week. One difference to Javatari is that Stellerator is a library that does not come with its own UI. The demo page with Flapping is a simple setup that you can copy and paste, but you could add more UI and interaction with the emulator if you like. If you need any assistance, just drop me a note.

Unifying the two codebases would definitely be useful. What we'd need to do is imo Set the code up such that Wifi, SD and GPIO assignment can be selected at build time Port the Makefiles for Linux and MacOS to the new codebase Port the ACE updater and add some sort of identification to make sure that people don't flash the wrong firmware on the wrong device (I am not sure whether this is really necessary though as the Pluscart doesn't have an SD slot for custom updates) ... However, I have too little spare time and too many projects, and the payoff in terms of less maintenance for the current firmware is much less than what would be needed to create a stable merged firmware, so I won't be starting this myself in the foreseeable future. I'll be happy to assist and contribute though if someone else starts out on this. If we want to do this we should also actively involve @electrotrains, @ZackAttack and @MacRorie in this discussion. In particular, I know that @ZackAttack is working on his own fork of the firmware which contains his version of bus stuffing (among other things). If we want to create a unified firmware we should try to integrate all features that are floating out there, otherwise we are just creating yet another fork. Regarding "standalone" builds for custom carts: I have done this in the past for @MacRorie, and the Unocart repo contains a version of the firmware that compiles into small drivers for the various banking schemes that can be concatenated with a ROM file in order to get a flashable image that runs the ROM directly from flash. There isn't support for many drivers yet, though, as I myself have no need for it and... too little spare time for too many projects

Sorry, I overlooked the conversation. Thanks, yeah, do a pull request, I'll integrate it.

Assume that a flash cell has something like 100000 good writes before it dies. Highscores are only a few kb, and a typical flash card in the R77 has a few GB free space that are used by the card's controller to arbitrate writes; that gives you another factor of at least 100000. So, as a rough estimate you can safely assume that you can save scores about 1E10 times --- that's more than seconds in an average human's lifespan. I think don't think you have to worry That said, it is as Stephen writes, you have to save manually, no scores are saved automatically.

Nice, so there is a 6502 emulator in Perl ? The nice thing here is that 6502.ts is a full-fledged VCS emulator, so the information is already there. I only need to add a proper API to extract them from the emulator during testing.

I have added a 'trap' method that allows to add assertions that are executed every time a trap condition is met: test('frame size is 312 lines / PAL', () => { let cyclesAtFrameStart = -1; runner .runTo('MainLoop') .trapAt('MainLoop', () => { if (cyclesAtFrameStart > 0) { assert.strictEqual(runner.getCpuCycles() - cyclesAtFrameStart, 312 * 76); } cyclesAtFrameStart = runner.getCpuCycles(); }) .runTo('MainLoop') .runTo('MainLoop'); }); The condition can be specified as a function instead of a label, which allows pretty much arbitrary conditions. The emulator has an event system, and events are emitted every time the bus is accessed. In principle, this allows to register handlers during testing that throw an Exception when an undesired access happens. Currently, this requires knowledge of the API of the underlying emulation components, but we can add a friendlier API for using those events on the runner. That's already possible. If you look at 'runUntil' in my first example, the first argument is a function. This function is executes after every instruction and can query arbitrary conditions. An example would be test('it takes 50 frames to count one second', () => { let frameNo = 1; runner .runTo('MainLoop') .writeMemoryAt('hours', 0) .writeMemoryAt('minutes', 0) .writeMemoryAt('seconds', 0) .writeMemoryAt('frames', 0) .trapAt('MainLoop', () => frameNo++) .runUntil(() => runner.readMemoryAt('seconds') === 1, 100 * 312 * 76); assert.strictEqual(frameNo, 50); }); Somehow I got the feeling that the examples are becoming a little bit contrieved ? I feel that I might have to develop a game (or collaborate with someone) in order to further develop this. An interesting possibility would be a small DSL for expressing assertions that would allow embedding assertions as comments into the code. The runtime could read the assertions from the DASM listing file and execute them whenever the line following the assertion is executed.