stella-emu / stella Goto Github PK
View Code? Open in Web Editor NEWA multi-platform Atari 2600 Emulator
Home Page: https://stella-emu.github.io
License: GNU General Public License v2.0
A multi-platform Atari 2600 Emulator
Home Page: https://stella-emu.github.io
License: GNU General Public License v2.0
At the bottom of the base P1 is displayed.
There is a RESP1 in this line. The first copy (there is only one) shouldn't show, but it does in the new core and Stellarator.
Yar's Revenge sometimes fails to start with exception "invalid width" being thrown. Sometimes this is caught in the ROM launcher and displayed, but sometimes the emulator outright crashes. Other times, the ROM starts for a second or two, only to crash a little later. This exception is thrown only in the Player class, so something is screwy there.
Note, this doesn't occur in Stellerator.
Probably a missing feature: The values in YStart have no effect (e.g. see Jammed).
Also, unrelated to the new core: Changing the Height property seems not to work anymore. E.g. see Acid Drop, the height is displayed is displayed as 210 (the same value for all games I checked) but the game displays ~260 lines. Changing the value doesn't change the display.
No idea why, but the text bar in Coke Zero moves down (actually it seems to start too high) a bit after a few seconds. This does not happen on real hardware.
Andrew Towers' notes describe special cases in retriggering the play sprites that are connected to the state of the start signal decoding logic. These are currently not accounted for by the 6502ts core. More investigation is required for proper emulation.
The recent addition of the PaddleReader class allows paddle games to work correctly. However, other games that use those inputs are now broken. In particular, ROMs using keypad controller (Alpha Beam with Ernie). Also, Compumate ROMs make extensive use of these registers, and the display isn't even showing up there.
I'm not sure if there's a bug in the PaddleReader class itself, or a difference in how the relevant parts of Stella now interact with the new code (in particular, Keyboard.cxx and CompuMate.cxx). I suspect the latter.
There is a slight displacement of the three tiny droids that count lives. Note that the leftmost droid is cut off in the middle.
The stars are all 1 pixel wide, while they are changing width between 0 (invisible), 1 and 2 pixel in the old core (and on real hardware too).
Also check the attached file which uses the same effect but with four objects. In the new core, all dots are 2 pixel wide (which looks very nice ;), while they alternate width (0..2 pixel) in the old one.
StarsEffect.zip
Same in Stellarator.
Note: Unrelated to new code (kill me, if I shouldn't post this here :))
Some mirror seem to be missing, e.g. trapreadm INPT4 does not catch INPT4|$30
I'm grouping these both together, since they both seem to be the same issue (and if I had to guess, related to player1).
In River Raid, after you play through to the first bridge and pass to the second screen, occasionally the 'house' on the left of the screen will jump horizontally.
In Frostbite, occasionally the ice-pans will jump in a similar fashion. When using debug colours, it is P1 in both cases.
Note that these also occur in 6502.ts.
The colon between minutes and seconds is corrupted. The right pixel is enabled and disabled ~1/3 cycle too early.
Super Challenge Football (1982) (Mattel).zip
The old NTSC/PAL autodetection isn't used, only the one from the new core. However, the new core autodetection is sometimes mistaking PAL for NTSC and vice-versa. The two need to be integrated, since the old way was working nearly 100%.
Between the old core and the new core, there is a (very) small speed difference. If you run e.g the title screen of Marble Craze in parallel on both cores (VSync enabled), you will find that pre2 is slightly faster. The difference is a bit more noticeable in the PAL version.
I don't think this is worth a fix, but maybe it can be used as an indicator for other differences.
In 6502.ts, timing is adjusted via cycles / second. In stella, timing is based on frames / second and needs correction for games with unorthodox frame timings.
Road Runner is highly sensitive to the timing details of HMOVE and will show Road Runner smeared over the whole width of the screen if timing is off (basically entering star field mode).
The 6502.ts core is written with Javascript JIT inlining in mind. The C++ implementation should be profiled and checked for possible performance gains through inlining.
I guess we can always force this to be PAL in the properties (once the new core honours using ROM properties), but I think it may be a bug in the new auto-detect code. In particular, the ROM has a scanline count of 324, which definitely means it should be PAL.
Crocodiles initially appear with a vertical line in their middle. This is a timing issue: hmove clock supression kicks in and gobbles the last pulse. As crocodiles are composed of two sprites, this leads to an initial displacement of both halves by one pixel. A fix is nontrivial and requires more research as timing is already highly constrained.
Pole position shows garbage at the left edge of the screen. I guess this is related to way 6502.ts is handling the missile and ball render counters during extended hblank.
The bottom text "START" changes to something like "SRM RT" as soon as you start entering the code (press
fire). No clue what is causing that.
Eshu has a testcase on AtariAge which exhibits a discrepancy between old and new core connected to a late write to NUSIZ.
This should be clarified on real hardware and, if applicable, fixed.
This test ROM should show combs for the columns, instead of straight edges. Attached is the ROM with a picture of the correct behaviour from the old Stella core.
In a level where the ice-pans separate (starts at level 4), they are not being positioned correctly. To see what I mean, look at the following snapshots in debug mode.
For the first one, I've paused and taken the snapshot just as the pans touch (which is where they should stop):
When I unpause, you can see that the pans continue to move together, and form a smaller pan than normal (they overlap, when they should just touch):
When the pans fully open, you can see that they aren't evenly spaced (there should be 6 small pans, all positioned equal distance from the next one):
The following two are snapshots from the old core, showing the proper behaviour:
P1 and M1 are affected; either one is moving too far to the left, or the other too far to the right (or both!).
In the old core, there is code that detects the maximum number of scanlines that can occur per frame, and essentially caps it; this is usually accompanied by completely blanking the screen. A few ROMs depend on having this properly emulated:
hectoByte.zip
In this ROM, it doesn't actually hit vsync at all, but it still runs on real hardware as well as the old core. Note the README that accompanies the ZIP file:
A VCS intro needs neither VSYNC nor proper interrupt vectors
The '342' scanlines you see with the old core are the result of capping (ie, this is maximum number of scanlines that can be shown in PAL mode).
Another related example, I think, is Q-Bert. When you press and hold reset, the scanline count goes very high, and as a result calculates a very low fps. This low fps is then fed into the sound subsystem, where is plays the sound very slowly. This isn't how the old core works; in the old core, these large-scanline frames are not used in the framerate calculation.
Finally, I think Quadrun has a related issue. When you press fire just after starting the ROM, the game should say 'quadrun, quadrun, quadrun'. This is happening with the very latest code, but it is running much too fast.
"The Lightbulb Lightens" ROM also exhibits a problem very similar to hectobyte.
Occasionally displays in PAL instead of NTSC and, if this happens, only one half of the title screen displays propely. Obviously, there is some sensitivity to the initial state here that the old core does not exhibit. Valgrind doesn't show anything, so is likely to be connected to the entropy injected into the initial machine state. Would be interesting to crosscheck with 6502.ts, but DPC(+) is currently not implemented there.
Positioning glitches in score display.
At the scoreboard, part of the left board, which is created by the 3rd copy of an 8 pixel wide missile (6 pixel hidden behind PF) is one pixel to narrow. It seems that the missile is positioned one pixel too far to the left.
The positioning is done with RESM0 ending at cycle 25.
@thrust26 has a testcase on http://atariage.com/forums/topic/259633-testing-the-new-stella-tia-core/?p=3644886 that displays garbage on the left edge of the screen (its even worse in the old core).
The dice in Yahtzee seem to be drawn at different lines (30 Hz flicker). One set is in the right place, and the other set is moved downwards. This also happens in Stellerator.
Note that the behaviour of this ROM is improved from the old core, where there was a die being drawn to the extreme left. So we have a fix and a regression :)
I believe the following wasn't an issue in pre2, so it must come from the last few commits. The house on the bottom-left is affected. These snapshots are in debug mode, so the issue can be seen more easily.
The first is from the old core, which I confirmed on real hardware is correct (specifically, the overhang of the roof is only one pixel):
This is from the most current commit (pre2 and later). There is some displacement, the overhang is two pixels, and there is now a hole in the roof:
For some strange reason, it seems the priority is incorrect too (although I can't be sure that's not an issue in the old core; the hole in the roof is the biggest problem).
The right two rods do flicker not together correctly.
Reason: The non-reflected copy displays 1 pixel too far left, the reflected copy 1 pixel too far right.
The attached test ROM illustrates how it can tell if it was run on an emulator or a real console. Obviously, the emulator should identify as a real console too.
emubug.zip
This bug is not related to the new core.
When you start a game from the Stella launcher and save a new high score on the SaveKey, go back to the launcher and start the same game again, the new high score is not loaded but the previous one. You have to go back to the launcher again and restart the game a 2nd time to get the new high score loaded.
This problem does not happen when you start a game directly (via command line) without the launcher.
Currently, RESMP tries to actually center the missile on the player, depending on player width. However, as eshu points out on AtariAge, this does not match the actual behavior of real hardware.
The positioning should be adjusted to precicely match real hardware (once I get my harmony cartridge).
Not sure what's the cause, but the positioning of P0 or P1 seems off by one pixel.
The rope is at the left of the crane in the new core, it should be on the right (+3 pixel). The code use RESMP0 to position the rope, so that's most likely the cause of the problem.
Same in Stellarator.
RSYNC is currently not implemented.
Topy has M1 displayed at the left edge of the screen in order to mask the HMOVE combs. The positioning of M1 depends on the interplay of the HMOVE movement clock and RESM1 and is highy sensitive to the timing of HMOVE. Any error there will result in the line being shifted by one pixel to the right.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.