[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: EOR 02D6,Y For Disk II Family Again
Holger Picker <pickerh@uni-muenster.de> wrote in message
Pine.A41.4.44.0302251233040.82542-100000@zivunix.uni-muenster.de">news:Pine.A41.4.44.0302251233040.82542-100000@zivunix.uni-muenster.de...
> On Mon, 24 Feb 2003, Bryan Parkoff wrote:
>
> > Date: Mon, 24 Feb 2003 17:53:50 -0600
> > From: Bryan Parkoff <BParkoff@satx.rr.com>
> > Newsgroups: comp.sys.apple2
> > Subject: EOR 02D6,Y For Disk II Family Again
> >
If I may interject something here, Bryan, are you removing the prom and
reading it
with a prom reader?, or are you dumping it from the machine while it is
running?
The code may in effect be changing the values just before they are dumped,
this
in turn would return an incorrect value. I'm not really sure if Apple is
different, but
it was always taught to me that you should never attempt to assimlate
anything
while the machine runs. Just a thought.
> > I have taken a look at the PROM code below. It does not make sense
to
> > me when I look at EOR 02D6,Y at address: C6AF. I changed from EOR
02D6,Y to
> > TYA NOP NOP before I execute at address C6A6. I do see that all 56
bytes
> > are stored in $300-$356 using encoded translated characters (96-->FC).
I
> > changed from TYA NOP NOP back to EOR 02D6,Y before I execute at address
> > C6A6. I do see that all 56 bytes are stored in $300-$356 using decoded
> > translated characters, but 6-2 is NOT decoded YET.
> > I am trying to figure out how 96-->FC are translated back to the
> > original byte. For example, $DB is in $354, $B6 is in $355, and $00 is
in
> > $356. The loop starts at $56 before it decreases to $00. LDY C08C,X
reads
> > $B6 in $355. $B6 is stored in Y Register before EOR executes. It may
mean
> > EOR 02D6,$B6. $02D6+$B6=$38C. It is how EOR locates $38C to get $12
value,
> > but it does not translate correctly. I know that translatation table is
in
> > $36C-$3D5. Please advise.
>
> I think, I see your problem here. Indeed, normally you would expect that
an
> instruction like LDA $2d6,y is used to decode the byte, but instead you
find
> an EOR here. The reason for the EOR is that at the same time you decode
the
> disk nibbles, you also calculate the checksum for the whole data field.
Take
> a look at the very last EOR instruction at address $c6d0. Here the
> additional checksum value is loaded from disk, and again an EOR is used to
> "xor" it with the previously calculated checksum. If the result is zero,
> then the checksum test was successful (i.e. the calculated checksum and
the
> checksum read from disk are identical), if not, the program will start
again
> looking for the sector, because the data was not read correctly. To sum it
> up: EOR is used for the additional checksum test. Don't worry about that
the
> bytes are xored while decoding them, because a similar method (the other
way
> round) was used to code the disk bytes before writing them to the disk.
>
> Holger
>
> > C6A6: A0 56 LDY #56
> > C6A8: 84 3C STY WorkByte (3C)
> > C6AA: BC 8C C0 LDY StrobeDataLatch,X (C08C)
> > C6AD: 10 FB BPL C6AA {-05}
> > C6AF: 59 D6 02 EOR 02D6,Y
> > C6B2: A4 3C LDY WorkByte (3C)
> > C6B4: 88 DEY
> > C6B5: 99 00 03 STA VectorPage,Y (0300)
> > C6B8: D0 EE BNE C6A8 {-12}
> > C6BA: 84 3C STY WorkByte (3C)
> > C6BC: BC 8C C0 LDY StrobeDataLatch,X (C08C)
> > C6BF: 10 FB BPL C6BC {-05}
> > C6C1: 59 D6 02 EOR 02D6,Y
> > C6C4: A4 3C LDY WorkByte (3C)
> > C6C6: 91 26 STA (Low_SectorRdBufAddr),Y (26)
> > C6C8: C8 INY
> > C6C9: D0 EF BNE C6BA {-11}
> > C6CB: BC 8C C0 LDY StrobeDataLatch,X (C08C)
> > C6CE: 10 FB BPL C6CB {-05}
> > C6D0: 59 D6 02 EOR 02D6,Y
> > C6D3: D0 87 BNE C65C {-79}
> >
> >
> >
> > --
> > Yours Truly,
> >
> > Bryan Parkoff
> > BParkoff@satx.rr.com
> >
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/03