'Tools to work on g64 et al'
Author:Nate (guest: search)
Date: Fri, May 27th, 2011 @ 21:42 ( . )

I'm still working on this. Had a long break due to work but might get some time this weekend, between prepping house for construction.

I've got g64/nib parsing and conversion and some various GCR formatting features. I need to implement the rest of the tool, then I'll notify you.


REPLY: [With No Quote] --- [With Quoted Text]

'Tools to work on g64 et al'
Author:hyper active (registered user: 296 posts )
Date: Mon, Jun 20th, 2011 @ 13:35 ( . )

Hiya.
Will your program work on nb2 files?
Nibread allows you to dump a track or tracks multiple times and read it out in several different densities.
Thanks.


REPLY: [With No Quote] --- [With Quoted Text]

'Tools to work on g64 et al'
Author:Nate (guest: search)
Date: Tue, Jun 21st, 2011 @ 00:35 ( . )

On 06/20/2011 @ 13:35, hyper active wrote :
Hiya.
: Will your program work on nb2 files?
: Nibread allows you to dump a track or tracks multiple times and read it out in several different densities.
: Thanks.
--



I've been busy and haven't finished this tool yet.

Not yet but I'll consider supporting them. You can always work with g64s pieced together from each density track.

BTW, I've always thought nibread should read data at the fastest bitrate and then downsample in nibconv. Is there any problem with this? That way any of the slower bitrate density settings could be recreated in software and tracks wouldn't have to be re-read.


REPLY: [With No Quote] --- [With Quoted Text]

'Tools to work on g64 et al'
Author:Pete Rittwage (registered user: 558 posts )
Date: Tue, Jun 21st, 2011 @ 09:37 ( . )

I recall trying that at some point, but the problem is that you often lose framing when reading at the wrong bit rate, and it can't be put back together again reliably. Timing isn't perfect on belt driven drives and at unknown rotation speed, and I don't think you can test rotation speed without writing data.

Even worse, some drives (some 1541-II's especially) will return random data that isn't based on the actual flux stream, when out of framing.

I can look at it again if there's something I missed, though.


REPLY: [With No Quote] --- [With Quoted Text]

'Tools to work on g64 et al'
Author:Nate (guest: search)
Date: Wed, Jun 22nd, 2011 @ 13:14 ( . )

Yeah, I understand that if you have a low density of 1 bits, choosing a bitrate setting that is too high would result in spurious 1's being clocked into the shift register.

Basically, you'd be creating "weak bits" if reading a low bitrate source at a higher rate.


REPLY: [With No Quote] --- [With Quoted Text]

'Tools to work on g64 et al'
Author:Pete Rittwage (registered user: 558 posts )
Date: Sat, Jul 02nd, 2011 @ 15:02 ( . )

I can try reading all at the lowest density and calculating. Do you have a routine to recalculate at another bit rate that I can experiment with?


REPLY: [With No Quote] --- [With Quoted Text]

'Tools to work on g64 et al'
Author:Pete Rittwage (registered user: 558 posts )
Date: Sat, Jul 02nd, 2011 @ 15:02 ( . )

Pseudo-code or an explanation would be fine...


REPLY: [With No Quote] --- [With Quoted Text]

'Tools to work on g64 et al'
Author:Fungus (registered user: 20 posts )
Date: Sun, Jul 03rd, 2011 @ 07:50 ( . )

I don't think 1571's and 1541-II's should be used on some disks to dump with as they don't function exactly the same as an older 1541. Been researching some of the hardware differences, so that vice disk emulation can be re-done lately. I've found that II's and 71's can not read with byte_sync disabled, it simply does not work at all on those drives.

That's the reason some games were released again with changes to the protection so that they would function on those drives. Star Rank Boxing is an excellent example of this, due to the way it checks the syncs and data before and after them.

Lord Crass can explain how these checks work in greater detail than I can at the moment. =]

Reading disks with multiple densities on a track or abnormal densities is just going to be a problem on any drive, the protections which do such stuff need to be analyzed and custom dumping would have to be done for such disks as you know it's a bit hard to auto detect the density reliably.

Also, very much looking forward to the release of G64/NIB editor. I can't wait ;)


REPLY: [With No Quote] --- [With Quoted Text]

'Tools to work on g64 et al'
Author:hyper active (registered user: 296 posts )
Date: Wed, Jul 13th, 2011 @ 00:46 ( . )

si.
Huri! Huri! Huri!


REPLY: [With No Quote] --- [With Quoted Text]

'Tools to work on g64 et al'
Author:Pete Rittwage (registered user: 558 posts )
Date: Thu, Jul 14th, 2011 @ 19:22 ( . )

Hi Nate, and all,

