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
Thought I should pass it along. :)
P.S. Subscription info for CBM Hackers list is on my web-page - see link below.
--
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Larry Anderson - Sysop of Silicon Realms BBS (300-2400bd) (209) 754-1363
Visit my Commodore 8-Bit web page at: