Re: nibtools, GCR, G64

From: Nate Lawson <>
Date: Thu, 30 May 2013 11:17:26 -0700
Message-Id: <>
On May 30, 2013, at 10:55 AM, wrote:

> On 2013-05-30, at 19:09, Nate Lawson wrote:
>> I posted it on my web page, both in Python script and Windows exe forms.
> So you have a Python compiler for Windows?

Yes, more like a bytecode packager (py2exe). The program is still interpreted but runs pretty quickly.

>> 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. Create a virtualenv, then just "pip install bitstream"

> 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.

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.


       Message was sent through the cbm-hackers mailing list
Received on 2013-05-30 19:00:04

Archive generated by hypermail 2.2.0.