Re: nibtools, GCR, G64

From: silverdr_at_wfmh.org.pl
Date: Thu, 30 May 2013 20:33:51 +0200
Message-Id: <D460F7E4-889F-4029-8EF2-593BBF4D3EF8@wfmh.org.pl>
On 2013-05-30, at 20:17, Nate Lawson wrote:

>>> http://root.org/~nate/c64/
>>> 
>>> Note that it's a beta and more testing/fixing is needed, but it does decode G64 files, including emulating drive behavior of aligning bits on sync.
>> 
>> Ha - I still need to collect all modules you import there to check that out in practice (windows exe is not much of a use here) but I already see that you delegate all the heavy-weight bit lifting to a "BistStream" lib. Something I have to do myself here without any crane..
> 
> It's easy to get.

For C? ;-)

> Create a virtualenv, then just "pip install bitstream"

Seems that my python installation doesn't have pip either (I am more from the enemy camp of precious stones rather than reptiles ;-)

>> Like: trk_stream.split(SYNC_SYMBOL) and there you are, right? Kinda c00l! But.. I discussed few minutes ago with Pete that "SYNC_SYMBOL" can theoretically also wrap around the track data of a G64. I suspect the "split" doesn't take this into account, does it?
> 
> BitStream has many useful features. One of them is a circular rotate. So you can just split() the original track data, rotate it circularly to a sync, and split/join the remainder.

.. and like magic, there you are: byte-aligned!

So if I find a SYNC not being byte-aligned, I should expect that the actual data (header or sector itself) won't be aligned either, right? If that's the case then.. arrghh... %^#$

> I have not done anything for wraparound but had plans to fix this behavior. You also have to properly sync-align data at the start of a track that is unframed unless you consider the last sync.
> This happens when the track gap is at the end of the G64 track. You get 0x55 for the trailing region but sometimes 0xaa for the starting region until the first sync brings things back into alignment.

Hm.. but that's odd. If it is only about the gap then losing a bit is not much of a deal but that's not only about the gap, right?

P. S. Shouldn't we take this off list?

-- 
SD!
       Message was sent through the cbm-hackers mailing list
Received on 2013-05-30 19:01:17

Archive generated by hypermail 2.2.0.