Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

833 Excellent


About DirtyHairy

  • Rank
  • Birthday 08/19/1980

Profile Information

  • Gender
  • Location
  • Interests
    Music, Guitar, Coding, Retrocomputing & Emulation, Computers & Technology in general, Books, Food, Family

Recent Profile Visitors

9,320 profile views
  1. 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.
  2. 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.
  3. Now with Palm m515 support (evidently, you need a m515 ROM to use it):
  4. 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?
  5. 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
  6. 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 😛
  7. DirtyHairy

    2XL emulator

    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.
  8. 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 😈
  9. 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.
  10. 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.
  11. 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.
  12. The internet does not forget 😏 As it declares itself Freeware, I have added it to the post. rally.prc
  13. 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 😛
  14. 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!
  15. 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.
  • Create New...