#96 Loader detection
Just to prove I'm not completely dead, a patch to a)
detect when a loader is occuring (basically, two INs
within 100 tstates of each other with B being either
incremented or decremented) and b) run the emulator at
the maximum possible speed when a loader is in progress.
Caveat: any sound sychronisation will still occur, so
you'll probably need to turn sound off to see any
effects. This shouldn't be too hard to work round.
Possible extension to this patch: automatically start
the tape when a loader is detected, and stop it when
the end is detected.
It'll need a bit of tidying up before it's committed,
but I think it's basically functional. I've tested it
on some games (Ant Attack, ATF (notable as it
decrements B rather than increments it), Bomb Jack,
Bubble Bobble, Cobra (both Alkatraz and Speedlock
versions), Colossal Adventure (Jewels of Darkness
version), Elite, Exolon, Head over Heels, Joe Blade,
Midnight Resistance, Rainbow Islands, Skool Daze and
Star Control) and it seems to work on all of them, but
any more testing appreciated.
Related
Fastloading patch for Fuse
Logged In: YES
user_id=11017
It has struck me in the past that it would be possible to get the sounds system
to be run fast enough that the pitch just goes up when the speed is turned up.
I would have thought that auto starting the tape would be one of the most
useful things the patch could do as people often don't realise that you may need
to press play if a tzx hits a speedload block when auto-load tapes is on.
Logged In: YES
user_id=29214
Updated fastloading patch. Some changes:
* Add a delay on load detection to reduce spurious
detections (eg the standard interrupt routine, which reads
from 0xfefe then 0xfdfe).
* Add a (smaller) delay on end of loader detection:
increases fastloader speed by 50-100% as we never drop out
of "fast" mode.
* Tweak the timing event code to better handle fastloading.
* Add automatic starting of tape playing on loader detection.
Major problem:
* Adding automatic tape stopping breaks loading as we get
the pause at the end of blocks at the wrong time. Ideas for
how to fix this welcome.
Minor problems:
* Sound still pulls the rate down.
* Automatic tape start breaks tape traps, as the tape is
already playing when the trap hits.
* Sound still pulls rate down.
* T
Updated fastloading patch
Logged In: YES
user_id=29214
Another updated patch: sound automatically disabled when a
loader detected (allowing full speed) and an option to
control its use.
Problems that remain:
* No automatic tape stopping.
* No tape traps.
Updated fastloading patch (2)
Logged In: YES
user_id=29214
A little bit of thought (which Fred had probably already got
to) reveals that this patch is actually two things:
1. Loader detection to start/stop tape.
2. Full speed while tape loading.
I've just committed the actual "fastloading" bit of this
patch, so you now get (optional) full speed while the tape
is playing.
Logged In: YES
user_id=29214
Nothing new here; just an updated patch with just the loader
detection bits.
Logged In: YES
user_id=29214
OK, found the problem with auto-stopping the tape: when the
tape was stopped, any edge events were left in the event
queue. If the tape was then started again before that event
happened (only likely to happen with pauses, but guess
exactly what we were getting here), we would end up with two
active edge events on the stack and everything went at ~ 2x
the correct speed, obviously causing failure.
Simple (and correct) fix: remove all edge events from the
event queue when we stop the tape. We even have a function
for doing this already :-)
Result: all the loaders I've just tested this with (most of
those listed above) now work. The notable failure is ATF.
In other news, tape traps still don't work properly.
Logged In: YES
user_id=29214
OK, the problem with tape traps wasn't that they weren't
working, but just that the standard auto-loader snapshot (at
least the 48K one) started with PC = 0x056c, one byte after
the trap. Previously, this wouldn't have mattered as we
would hit the trap again quite soon, but now we
automatically start the tape and therefore don't execute
that code path again (until we hit another block, anyway).
Solved (for the 48K machine anyway; I haven't tested the
rest yet) by bumping PC back one in the auto-load snapshot.
I'll do this for the rest unless anyone tells me I'm doing
something stupid.
Logged In: YES
user_id=29214
OK, almost final version of this patch. Unchanged
functionally from the previous version, but tidies it up and
adds an option for it.
I'll commit this at the weekend unless somebody gives me a
convincing reason not to (I've also updated the autoload
snaps which needed doing).
Logged In: YES
user_id=29214
The "final" version of this patch has some problems in that
it doesn't work too well loader detection off. I've fixed
these up, but don't have time to produce an updated patch at
the moment. I'll try and get one uploaded tomorrow sometime.
Also to do: documentation.
Logged In: YES
user_id=29214
I've commited this. I'll open a bug with none failure cases.
At the moment, I'm getting various warnings/errors about
sound being re-enabled when it's already active (using
GTK+), which have started since Fred's patch to fix the SDL
problem... looks like more work needed there.