| |
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: 11136 |
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: 11136 |
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: 1628 |
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: 11136 |
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: 1825 |
*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? |
... 11 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 - Next |
