From: Jim Brain (brain_at_jbrain.com)
Date: 2008-11-07 19:05:10
Marko Mäkelä wrote:
> In the summer of 2003, around the time I became a father, I implemented
> serial bus interface for the C2N232 adapter. By December, I had it mostly
> working, except that it couldn't talk to a 1541. It would emulate up to
> 32 devices. I tested by issuing LOAD, SAVE, OPEN, GET#, PRINT# commands
> on the C64 or VIC-20 and by sending appropriate control/data sequences
> to the modified C2N232 over RS-232.
>
Yep, I remember looking at your protocol and discussing this back in 2005.
> I made the interface very low-level. The firmware running in the C2N232
> takes care of asserting the bus or responding to ATN. It can act as a
> controller or as up to 32 devices. (You tell it which serial bus device
> numbers it will emulate.) It will relay all commands and data over the
> RS-232 link. The software running on the PC would act as appropriate
> (emulating disk drives and printers, or emulating a host that talks to
> real serial bus hardware).
>
I implemented the low level protocols in 2005, and found that RS232
communication interfered with transfers resulting in corrupt data. I
was not able to resolve the issue. I remember one example:
64 would open a file for reading.
low level protocol would send 2 command bytes + filename.
PC would open file and send ack back
64 would open channel for reading
low level protocol would send 2 command bytes
PC would respond with 254 of data
64 would issue GET#,A$
low level protocol would send 1 byte of data back
64 would immediately bring ATN low
low level protocol would then send ack to PC telling it that 1 byte had
been sent
64 would send 2 more command bytes...
Under load, the link would get saturated with chatter and the system
would often corrupt data. Another example generated the same issue and
corrupted file loads. While I am no IEC expert, I finally gave up.
To contrast, I implemented a high level protocol the other day that let
the uC maintain buffer positions and only sends/receives data in blocks,
and it works fine.
I also support fastloaders, which further complicates a low level
protocol, but has no impact on the high level protocol.
> Wolfgang Moser just made me aware of the sd2iec a couple of days ago. It
> feels like a good idea. I was wondering if you could implement some tape
> emulation in it. However, that would require some user interface (LEDs or
> display and some buttons) for selecting the image to read or write (virtual
> tape control; play/rec/fast-forward/rewind). Maybe not worth the trouble
> and additional hardware cost.
>
uIEC uses the sd2iec firmware, and it's the same firmware I hacked to
implement my initial high level protocol. It works fine, even at
500,000bps.
Thus, while I agree there might be some utility in a low level protocol,
I'd rather concentrate my efforts on a high level protocol at this time.
Jim
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.