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-19 22:58 -0700
Organization	A noiseless patient Spider
Message-ID	<m3oacgaj2d.fsf@gmail.com> (permalink)
References	(4 earlier) <bdbf2ce1-774c-460a-8068-80315d6de51f@googlegroups.com> <m3y4boadwd.fsf@gmail.com> <n7gdc4$eo5$1@dont-email.me> <m3si1v9z8i.fsf@gmail.com> <5f91898b-5d5d-41fe-9103-e36659ad9d6b@googlegroups.com>

Show all headers | View raw

Frank Schnorbus <fandr76@aol.com> writes:

> On Sunday, January 17, 2016 at 10:29:28 PM UTC-8, awanderin wrote:
>> 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.
>> 
>> Jerry    awanderin at gmail dot com
>
>
>
> Jerry, I really appreciate the time and thought you've put into this!
> I am happy to say that our nibblized 410 bytes match exactly.
>
> Where I have the question, the problem, is in what order are those 8
> strings of 51 bytes (plus 2 leftovers) written?  In other words, the
> next step is to put the strings together and XOR them.  In ProDOS
> there certainly was some flipping of the order, and based on what I
> could deduce from the Woz comments and from other sources, I think DOS
> 3.2 is also.  The 3 strings of concatenated bytes get written first in
> backwards order, then the leftover, then the 5 strings of 5-bit bytes
> in forward order, then the leftover.  As far as I can tell, anyway.
> In the table above you have the order in straight forward 5 strings
> (+1) then straight forward 3 strings (+1).

Yes, of course.  The write routines start with byte 409, work backwards
to byte 256, and then write bytes 0 through 255.  That's the order.  The
details are that each byte written is the XOR of the current checksum
with the byte.  That also becomes the new checksum.  This checksum byte
is written after all 410 of the bytes are written.  The initial checksum
is zero.  Oh, and before they bytes are written to disk, they are
translated to "disk nibbles" using the table.  I'm pretty sure you had
this part nailed down already.

Reading is similar; read bytes 409 --> 256, then 0 --> 255, doing the
checksum calculation as you go.


For 6&2 encoding, it's similar, bytes 341 --> 256 are written and then
bytes 0 --> 255, followed by the checksum.


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