Necrosys STE demo

[Steven Seagal]

This demo boots with 'fast' and 'slow' modes in Steem, but not with Pasti (MSA version).

[lotek_style]

Why even do a PASTI? This is an unprotected demo that can be MSA'ed without problems.

[Steven Seagal]

Just reporting a possible bug dude, there's no reason it shouldn't work, with the same MSA image, of course.

[ijor]

Finally checked why it fails.

The image, at least the one I have, is bad. The MSA image has 82 tracks, but the demo tries to read sectors from the 83rd track (track 82).

It works in Steem actually because what seems to be a bug in Steem. Steem doesn't set the Sector Not Found status flag, when it should. So the demo boots (even when inadvertently it didn't read anything from those sectors).

Pasti sets the FDC error flag, correctly, so the demo keeps retrying reading the non existent sector for ever.

[Steven Seagal]

I attach the files that work in Steem.

The MSA image header claims 83 tracks:

Code: Select all

MSA ID E0F sides 2 tracks 83 (0-82) sectors 10

Here's the first sector of track 82:

Code: Select all

619447828 FDC(1) CR $80 A:0 STR E2 TR 82 CYL 82 SR 1 DR 82 dma $3FED4A #1 PC $FFC8
#001 (0-82-01) to 3FED4A: 26 1A 4D 44 0E F5 0B 24 22 01 FE 09 18 F7 09 12
#002 (0-82-01) to 3FED5A: 08 11 00 F7 FF 06 F3 DA DE EE F8 E3 E6 F1 F7 F5
#003 (0-82-01) to 3FED6A: E3 E4 E7 E0 E9 EE E2 C6 D9 E7 FC 06 ED DC F1 08
#004 (0-82-01) to 3FED7A: F7 D7 E2 FC 0D F6 E9 F0 15 26 12 05 1E 13 0D 0D
#005 (0-82-01) to 3FED8A: FC 05 06 FD FF 1C 0B F5 F5 02 00 CD EB 06 F9 EE
#006 (0-82-01) to 3FED9A: F8 05 FE E9 F9 F9 EB 00 EB F4 EB F7 F2 F1 0C 18
#007 (0-82-01) to 3FEDAA: 12 F7 FB 21 2D 14 20 31 13 F4 1C 24 0F 03 18 24
#008 (0-82-01) to 3FEDBA: 15 1D 24 16 32 47 55 39 29 2F 3C 1B 1C 1C 10 F2
#009 (0-82-01) to 3FEDCA: F9 08 0D EC E9 02 F1 D2 E0 E3 EE E8 E1 DF C8 E0
#010 (0-82-01) to 3FEDDA: E0 C2 D2 F6 0A F3 EE EA EB D8 DB D5 F0 03 FD 0D
#011 (0-82-01) to 3FEDEA: 07 00 12 09 F9 15 18 11 00 F0 F8 FF 01 03 FD D9
#012 (0-82-01) to 3FEDFA: E3 0A FF E4 DA E9 15 EA DA ED 13 30 1B 11 0A 0D
#013 (0-82-01) to 3FEE0A: 1F 0A F9 0F 11 00 03 13 28 0B 0D 28 2F 38 27 0A
#014 (0-82-01) to 3FEE1A: 07 2E 31 00 FC F3 E1 DA E9 EC DD F3 09 FD E8 EF
#015 (0-82-01) to 3FEE2A: 03 FA E0 FC 07 F7 F8 07 07 0D 1B 17 18 1C 3C 36
#016 (0-82-01) to 3FEE3A: 15 27 2D 07 00 0D 32 2C 08 F9 04 27 15 ED ED F4
#017 (0-82-01) to 3FEE4A: F9 E8 DB F0 00 04 E4 F0 F5 E9 F9 EE 16 13 FB E0
#018 (0-82-01) to 3FEE5A: E0 ED EE DF D4 DC E9 E9 EF 03 F4 F1 FD F5 EE F5
#019 (0-82-01) to 3FEE6A: 0A 23 27 04 E7 EE 04 04 F4 EF 08 14 F6 E6 E0 F5
#020 (0-82-01) to 3FEE7A: 1F 2D FB FE 24 32 2A 25 27 29 14 18 F9 FE 1C 1B
#021 (0-82-01) to 3FEE8A: F9 E9 09 0F ED DA CF DB 09 F4 EB F9 10 1F 04 ED
#022 (0-82-01) to 3FEE9A: FB 01 F8 F2 EC ED DE FD 0E 00 F7 02 17 28 F3 E4
#023 (0-82-01) to 3FEEAA: 08 00 FA F2 FD EA F8 FC 13 18 12 0B F0 FF 18 11
#024 (0-82-01) to 3FEEBA: 01 FC 14 25 17 FF 02 08 06 F4 DD F7 03 FF 17 0A
#025 (0-82-01) to 3FEECA: FB 10 13 02 ED 0E 1F 12 1C 16 15 F6 02 1E 0C 00
#026 (0-82-01) to 3FEEDA: 11 1A 0C 13 21 15 0F 06 11 04 F8 FB F7 EE E0 FB
#027 (0-82-01) to 3FEEEA: FD F2 E7 F4 24 14 F9 E7 E1 D9 F0 E1 E5 C3 EF FB
#028 (0-82-01) to 3FEEFA: 04 D0 A6 F4 0A E1 03 45 27 FB E8 24 4C 25 EB F6
#029 (0-82-01) to 3FEF0A: 06 09 BA C8 1A 0C 1F 04 F2 DE 2F 0C C6 D2 1D F6
#030 (0-82-01) to 3FEF1A: F4 04 34 03 F7 E4 F5 00 FA F5 FE 08 25 15 0C 0B
#031 (0-82-01) to 3FEF2A: 0B 14 FA E8 ED 01 0E 04 05 0B 03 10 DC E3 D6 E4
#032 (0-82-01) to 3FEF3A: 1F 40 19 D8 21 32 13 28 3B 26 29 4C 44 2A 2D 2E
619610656 FDC(1) IRQ CR 80 STR 80 ( MO ) TR 82 (CYL 82) SR 1 DR 82


