Jump to content
IGNORED

This cracked ATR fails to load on #FujiNet. Why?


tschak909

Recommended Posts

First guess is timing... It reads sector 9 twice, suggesting a phantom sector check. if two consecutive reads don't return quickly = fail check.... But it gets past that part OK on a real drive as well as RespeQt just fine...

 

But then farther along it does 21 reads of sector 1 and then starts jumping all over.

 

It loads fine on RespeQt, (which has no inter-sector or inter-track latency....)

I happened to have a Percom AT88-S1 connected so wrote out the ATR, and it indeed fails to boot -freezing - after the jumping around portion as well.

It also fails to load on a Mini-Speedy with track buffering still enabled.

Lastly.. it fails on a real STOCK 1050.

 

FujiNet Track buffering may be inducing delays similar to a real drive, and the latency detection portions of the protection were not completely removed from this crack.

 

Good news, FujiNet operates similarly to a real disk drive. ?

 

[Disk 1] Mounted 'Pinball Construction Set.atr' as 'SD Diskette (90k)'."
[Disk 1] Get status."
[Disk 1] Read sector 1 (128 bytes)."
[Disk 1] Read sector 2 (128 bytes)."
[Disk 1] Read sector 3 (128 bytes)."
[Disk 1] Read sector 4 (128 bytes)."
[Disk 1] Read sector 5 (128 bytes)."
[Disk 1] Read sector 6 (128 bytes)."
[Disk 1] Read sector 49 (128 bytes)."
[Disk 1] Read sector 50 (128 bytes)."
[Disk 1] Read sector 51 (128 bytes)."
[Disk 1] Read sector 52 (128 bytes)."
[Disk 1] Read sector 9 (128 bytes)." [x2]
[Disk 1] Read sector 10 (128 bytes)."
[Disk 1] Read sector 11 (128 bytes)."
[Disk 1] Read sector 12 (128 bytes)."
[Disk 1] Read sector 13 (128 bytes)."
[Disk 1] Read sector 14 (128 bytes)."
[Disk 1] Read sector 15 (128 bytes)."
[Disk 1] Read sector 16 (128 bytes)."
[Disk 1] Read sector 17 (128 bytes)."
[Disk 1] Read sector 18 (128 bytes)."
[Disk 1] Read sector 19 (128 bytes)."
[Disk 1] Read sector 20 (128 bytes)."
[Disk 1] Read sector 21 (128 bytes)."
[Disk 1] Read sector 22 (128 bytes)."
[Disk 1] Read sector 23 (128 bytes)."
[Disk 1] Read sector 24 (128 bytes)."
[Disk 1] Read sector 25 (128 bytes)."
[Disk 1] Read sector 26 (128 bytes)."
[Disk 1] Read sector 27 (128 bytes)."
[Disk 1] Read sector 28 (128 bytes)."
[Disk 1] Read sector 29 (128 bytes)."
[Disk 1] Read sector 30 (128 bytes)."
[Disk 1] Read sector 31 (128 bytes)."
[Disk 1] Read sector 32 (128 bytes)."
[Disk 1] Read sector 33 (128 bytes)."
[Disk 1] Read sector 34 (128 bytes)."
[Disk 1] Read sector 35 (128 bytes)."
[Disk 1] Read sector 36 (128 bytes)."
[Disk 1] Read sector 37 (128 bytes)."
[Disk 1] Read sector 38 (128 bytes)."
[Disk 1] Read sector 39 (128 bytes)."
[Disk 1] Read sector 40 (128 bytes)."
[Disk 1] Read sector 1 (128 bytes)."
[Disk 1] Read sector 9 (128 bytes)."
[Disk 1] Read sector 50 (128 bytes)."
[Disk 1] Read sector 41 (128 bytes)."
[Disk 1] Read sector 1 (128 bytes)."
[Disk 1] Read sector 54 (128 bytes)."
[Disk 1] Read sector 1 (128 bytes)." [x21]
[Disk 1] Read sector 217 (128 bytes)."
[Disk 1] Read sector 19 (128 bytes)."
[Disk 1] Read sector 145 (128 bytes)."
[Disk 1] Read sector 37 (128 bytes)."
[Disk 1] Read sector 253 (128 bytes)."
[Disk 1] Read sector 55 (128 bytes)."
[Disk 1] Read sector 37 (128 bytes)."
[Disk 1] Read sector 73 (128 bytes)."
[Disk 1] Read sector 1 (128 bytes)."
[Disk 1] Read sector 91 (128 bytes)."
[Disk 1] Read sector 19 (128 bytes)."
[Disk 1] Read sector 109 (128 bytes)."
[SNIP]

 

