Commodore 2031LP and Zoomfloppy

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Commodore 2031LP and Zoomfloppy

André Fachat
Hi there,

I was finally able to do some tests using my zoomfloppy and a real 2031LP, a
1541 converted to IEEE488 using the 64er schematics and ROM, and a 1001.

What I found was that the 1001 was working very well, even surviving the ROM
read test on it (a shell script that repeatedly reads the ROM and compares it
with what it should be).

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. I
also got values NIDJ, GNBI, NJNJ, DOB@ ....
In the end it also hangs, but that can be resolved by resetting the drive
(with the reset button I conveniently added when I converted it :-)

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.

Both, the 2031 and the 1541par fail reading their ROMs at all.

Just for the fun of it, I connected both the 1001 and 2031lp to the zoomfloppy,
to get this detection:

fachat@euler:~/Documents/8bit/OpenCBM/opencbm/internal/testsuite$ cbmctrl
detect
 8: *unknown*, footprint=<DBDC>
 9: 8250 dos2.7
fachat@euler:~/Documents/8bit/OpenCBM/opencbm/internal/testsuite$ cbmctrl
detect
 8: *unknown*, footprint=<B@EC>
 9: 8250 dos2.7
fachat@euler:~/Documents/8bit/OpenCBM/opencbm/internal/testsuite$ cbmctrl
detect
 8: *unknown*, footprint=<C@BL> (cannot determine cable type)
 9: 8250 dos2.7
fachat@euler:~/Documents/8bit/OpenCBM/opencbm/internal/testsuite$ cbmctrl
detect
 8: *unknown*, footprint=<DOB@>
 9: 8250 dos2.7

But still failing to read the ROM. But at least it does not disturb reading
the ROM on the 1001.

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?)

Regards
André


Reply | Threaded
Open this post in threaded view
|

Re: Commodore 2031LP and Zoomfloppy

Ethan Dicks
On Tue, May 29, 2018 at 4:18 PM,  <[hidden email]> wrote:
> Hi there,
>
> I was finally able to do some tests using my zoomfloppy and a real 2031LP, a
> 1541 converted to IEEE488 using the 64er schematics and ROM, and a 1001.
>

> 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. I
> also got values NIDJ, GNBI, NJNJ, DOB@ ....
> In the end it also hangs, but that can be resolved by resetting the drive
> (with the reset button I conveniently added when I converted it :-)

With my 2031LP, I also noticed a pattern of what appeared to be status
text (lots of '0' and some ',' and parts of the ASCII of DOS status
messages) intertwined with the footprint.  I posted some examples a
couple of weeks ago from my tests.

> 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.
>
> Both, the 2031 and the 1541par fail reading their ROMs at all.

That looks just like my experience with my ZF and my 2031LP.  I got
zero file-size on attempting to download the ROMs.

> 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?)

Could be a problem with M-R I suppose.

I don't know the 1001 drive but the 2031LP happens to use 75160/75161
IEEE drivers and I'm wondering if there's a subtle difference in
handshaking or a delay in turning around the interface on the drive
compared with drives with the 3x 3446 buffers.  I used to do some IEEE
hacking in the PET days but I don't know how the 6502 has to change to
use the newer line drivers.

-ethan

Reply | Threaded
Open this post in threaded view
|

Re: Commodore 2031LP and Zoomfloppy

Spiro Trikaliotis
In reply to this post by André Fachat
Hello André,

* On Tue, May 29, 2018 at 10:18:21PM +0200 [hidden email] 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/

Reply | Threaded
Open this post in threaded view
|

Re: Commodore 2031LP and Zoomfloppy

André Fachat
Hi Spiro,

On Mittwoch, 30. Mai 2018 23:19:42 CEST Spiro Trikaliotis wrote:

> Hello André,
>
> * On Tue, May 29, 2018 at 10:18:21PM +0200 [hidden email] 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.

Indeed this seems to be the case.

....
> 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,

This is exactly what seems to be happening. I added some debug output to
xum1541.c, to see what data is actually transferred on the host side, and saw
that the result always looked like part of a status message, sometimes even
just from the 00, OK,00,00
 
> 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.

