Re: PC as 1541

From: Spiro Trikaliotis <ml-cbmhackers_at_trikaliotis.net>
Date: Thu, 28 Apr 2011 21:02:11 +0200
Message-ID: <20110428190211.GD21751@trikaliotis.net>
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 list
Received on 2011-04-28 20:00:12

Archive generated by hypermail 2.2.0.