| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
Create G64 disk image using real hw: possible?
There is a way to create a G64 image using only real hardware? |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
you can use Zip-Collection V2.0 sixpack to make a GCR image (that works with originals at a similar success rate as G64 images do) - however, you'd have to convert it to an actual G64 file, there are no native tools for that afaik.
the question is "what you are going to do with it?" though. as soon as you obtained hardware that can _use_ G64, you should also be able to write to them :) |
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
It 's just a matter of laziness. I do not want to install all drivers and hardware using a pc...
I know there is a way to create .d64 (from 1541 to sd2iec or to 1581 for eg.).
Then i thought that someone had created something similar for G64 and "protected" software... |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Is there anything out there which can do the reverse? Any idea how powerful the six-pack writer is?
You can squeeze quite a few extra kilobytes onto a floppy by abandoning the standard format, but it's difficult to distribute the resulting demo/game without tools for the users to dump the results back out using standard equipment. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
it should fail at the obvious stuff: index alignment, non standard bitrates (tracks recorded with slowed down drive) and probably also with different densities within a single track.
besides that it was good enough for a generation of crackers to swap their originals :) |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quoting Groepazit should fail at the obvious stuff: index alignment, non standard bitrates (tracks recorded with slowed down drive) and probably also with different densities within a single track. Cool :)
I'll give it another shot with the non-standard bit-rates stripped out and the inter-sector gaps lengthened. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Well, in theory all we need is the best nibble copier around and instead of writing to a disk it has to write on a file on a different device (where possibly there is an sd2iec or utilamet2+ or something like that).
Basically is what nibtools does but on c64.
The same drivecode of nibtools could be used directly.
Or something better than that if there is. |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Maybe some of the code from here could be used/adapted, for using the ultimate as storage device.
https://github.com/T-Pau/Tachyon-RL |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
nibtools is basically burstnibbler (the drive code anyway).
MarcusC64 (iirc) made a version that writes the raw data to REU memory and can dump that on 1541U or similar setups - and then you can convert the resulting data into a g64. Its still a bit hit and miss though, and requires manual work with non trivial protections, because certain things cant be handled automatically (different speeds on a single track, track alignment, weak bits) |
| |
Count Zero
Registered: Jan 2003
Posts: 1821 |
*bump* Bits and Nibbles : The Ultimate Copy
Thought all the drive freaks would dive into that and see what it does :) |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting Groepaznibtools is basically burstnibbler (the drive code anyway).
MarcusC64 (iirc) made a version that writes the raw data to REU memory and can dump that on 1541U or similar setups - and then you can convert the resulting data into a g64. Its still a bit hit and miss though, and requires manual work with non trivial protections, because certain things cant be handled automatically (different speeds on a single track, track alignment, weak bits)
I was thinking about the best nibble copier around which *seems* to be the one in maverick.
Or is burstnibbler/nibtools code better? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
Burstnibbler uses parallel connection to begin with, which is pretty much a requirement for a proper nibbler (unless you install extra memory in the drive).
For Zoomfloppy (or similar purposes) it doesnt really matter anyway, as the drivecode can be relatively dumb, and all the complex stuff can be done on the recieving end. All you need to do is read a full track raw and send it over. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting GroepazBurstnibbler uses parallel connection to begin with, which is pretty much a requirement for a proper nibbler
I don't agree.
It was true at the time and only for speed reasons. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
You can agree or not, you still need it (or expanded memory in the drive) to read a full revolution raw and reliably. |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
If only they'd put 8K+ in there from the beginning... :P
Come to think of it, I still have a +8K board waiting to be installed. :) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting tlrIf only they'd put 8K+ in there from the beginning... :P
Come to think of it, I still have a +8K board waiting to be installed. :) Hah, and i still have a parallel cable upgrade kit sitting around... =) |
| |
Comos
Registered: May 2004
Posts: 71 |
Quote: Quoting GroepazBurstnibbler uses parallel connection to begin with, which is pretty much a requirement for a proper nibbler
I don't agree.
It was true at the time and only for speed reasons.
How did you come to that conclusion? |
| |
Fungus
Registered: Sep 2002
Posts: 616 |
Nibblers are not duplicators, so lets just set that straight right now. Zoom Floppy is incapable of making any of kind of proper disk image for protected software.
I'll wait for the big brain to claim he can read weak bits perfectly with 1541 and then make popcorn. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
Once you can read a full revolution reliably without parallel cable or memory expansion, you can also read woke bits. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting GroepazYou can agree or not, you still need it (or expanded memory in the drive) to read a full revolution raw and reliably.
Why?
You can read parts of a track and then stitch them together as the data repeats. Also with weak bit a single rotaion won't show you everything. For sure it's faster with a parallel cable or a memory expansion, I am just saying that technically it's only the speed of the operation that changes. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting GroepazOnce you can read a full revolution reliably without parallel cable or memory expansion, you can also read woke bits.
If I understood it correctly, a real weak bit is a bit that is magnetized lightly and has an unstable state so that sometimes it reads as a 0 and sometimes as a 1.
A single revolution will only read it in one way. Or I got the concept wrong? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
Quote:You can read parts of a track and then stitch them together as the data repeats.
you cant do this reliably on arbitrary data. it only works if you have reliable syncpoints on the track.
Quote:If I understood it correctly, a real weak bit is a bit that is magnetized lightly and has an unstable state so that sometimes it reads as a 0 and sometimes as a 1.
A single revolution will only read it in one way. Or I got the concept wrong?
this is one type of weak bit, another type is created by using invalid GCR sequences (too many consecutive zeros). |