Link to comment
Share on other sites

where is the atr from in any event? it does not seem cracked much if at all

if it were an ATX or similar, you would have to write it out with a bitwriter, archiver, or happy... but it sounds like bitwriter would be the choice to do it no matter what.

then you might end up with a disk that works on real disk drives...

Edited by _The Doctor__
Link to comment
Share on other sites

I pulled it from this thread again, two different releases. I sure as hell wish that when people say THIS WORKS, they would actually POST THE IMAGE THAT WORKED INTO THE THREAD :)

 

I am trying to work out edge cases in the disk emulation for ATR before I go on to tackle ATX emulation. (The first pass of ATX emulation I adapted from @Farb's code did not work, but there were too many potential problems to isolate at that time, we were still working out SIO timing issues, I will try again soon. The ESP has a much finer system clock than the AVR, so we should be able to get the angular timings we need.)

 

I just spent the last 15 minutes looking through RespeQt and SDrive-Max's code. For ATR's in both the FDC status is ALWAYS all clear (second byte 0x00 XOR'd), and neither bother even turning on the motor bit. (I don't either).

 

And for now, all track buffering is turned off in #FujiNet code, as we figure out a scheme that won't induce constant pauses in network fetch (we are trying to connect a coroutine that async fetches into a ring buffer.)

 

-Thom

 

Link to comment
Share on other sites

6 minutes ago, Nezgar said:

The ATR in your first post is NOT the same as the ATR from the post I linked to.

Specifically: EA 40 sector boot skew align.zip

Yup, I grabbed that one and tested as well.. Will paste it here:

 

it's from the B/ directory in this release.

Pinball Construction Set.atr

 

Fun fun fun debugging all of this. I do it for all of you :)

 

-Thom

 

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

41 minutes ago, Wrathchild said:

which would indicate that RespeQt is honouring the timings

If you are talking about RespeQt that supports ATX, then the answer is yes.

Or at least I try because this is really challenging under Windows ;) Timing is not so accurate !

The 21 read of sector #1 of track 0 is here to calibrate and measure the speed of the drive then the following reads always read sector #1 of different tracks (never the same if you reboot).

Timing should then be consistent (all sectors #1 are aligned among all the tracks).

  • Like 1
Link to comment
Share on other sites

The issue would appear to be down to this section:

 

image.thumb.png.93f52fb1efeaac01791cf70151771d12.png

 

So the VCOUNT check determines which code path is taken etc.

 

In Altirra I used the trace: bt $b49f "$%02x $%02X" db($14) db($d40b)

 

With PAL accurate timing this gives outputs of:

$0b $2C
$0b $26
$0b $21
$0b $1C
$0b $17
$0b $11
$0b $0C
$0b $07
$0b $02
$0b $99
$0b $93
$0b $8E
$0b $89
$0b $84
$0b $7F
$0a $79
$0a $74

 

and this stops there and the load continues.

 

Whereas with accurate timing off it returns:

$04 $25
$04 $32
$04 $3A
$04 $24
$04 $1A
$04 $26
$04 $23
$04 $17
$04 $1B
$04 $01
$04 $26
$04 $44
$04 $70
$04 $90
$04 $13
$04 $2F
$04 $44
$04 $5A
$04 $5E

...

and so the load is screwing up

 

Link to comment
Share on other sites

Yes the atr works fine to make a real disk and on ape/respeqt... but, it's still timing dependent... it's just way loose with the timing.... I started messing with the baud rate till it breaks for whatever reason. Not scientific, but all I can do until I get a new display/screen for my piece o crap computator....

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...