link about Disciple and +D

ZX80, ZX 81, ZX Spectrum, TS2068 and other clones
Stefan
Member
Posts: 19
Joined: Fri Nov 29, 2013 10:21 pm

Re: link about Disciple and +D

Post by Stefan »

nuc1e0n wrote: Sun Feb 13, 2022 10:13 pm Perhaps the order the tracks and sides are stored in is different comparing one file type to another? Even if the layout on the original disks is still the same?
I think that that you are hitting the nail on the head. It is not the disk interface that is causing the difference, but the internal layout of the container file - img vs mgt.

The more general purpose img files are laid out in LBA format:
In the LBA addressing scheme, sectors are numbered as integer indexes; when mapped to CHS (cylinder-head-sector) tuples, LBA numbering starts with the first cylinder, first head, and track's first sector. Once the track is exhausted, numbering continues to the second head, while staying inside the first cylinder. Once all heads inside the first cylinder are exhausted, numbering continues from the second cylinder, etc.
cborn
Well known member
Posts: 267
Joined: Tue Oct 06, 2020 7:45 pm

Re: link about Disciple and +D

Post by cborn »

The reading never has been a problem, that is true, its the writing inbetween and actualy i DID ruin some images which were for severall years on my very chaotic site. I copied those images from real disc from my disiple(3d) with RealSpectrum about 15 years ago www.cborn.nl/zxfiles/DDISC.zip
A file on disc that uses more then 1 sector uses the last two bytes for track and sector information.
both drives can find that next track and sector.
But while using emulators on LINUX i switched to Plus D since fuse has only half a working disciple and that for many years.
Somewere on that track(!) i used original copies from Disciple on the emulated +D and they got ruined. Thats only while WRITING to them.
How it happend? I dont know
I know that mgtDD is straight forward, readinfg the directory sector after sector so every thing is red from the "fysic" track 0-3.
have a carrot?
cborn
Well known member
Posts: 267
Joined: Tue Oct 06, 2020 7:45 pm

Re: link about Disciple and +D

Post by cborn »

dom wrote: Wed Apr 21, 2021 10:16 pm If you were hinting at creating MGT format discs, then appmake has a +mgt option which can create +zx discs (untested) which with a small addition in zx.cfg could be used.
Do you perhaps have an example off the command since i dont get it working.
I did make a mgt file with mgtman but it has no file name inside the image according Fuse while mgtman does show that filename itself.
Its a 500kb wave from pcmenc which i got working again in debian. If i get a zx playing it on an +d or disciple then i gonna listen to it to the end off this eon.
:p
cborn
Well known member
Posts: 267
Joined: Tue Oct 06, 2020 7:45 pm

Re: link about Disciple and +D

Post by cborn »

z88dk-appmake +mgt --zx -b 0mozarts15a.bin -o mozart.mgt
mgt: Could not find parameter CRT_ORG_CODE (not z88dk compiled?)

http://www.cborn.nl/zxfiles/wav2ay/0mozarts15a.bin
User avatar
dom
Well known member
Posts: 2076
Joined: Sun Jul 15, 2007 10:01 pm

Re: link about Disciple and +D

Post by dom »

I think you need to add the option -c mozarts15a.map to appmake after compiling with -m

I've never tested the +D disc creation hence why it's not available as a top level subtype
cborn
Well known member
Posts: 267
Joined: Tue Oct 06, 2020 7:45 pm

Re: link about Disciple and +D

Post by cborn »

Hi, if you mean compiling the mozart file, that aint compiled, its a data pack
https://www.msx.org/downloads/related/s ... ncoder-001
https://www.msx.org/forum/development/m ... sg?page=11

But i realize now that the error message is about an ORG indeed, which is not needed at all.
I did choose the option "code" from mgt since that seemed the most correct.
Technicly an "OPENFILE-TYPE" is the apropriate type or at least an a$()DATA file. But that is future talking i supose.
btw , i did set 0 twice. i think thats the ORG and the Length ? was that mgtman? now i have to check what i did with what
Post Reply