Hi Ruud,
>New X1541-cable,
>
>A lot of people happily use the X1541-cable to connect their PC with their
>C= equipment. I was one of them until one day my PC started to smoke. I
>opened my PC and found out that my I/O-card had gone to the moon. From that
>day on I used X1541 only in combination with an old-fashion all-TTL-ICs
>card and was happy again.
Happily I gone into that conclusion in very early time :-)
>When soldering the cable I instantly knew there was something fishy about
>it because I knew the lines of the IEC-bus were used to transport signals
>in two directions while the LPT-port had no line capable of doing this.
And the authors of X1541 supported programs doesn't mention risk came with it.
>The problem is that more and more users, including myself, have mother-
>boards with an onboard LPT-port and no hair on my head thinks of it using
>this port for things like X1541. It is easy to say to buy an extra card for
>this purpose but I also have no confidence in these as they are fitted with
>VLSI-chips as my I/O-card was.
>The hardware:
>
>There are two directions to go:
>1) using transistors, resistors etc.
>2) using TTL ICs
Or
3) Use resistors in range 100-200 Ohms, so risk could be minimized (but not
resolved) and programs should support that little modification :-).
>Another idea is to use pin 10, Acknowledge, as input for the ATN-signal
>because this input is capable of generating an interrupt. This can be an
>advantage when using the PC as diskdrive for an C64.
I can remember that some cards won't like correctly generate interrupts.
>Extra idea:
>
>The datalines of LPT-port are not used. How about connecting them to the
>userport for 8 bit parallel transfers?
I already connected and works perfectly.
>For the old ports this can only be used for reading but for bidirectional
>ports.... (And I rebuild an old one :-) )
Done. What about my version?
http://members.tripod.com/~Frank_Kontros/easyport/cable.gif
OK! Needs bi-directional port, but simple.
>The consequence is that to use this feature the kernal has to be changed.
Changed successfully. Not completed, but the whole serial protocol emulated by
parallel way, fastload/save/verify, DOS WEDGE, F-keys.
>Yvo Nelemans wrote Server64 and he wrote it in Turbo Pascal :-). He stopped
>with the devellopment and I have decided to resume with this project after
>getting his permission. Server64 is meant to use the PC as diskdrive for
>the C64. Unfortunally it also is as slow as a standard diskdrive in
>combination with a standard C64.
I wrote it in asm, so you can compare the speedz. Just only 10 native mode drives
emulated and a 256K REU, but in future ... anything possible.
>My questions to you are:
>1) does anybody have detailed protocol specifications of a fastloader only
>using the IEC-cable (example EXOS V3) and/or its sourcecodes?
>2) the same for a parallel fastloader (like SpeedDos)?
In my opininon there are no fastloader specifications at all. All transfer
operations should be maximally synchronized. There are general rules, but
no specifications. Isn't you meant the burst protocol specifications, used
in 1571/81 drives?
Regards,
Frank
-
This message was sent through the cbm-hackers mailing list.
To unsubscribe: echo unsubscribe | mail cbm-hackers-request@dot.tcm.hut.fi.
Archive generated by hypermail 2.1.1.