Need some information on "Packing".

[Mr Nours]

Hi all,

We are trying to debug some menu that are not workings with the Cosmosex and need some help.

We're trying to make the Cosmosex works fine with the fuzion 87 menudisk. This menu works fine under real STE, Hatari & Steem, but let appears some screen data corruption with Magic Pockets after being depacked on the Cosmosex emulated floppy disk drive.
( viewtopic.php?f=103&t=26834&p=286738#p286738 )
I had copied all magic pockets files a more standard disk image (80/9/2 geometry ) and now data seems corrupted even under Steem & hatari. I don't understand why...

Does linking & depacking is related to the disk geometry? I was thinking that was working only at a file level...

Is there here some Jedi menudisk master who could explain how linking and depacking works to a lost menudisk Padawan... ?

Nrs.

[Jeff_HxC2001]

FYI, the image seems to work fine with the SD HxC Floppy Emulator too :

SAM_1197.jpg

SAM_1198.jpg

(Not tried with the Gotek-HxC, but this should work too.)

[...] was thinking that was working only at a file level...

Don't count on this ! Many stuff was hardcoded, so you must keep the exact disk geometry.
Even worst, with some softwares, the timings may be a problem...

[AtariZoll]

We're trying to make the Cosmosex works fine with the fuzion 87 menudisk. This menu works fine under real STE, Hatari & Steem, but let appears some screen data corruption with Magic Pockets after being depacked on the Cosmosex emulated floppy disk drive.
( http://www.atari-forum.com/viewtopic.ph ... 38#p286738 )
I had copied all magic pockets files a more standard disk image (80/9/2 geometry ) and now data seems corrupted even under Steem & hatari. I don't understand why...
Nrs.

Why on Earth you copy files ? You need just to serve floppy image file (not what you created, but org. menu disk - ST or MSA) to CosmosEx, and it will be fine.

[Mr Nours]

FYI, the image seems to work fine with the SD HxC Floppy Emulator too :

Thanks you for testing. Our conclusion is that there is a problem the way Cosmosex handle this image disk... Jookie seems to thinks that the problems occurs when PRG are not relying on TOS function to read floppies.

Why on Earth you copy files ? You need just to serve floppy image file (not what you created, but org. menu disk - ST or MSA) to CosmosEx, and it will be fine.

No, it is not fine. This why i copied files to another geometry and i'm doing some strange tests . As i said i was thinking that linking/packing/depacking on menu disks was working only at file level. I was wrong, it seems that is is somewhat linked to the disk geometry...

Cheers,

Nrs.

[AtariZoll]

If CosmosEx works not well with regular ST image - here I mean original menu disk image, of course, not that with changed geometry, then it is error on CosmosEx floppy emulation. And you don't need to change geometry to some "more standard" disk geometry - that's nonsense. No standard disk geo. by Atari. Most used is 10 sectors/track, and it works flawless on any Atari, TOS version.
Considering packing/linking - yes, there are many cases where it is not really file based, but somewhere there is exact location on disk used. Btw. your thread title is misleading - packing has nothing with all this.

Reading other replies here, I'm sure that CosmosEx floppy emulation is really on some beginning level. It seems that it lacks low level floppy access functions. And that strange, years after some other HW floppy emulators already solved it. Or whole concept of it is not based on real HW floppy emulation, but goes via TOS functions - Trap #1 and XBIOS 8/9 ?

P.S. and even if there is no floppy geometry dependance, many loaders use custom, direct floppy access for file read instead TOS, and it will work only with proper low level floppy emulation. Something what is discussed here: http://atari.8bitchip.info/imgrun.php