Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store

DirtyHairy

Members
 View Profile  See their activity

  • Posts

    873

  • Joined

  • Last visited

 Content Type 

Everything posted by DirtyHairy

  1. DirtyHairy
    I propably should resist the urge to answer, but here it goes anyway Mr. SQL, I am sorry to say, but most of your claims are half-truths at best, and much is simply wrong. With modern compilers, the speed of C++ written with performance in mind is virtually indistinguishable from that of hand-written assembly (and easily surpasses that of poorly written assembly), with the added benefits of portapability, readability and maintainability. There is almost no reason to directly code anything in assembly these days, with the exception of low-level OS bootstrapping code or software targetting highly constrained systems. The tearing issues you claim to observe on your system with your stuff are not the consequence of any mystical performance issue within Stella, but just vsync issues peculiar to your own particular video stack (OS - driver - window manager - SDL2 - Stella). In fact, I can run your stuff fine in Stella, 6502.ts and Javatari on my own system. You disprove your hypothesis of "mystical missing assembly optimizations" yourself by praising Javatari for rendering your stuff perfectly: like 6502.ts, Javatari is JITted Javascript (a dynamically typed, rubbery nightmare when it comes to performance) running on the browser API, with several layers between the code and the display hardware, and no hand-written assembly in sight. There is no CBS RAM bug, there just are differences in the treatment of uninitialized memory between the various emulators. If you come up with evidence that CBS RAM worked differently (like a failing historic cartridge) we can talk again, but without that, you are basically asking emulation authors to tailor their memory initialization to your own interpretation of how this piece of hardware might have acted in absence of proper initialization. The flashback is arguably not a new VCS iteration, but a modern, ARM-based handheld that runs a VCS emulator of mediocre accuracy and that is manufactured by a company that purchased the right to use the Atari brand from whatever entity that currently holds the right of the former company's brand assets. You have all right to be of different opinion, but you'll have a hard time convincing emulation authors to emulate the flaws and idiosyncracies of another emulator.
  2. DirtyHairy
    My bad, my second (borked) link points to the wrong issue. I meant to link https://github.com/stella-emu/stella/issues/36 , which also doesn't show the asymmetry I refer to Check out the last of Keatah's screenshots in the form post to see what I mean: http://atariage.com/forums/topic/259633-testing-the-new-stella-tia-core/page-2?do=findComment&comment=3651891 The second to colums are blockier than the left two columns, which was due to the missing emulation of a clocking glitch triggered by NUSIZ during decode. It is hard to tell for sure from your screenshot, but it seems to be off in the same way (can't test, I'm on linux). Considering the Pitfall and Double Dragon, those don't look like any edge cases (as in "deviations from Andrew Tower's notes" ) that I have encountered. If implemented correctly, under normal circumstances, a sprite never shows up on the line in which it has been positioned (the exception being multiple NUSIZ copies). However, the sprite counters get a two pixel offset if hit during hblank and a one pixel offset if hit during the very last cycles of an extended hblank (shifting the sprite to the left). I don't know what is going on at the low level there (and schematics make my eyes hurt ), but there are remnants of similar peculiarities during extended hblank in other edge cases, too. There is a chance that this may be connected to your issues. Testcases that come to mind are Jungle Hunt (a horizontal rift in the crocodiles as they appear on the left) and G.I. Joe (a hole in the roof of the house). Looking for slightly different issues, Topy and DK Junior are games that are very sensitive to HMOVE timing --- if those are glitched, I would suspect an issue related to RESx and HMOVE timing. No idea about Yar's revenge. As Spiceware says, DK Arcade makes very heave use of flicker, so there's likely nothing wrong there (unless you skip frames).
  3. DirtyHairy
    Nice work! The Meltdown screenshot looks to me like there is a asymmetry between the two columns to the right and those to the left. We've had the same issue with 6502.ts and the new Stella core, and improved modelling of NUSIZ during draw / decode fixed it --- you can find the corresponding bug with testcases and commits here: https://github.com/stella-emu/stella/issues/63 (and the original meltdown ticket with a less accurate fix here https://github.com/stella-emu/stella/issues/56). In general, if you like, if you're stumped on any aspects of TIA emulation, I'm happy to discuss those --- chances are that we've encountered and fixed the very same corner cases. On the other hand, of course, solving these riddles is part of the fun...
  4. DirtyHairy
    The commit you are behind is Stephen's merge request. Merging a branch into another will create a merge commit which has two ancestors and which updates all affected files to their merged versions.
  5. DirtyHairy
    I am a shell dweller, so I do not know how to do this with Xcode, but here's what you have to do on the CLI: 1) Add a remote that points to the upstream stella repo (a git repository can track and merge from arbitrarily many remote repositories): git remote add upstream git@github.com:stella-emu/stella.git You only have to do this once. 2) Fetch upstream changes git fetch upstream At this point, the upstream changes are avaiable locally, but they're not integrated into your own code yet. 3) Make sure that you are on the branch you want to merge the remote changes into (master I guess) git checkout master 4) Merge remote branch (usually master) into your own branch git merge upstream/master 5) Push the changes back into your own repo git push Github themselves has a pretty good documentation of these steps at https://help.github.com/articles/syncing-a-fork/
  6. DirtyHairy
    Forgot about that one, yep, Xcode (as most IDEs and editors) has native git support (github is only a particular hosting platform). In order to contribute back your changes, you'll have to create a github accout and fork the Stella repository (using the button in the upper right corner of the interface). You can then checkout your own fork and commit and push your changes there. Once you are ready, you do a pull request against the main repo (using the web gui) that then can be merged back.
  7. DirtyHairy
    Git has a very rich CLI interface with excellent documentation for each subcommand accessible via "--help" that I prefer to graphical frontends, but that comes down to personal taste I guess If you're looking for an OSX gui, there's sourcetree (https://www.sourcetreeapp.com/) which seems to be pretty good (most mac people at my workplace use it), and gitkraken (https://www.gitkraken.com/) also looks promising. If you're going for the CLI and have some time to spare, the official tutorial (https://git-scm.com/docs/gittutorial) should be more than enough to get you started. Actually, beyond first looks, git and svn are very different. In particular, Git is decentral. Each clone is a full-fledged copy of the cloned repo, and you can work and commit offline without restrictions. Git has a true branches and tags (which are just lazy copies in SVN) Changes are either "pushed" to the remote repository in batches, or you put your branch - either master (that's what SVN's trunk is) or a feature branch - for a pull request. The latter is the workflow advocated by github, and it offers a web interface for exactly that: you fork a repository, make your changes, either on master or on a feature branch, and then use the web interface to make a pull request. This workflow is what's described in the stella docu.
  8. DirtyHairy
    Didn't know about that, pretty interesting. To add yet another variant: 6502.ts does not try to detect the presence of SC RAM beforehand, but instead switches it on at runtime once the code tries to write it. I was a bit worried about sloppy code giving false positives when I implemented it this way, but I haven't encountered any issues since --- the constructor argument to fix the behavior is still unused
  9. DirtyHairy
    Just go ahead, fork it on Github and start committing, then we can satisfy our curiosity now ...just kidding, take your time, but I am looking forward to trying this stuff out, too
  10. DirtyHairy
    Almost. There are three aspects to TVMode (I refer to the quantities currently used by the code in this post ) * It is the result of the initial autodetection at startup (which subsequently determines PAL50/60 and friends): the emulation runs for 60 or so frames during which the value is detected, then it resets with the value fixed. The set of possible results of autodetection is precisely the value set of TVMode --- there is no more information that the TIA can determine. This is unchanged from Stella 4 (apart from the actual detection algorithm), but there the result was directly mapped to PAL50 or NTSC60 in the old code. So regardless of how we call it and how we represent it, this quantitiy exists and has meaning. * It determines frame height (unless configured manually or via ROM properties). My previous statement was a bit misleading here: it is ystart which is autodetected, not height. * It is a paramter that stabilizes ystart autodetection. Part of the confusion that there are two autodetected quantities, and they are autodetected at different points in the emulation lifecycle: TVmode is detected during startup, before anything is actually displayed, while ystart is detected during the first few visible frames. In many cases TVMode does not influence the detected ystart value, but we have seen enought fragile cases where it is relevant. From what I have seen, I think that leaving it out will leave too many loose ends for autodetection to work reliably. We both have seen such cases. Some are treated correctly, some fail initial autodetection (and need PAL50/60, NTSC50/60 or SECAM50/60 specified), some fail ystart autodetection (requiring ystart and possibly specified), and some fail both. We basically try to guess from the video signal what console the game was intented to run on, and if the signal is bad, autodetection becomes unreliable. There is no way to autodetect all ROMs correctly, and changing names won't help, either Regardless of how we call it, the information represented by TVMode will always be there, and not using it in autodetection would be waste. It is only truly irrelevant if all paramters (ystart, height and ConsoleTiming, now using the new term, are specified). The same holds true for PAL50/60 and friends, but I think ConsoleTiming offers less possibility for misunderstandings while representing the same information.
  11. DirtyHairy
    That's precisely what I had in mind (possible with other identifier names, but I am unsure about those myself). To rephrase it in my words and add a bit of lore about the new TIA core: FrameTiming ========== The quantities that define what parts of a frame are displayed (a frame basically is the period between two VSYNC cycles) are visible frame height ("height") and visible frame start ("ystart"), These can be autodetected or set (either manually or via ROM property). In case of autodetection, the selected FrameTiming (aka currently TVMode) defines a baseline from which autodetect starts (if this is wrong, autodetect might go funky in edge cases). FrameTiming itself can either be preset or autodetected from the total number of scanlines per frame (the stuff between two VSYNC cycles) when the console starts up. Basically, FrameTiming is something that parameterizes a simulated, very flexible TV set and usually is autodetected. It has no relevance outside the question "which scanlines are shown on screen". ConsoleTiming =========== This defines the TIA flavor and oscillator frequency used in the console --- either a PAL, NTSC or SECAM model. It is used to select the palette and the oscillator frequency. It cannot be autodetected, but it can be changed at runtime. PAL50/60 and friends =========== Those represent a specific frame layout on a specific console type. A game written for PAL60 should run on a PAL console and will generate a NTSCish frame layout. They all amount to selecting a specific combination of ConsoleTiming and FrameTiming (and the latter will usually be autodetected fine, just as an ordinary TV set will usually adapt to the signal within a tolerance window and display it). Does that make sense? Actually, after writing all this, I think I would prefer to use FrameLayout instead of FrameTiming EDIT: I think this also answers you question about the signifcance of FrameTiming: it defines a baseline for the frame detection algorithm. If ystart and height are set, it is irrelavant. ANOTHER EDIT: I forgot another, very important use for FrameTiming: if ConsoleTiming is not specified, the autodetected value of FrameTiming is used to set it
  12. DirtyHairy
    I agree, the situation is mildly confusing. Actually, the name TVMode is a leftover from 6502.ts where it denotes the console type, PAL, SECAM or NTSC. As such, in 6502.ts, it determines oscillator frequency and palette (the display code automatically adapts to the frame timing). In Stella, it just denotes the frame timing. Perhaps it makes sense to refactor things at some point: * Rename TVMode to FrameTiming * Replace Display->Format with a new enum that describes the console type: NTSC / PAL / SECAM and determines oscillator and palette. PAL50/60, NTSC50/60 and SECAM50/60 would just be the six different combinations of those two settings. Thinking of it, there is a minor bug in the new code: the simulation of the paddle readout circuit uses TVMode for determining the time base. This is slightly off for PAL60 & friends. I'll open a corresponding bug later.
  13. DirtyHairy
    I guess the easiest way would be to add myTia as a property to Cartridge and inject the TIA instance via setter after it has been constructed in Console. What do you think, Stephen?
  14. DirtyHairy
    Regarding test.bin: we have a closed bug for this one: https://github.com/stella-emu/stella/issues/58 . I did not test myself, but it seems that this now displays correctly.
  15. DirtyHairy
    Keatah, could you check the failing ROMs with pre4, too? There is an experimental RIOT change in pre5 that I guess is responsible for at least some of those.
  16. DirtyHairy
    These look pretty amazing, a real pity that my Jr. does not play well with bus stuffing Looking forward to the pull request, maybe I'll make an attempt to port BUS to 6502.ts
  17. DirtyHairy
    I am not currently tagging releases for 6502.ts (having a rolling release build at https://6502ts.github.io/stellerator/) and thus, I won't start a new release thread. Still, there has been a ton of improvements to 6502.ts since I originally started this thread. Most notably TIA emulation has evolved together with Stella and reflects the current state of Stella 5 Timers have been vastly improved; all RIOT-related bugs should be gone now CPU emulation has slightly improved, and many undocumented opcodes are now implemented I have implemented a few new bankswitch schemes, including supercharger There is a new experimentlal "merge frames" setting that reduces the frame rate pumped out by the emulator. I would be interested whether this option improves things if you are experiencing slowdowns on desktop grade machines As before, the emulator runs best on Chrome and Firefox. Edge and Safari work to varying degrees --- Edge reportedly only with WebGL disabled, and Safari may show have with importing and managing cartridges due to its broken IndexedDB implementation. If you'd like to report bugs, please include the build number at the bottom of the help page.
  18. DirtyHairy
    I can reproduce this in Stella 4, too. Note that, while the playfield vibrates up and down, the score stays fixed, so this is not a bug with frame start detection (as opposed to Marble Craze), but rather a ROM bug (it's a proto, after all ).
  19. DirtyHairy
    The glitch is a byproduct of the emulation of NUSIZ during player decode / draw. This aspect of TIA emulation is considerably improved over Stella 4 in pre-5, but there are still some corner cases that I have to investigate, emulating which will hopefully fix this for good.
  20. DirtyHairy
    Fixed in git
  21. DirtyHairy
    No, it doesn't. It is acting different from real hardware + the harmony cart, which is to be expected as the harmony runs initialization code before the payload is started. You must realize that, while there is a reference point you can compare the emulation of history CBS games to (you can just pull out Mountain King and compare), there is no hardware implementation of Defender III that would define how the game should look like. If RAM were initialized properly, the constraints imposed by historic hardware would be enough to determine the behavior, but as it is, the behavior is determined by the initial state of a nonexistent hardware implementation. An emulator is a model that tries to reproduce historic hardware faithfully. If you test the model outside the domain where behavior is fixed by the history hardware implementation, you are bound to get discrepancies. That said, a good emulator will still act as a sensible extrapolation of the historic hardware, but it will always stay an effective model.
  22. DirtyHairy
    RIOT at least is static (you can check the MOS 6532 datasheet). I don't know any details about the RAM used by CBS, but even if it were DRAM (which I doubt as it would have required CBS to include the necessary refresh circuitry), the initial state may depend on external factors and be nondeterministic, so I wouln't depend on any particular initial value there. At any rate, imho, the initial state of electrical components that do not have any well defined behavior on power on is not the domain of emulators.
  23. DirtyHairy
    I think that this an issue connected to the initial state of CBS and RIOT RAM (and thus propably not an emulation issue). In this case, testing on harmony won't get much closer to real hardware as CBS RAM is emulated there, too.
  24. DirtyHairy
    This suggests that the code relies on uninitialized values (CBS RAM, most likely) and is supported by the fact that running the game in 6502.ts/stellerator yield different results depending on the RNG seed involved. Note that the initial values of RAM (RIOT and CBS) should be considered undefined on startup, though real hardware acts predicatbly to some degree. Most emulators (inclduding Stella and 6502.ts) account for this by randomizing RAM contents, others just zero it. Also, unless you are replacing the ROM in an actual CBS cartridge, chances are that "real hardware" means "harmony cart" in this context, and this implies that the initial contents of the CBS RAM are determined by the ARM driver code running on the harmony's microcontroller, which I guess again differs from the behavior displayed by real hardware. Mr SQL, I think you may be missing some initialization code there --- this will cause the code to act predictably and allow you to fix this reliably
  25. DirtyHairy
    For the record: we've fixed this in Stella as well
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2023 AtariAge

×
×
  • Create New...