I am currently looking at the transition from SecListen to Bsout - it seems to
me that there is something going horribly wrong.

> 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.

This side of the communication seems to work reliably.
 

> 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?

The command you wrote executes completely as expected. It just shows the drive
status 20 times, from the first "73,cbm dos v2.6 2031,00,00" to 19 following
"00, ok,00,00".

> > 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.

Yes, I currently also suspect the IEEE 488 communication.

Regards,
André


Reply | Threaded
Open this post in threaded view
|

Re: Commodore 2031LP and Zoomfloppy

André Fachat
In reply to this post by André Fachat
Just for your info, I think I found the problem and spiro already merged
the fix.

The problem seems to have been that there was not enough time between DAV
going high on the last data byte before an UNLISTEN, and the ATN going low.
The drive detected both in the same read and ignored the valid byte as it
also saw ATN going low. A small delay after sending the last data byte
seems to fix this problem just fine, the 2031 now works fine and stable
with the zoomfloppy with the updated opencbm firmware.

Cheers
André


Am 29. Mai 2018 22:20:18 schrieb [hidden email]:

> Hi there,
>
> I was finally able to do some tests using my zoomfloppy and a real 2031LP, a
> 1541 converted to IEEE488 using the 64er schematics and ROM, and a 1001.
>
> What I found was that the 1001 was working very well, even surviving the ROM
> read test on it (a shell script that repeatedly reads the ROM and compares it
> with what it should be).
>
> 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. I
> also got values NIDJ, GNBI, NJNJ, DOB@ ....
> In the end it also hangs, but that can be resolved by resetting the drive
> (with the reset button I conveniently added when I converted it :-)
>
> 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.
>
> Both, the 2031 and the 1541par fail reading their ROMs at all.
>
> Just for the fun of it, I connected both the 1001 and 2031lp to the zoomfloppy,
> to get this detection:
>
> fachat@euler:~/Documents/8bit/OpenCBM/opencbm/internal/testsuite$ cbmctrl
> detect
>  8: *unknown*, footprint=<DBDC>
>  9: 8250 dos2.7
> fachat@euler:~/Documents/8bit/OpenCBM/opencbm/internal/testsuite$ cbmctrl
> detect
>  8: *unknown*, footprint=<B@EC>
>  9: 8250 dos2.7
> fachat@euler:~/Documents/8bit/OpenCBM/opencbm/internal/testsuite$ cbmctrl
> detect
>  8: *unknown*, footprint=<C@BL> (cannot determine cable type)
>  9: 8250 dos2.7
> fachat@euler:~/Documents/8bit/OpenCBM/opencbm/internal/testsuite$ cbmctrl
> detect
>  8: *unknown*, footprint=<DOB@>
>  9: 8250 dos2.7
>
> But still failing to read the ROM. But at least it does not disturb reading
> the ROM on the 1001.
>
> 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?)
>
> Regards
> André
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Commodore 2031LP and Zoomfloppy

Jim Brain
On 6/4/2018 7:58 AM, André Fachat wrote:

> Just for your info, I think I found the problem and spiro already
> merged the fix.
>
> The problem seems to have been that there was not enough time between
> DAV going high on the last data byte before an UNLISTEN, and the ATN
> going low. The drive detected both in the same read and ignored the
> valid byte as it also saw ATN going low. A small delay after sending
> the last data byte seems to fix this problem just fine, the 2031 now
> works fine and stable with the zoomfloppy with the updated opencbm
> firmware.
>
> Cheers
> André
Knowing how hard it is to pry time away from other worthwhile things to
add value to a project, please accept these thanks for the time you
spent on this.

Jim


Reply | Threaded
Open this post in threaded view
|

Re: Commodore 2031LP and Zoomfloppy

Ethan Dicks
On Mon, Jun 4, 2018 at 12:58 PM, Jim Brain <[hidden email]> wrote:

> On 6/4/2018 7:58 AM, André Fachat wrote:
>>
>> Just for your info, I think I found the problem and spiro already merged
>> the fix.
>>
>> The problem seems to have been that there was not enough time between DAV
>> going high on the last data byte before an UNLISTEN, and the ATN going low...
>
> Knowing how hard it is to pry time away from other worthwhile things to add
> value to a project, please accept these thanks for the time you spent on
> this.

