Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.apple2 > #26827
| Newsgroups | comp.sys.apple2 |
|---|---|
| Date | 2016-01-19 01:13 -0800 |
| References | (3 earlier) <m337u0bsf9.fsf@gmail.com> <bdbf2ce1-774c-460a-8068-80315d6de51f@googlegroups.com> <m3y4boadwd.fsf@gmail.com> <n7gdc4$eo5$1@dont-email.me> <m3si1v9z8i.fsf@gmail.com> |
| Message-ID | <5f91898b-5d5d-41fe-9103-e36659ad9d6b@googlegroups.com> (permalink) |
| Subject | Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS |
| From | Frank Schnorbus <fandr76@aol.com> |
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).
Not to say you aren't right, but I could point you to where my doubts are raised. Which was why I thought I'd better get a 2nd opinion on this...
So given what I'm saying above, I'm thinking the same bytes are in this order:
05 08 0C 08 01 10 01 04 18 05 00 06 01 0A 14 05 1D 04 18 01 03 12 13 05 0C 02 1A 1A 12 14 16 13 0C 19 01 0A 04 01 04 0C 04 06 06 01 10 10 01 07 06 10 00 02 06 00 0A 15 00 01 0C 14 0C 15 00 01 18 11 14 09 04 00 1C 10 1A 09 10 00 1A 1A 00 14 05 09 01 16 04 12 06 0A 0D 00 01 1E 0A 0A 15 0C 16 1D 13 0A 15 1C 02 1B 0A 09 05 01 08 14 16 01 01 05 0C 13 06 0F 08 17 03 14 08 12 00 17 0A 05 15 1E 04 10 03 02 0C 09 11 06 05 00 04 02 02 14 17 08 12 01 1A 18 15 1E 10 04 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
And to use the same formatting as above to make it easier:
000: 05 08 0C 08 01 10 01 04 18 05 00 06 01 0A 14 05
010: 1D 04 18 01 03 12 13 05 0C 02 1A 1A 12 14 16 13
020: 0C 19 01 0A 04 01 04 0C 04 06 06 01 10 10 01 07
030: 06 10 00 02 06 00 0A 15 00 01 0C 14 0C 15 00 01
040: 18 11 14 09 04 00 1C 10 1A 09 10 00 1A 1A 00 14
050: 05 09 01 16 04 12 06 0A 0D 00 01 1E 0A 0A 15 0C
060: 16 1D 13 0A 15 1C 02 1B 0A 09 05 01 08 14 16 01
070: 01 05 0C 13 06 0F 08 17 03 14 08 12 00 17 0A 05
080: 15 1E 04 10 03 02 0C 09 11 06 05 00 04 02 02 14
090: 17 08 12 01 1A 18 15 1E 10 04 1A 09 16 0C 16 10
0A0: 10 00 16 16 19 07 05 1A 16 00 14 00 09 01 14 0D
0B0: 01 00 1C 0D 09 15 10 10 0C 16 10 15 0F 01 17 14
0C0: 19 16 08 15 1C 15 09 10 18 09 00 06 00 1C 10 09
0D0: 14 02 09 09 10 09 09 1F 14 1E 1B 09 01 00 19 14
0E0: 15 09 15 01 12 08 1C 04 01 08 09 10 05 14 01 01
0F0: 17 04 00 18 09 10 0B 07 00 1A 09 10 09 01 14 07
100: 09 08 10 09 1C 04 10 09 10 10 1A 02 19 11 1B 05
110: 10 01 09 12 03 00 00 1D 14 0C 02 10 19 10 09 10
120: 00 10 19 05 01 17 1D 13 09 09 14 11 07 05 09 09
130: 11 10 16 00 02 08 1C 0C 02 0C 14 08 08 06 16 04
140: 02 00 01 09 1E 09 01 0D 1A 01 15 08 1C 01 0C 10
150: 08 10 09 19 09 02 01 13 03 1A 12 14 0C 09 00 16
160: 19 14 09 05 08 00 04 09 16 09 1C 01 19 03 15 19
170: 19 09 1A 1E 01 15 15 0A 16 1C 04 00 1A 00 19 0C
180: 16 10 08 19 09 10 1F 15 1D 13 1E 01 1E 01 0C 10
190: 09 01 01 16 1F 01 0E 19 09 09
-Frank
Back to comp.sys.apple2 | Previous | Next — Previous in thread | Next in thread | Find similar
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