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.