(I am cross-posting this to the Nate's XUM-1541 devel list also to see if there is any interest in my helping to implement something like this on another level.)

Thanks very much for taking your valuable time for old hobbies. I am sorry for my brain-dump format of this message, as it will be long and rambling.

The 'nibedit' idea reminds me of something I've been thinking about for a while with regard to NIB files as Markus created, and all the different formats of emulator files we have to deal with (not to mention X cables).

It seems to me that the image formats as passed down over the years are inherently inflexible. I've considered getting rid of the NIB format altogether and converting to a more modern XML-tagged "description" of the disk data that is in the file as we captured it. These files could contain lots of different tags to describe everything down to whatever level we have access to and at any level of detail.

For example, a NIB image as read now into an XML format would contain tags with the timestamp, OS, program version, interface/cable type, interface firmware revision, drive type, drive speed, drive ROM hash, switches used, IHS or no, SRQ or parallel, halftracks, publisher, copyright, etc. (down to incredible detail). Some of this is currently in an accompanying "log" file that most people unfortunately don't submit to me.

Track or sector tags would contain:
*) detected density
*) detected track types (nosync/killer)
*) length as measured.
*) description of following data chunk

A data chunk could be:
*) a "NIB" revolution, which is 1.x disk revolutions of GCR as read from the shifter (raw GCR)
*) a "track cycle" of data from IHS pulse to IHS pulse (hole start or hole end?)
*) fully decoded GCR data (D64-type data)
*) separate raw sector headers and raw data sectors (breakout)
*) HEX-formatted values of GCR data
*) a single non-standard, or sync-to-sync GCR run
*) description of "signature track". (So replace Pirateslayer track data with <tr>2<sig>pslayer1</sig></tr>
*) flux transition timings, used with different imaging hardware
*) compression type of any of the above
The benefits are endless, and it could be used to convert to existing format, so it's backwards-compatible.

You could "patch" the images using tags which we would could just be a another tag later in the XML file that supercedes the other tag. So edit a track, sector, or just a pattern of bytes using a description. This could be used for high score tracks/sectors, protection descriptions or patches, image differentials (alternates), or simple editing. If you want to "edit" a track, just define a new track at the end of the file with the new data.

This could really be an "open" emulator media format like we've never had before. For any media for any emulator type.

-Pete


REPLY: [With No Quote] --- [With Quoted Text]

'Tools to work on g64 et al'
Author:hyper active (registered user: 296 posts )
Date: Sat, Jul 30th, 2011 @ 18:05 ( . )

Hi Nate.
Any idea when you'll be releasing your utility to edit nib and g64 files?
Or have you decided to leave it and let Peter develop his .xml system?
Thanks.


REPLY: [With No Quote] --- [With Quoted Text]

'Tools to work on g64 et al'
Author:Nate (guest: search)
Date: Sun, Jul 31st, 2011 @ 15:38 ( . )

It will be a while. First in line for hobby time is to get the firmware update utility for ZF written so we can do another release of OpenCBM for it. I'm also helping get SRQ nibbling working on the 1571.

So it will be a while until I can finish and release this tool. There has been additional discussion of Pete's ideas, and I'm not getting involved in that so he can do whatever he wants.


REPLY: [With No Quote] --- [With Quoted Text]

'Tools to work on g64 et al'
Author:Pete Rittwage (registered user: 558 posts )
Date: Sun, Jul 31st, 2011 @ 15:43 ( . )

I was not trying to subvert Nate's tool, and do not plan in the immediate future to change anything. I currently do not have the time to implement a new file format.

A GUI-based G64 editor would be the way to go for this, but someone with more time would need to develop it.


REPLY: [With No Quote] --- [With Quoted Text]

'Tools to work on g64 et al'
Author:hyper active (registered user: 296 posts )
Date: Thu, Sep 01st, 2011 @ 18:45 ( . )

Any idea on when you might release the utility? what sort of time frame are we looking at, October, Christmas? new year?
Thanks, not trying to sound impatient or anything.


REPLY: [With No Quote] --- [With Quoted Text]

'Tools to work on g64 et al'
Author:Nate (guest: search)
Date: Tue, Sep 13th, 2011 @ 17:40 ( . )

It's last in line, behind getting the next ZoomFloppy release out. That's still got a bit of work remaining too, but the end is in sight.


REPLY: [With No Quote] --- [With Quoted Text]

'Tools to work on g64 et al'
Author:hyper active (registered user: 296 posts )
Date: Thu, Dec 01st, 2011 @ 02:06 ( . )

will your editor be released in time for Christmas?


REPLY: [With No Quote] --- [With Quoted Text]

'Tools to work on g64 et al'
Author:hyper active (registered user: 296 posts )
Date: Thu, May 31st, 2012 @ 06:39 ( . )

Hi nate. any ideas about the release date of your nib/g64 editing tool?
Cheers.


REPLY: [With No Quote] --- [With Quoted Text]


--- 0 Users Online --- 0 Recent Unique Posters

Q305=1660601961 - Threads: / 1660601961