Support of double sided disks (1571) for g64 and p64
Versatile Commodore Emulator
Brought to you by:
blackystardust,
gpz
Menu
▾
▴
4 Attachments
#122 Support of double sided disks (1571) for g64 and p64
This patch adds support of double sided disks (g64 and p64 format) to vice. Note that true drive emulation is required for this to work.
Without true drive emulation, the new formats cannot be used (no regression since they double sided g64, p64 were never supported).
This should also fix bug 656.
since you changed/extended the g64 and p64 format specs it would be great if you could also update the documentation (vice.texi)
it'd also be interesting to know what tools you used/modified to create those images :)
Well, for g64, vice supported 42 tracks (or 84 half tracks). I just used the half-tracks 1-84 for side 1, and 85-168 for side 2.
For p64, I used bit 7 of the track number for the side (assuming there are no disks with more then 127 tracks). And in the flag byte, bit 1 is set if both sides are stored in the image.
For creating those files, I used my own software (both GPL V3):
https://github.com/markusC64/g64conv (written in perl, can be used on windows, unix, linux, ...) - any perl >= 5.8.x should work.
https://github.com/markusC64/p64conv (c++, currently only linux and unix are supported; needs google's re2 library).
Use the first to convert d71 to g64, the g64 to p64.txt (a textual representation of an p64 image) and the second to convert p64.txt to p64
BTW: I hope that creation of empty images will be added to vice by someone who knows the vice source code better than me.
For the requested update of the documentation: I think I'll do that soon - if there is an interest to include this improvement in vice.
Update: Of cause cou can also take a single sided g64, convert it into textual representation by using g64conv. Use your favourite text editor to edit the image, i. e. adjust the header settng for a maximum of 168 tracks, copy and paste tracks 1-35 into tracks 43-77 (tracks, not hald tracks!). The latter just to get the right track length.
Again use g64conv to convert back.
Edit: Fixed typo.
Last edit: Markus 2016-05-23
yes, please make a seperate patch for vice.texi that documents your changes... i am very reluctant to add any support for formats that are not properly described in our documentation (especially now where we finally managed to get it somewhat up to date...)
I'm not very good at writing documentations, but here is a doc update.
applied in r32586 - please test :)
would be great nevertheless if you could have a look at image creation from within VICE too... not exactly my area of expertise either =)
reworked the patch a bit:
image creation (from vice menus and c1541) is now working
the images use GCR-1571 as magic bytes, that makes it much easier to handle them
please test, especially corner cases :)
honestly, for me it doesn't work at all using winvice. but maybe i'm doing something wrong.
i took above g64 image for testing, winvice x64sc r32593, floppy set to 1571
then i saved some small file in x128 to that image, now i'm not even able to load the directory in x64sc, ALT-8 shows > 8000 free blocks.
that patch probably worked at the time posting, but there were some changes since then it seems.
Last edit: Querino 2017-01-03
that test.g64 will not work, it still has the GCR-1541 magic
ah, ok. still i do struggle.
creating a new g64 disk image works, but has now 783 free blocks with ALT-8, loading the dir shows 664 though.
are there any working double sided images around?
you probably have to use x128 - or switch the drive into doublesided mode manually using DOS commands
ok, i created a g71 now.
the g71 is almost 4 times as big as a g64 image. ALT-8 in winvice shows correct 1328 free blocks.
however, load"$",8 still comes up with 664 blocks (winvice AND also SDL). but i can save and load files.
the same is true for x128, only 664 free blocks.
but after all i can save only up to the usual 664 blocks i guess.
i see, this isn't for me. :) as long as the other formats aren't broken, i'm fine actually.
Last edit: Querino 2017-01-03
please attch such a g71... they should become almost exactly twice as large as g64s
well, that's why i mentioned it...
I've analyzed the test.7z contents: The image is buggy. Track 36 contains the second side of track 1. This track should be track 43. Track 37 and the following likewise.
Track 36 is Track 36 side 0.
Track 43 would be Track 1 side 1.
Last edit: Markus 2017-01-03
how did you come to this conclusion? as far as i can see the general layout it ok, just the BAM ended up at the wrong place somehow
this is the layout before formatting: http://pastebin.com/CfpTUqCC
edit: wait... how does the 1571 actually number the tracks in the sector headers? ... right now it will have 43 in the first track on side 1 - thats probably wrong (and should be 36?) ... and the extra sectors (on both side) should get unused/invalid numbers? or what? =) ie, there is no field for the side in the headers and numbering starts at 1 again for the second side, right?
Last edit: gpz 2017-01-03
No, it should not be 36 - otherwise you cannot store contents of track 36 side 0 up to track 42 side 0 (used by some copy protections).
I've added a hand-made test.g71 (I've updated my g64conv to suport g71). Compare to your image:
open 1,8,15
open 2,8,2,"#"
print#1,"u1 2 0 36 0"
My image is working, the vice generated is not working. Notice that the head position is 43 in this test (the UI might want to switch to track / side display).
A further diagnostic has been to convert the g71 to txt and look at it with a text editor (using g64conv).
the question is, when you format a disk using the DOS - what track number goes into the header of the first track on side 1? is it really 43?
In the header there is track 36. But by format of g71, Side 0 is stored on Tracks 1 to 42 (just like 1541) and Side 1 is stored on Tracks 43 to 84 (for sure a 1541/1571 cannot access track >= 43 side 0).
As an illustration an extract from g64conv:
track 43
speed 3
begin-at 0
sync 32
; header
gcr 08
begin-checksum
checksum 25
; sector
gcr 00
; track
gcr 24
; id2
gcr 31
; id1
gcr 30
end-checksum
gcr 0f
gcr 0f
; Trk 36 Sec 0
bytes 55 55 55 55 55 55 55 55 55 ff
The problem is that cbm dos does not use tracks 36 - 42 on side 0. But they are accessible.
Last edit: Markus 2017-01-03
In one sentence: You must differ between logical track number and physical track number. The latter is determined by head position and selected head (side 0 or 1) and nothing else.
thats all i wanted to know (and that is what was wrong)
of course - and if you look at the pastebin i posted above, you can see that is already the case :)
To tell the truth: When developing the tools, I had created an empty disk (all zeros on all tracks) and let the emulated 1571 format it. And then looked at it.
Just one thing I'd like to mention: Think of a one sided real disk in a 1571. 1541 Mode. Using "u0>h1" you can switch to the second side. And then you can format it. As it is a real disk, you can put it in a 1541, too and read the disk (just side 0, but that's ok, as side 0 does not contain any reference to side 1).
Using g71 you can do the same in vice. But you cannot put that disk in an emulated 1541. I'd like this to be improved.
Edit: You are right. You're starting from track 43. I was just fooled by seeing physical tracks 36 (and following) being formatted, whereas a real 1571 would not have formatted them.
Last edit: Markus 2017-01-03
one thing at a time please... however using g71/d71 in 1541 may be problematic using the current architecture. i'd rather see 1571 working correctly first =)
Last edit: gpz 2017-01-03
I agress, 1571 working first is desirable. But the other should not be forgotten, so I mentioned it. I think I'll prepare such a g71. In the process of making g71 on an emulated 1571 working, we'll need that image as a test, too.
r32597 fixes the formatting itself (logical track 36 is on physical track 43 in the image now)
however, something with the created BAM is still weird, i dont really get it ... :/
edit: the second BAM block is messed up for some reason. it shows correct number of blocks in the preview window because that also uses vdrive (so one bug cancels out the other). perhaps that should go into a new ticket. sigh
Last edit: gpz 2017-01-03
oh well, my motivation to dig further is exhausted - there are some fundamental problems with supporting double sided images properly. the juggling with track offsets combined with no concept of handling disk sides independent from that make my head explode.
for the time being, we'll have to consider anything vdrive related (create images, preview directory, c1541 image handling and perhaps more) broken. if you want to dig further yourself, vdrive-bam.c may be a starting point. i'm giving up here