Hello, * On Tue, Apr 26, 2011 at 10:38:28PM +0200 Gábor Lénárt wrote: > On Tue, Apr 26, 2011 at 09:04:07PM +0200, Spiro Trikaliotis wrote: > > The problems are different when using the PC as a IEC controller > > (connecting a 154x TO a PC) instead when using the PC as floppy drive. > > > > In both cases, there is the problem with the "listener hold off" (cf. > > http://www.trikaliotis.net/opencbm#faq_hw, second question). This one is > > solved with the "multitask cable(s)" XM1541 and XA1541. > > > > OTOH, a IEC drive must react to an activated ATN within 1ms, or the > > controller (the C64, C128, or whatever) will miss that it is connected. > > 1ms seems like a long time; unfortunately, with a multitasking OS, it > > can be tricky to achieve this. That's why a DOS only solution is much > > easier here: You have control about the exact timing. > > I am wondering if it's possible to use ATN line then to generate an IRQ on > the PC side (so you don't need polling). Neglecting that the "market" for a parallel port based solution will get smaller and smaller: In principle, this would be possible, yes. Unfortunately, the number of parallel port input lines is limited on the PC. Even worse, the number of input lines that can generate an IRQ is much more limited: You only have one line. For the listener hold off, we already need the DATA line generate an interrupt. We could add the ATN line, so both DATA and ATN generate an IRQ. However, then we would need another input line (to distinguish ATN and DATA), which we do not have. In fact, the current X*1541 cables all do not have an ATN input line at all! Furthermore, we already have enough problems with the IRQ. Some cards do not generate any interrupt at all, other cards generate it on the wrong edge (very bad) or on both (this is not a problem, OpenCBM can handle that). Then, it seems the OS even might not present the IRQ to us, even if it is generated (this seems to be the case in Windows in some cases). We can be lucky that OpenCBM even works at all, at least on most machines! The 1541EMU cable is special again, as it allows the PC to act as a floppy ONLY. That is, the 1541EMU cable is no full replacement for an X*1541 cable! > This means the need to write a > custom driver then of course, but maybe it can be done then using a more > modern OS (I am thinking about Linux, anyway I wouldn't try to write a > device driver for Windows ...). You are aware that OpenCBM runs on Linux? Even more, OpenCBM started out on Linux (done by Michael Klein) and was ported to Windows by me afterwards. So, why is Linux a "more modern OS" then? > However I am still not sure, it can be > garantueed even with IRQ on the PC side to have that 1ms, and since I don't > know deeper thing on IEC protocol, I am sure it's not just this simple as I > imagine ... If the IRQ would not be able to guarantee 1 ms, then OpenCBM would not work. We most react to the listener hold off in less than 200 us, or the other side will think we are signalling an EOF condition. > Honestly, since the need of parallel port, MSDOS, etc, I think the way > should be followed to use some kind of uC at least, That's what the ZoomFloppy (or the XS1541 or the XU1541) is about. That's exactly why they were invented. Regards, Spiro. -- Spiro R. Trikaliotis http://opencbm.sf.net/ http://www.trikaliotis.net/ http://www.viceteam.org/ Message was sent through the cbm-hackers mailing listReceived on 2011-04-28 20:00:12
Archive generated by hypermail 2.2.0.