It is too slow in Steem SSE (timing problem to investigate).
EDIT: bug found, I call it "HBL drift".

The HFE version works in Steem but not on my STE + HxC device, where it is stuck at track 82.

[ijor]

I attach the files that work in Steem.
The MSA image header claims 83 tracks:

Ah. Ok. That is a different image than the one I had and tested.

Yeah, it doesn't work with Pasti. But Pasti behavior is correct, at least it's not less correct than Steem. The demo seeks to track 83 (that's the 84th! track), then back to track 32, and expect to read sectors at track 32 without problems.

But on real life, most drives won't let you position the head at track 83 (many not even at track 82). Then, the drive head's physical position is not what the program and the FDC believe. The track register doesn't match the actual drive's head position. So seeking to track 32, without performing a full restore, won't work. It won't position the head at track 32. That's what Pasti is emulating.

I can't change the behavior without risking breaking something else. Ideally this would require a configuration option.

[AtariZoll]

And why Pasti emulates not some "super floppy drive", with mechanic capable to reach lets say track 85 ?
Why must emulate some limited drive ?

To add that I had external Epson floppy drive (5V only), very silent, what could max tracks 0-79. But it was OK for me. Most of originals (over 98%) goes not over track 79. I did not use much cracks.
Demos are other category where they went on very high track usage, so why not support it - it costs less than buying new floppy drive

[ijor]

Most of originals (over 98%) goes not over track 79.

And I recall only a single commercial title that uses 83 tracks.

And why Pasti emulates not some "super floppy drive", with mechanic capable to reach lets say track 85 ?
...Demos are other category where they went on very high track usage, so why not support it

Supporting mega images might make some sense, even with more sectors than physically possible. But this is not the case here. This image has 83 tracks, and Pasti supports that. The problem is something different.

The problem is the coding performed by the demo. Not too sure it is ok to support that blindly. Because if I do, this conceivable might break other software that depends on a lower physical limit. So, as I said, this would ideally require a configuration option.

[AtariZoll]

Yes, coding is often not flawless. And not only in demos or cracks. For instance, Microprose Golf intro is coded so, that it will change Timer vector immediately after loading next stage, without checking is music playback finished.
What SW is which fails on drives capable to reach high tracks (over 82-3) ? I think that adding config option would be best.

[Steven Seagal]

For comparison:
CAPS (IPF), max track seems to be 83. Use the same for STW.
ST, MSA, DIM on Steem "native": 85!
ProCopy won't go beyond 81, ACopy: 85, FastCopy: 86! "Break my drive"