English Amiga Board

English Amiga Board (http://eab.abime.net/index.php)
-   Coders. General (http://eab.abime.net/forumdisplay.php?f=37)
-   -   Custom MFM & Dos tracks (http://eab.abime.net/showthread.php?t=34353)

BippyM 19 January 2008 11:28

Custom MFM & Dos tracks
 
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 19 January 2008 12:13

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 :banghead

BippyM 19 January 2008 12:20

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 19 January 2008 12:25

Quote:

Originally Posted by bippym (Post 388758)
#cmd_nonstd

TD_MOTOR = CMD_NONSTD

BippyM 19 January 2008 12:29

so it basically just turns on the drive motor hmmmmm

Toni Wilen 19 January 2008 13:04

Quote:

Originally Posted by bippym (Post 388768)
so it basically just turns on the drive motor hmmmmm

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

BippyM 19 January 2008 17:35

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 19 January 2008 23:03

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 :help

Codetapper 20 January 2008 23:19

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 21 January 2008 00:35

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 21 January 2008 00:59

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

BippyM 21 January 2008 01:06

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 21 January 2008 07:38

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 21 January 2008 14:23

The game is wipe-out (SPS #0161)

BippyM 22 January 2008 06:09

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 25 January 2008 13:25

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 :confused

BippyM 25 January 2008 13:56

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 25 January 2008 14:21

Quote:

Originally Posted by bippym (Post 390661)
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 25 January 2008 14:57

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

Track 5 I think!

meynaf 25 January 2008 15:24

Quote:

Originally Posted by bippym (Post 390685)
that is the offset on disk to look for the data not the length of the data!

Track 5 I think!

Oops... My mistake... :o


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.


All times are GMT +2. The time now is 05:48.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.

Page generated in 0.04784 seconds with 11 queries