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 00:00:50 -0700 Organization: A noiseless patient Spider Lines: 156 Message-ID: References: <9e054763-c065-493a-8b57-1bc7abe93cd7@googlegroups.com> <8fa4554d-e86b-4f60-8282-39960a6834bd@googlegroups.com> <3a8b9739-0f8a-497e-8168-cc93b6d84956@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="3f7daab8c080c0d7ccea7a857596d713"; logging-data="1486"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18WxZlNmg4kSdSvkYFZD9gEuurm053ii+w=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:M85g5ndu9srKi5UcbqO/zW2DkLY= sha1:XmycM4dERdXrHjKVrqPMsrAxBy0= Xref: csiph.com comp.sys.apple2:26785 Frank Schnorbus writes: [...] > Hi Jerry, > > Thanks! First here is a short update, then let me ask a favor. Not > being a programmer, and Python not being on my machine, I thought, OK, > let's go get it and see what happens. I got it installed, along with > the latest edition of Tcl/Tk to make it all work. And of course I > don't know what to do with it once it launches; I don't see a way to > input the code you've provided. I also don't "see" the way the bits > are stacked by just looking at the Python code or remarks; not > surprising given that Python is new to me. > > So here's my request; if you have Python running, can you plug in the > code you've got above, import the 256 bytes I have above, and send me > the 410 bytes you get in the output? I will compare that with the 410 > I "think" they should be. Presuming, of course, that this Python code > is arranging the bits in the same order that Apple DOS 3.2 > does. Whoever made the Python code was reading and writing Apple DOS > 3.2, right? 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. Will you repost them here or email them to me? My python code is part of a fairly complete disk-image reading/writing tool that I haven't taken the time to put on the web. I might do that some time. It can read/write most apple disk-images (nib, dsk, 2mg). I shouldn't have any trouble turning the 256 bytes into 410 5&3 nibbles. ----- I'll try to describe what the preNib53 routine does better than the comments: The input buffer is 256 bytes, indexed 0...255. Each byte contains eight valid bits. The output buffer is 410 bytes, index 0...409. Each byte contains five valid bits. Input bytes 0, 5, 10, ... 245, 250 are read and have their 5 most-significant bits, that is, bits 7...3, shifted to bits 4...0 in the output buffer. Input byte 0's bits get stored in output byte 50, input byte 5's bits get stored in output byte 49, and so on, down to input byte 250's bits getting stored in output byte 0. Hopefully that makes sense. Then the process repeats with input bytes 1, 6, ..., 251, being stored in output bytes 101, 100, ..., 51. And so on for 2, 7, ..., 252. And 3, 8, ..., 253, and then 4, 9, ..., 254. Input byte 255 is handled specially. Its 7...3 bits go into output byte 255. Its 2...0 bits go into output byte 409. Next, the low-order 3 bits have to be rearranged. Output byte 306 gets input byte 0's bits 2...0, input byte 3's bit 2, and input byte 4's bit 2. This process repeats in the same step-by-five input bytes fashion as above, except there are only three groupings, not five. Another way to describe this part is that for the input bits 2...0, bytes 0, 5, ..., 250, then 1, 6, ..., 251, then 2, 7, ..., 252 have their bits 2...0 kept in the same output byte (306...256, 357...307, and 408...358, respectively). This leaves the input bytes 3, 8, ..., 253 and input bytes 4, 9, ..., 254 to have their bits 2...0 spread across the above three groups of 153 bytes. The "2" bits go with the first group, that is, into output bytes 306, 305, ..., 256. The "1" bits go into output bytes 357, 356, ..., 307, and the "0" bits go into output bytes 408, 407, ..., 358. So for some examples: Input byte 4. Its bits are HGFEDCBA (bits 7 --> 0). Bits HGFED are stored into output byte 254 as 000HGFED. Bits CBA are stored into bit 0 of output bytes 306, 357, and 408, respectively: 306: 000????C 357: 000????B 408: 000????A Another example, let's pick input byte 201. 201 divided by 5 is 40 remainder 1. Thus, bits HGFED are headed for output byte 61: 61: 000HGFED Its bits CBA, because the remainder is 1, stay together and go into 317: 000CBA?? The question marks are filled in from other input bytes. I hope that makes some sense. It might even make the comments below more understandable (but I obviously ought to improve them because they are vague.) In the source-comments, a.b:c implies "a" is the byte index, and "b:c" are the contiguous bits from that byte. "a.b" indicates a single bit, "b" from byte "a". || """ || Map 256 8-bit bytes to 410 5-bit nibbles. || Output is 410 bytes in range 0..31. || || Input Output (bits 4:0) || 0.7:3 50 0x32 0.7:3 || 5.7:3 49 0x31 5.7:3 || ... || 250.7:3 0 0x00 250.7:3 || || 1.7:3 101 0x65 1.7:3 || 6.7:3 100 0x64 6.7:3 || ... || 251.7:3 51 0x33 251.7:3 || || 2.7:3 152 0x98 2.7:3 || 7.7:3 151 0x97 7.7:3 || ... || 252.7:3 102 0x66 252.7:3 || || 3.7:3 203 0xcb 3.7:3 || 8.7:3 202 0xca 8.7:3 || ... || 253.7:3 153 0x99 253.7:3 || || 4.7:3 254 0xfe 4.7:3 || 9.7:3 253 0xfd 9.7:3 || ... || 254.7:3 204 0xcc 254.7:3 || || 306 0x132 0.2:0, 3.2, 4.2 || 305 0x131 5.2:0, 8.2, 9.2 || ... || 256 0x100 250.2:0, 253.2, 254.2 || || 357 0x165 1.2:0, 3.1, 4.1 || 356 0x164 6.2:0, 8.1, 9.1 || ... || 307 0x133 251.2:0, 253.1, 254.1 || || 408 0x198 2.2:0, 3.0, 4.0 || 407 0x197 7.2:0, 8.0, 9.0 || ... || 358 0x166 252.2:0, 253.0, 254.0 || || 255.7:3 255 0xff 255.7:3 || 255.2:0 409 0x199 255.2:0 -- -- Jerry awanderin at gmail dot com