Hello André, * On Tue, May 29, 2018 at 10:18:21PM +0200 afachat@gmx.de wrote: > The converted 1541 would give, after reset, a correct status, but a detect > command would result in a message like > > 8: *unknown*, footprint=<F@NJ> > > however the footprint number is actually changing from detect to detect. The "unknown" is to be expected (as the footprint is not known). However, the footprint should be stable. As it is not, it is a sign that there is a communication problem. The identification is rather simple at the moment: It reads in two bytes from $FF40 and compares it against known magic numbers. If it is $AAAA, then it uses the value of $FFFE/$FFFF instead. Obviously, this is very well suited for the 154x and 157x, but does not fit very good for other ROM variants. From what I see, the footprint is output as: 1. Let the variable "magic" be the word from $FF40 (or $FFFE). Let it be 'wxyz', in hex. For example, if it is $12B4, then w=1, x=2, y=$B, z=4. 2. The 1st char of the footprint is: w | 0x40 3. The 2nd char of the footprint is: x | 0x40 4. The 3rd char of the footprint is: y | 0x40 5. The 4th char of the footprint is: z | 0x40 Thus, your output F@NJ, hex 46 40 4e 4a, translates to a magic byte of $60ea. Looking at the other values: - DBDC --> hex 44 42 44 43 --> magic byte $4243 --> 'BC' (if interpreted as petscii) - B@EC --> hex 42 40 45 43 --> magic byte $2053 --> ' S' (if interpreted as petscii) - C@BL --> hex 43 40 42 4c --> magic byte $302C --> '0,' (if interpreted as petscii) - DOB@ --> hex 44 4f 42 40 --> magic byte $4F20 --> 'O ' (if interpreted as petscii) That's interesting, because this results in some (simple) text-like answer. Perhaps, the floppy answers with some error message? "0," indicates that it might be an output like on the error channel, Looking at the ROM 901484-05, which is the most likely ROM for the 2031LP, then we see that $FF40 contains $AAAA, thus, $FFFE is important, and that is $FEB6. Thus, the footprint should be <ONKF>. None of your footprints matches this. Thus, it seems we have a severe communication problem. As the 2031 is so similar to the 154x, I am sure that the commands must be interpreted the same as there. Thus, I can rule out command differences, and it must be a communication problem. If you try the tests multiple times, do you see some footprint more other? Or are they completely random? Especially the C@BL --> "0," is interesting, it might be part of a "30,SYNTAX ERROR..." message from the floppy! I see that Ethan had to DOB@ more oftern, which indicates "O " text, but also the C@BL which indicates the "0,". > The 2031LP also was giving strange errors on detection. After drive power up, > status gives the correct message, but detect also returns a similar message to > the one above. That's interesting. "status" does not perform much communication from ZF to the floppy. It justs send a TALK, and then the floppy has to talk. The detect, on the other hand, has to send a M-R command to the floppy in order to operate. That might be an indication that the communication from the 2031 to the ZF works, but the other way, there are problems. Can you execute the following commands: cbmctrl reset; sleep 5; for ((I=1; I<20; I++)); do cbmctrl status; done Does the status look good in all cases? Does the communication stop at some point of time? Of course, if you like, feel free to do more than 20 executions. ;) > Interesting. It seems either the 2031 has a problem with the IEEE488 protocol > of the zoomfloppy, or something is different with I guess M-R with which the > ROM is read (and the drive type detected?) Exactly, it is M-R that is read. However, looking at the ROM code, the 2031 does not differ at all in the implementation of M-R from the 154x. If there were problems, I would have expected them for the 1001, as the implementation might differ. Regards, Spiro. -- Spiro R. Trikaliotis http://www.trikaliotis.net/Received on 2018-05-30 23:19:42
Archive generated by hypermail 2.2.0.