Absolutely.  As someone with this hardware setup, I am grateful you
were able to drill down to the specific cause of the problem.

Looking forward to installing the next build.

-ethan

Reply | Threaded
Open this post in threaded view
|

Testing the IEEE firmware of ZF (was: Commodore 2031LP and Zoomfloppy)

Spiro Trikaliotis
In reply to this post by André Fachat
* On Mon, Jun 04, 2018 at 02:58:27PM +0200 André Fachat wrote:
> Just for your info, I think I found the problem and spiro already merged the
> fix.

André was so kind to also generate a firmware for testing. It would be
nice if this could be tested with as many IEEE drives as possible, as it
changes the timing. Especially the 2031 (which is known to not be
working before the patch) and a 8x50 or SFD 1001 (which are known to be
working before the patch) would be very interesting.

If anyone has some time for this, the binary of André is here:

https://raw.githubusercontent.com/fachat/OpenCBM/eeba73c7c06dd12c3cd95b2a683cd0d6b8fed1eb/xum1541/xum1541-ZOOMFLOPPY-v99.hex

Note that I specifically asked André to change to version of the binary,
so we can recognise it. It is know at version "99", don't be surprised.

For Windows users, you also need an adjusted .inf file.

Thank you for your help, and especially thanks to André for this find.


Regards,
Spiro.

--
Spiro R. Trikaliotis
http://www.trikaliotis.net/

Reply | Threaded
Open this post in threaded view
|

Re: Testing the IEEE firmware of ZF (was: Commodore 2031LP and Zoomfloppy)

Ethan Dicks
On Mon, Jun 4, 2018 at 3:09 PM, Spiro Trikaliotis
<[hidden email]> wrote:
> * On Mon, Jun 04, 2018 at 02:58:27PM +0200 André Fachat wrote:
>> Just for your info, I think I found the problem and spiro already merged the
>> fix.
>
> André was so kind to also generate a firmware for testing. It would be
> nice if this could be tested with as many IEEE drives as possible, as it
> changes the timing. Especially the 2031 (which is known to not be
> working before the patch) and a 8x50 or SFD 1001 (which are known to be
> working before the patch) would be very interesting.

I have a 2031 I'm happy to use for confirmation testing.  I also have
4040 drives and I think I have an 8050 up in the attic...  it might
even be possible for me to stuff an old set of chips into a 4040 and
turn it back into a 2040 but that won't happen this week.  In fact, I
won't have access to my hardware until Friday at the earliest.

> If anyone has some time for this, the binary of André is here:
>
> https://raw.githubusercontent.com/fachat/OpenCBM/eeba73c7c06dd12c3cd95b2a683cd0d6b8fed1eb/xum1541/xum1541-ZOOMFLOPPY-v99.hex

Perfect.

> Note that I specifically asked André to change to version of the binary,
> so we can recognise it. It is know at version "99", don't be surprised.

Got it.

> Thank you for your help, and especially thanks to André for this find.

Indeed!

-ethan

Reply | Threaded
Open this post in threaded view
|

Re: Commodore 2031LP and Zoomfloppy

André Fachat
In reply to this post by Jim Brain


Am 4. Juni 2018 7:00:24 PM schrieb Jim Brain <[hidden email]>:

> On 6/4/2018 7:58 AM, André Fachat wrote:
>> Just for your info, I think I found the problem and spiro already
>> merged the fix.
>>
>> The problem seems to have been that there was not enough time between
>> DAV going high on the last data byte before an UNLISTEN, and the ATN
>> going low. The drive detected both in the same read and ignored the
>> valid byte as it also saw ATN going low. A small delay after sending
>> the last data byte seems to fix this problem just fine, the 2031 now
>> works fine and stable with the zoomfloppy with the updated opencbm
>> firmware.
>>
>> Cheers
>> André
> Knowing how hard it is to pry time away from other worthwhile things to
> add value to a project, please accept these thanks for the time you
> spent on this.

Hi Jim,
it is always a pleasure to get something to work, and at the same time help
the community. Your thanks is very much appreciated, as I also thank you
for your excellent work and community support!

André