Re: PICs on Linux

Re: PICs on Linux

[Ryan Underwood]

Hello,

On Sat, Nov 06, 2004 at 10:12:04PM -0600, easlab@absamail.co.za wrote:
> 
> Ryan Underwood wrote:
> > /etc/dosemu/dosemu.conf
> > 
> > If you want to disable the printer driver completely, here's what is in
> > my modules.conf, but on your system it might differ:
> > 
> I don't "want" to do anything other than use the parport to drive
> the device as it would under DOS. 

fine (?)

> Especially I don't want to get married to DOSEMU.

I'm not sure what you mean by this.  You will need to be familiar with
DOSEMU in order to make use of it.

> Apparently OP wrote that one needs to "disable the printer driver" ?

The printer driver and DOSEMU's port passing cannot share the physical
printer port.  Therefore you need to disable the printer driver if you
want to use DOSEMU's port passing, either temporarily or permanently.

> > # Don't load lp driver.
> > 
> > alias char-major-6 off
> > alias /dev/printers* off
> > alias /dev/lp* off
> 
> Thanks, apparently that would acheive 1 of the 3 requirements 
> which OP listed ?
> 
> I've seen info. about:
> $_ports = "0x378 0x379 0x37a"

Yes, and remember to use 'fast' unless you want to do debugging/tracing:
$_ports = "fast range 0x378 0x37a"

means pass through 0x378-0x37a in fast mode.

> So now I need to investigate: "2. pass the IRQ to DOSEMU,"

It's directly underneath $_ports in the config file ($_irqpassing).

You have to start DOSEMU as root or use sudo in order for port/irq
passing to work.

-- 
Ryan Underwood, <nemesis@icequake.net>

Re: PICs on Linux

[Bart Oldeman]

Hello,

> The printer driver and DOSEMU's port passing cannot share
> the physical printer port.  Therefore you need to disable
> the printer driver if you want to use DOSEMU's port
> passing, either temporarily or permanently.
>
> Yes, and remember to use 'fast' unless you want to do
> debugging/tracing: $_ports = "fast range 0x378 0x37a"
>
> means pass through 0x378-0x37a in fast mode.
>
> You have to start DOSEMU as root or use sudo in order for
> port/irq passing to work.

It's still a bit tricky. This is the nature of direct
hardware access under Linux, the jail around you (protected
mode OS) needs to be partially broken down. There are
security issues to deal with, etc etc. -- this is why we can
never let this happen out of the box for a normal (non-root)
user.

This is not unique to Linux, under Windows XP there are even
people trying to make a buck selling direct hardware access.
http://www.zeecube.com/ParPort2004.htm
we don't ask for $19.95 but you have to pay in other ways
(trickier setup) so to speak.

However:
Linux 2.4 and 2.6 kernels provide a ppdev device driver that
allows raw parallel port access via /dev/parports/0 etc.
DOSEMU could virtualize the parallel port hardware and
re-route it through that device thereby avoiding the root
issue. I don't have any parallel port hardware to play with
but it could be a nice little project to implement in DOSEMU
one day.

Speed shouldn't be such a big deal: according to
http://www.ussg.iu.edu/hypermail/linux/kernel/0303.0/0978.html
you can only do about 300000 inb's and outb's per second
anyway.

Bart

Re: PICs on Linux

[Bart Oldeman]

> However:
> Linux 2.4 and 2.6 kernels provide a ppdev device driver
> that allows raw parallel port access via /dev/parports/0
> etc. DOSEMU could virtualize the parallel port hardware
> and re-route it through that device thereby avoiding the
> root issue. I don't have any parallel port hardware to
> play with but it could be a nice little project to
> implement in DOSEMU one day.

Wine has this already:
http://cvs.winehq.com/cvsweb/wine/dlls/winedos/ppdev.c?rev=1.3
it may even be fairly easy to port this.

Bart

Re: PICs on Linux

[Ryan Underwood]

Hi Bart,

On Mon, Nov 08, 2004 at 02:21:16PM +1300, Bart Oldeman wrote:
> 
> Speed shouldn't be such a big deal: according to
> http://www.ussg.iu.edu/hypermail/linux/kernel/0303.0/0978.html
> you can only do about 300000 inb's and outb's per second
> anyway.

Speed betweeen a virtualized and non-virtualized parallel port I/O can
be a big deal in my experience.  I have at least one device that gives
up when parallel ports are passed through in non-fast mode.  It operates
with tristate data lines and one strobe pin.  I'm not sure what the
problem is, only that the port must be fast for it to work.  On a
(much?) faster machine, probably the port virtualization would not
affect it.  But requiring the use of ppdev doesn't make sense in this
case.

By the way, I have benchmarked ppdev vs raw portio performance on this
device with a linux program.  The difference is quite significant (ppdev
only performs around 60% of the rawio speed IIRC).  On a better device
which uses interrupt or DMA driven I/O, the difference would not be that
significant, but on this device, transfer rate depends on how fast the
registers of parallel port can be "twiddled", so it is greatly affected
by any delay therein.

-- 
Ryan Underwood, <nemesis@icequake.net>

Re: PICs on Linux

[Bill Couture]

On Thu, 11 Nov 2004, Ryan Underwood wrote:

> Check dosemu-devel@lists.sourceforge.net.  That is where the development
> related traffic happens.  linux-msdos@vger.kernel.org is still alive but
> most user questions are handled through the sourceforge tracker in these
> days.

OK, I'll take a look.

> > When I looked at DOSEMU, I quickly noticed that the CPU flags were
being
> > done wrong.  I should look at it again and see if they have been
fixed.
>
> Can you be more specific please, and/or file and issue in the bug
> tracker?  This sounds like something that would be a good idea to fix.

I'll have to look at my archives, but as I remember when I saw that he
was computing flags by some logical method rather than doing the actual
operation and looking at the results, it didn't seem right to me (i've
done a 80x86 emulator before, in the mid-80's -- very useful as a
debugger).

The problem showed up with instructions like ADC and SBB, where CY was
not 0.  Thus, you had 3 values going into the computation and affecting
the flags, in which case the flags were wrong in some cases.

As I said, I'll have to go into my archives and try to find it.

Bill