Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: awanderin Newsgroups: comp.sys.apple2 Subject: Re: DOS 3.2, 3.3 and ProDOS GCR in RWTS Date: Sun, 17 Jan 2016 23:29:49 -0700 Organization: A noiseless patient Spider Lines: 172 Message-ID: References: <3a8b9739-0f8a-497e-8168-cc93b6d84956@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Injection-Info: mx02.eternal-september.org; posting-host="3f7daab8c080c0d7ccea7a857596d713"; logging-data="28833"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX182YGNfiTONosYimNm062a9cYInq8xe+ps=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:Tb9cyRhLpFrE7EYz61JIfm6KHZw= sha1:a+lxjoL67/8okprSXcmSs4gCQfg= Xref: csiph.com comp.sys.apple2:26801 ultramagnus_tcv 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. > > 0138B0034C32A18643C903088A29704A4A4A4A09C08549A0FF844828C8B148D03AB00EA90= 38D0008E63DA54948A95B486085408548A063B148999409C8C0EBD0F6A206BC1D09BD240999= F209BD2B099D7F0ACA10EEA9098549A986A000C9F9B02F85488460844A844C844E8447C8844= 2C88446A90C8561854B201209B068E661E661E646A546C90690EFAD000C0D010CD06DA904D0= 02A54A186D230CA8900DE64BA54B4AB006C90AF055A004844AAD0209290FA8B14AD90209D0D= B8810F629F0C920D03BA010B14AC9FFD033C8B14A8546C8B14A8547A900854AA01E844B8461= C8844D201209B017E661E661A44EE64EB14A8546B14C8547114AD0E74C00204C > > > 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 =3D inbuf[y] > TypeError: 'long' object has no attribute '__getitem__' > > If I pass the bytes as a string, I get... > out[x] =3D 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 =3D '0138B0034C32A18643C903088A29704A4A4A4A09C08549A0FF844828C8B= 148D03AB00EA9038D0008E63DA54948A95B486085408548A063B148999409C8C0EBD0F6A206= BC1D09BD240999F209BD2B099D7F0ACA10EEA9098549A986A000C9F9B02F85488460844A844= C844E8447C88442C88446A90C8561854B201209B068E661E661E646A546C90690EFAD000C0D= 010CD06DA904D002A54A186D230CA8900DE64BA54B4AB006C90AF055A004844AAD0209290FA= 8B14AD90209D0DB8810F629F0C920D03BA010B14AC9FFD033C8B14A8546C8B14A8547A90085= 4AA01E844B8461C8844D201209B017E661E661A44EE64EB14A8546B14C8547114AD0E74C002= 04C' >>> s =3D bytearray([int(sector[i:i+2], 16) for i in range(0, len(sector), = 2)]) >>> o =3D 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: >> 0138B0034C32A18643C903088A29704A4A4A4A09C08549A0FF844828C8B148D03AB00EA9= 038D0008E63DA54948A95B486085408548A063B148999409C8C0EBD0F6A206BC1D09BD24099= 9F209BD2B099D7F0ACA10EEA9098549A986A000C9F9B02F85488460844A844C844E8447C884= 42C88446A90C8561854B201209B068E661E661E646A546C90690EFAD000C0D010CD06DA904D= 002A54A186D230CA8900DE64BA54B4AB006C90AF055A004844AAD0209290FA8B14AD90209D0= DB8810F629F0C920D03BA010B14AC9FFD033C8B14A8546C8B14A8547A900854AA01E844B846= 1C8844D201209B017E661E661A44EE64EB14A8546B14C8547114AD0E74C00204C >> >> >> And here are the actual bytes written to the disk: >> ACB6EDF2FF9EB7FBD9F9FDF6F9DAEFEE9DB9EDDADDDDAEFEF2A6DBEDF3CFFAF7EED7F4FF= F4CEE6EDF4D3CDE9EBEFCED3CDFEF5EBDDA7DAE5B6FAD9FAD9F7F2F6EACD9DABF5FCEDEFFAE= 9E7BCB9F9BAF3FDB29DABAB9B9AB2D9E9B7D3DBABEED9EF9AD6DFBBB2969696B4EFB5F2FABC= CFF2BDF7CFFEDDFAD9ECE5E6DADA9AFBF5DDFB96F7FC9DACF9EEEEF2FAEDF3FEF39BDEED9AA= CB2ABBAE5EBDF9EEADDADDBBFFEEADCA7DCF7CEEDF5FFB5DFDAF2F7ADABDFEFAEB6DEE6F2F2= F9F9F2F2EFEFEFEFEDDAB7EED9B7EDFBE5D9F9F9F2BFAE9FEBF5DAD7D7D7D7DFF7F7DAF2DCD= 3B4E79B969B9BF6ECEEE7F4F3E5FBB9CEB7ADE5B2DEFAE7FBFB96FEEAF2EDFEE5FDE5D6F2F9= E79AA7ABE59FFEDBF59AF59AB9DDF9F6F5B2FAFCFADDE9DFFED6AFADF7FECFFEF2EDDACFFEF= 2EDFBE6D7F2FAECDDF2F2F9E6B7EFCBAE9FEBE5FCD7D7D7EEFAE6E6FFFEF2EDFDFFEFEDBABB= DDAFE6B7A7CBB7 >> >> >> 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