wavemotion-dave/GimliDS
1
Fork 0
mirror of https://github.com/wavemotion-dave/GimliDS.git synced 2025-06-18 13:55:32 -04:00
Code Issues Actions Packages Projects Releases Wiki Activity

Update README.md

Browse Source
This commit is contained in:
wavemotion-dave 2025-05-07 09:10:08 -04:00 committed by GitHub
parent 73b2e86c58
commit 99105f171f
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 19 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
README.md
View File

@ -87,6 +87,25 @@ Although primarily a disk-based emulator, GimliDS does support the more common C
This should cover a wide number of carts - recommend you seek out the OneLoad64 cart archive.
## Regarding Accuracy
Obviously the emulator is not perfect. It's doing what is known as 'line emulation' - meaning that it executes 1 line of CPU, 1 line of VIC graphics, 1 line of SID music, etc.
In the PAL world, there are 312 scanlines - of which 200+ are 'visible' on screen. This is fairly typical for my emulators - and many emulators in general. But it's not
perfectly accurate - as things can change mid-scanline. And for the C64, some cool effects can be done by careful timing of when certain peripherals (video, sound, etc) are accessed.
To that end - many games don't try to pull off these fancy tricks - and will play reasonably perfectly on the emulator.
But some games use these tricks to a lesser or greater extent. This can result in small graphical glitches (things like a flickering / unstable line near the top or bottom of the playfield) to more extensive 'garbage' on screen or poor audio/music output.
Until I can gain a better understanding and try to improve the emulation (without going FULL cycle-accurate which will cripple the emulation speed), there are some tricks we can pull to help. One of them is the 'CPU Adjustment' settings in the Configuration (set on a per game basis).
The one that is more interesting is the CPU CYCLES adjustment. This ranges from -9 cycles to +9 cycles with the default being +0 (no adjustment). This gives the C64 CPU extra cycles to play with on a per-scanline basis. As the beam races down the screen, the CPU and the VIC/SID can get slightly out of alignment... and making an adjustment can help. But be careful - too much adjustment and you're running "out of spec" and could crash the game.
How would this work... well, if you're not experiencing any weird graphical glitches, you should NOT touch the setting. But let's take Gauntlet which has a slight flicker/flash of the P2 'G' in the lower left of the screen. This kind of flicker is indicative of a timing issue. By pushing the CPU CYCLES adjustment to +2 or +3, the flickering lessens. If you push to +5 it goes away and the screen is nice and stable. You should adjust only as much as is needed to achieve the effect and NO more.
In general, if you have a scanline instability/flicker near the top of the screen, use slightly negative CPU adjustment values. If the glitch is towards the bottom of the screen... use a slightly positive adjustment value.
## Acknowledgements
* The opening jingle was done by DeNL and comes courtesy of the roalty free jingles at pixabay.