| |
jab
Registered: Apr 2020
Posts: 20 |
Release id #247263 : Nightfall
There is a spot in the middle of the demo (before the isometric part) in which the loader often crashes on real floppy drives. Sorry about that, we ran out of time to debug. We will look into it after having recovered from the party :) |
|
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Never blame the loader until you really know it's the loader's fault. :) |
| |
jab
Registered: Apr 2020
Posts: 20 |
Krill:
Sorry again, my sentence was badly formed :) There is a spot in the demo where something causes the loader routine to hang: Execution doesn't return and the drive is left spinning. Powering down the drive returns from the routine with an error flag (this is indicated by the screen turning red).
...but we have already agreed that Frostbyte will contact you with more details, so I won't try going further into it here. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Ah no problem, that was just a general statement, and the post made before i even knew Nightfall uses that loader by yours truly. =)
Interesting problem, can't wait to see what's at the core of it! |
| |
hedning
Registered: Mar 2009
Posts: 4732 |
Oh. I was just about to transfer the top demos to disk here (yes, some of us do that still ;)). Guess I'll wait a while with this one then. |
| |
Flex
Registered: Feb 2002
Posts: 111 |
If you want to run "Nightfall" on your beloved 1541 drive, download the "fixed" version that is now available.
https://csdb.dk/release/download.php?id=303727 |
| |
mankeli
Registered: Oct 2010
Posts: 146 |
What was the problem? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Also: new entry pls |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting mankeliWhat was the problem? It was, in fact, a loader bug. Two, actually. Either one alone would most likely have gone unnoticed, but they colluded.
The first bug is what's fixed with that recent patch. Under certain circumstances, the r/w head could land on an unintended destination (half-)track after stepping, causing delays or lock-ups.
This is a regression introduced with at least v184, after the 1541 drivecode had undergone a massive overhaul (for speed gains, of course).
Now, normally the track-correction mechanism would fix such errors, making them transient.
But there lies the second bug, also introduced during that overhaul (or thereabouts) due to having to sacrifice some code for other code. (Damn you, mere 2K of drive RAM.)
In this instance, the head landed on a wrong (full-)track with another bit-rate than the intended one.
Read-errors abound, and track-correction mechanism is invoked.
It cycles through the 4 bit-rates until a block is read successfully, and if no such success, stepping down a half-track. Repeat until good.
Once a block is read successfully, but the track denoted in the block header is not the one the loader expects, step to actually desired track.
The problem here was that ALL block headers (normally coming with a header tag of GCR $52) were mis-read as GCR $55 (block data tag) due to a wrong bit-rate while bit-rate cycling, and thus the block-read routine got stuck, never finding an actual block header (but still getting SYNCs, so no timeouts).
In earlier revisions, there were exactly 2 tries to get a block header, and an error if those 2 tries were unsuccessful (because the expectation is to get block header and block data alternatingly), causing the track-correction mechanism to proceed until good.
With the aforementioned byte-saving, these 2 tries became a simple loop-until-fine, and that turned out to be a Bad Idea.
Now, trying to find those measly 3 bytes to get the old 2-tries method back. (And yes, new version coming ASAP.) =)
(Oh, and thanks a bunch to Thierer [maker of SD2IEC firmware patch to support this loader] for providing real1541 logic analyser bus-snoop logs enabling me to track down these two bugs.) |
| |
iAN CooG
Registered: May 2002
Posts: 3193 |
New Entry for the now released 100% fixed release
Nightfall 100%
credits copied, fill the missing infos if and when known |
