Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS

From	awanderin <awanderin@gmail.com>
Newsgroups	comp.sys.apple2
Subject	Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS
Date	2016-01-17 23:29 -0700
Organization	A noiseless patient Spider
Message-ID	<m3si1v9z8i.fsf@gmail.com> (permalink)
References	(2 earlier) <3a8b9739-0f8a-497e-8168-cc93b6d84956@googlegroups.com> <m337u0bsf9.fsf@gmail.com> <bdbf2ce1-774c-460a-8068-80315d6de51f@googlegroups.com> <m3y4boadwd.fsf@gmail.com> <n7gdc4$eo5$1@dont-email.me>

Show all headers | View raw

ultramagnus_tcv <mikew@thecomputervalet.com> writes:

> On 2016-01-17 07:00:50 +0000, awanderin said:
>
>> My newsreader doesn't have the original articles right at hand (I think
>> I could make it go get them if I tried), so I don't have your original
>> 256 bytes handy.
>
>
> These are the original 256 bytes.
>
> 0138B0034C32A18643C903088A29704A4A4A4A09C08549A0FF844828C8B148D03AB00EA9038D0008E63DA54948A95B486085408548A063B148999409C8C0EBD0F6A206BC1D09BD240999F209BD2B099D7F0ACA10EEA9098549A986A000C9F9B02F85488460844A844C844E8447C88442C88446A90C8561854B201209B068E661E661E646A546C90690EFAD000C0D010CD06DA904D002A54A186D230CA8900DE64BA54B4AB006C90AF055A004844AAD0209290FA8B14AD90209D0DB8810F629F0C920D03BA010B14AC9FFD033C8B14A8546C8B14A8547A900854AA01E844B8461C8844D201209B017E661E661A44EE64EB14A8546B14C8547114AD0E74C00204C
>
>
> I played around with the script very (very) briefly this morning and I
> didn't have much success with the function.
>
> If I pass the bytes as they are up there, I get an invalid token
> error. I believe that's because Python interprets that first zero to
> mean the following should be treated as octal. (Python, I believe,
> points at the COLUMN relating to the first incorrect octal digit
> which, in this case is the first 8 after 013.
>
> If I pass the bytes as 0x013... then I get ...
> t1 = inbuf[y]
> TypeError: 'long' object has no attribute '__getitem__'
>
> If I pass the bytes as a string, I get...
> out[x] = t1 >> 3
> TypeError: unsupported operand type(s) for >>: 'str' and 'int'
>
> I know you didn't post the entire script here, so you may do some
> massaging or you may be calling a file before you call the function. I
> don't know.
>
> But now I'm curious!!!

Yes, I neglected to mention (bad comments again) that the inbuf
parameter for preNib53() is a bytearray object.

In my posting yesterday I also forgot to say that the XORing of data
happens in the write routine, not in the pre-nibble/post-nibble
routines.

Here's how I converted the input to output using Python's interactive
shell (nibble.py is the module that contains the preNib53 function):

>>> import nibble
>>> sector = '0138B0034C32A18643C903088A29704A4A4A4A09C08549A0FF844828C8B148D03AB00EA9038D0008E63DA54948A95B486085408548A063B148999409C8C0EBD0F6A206BC1D09BD240999F209BD2B099D7F0ACA10EEA9098549A986A000C9F9B02F85488460844A844C844E8447C88442C88446A90C8561854B201209B068E661E661E646A546C90690EFAD000C0D010CD06DA904D002A54A186D230CA8900DE64BA54B4AB006C90AF055A004844AAD0209290FA8B14AD90209D0DB8810F629F0C920D03BA010B14AC9FFD033C8B14A8546C8B14A8547A900854AA01E844B8461C8844D201209B017E661E661A44EE64EB14A8546B14C8547114AD0E74C00204C'
>>> s = bytearray([int(sector[i:i+2], 16) for i in range(0, len(sector), 2)])
>>> o = nibble.preNib53(s)
>>>
>>> print ' '.join(['{0:02x}'.format(x) for x in o])
1a 09 16 0c 16 10 10 00 16 16 19 07 05 1a 16 00 14 00 09 01 14 0d 01 00 1c 0d 09 15 10 10 0c 16 10 15 0f 01 17 14 19 16 08 15 1c 15 09 10 18 09 00 06 00 1c 10 09 14 02 09 09 10 09 09 1f 14 1e 1b 09 01 00 19 14 15 09 15 01 12 08 1c 04 01 08 09 10 05 14 01 01 17 04 00 18 09 10 0b 07 00 1a 09 10 09 01 14 07 09 08 10 09 1c 04 10 09 10 10 1a 02 19 11 1b 05 10 01 09 12 03 00 00 1d 14 0c 02 10 19 10 09 10 00 10 19 05 01 17 1d 13 09 09 14 11 07 05 09 09 11 10 16 00 02 08 1c 0c 02 0c 14 08 08 06 16 04 02 00 01 09 1e 09 01 0d 1a 01 15 08 1c 01 0c 10 08 10 09 19 09 02 01 13 03 1a 12 14 0c 09 00 16 19 14 09 05 08 00 04 09 16 09 1c 01 19 03 15 19 19 09 1a 1e 01 15 15 0a 16 1c 04 00 1a 00 19 0c 16 10 08 19 09 10 1f 15 1d 13 1e 01 1e 01 0c 10 09 01 01 16 1f 01 0e 19 09 09 00 10 06 07 01 10 10 01 06 06 04 0c 04 01 04 0a 01 19 0c 13 16 14 12 1a 1a 02 0c 05 13 12 03 01 18 04 1d 05 14 0a 01 06 00 05 18 04 01 10 01 08 0c 08 05 1c 15 0a 13 1d 16 0c 15 0a 0a 1e 01 00 0d 0a 06 12 04 16 01 09 05 14 00 1a 1a 00 10 09 1a 10 1c 00 04 09 14 11 18 01 00 15 0c 14 0c 01 00 15 0a 00 06 02 10 1e 15 18 1a 01 12 08 17 14 02 02 04 00 05 06 11 09 0c 02 03 10 04 1e 15 05 0a 17 00 12 08 14 03 17 08 0f 06 13 0c 05 01 01 16 14 08 01 05 09 0a 1b 02 04


Reformatting that output for easier viewing:

000: 1a 09 16 0c 16 10 10 00 16 16 19 07 05 1a 16 00
010: 14 00 09 01 14 0d 01 00 1c 0d 09 15 10 10 0c 16
020: 10 15 0f 01 17 14 19 16 08 15 1c 15 09 10 18 09
030: 00 06 00 1c 10 09 14 02 09 09 10 09 09 1f 14 1e
040: 1b 09 01 00 19 14 15 09 15 01 12 08 1c 04 01 08
050: 09 10 05 14 01 01 17 04 00 18 09 10 0b 07 00 1a
060: 09 10 09 01 14 07 09 08 10 09 1c 04 10 09 10 10
070: 1a 02 19 11 1b 05 10 01 09 12 03 00 00 1d 14 0c
080: 02 10 19 10 09 10 00 10 19 05 01 17 1d 13 09 09
090: 14 11 07 05 09 09 11 10 16 00 02 08 1c 0c 02 0c
0a0: 14 08 08 06 16 04 02 00 01 09 1e 09 01 0d 1a 01
0b0: 15 08 1c 01 0c 10 08 10 09 19 09 02 01 13 03 1a
0c0: 12 14 0c 09 00 16 19 14 09 05 08 00 04 09 16 09
0d0: 1c 01 19 03 15 19 19 09 1a 1e 01 15 15 0a 16 1c
0e0: 04 00 1a 00 19 0c 16 10 08 19 09 10 1f 15 1d 13
0f0: 1e 01 1e 01 0c 10 09 01 01 16 1f 01 0e 19 09 09
100: 00 10 06 07 01 10 10 01 06 06 04 0c 04 01 04 0a
110: 01 19 0c 13 16 14 12 1a 1a 02 0c 05 13 12 03 01
120: 18 04 1d 05 14 0a 01 06 00 05 18 04 01 10 01 08
130: 0c 08 05 1c 15 0a 13 1d 16 0c 15 0a 0a 1e 01 00
140: 0d 0a 06 12 04 16 01 09 05 14 00 1a 1a 00 10 09
150: 1a 10 1c 00 04 09 14 11 18 01 00 15 0c 14 0c 01
160: 00 15 0a 00 06 02 10 1e 15 18 1a 01 12 08 17 14
170: 02 02 04 00 05 06 11 09 0c 02 03 10 04 1e 15 05
180: 0a 17 00 12 08 14 03 17 08 0f 06 13 0c 05 01 01
190: 16 14 08 01 05 09 0a 1b 02 04

After this, the write routine XORs each successive byte with the current
checksum, uses that as an index to the 5&3 disk-byte table, and outputs
the byte that actually goes to the disk.

>
> ---
>
>
> I've quoted Frank's original message below:
>
> On 2016-01-10 05:24:34 +0000, Frank Schnorbus said:
>
>> I am not a programmer, but I have been fascinated by the scheme used
>> to write data to the disk.  Some time ago, for the fun of it, I
>> wrote an Excel spreadsheet that converts 256 bytes of data to the
>> 342 (plus 1 checksum) bytes written to the disk for ProDOS.  The
>> spreadsheet converts it back the other way also.
>>
>> For example here are the data bytes:
>> 0138B0034C32A18643C903088A29704A4A4A4A09C08549A0FF844828C8B148D03AB00EA9038D0008E63DA54948A95B486085408548A063B148999409C8C0EBD0F6A206BC1D09BD240999F209BD2B099D7F0ACA10EEA9098549A986A000C9F9B02F85488460844A844C844E8447C88442C88446A90C8561854B201209B068E661E661E646A546C90690EFAD000C0D010CD06DA904D002A54A186D230CA8900DE64BA54B4AB006C90AF055A004844AAD0209290FA8B14AD90209D0DB8810F629F0C920D03BA010B14AC9FFD033C8B14A8546C8B14A8547A900854AA01E844B8461C8844D201209B017E661E661A44EE64EB14A8546B14C8547114AD0E74C00204C
>>
>>
>> And here are the actual bytes written to the disk:
>> ACB6EDF2FF9EB7FBD9F9FDF6F9DAEFEE9DB9EDDADDDDAEFEF2A6DBEDF3CFFAF7EED7F4FFF4CEE6EDF4D3CDE9EBEFCED3CDFEF5EBDDA7DAE5B6FAD9FAD9F7F2F6EACD9DABF5FCEDEFFAE9E7BCB9F9BAF3FDB29DABAB9B9AB2D9E9B7D3DBABEED9EF9AD6DFBBB2969696B4EFB5F2FABCCFF2BDF7CFFEDDFAD9ECE5E6DADA9AFBF5DDFB96F7FC9DACF9EEEEF2FAEDF3FEF39BDEED9AACB2ABBAE5EBDF9EEADDADDBBFFEEADCA7DCF7CEEDF5FFB5DFDAF2F7ADABDFEFAEB6DEE6F2F2F9F9F2F2EFEFEFEFEDDAB7EED9B7EDFBE5D9F9F9F2BFAE9FEBF5DAD7D7D7D7DFF7F7DAF2DCD3B4E79B969B9BF6ECEEE7F4F3E5FBB9CEB7ADE5B2DEFAE7FBFB96FEEAF2EDFEE5FDE5D6F2F9E79AA7ABE59FFEDBF59AF59AB9DDF9F6F5B2FAFCFADDE9DFFED6AFADF7FECFFEF2EDDACFFEF2EDFBE6D7F2FAECDDF2F2F9E6B7EFCBAE9FEBE5FCD7D7D7EEFAE6E6FFFEF2EDFDFFEFEDBABBDDAFE6B7A7CBB7
>>
>>
>> The last, B7, is the checksum.
>>
>> Lately I thought it would be fun to write similar spreadsheets for
>> DOS 3.2.1 (which covers back to DOS 3.1 and uses 5x3, producing
>> 410+1 bytes), and for DOS 3.3 (which like ProDOS uses 6x2).  I think
>> I have it done for 3.2.1, but I need to confirm my work!  I have an
>> Apple IIc, but it is in a box, and I am so rusty on how to do
>> something like this, especially with DOS 3.2, that it would take me
>> weeks (or months).  Are there any experts here that might be able to
>> help me?  I'd be so appreciative!
>
>

--
--
Jerry    awanderin at gmail dot com

Back to comp.sys.apple2 | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

DOS 3.2, 3.3 and ProDOS GCR in RWTS Frank Schnorbus <fandr76@aol.com> - 2016-01-09 21:24 -0800
  Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS fadden <thefadden@gmail.com> - 2016-01-09 21:58 -0800
    Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS Frank Schnorbus <fandr76@aol.com> - 2016-01-10 10:15 -0800
      Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS awanderin <awanderin@gmail.com> - 2016-01-10 23:00 -0700
        Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS Frank Schnorbus <fandr76@aol.com> - 2016-01-10 23:56 -0800
          Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS awanderin <awanderin@gmail.com> - 2016-01-13 23:12 -0700
            Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS Frank Schnorbus <fandr76@aol.com> - 2016-01-15 23:21 -0800
              Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS Frank Schnorbus <fandr76@aol.com> - 2016-01-16 00:02 -0800
              Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS awanderin <awanderin@gmail.com> - 2016-01-17 00:00 -0700
                Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS ultramagnus_tcv <mikew@thecomputervalet.com> - 2016-01-17 09:55 -0600
                Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS awanderin <awanderin@gmail.com> - 2016-01-17 23:29 -0700
                Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS Frank Schnorbus <fandr76@aol.com> - 2016-01-18 07:08 -0800
                Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS ultramagnus_tcv <mikew@thecomputervalet.com> - 2016-01-18 10:56 -0600
                Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS Frank Schnorbus <fandr76@aol.com> - 2016-01-19 01:13 -0800
                Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS awanderin <awanderin@gmail.com> - 2016-01-19 22:58 -0700
                Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS Frank Schnorbus <fandr76@aol.com> - 2016-01-18 07:05 -0800
        Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS fadden <thefadden@gmail.com> - 2016-01-11 09:30 -0800
          Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS D Finnigan <dog_cow@macgui.com> - 2016-01-11 19:34 +0000
            Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS scott@alfter.diespammersdie.us (Scott Alfter) - 2016-01-11 21:18 +0000
              Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS Frank Schnorbus <fandr76@aol.com> - 2016-01-11 21:33 -0800
                Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS gids.rs@sasktel.net - 2016-01-12 09:30 -0800
                Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS Frank Schnorbus <fandr76@aol.com> - 2016-01-13 20:48 -0800
                Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS ultramagnus_tcv <mikew@thecomputervalet.com> - 2016-01-14 16:36 -0600
                Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS Denis Molony <denisbytezone@gmail.com> - 2016-01-15 20:09 -0800
                Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS "Michael 'AppleWin Debugger Dev'" <michael.pohoreski@gmail.com> - 2016-01-18 10:06 -0800
                Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS Denis Molony <denisbytezone@gmail.com> - 2016-01-18 11:14 -0800
                Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS "Michael 'AppleWin Debugger Dev'" <michael.pohoreski@gmail.com> - 2016-01-19 23:09 -0800
                Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS Frank Schnorbus <fandr76@aol.com> - 2016-01-15 23:29 -0800
                Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS ultramagnus_tcv <mikew@thecomputervalet.com> - 2016-01-16 14:15 -0600
              Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS Raymond Wiker <rwiker@gmail.com> - 2016-01-12 21:47 +0100
  Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS "Michael 'AppleWin Debugger Dev'" <michael.pohoreski@gmail.com> - 2016-01-10 07:56 -0800
    Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS Frank Schnorbus <fandr76@aol.com> - 2016-01-10 10:22 -0800

csiph-web