Custom MFM & Dos tracks

[BippyM]

Hi guys

A quick query really

i'm looking at a game that uses both custom mfm and dos mfm tracks on the same disk, and i'm curious about the doio structure

now the filesize being passed to the iorequest structure is $00072800 bytes, and generally loads to $59e8 (though this changes as allocmem is used).

Now the game actually only loads about 3-4kb into ram and not 468992 bytes as passed to the iorequest structure!

Could this be due to the game hitting an unreadable mfm encoded track? or maybe i'm missing something!

I broke into the bootblock in a few places and I checked the iorequest offset myself so I know the size is right!

Also after the doio command the game then clears d0, clears $24 of the iorequest and then does a #cmd_nonstd before doing another doio.. what does this do?

[Thorham]

Are you sure it's 3 to 4 kb? Couldn't it be 5kb? I'm asking because when you pass the nr of bytes to be read to the hardware, only the lower 13 bits of the register are used for size. This means that only $2800 would be used for size and not $72800! $2800 is 10kb, and since mfm encoding requires reading twice the amount of data (mfm coding doubles the nr of bytes) this would end up reading 5kb of real data to memory.

By the way, dos uses mfm encoding. The only other format is gcr, which uses a more compact form of encoding, and can therefore store more data on the disk.

Since I don't know much about this topic, though, I could be completely wrong. In that case I'll just

[BippyM]

Okay it is using execs standard doio command and the track(s) are in standard dos format, the rest is encoded with more data on the tracks

I guess $2800 could be read in, but that is far too much data, it only lasts for about 3-4kb.. tho there is no saying the rest of the data is blank or padded out!

[Toni Wilen]

Originally Posted by bippym

#cmd_nonstd

TD_MOTOR = CMD_NONSTD

[BippyM]

so it basically just turns on the drive motor hmmmmm

[Toni Wilen]

Originally Posted by bippym

so it basically just turns on the drive motor hmmmmm

More like turns off the motor. Check trackdisk.device autodocs first

[BippyM]

yeah that's what i meant ;-) i had checked the trackdisk autodocs and then posted. If what thoram says is correct how are large file sizes passed to be read if only the lower 13bits are used?

[BippyM]

I changed the title and some of my first post to make it more understandable

I'm still confused as to why $72800 is passed to the iorequest structure..

again if only the lower 13bits are used, then $2800 is perhaps all that is loaded, but then how would the game handle a file that is larger?

I am kerfuffled

[Codetapper]

Are you sure you are not confusing the hardware register $dff024 and the IO request structure?

Reading a track of data by hitting $dff024 twice certainly only looks at the lower bits, but an IO request should read the whole data.

[BippyM]

no i'm looking at the iorequest structure (as pointed to by a1)

I can post the whole bootblock if you want to see it!

the file is actually only 4096 bytes.

[Thorham]

Please do. That would be quite useful. It's always a bit easier when there's some code to look at.

[BippyM]

here is a screenshot of the bootblock.

I was going to resource it, but there is no need, any half decent asm guy will know what is happening


I know what is loaded, and I have it saved to disk, I just don't know why only 4096 bytes is saved!

I'll post a pic of the registers if needed

[Codetapper]

That looks like a normal bootblock from a game that then loads a Rob Northen loader - can you tell us what game it is from?

According to my Mapping the Amiga book, the io_Length field is an unsigned long, so should read the full amount. Unless something smart is happening like it's loading the data over the code and bailing out or something odd...

If we can look at the game itself that might help...

[BippyM]

The game is wipe-out (SPS #0161)

[BippyM]

Did you take a look Codetapper?

Basically Horace wants me to do a whdload install, currently it is far too complex for my asm knowledge, but I hope to ry and learn as much as etc.. a real tangable project

[meynaf]

According to the code shown in the image, it's $5800, not $72800, which is passed to DoIo.
There's nothing mysterious in that code

[BippyM]

err where do you get $5800 from?

I jumped in directly before the jump to allocmem and d0 contained $72800 as did the io-request structure pointed to by a1!

I'll do another screenshot if you require it

[meynaf]

Originally Posted by bippym

err where do you get $5800 from?

I jumped in directly before the jump to allocmem and d0 contained $72800 as did the io-request structure pointed to by a1!

I'll do another screenshot if you require it

I got the $5800 from the instruction located at 05003c (look in your screenshot).

[BippyM]

that is the offset on disk to look for the data not the length of the data!

Track 5 I think!

[meynaf]

Originally Posted by bippym

that is the offset on disk to look for the data not the length of the data!

Track 5 I think!

Oops... My mistake...


The code reads from track #4 (4*512*11), 5th track if you prefer.
The length of the data is available chip memory, minus 31.5k, and rounded to a multiple of 512 bytes ($72800 in your case).

That (pretty dirty IMO) code won't work if there is 1 or 2 Mb of chip memory...

So you're right, it tries to read $72800 bytes, but, of course, it can stop if there is an unreadable track (or simply an unreadable block). That's probably what happens to you.

Now what's really read from disk (in terms of contents) ? Looking at this new code (should be code because we jump to it) might help in understanding how much data really needed to be read.