[Emc-users] non-progress for Futurlec PCI8255 card

[Gene Heskett]

Greetings;

Last night I burned a cd with the whole tree of the 2.6.10-rc1-bk10
kernel on it, took it down to the box I hope to use and used mc to
copy it back to /usr/src.

A make xconfig bombed, apparently not all the X stuff is installed,
but a make menuconfig worked and I reset the .config for the diffs in
the mobo's and added the vendor/product stuffs to
drivers/pci/pci.ids, and rebuilt it, that took 65 minutes just for
the compile and install! The changes did make it into the
self-generated drivers/pci/devlist.h however.

On reboot to the new kernel, I half expected to see if find the board,
report it according to the data in pci.ids, but its totally ignoring
it yet. The stuff for 00:10.0 in the /proc system is still exactly
as before.

What would be the next step in cobbling up a driver for it?

[Paul]

Hi Gene

I would have thought it highly unlikely that any 2.6 kernel would have a
driver that would recognise your IO card - Do you have access to a M$
operating system ?
You might find the drivers supplied with the card will produce some usable
information - If not, then it will be a case of doing a dump
from /proc/bus/pci/00/10.0 (change to suit) and crafting a simple test driver
with some "best guess" routines.

Regards, Paul.

Post by Gene Heskett
On reboot to the new kernel, I half expected to see if find the board,
report it according to the data in pci.ids,  but its totally ignoring
it yet.  The stuff for 00:10.0 in the /proc system is still exactly
as before.
What would be the next step in cobbling up a driver for it?

[Gene Heskett]

Post by Paul
Hi Gene
I would have thought it highly unlikely that any 2.6 kernel would
have a driver that would recognise your IO card - Do you have
access to a M$ operating system ?

Unforch Paul, No. No M$ allowed on the premises. The last M$ code in
this place is in the roms of rsdos in several vintage TRS-80 Color
Computers, but they all boot to various versions of os9/nitros9,
kicking those roms out with a deselection. I could rustle up a copy
of drdos-7.02 on floppies, but I doubt that would be any good for
this.

I am trying to install from the cd, but not having a lot of luck
making it do what I'd like. Its toasted the old FC2 install by now,
but as it was formatting the filesystem, it came to me that if CFDisk
was smart enough, or maybe its the installer thats a bit simple, I
could split the 60GB main drive in two, put the bdi on half of it,
and FC3RC5 on the other half, and use grub to determine which it
booted. Each would have its own set of duplicated directories for
everything but /var that way, and invisible to the other unless they
were specifically mounted to a /mnt/other_half location.

But, I got so frustrated with the installer because it absolutely
insists on the swap partition being on the same drive as the install.
I've never, ever done that, always putting in an old, smaller drive
as hdb and using maybe 1GB of the outside of it as swap, and whatever
is left over as /var so that if the main drive gets a tummy ache &
goes read-only on me (its happened several times now due to a kernel
bug early in the 2.6.7 series), I still have system logs to tell me
whats getting sick. But, if I put emc on the main drive as its doing
right now, then the installer can't find the swap on the other drive.
This really ought to be fixed somehow. Anyway I gave up and pointed
the install at the inside, 51GB partition and let it do its thing I
guess so I can see how it runs from a hard drive.

I also ran a cable to it tonight, so I've got networking, or did till
I let it format /dev/hda8, but I can set that up again with minimal
trouble.

Better planning for the install is needed, but now that I know what
its going to do, I'll fix the appropriate /etc/fstab's after I make
an install on the front half of the disk, using the back half as
swap, then fix that partitions /etc/fstab to put swap on the first
partition of /dev/hdb, then install FC3 on the inside half, pointing
the root= line of grub.conf to the correct half of the main drive for
that boot. Sounds good anyway or does if I can stop that installer
from putting in lilo. :) I'm assuming it will ask first?

Humm, maybe this would be a good time to bite the bullet and actually
make wine work? It might be able to exercize that code thats in
the .exe files. I certainly don't have any M$ compiler tools
available though.

Anyway, I'm poking around, seeing if its got any ticklish spots :)

Post by Paul
You might find the drivers supplied with the card will produce some
usable information - If not, then it will be a case of doing a dump
from /proc/bus/pci/00/10.0 (change to suit) and crafting a simple
test driver with some "best guess" routines.

A cat of that is zero bytes long. Thats why I was fiddling with a
fresh kernel build, trying to trigger a better read or something.

Post by Paul
Regards, Paul.

Post by Gene Heskett
On reboot to the new kernel, I half expected to see if find the
board, report it according to the data in pci.ids,  but its
totally ignoring it yet.  The stuff for 00:10.0 in the /proc
system is still exactly as before.
What would be the next step in cobbling up a driver for it?

[Gene Heskett]

Post by Gene Heskett

Post by Paul
Hi Gene
I would have thought it highly unlikely that any 2.6 kernel would
have a driver that would recognise your IO card - Do you have
access to a M$ operating system ?

Unforch Paul, No. No M$ allowed on the premises. The last M$ code
in this place is in the roms of rsdos in several vintage TRS-80
Color Computers, but they all boot to various versions of
os9/nitros9, kicking those roms out with a deselection. I could
rustle up a copy of drdos-7.02 on floppies, but I doubt that would
be any good for this.
I am trying to install from the cd, but not having a lot of luck
making it do what I'd like. Its toasted the old FC2 install by now,
but as it was formatting the filesystem, it came to me that if
CFDisk was smart enough, or maybe its the installer thats a bit
simple, I could split the 60GB main drive in two, put the bdi on
half of it, and FC3RC5 on the other half, and use grub to determine
which it booted. Each would have its own set of duplicated
directories for everything but /var that way, and invisible to the
other unless they were specifically mounted to a /mnt/other_half
location.

And I just found a new problem. The install didn't install grub in
the mbr, which is what I would have liked, but I didn't let it. Then
since its getting rather sleepy out, I figured I'd do a gracefull
shutdown and attack it again for a few hours tomorrow. Unforch as
whatever user it left me as, I didn't have permissions to do a
shutdown. I tried an su - and entered the password, no dice, ditto
for an su root, bad password. So I hit the power switch. I'll redo
that partition and install tommorrow along the lines I've described
and see if I can make it work as a dual booting system, one to FC3RC5
and the other to your patched morphix. Can this live in a 10GB
world? That would leave me with enough for the fedora install to
grow, like they always do... Particularly if you run yum regularly,
which will eat up the /var with its cache in a few weeks.

Post by Gene Heskett
But, I got so frustrated with the installer because it absolutely
insists on the swap partition being on the same drive as the
install. I've never, ever done that, always putting in an old,
smaller drive as hdb and using maybe 1GB of the outside of it as
swap, and whatever is left over as /var so that if the main drive
gets a tummy ache & goes read-only on me (its happened several
times now due to a kernel bug early in the 2.6.7 series), I still
have system logs to tell me whats getting sick. But, if I put emc
on the main drive as its doing right now, then the installer can't
find the swap on the other drive. This really ought to be fixed
somehow. Anyway I gave up and pointed the install at the inside,
51GB partition and let it do its thing I guess so I can see how it
runs from a hard drive.
I also ran a cable to it tonight, so I've got networking, or did
till I let it format /dev/hda8, but I can set that up again with
minimal trouble.
Better planning for the install is needed, but now that I know what
its going to do, I'll fix the appropriate /etc/fstab's after I make
an install on the front half of the disk, using the back half as
swap, then fix that partitions /etc/fstab to put swap on the first
partition of /dev/hdb, then install FC3 on the inside half, pointing
the root= line of grub.conf to the correct half of the main drive
for that boot. Sounds good anyway or does if I can stop that
installer from putting in lilo. :) I'm assuming it will ask first?
Humm, maybe this would be a good time to bite the bullet and
actually make wine work? It might be able to exercize that code
thats in the .exe files. I certainly don't have any M$ compiler
tools available though.
Anyway, I'm poking around, seeing if its got any ticklish spots :)

Post by Paul
You might find the drivers supplied with the card will produce some
usable information - If not, then it will be a case of doing a
dump from /proc/bus/pci/00/10.0 (change to suit) and crafting a
simple test driver with some "best guess" routines.

A cat of that is zero bytes long. Thats why I was fiddling with a
fresh kernel build, trying to trigger a better read or something.

Post by Paul
Regards, Paul.

Post by Gene Heskett
On reboot to the new kernel, I half expected to see if find the
board, report it according to the data in pci.ids,  but its
totally ignoring it yet.  The stuff for 00:10.0 in the /proc
system is still exactly as before.
What would be the next step in cobbling up a driver for it?

[Gene Heskett]

Post by Paul
Hi Gene
I would have thought it highly unlikely that any 2.6 kernel would
have a driver that would recognise your IO card - Do you have
access to a M$ operating system ?
You might find the drivers supplied with the card will produce some
usable information - If not, then it will be a case of doing a dump
from /proc/bus/pci/00/10.0 (change to suit) and crafting a simple
test driver with some "best guess" routines.
Regards, Paul.

I've made some progress in that I booted from the cd, and then hand
copied what I could see to /mnt/hda5, which should be the working
partition for the BDI install. I added the
/etc/sysconfig/network-scripts from hda3 to that also on the odd
chance I might have working networking when booted to it. But I
haven't yet tried to boot BDI from the hard drive. While it was
booted to the cd, I wandered around in the /proc directory and
extracted a few things that may, or may not, be helpfull. I also
rebooted it about 40 times trying various options for the memory hole,
and the reserved areas, even changed the partports IRQ from 7 to 5
without effecting the resource clash the bios reports but will NOT
show me on those screens that are supposed to do that. Its an old
Phoenix bios 4 release 6 copyright (newset date) 1997. And since
Micron Electronics is freeking history, the chances of finding an
updated bios for that board are somewhere between .000nothing and zip.
Leastways I can't find any hits on google.

/boot/grub/grub.conf now looks like this:
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/hda3
# initrd /initrd-version.img
#boot=/dev/hda
default=0
timeout=15
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
# 0
title Fedora Core (2.6.9-1.649)
root (hd0,0)
kernel /vmlinuz-2.6.9-1.649 ro root=/dev/hda3
initrd /initrd-2.6.9-1.649.img
# 1
title BDI-Live
root(hd0,0)
kernel /vmlinuz-2.4.25-adeos root=/dev/hda5
# 2
title Other
rootnoverify (hd0,1)
chainloader +1
---------
Note I left out the usual ro in the kernel line.

the /mnt/hda5/etc/fstab now looks like this:
--------
none /proc proc defaults 0 0
none /dev/pts devpts mode=0622 0 0
/floppy /floppy supermount auto,user,fs=auto,dev=/dev/fd0 0 0
/dev/cdrom /mnt/cdrom auto user,noauto,exec,ro 0 0
# Added by Morphix
/dev/hda1 /mnt/hda1 ext3 noauto,users,exec 0 0
# Added by Morphix
/dev/hda2 /mnt/hda2 vfat noauto,users,exec,umask=000,uid=morph 0 0
# Added by Morphix
/dev/hda3 /mnt/hda3 ext3 noauto,users,exec 0 0
# Added by Morphix
/dev/hda5 /mnt/hda5 ext3 noauto,users,exec 0 0
# Added by Morphix
/dev/hdb1 none swap defaults 0 0
# Added by Morphix
/dev/hdb2 /mnt/hdb2 ext3 noauto,users,exec 0 0
/dev/sda1 /mnt/sda1 auto noauto,users,exec,umask=000,uid=morph 0 0
/cdrom1 /cdrom1 supermount auto,user,fs=auto,dev=/dev/cdrom1
------
which looks a bit verbose, apparently Morphix found everything.

The /boot (hda1) directory now looks like this:
[***@shop /]# ls -l boot
total 3777
-rw-r--r-- 1 root root 5824 Jun 15 20:38 boot.b
-rw-r--r-- 1 root root 612 Jun 15 20:38 chain.b
-rw-r--r-- 1 root root 50929 Oct 29 00:46 config-2.6.9-1.649
-rw-r--r-- 1 root root 38928 Mar 31 2004 configure-2.4.25-adeos
drwxr-xr-x 2 root root 1024 Nov 5 18:51 grub
-rw-r--r-- 1 root root 396110 Nov 5 13:47 initrd-2.6.9-1.649.img
drwx------ 2 root root 12288 Nov 5 13:19 lost+found
-rw-r--r-- 1 root root 81860 Sep 29 14:42 memtest86+-1.26
-rw-r--r-- 1 root root 640 Jun 15 20:38 os2_d.b
-rw-r--r-- 1 root root 714266 Oct 29 00:46 System.map-2.6.9-1.649
lrwxrwxrwx 1 root root 20 Nov 6 13:52 vmlinuz -> vmlinuz-2.4.25-adeos
-rw-r--r-- 1 root root 1122489 Mar 31 2004 vmlinuz-2.4.25-adeos
-rw-r--r-- 1 root root 1405833 Oct 29 00:46 vmlinuz-2.6.9-1.649

Which brings up a question, I didn't see memtest86 in the bdi-live boot
menu, should I add it, and memtest86 to the real /boot dir?
Seems like it might be a bit handier than sneakernetting a floppy around.

Now, to the stuff I extracted from proc, no idea if its helpfull
or if I need to shitcan this mobo and get one with an Award bios.
From /proc/isapnp:
Card 1 'YMH0030:OPL3-SA3 Snd System' PnP version 1.0
Logical device 0 'YMH0021:Unknown'
Device is active
Active port 0x240,0xe80,0x388,0x300,0x100
Active IRQ 5 [0x2]
Active DMA 1,3
Resources 0
Priority preferred
Port 0x220-0x220, align 0xf, size 0x10, 16-bit address decoding
Port 0x530-0x530, align 0x7, size 0x8, 16-bit address decoding
Port 0x388-0x388, align 0x7, size 0x8, 16-bit address decoding
Port 0x330-0x330, align 0x1, size 0x2, 16-bit address decoding
Port 0x370-0x370, align 0x1, size 0x2, 16-bit address decoding
IRQ 5 High-Edge
DMA 0 8-bit byte-count type-A
DMA 1 8-bit byte-count type-A
Alternate resources 0:1
Priority acceptable
Port 0x240-0x240, align 0xf, size 0x10, 16-bit address decoding
Port 0xe80-0xe80, align 0x7, size 0x8, 16-bit address decoding
Port 0x388-0x388, align 0x7, size 0x8, 16-bit address decoding
Port 0x300-0x300, align 0x1, size 0x2, 16-bit address decoding
Port 0x100-0xffe, align 0x1, size 0x2, 16-bit address decoding
IRQ 5,7,2/9,10,11 High-Edge
DMA 0,1,3 8-bit byte-count type-A
DMA 0,1,3 8-bit byte-count type-A
Alternate resources 0:2
Priority functional
Port 0x220-0x280, align 0xf, size 0x10, 16-bit address decoding
Port 0x530-0xf48, align 0x7, size 0x8, 16-bit address decoding
Port 0x388-0x3f8, align 0x7, size 0x8, 16-bit address decoding
Port 0x300-0x334, align 0x1, size 0x2, 16-bit address decoding
Port 0x100-0xffe, align 0x1, size 0x2, 16-bit address decoding
IRQ 5,7,2/9,10,11 High-Edge
DMA 0,1,3 8-bit byte-count type-A
DMA 0,1,3 8-bit byte-count type-A
Logical device 1 'YMH0022:Unknown'
Compatible device PNPb02f
Device is not active
Active DMA 0,0
Resources 0
Priority preferred
Port 0x201-0x201, align 0x0, size 0x1, 16-bit address decoding
Alternate resources 0:1
Priority acceptable
Port 0x201-0x211, align 0xf, size 0x1, 16-bit address decoding

From /proc/pci:
PCI devices found:
Bus 0, device 0, function 0:
Host bridge: Intel Corp. 440LX/EX - 82443LX/EX Host bridge (rev 3).
Master Capable. Latency=32.
Prefetchable 32 bit memory at 0xf8000000 [0xfbffffff].
Bus 0, device 1, function 0:
PCI bridge: Intel Corp. 440LX/EX - 82443LX/EX AGP bridge (rev 3).
Master Capable. Latency=96. Min Gnt=12.
Bus 0, device 7, function 0:
ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 1).
Bus 0, device 7, function 1:
IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 1).
Master Capable. Latency=64.
I/O at 0xfcb0 [0xfcbf].
Bus 0, device 7, function 2:
USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 1).
IRQ 9.
Master Capable. Latency=64.
I/O at 0xfcc0 [0xfcdf].
Bus 0, device 7, function 3:
Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 1).
IRQ 9.
Bus 0, device 14, function 0:
Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 4).
IRQ 9.
Master Capable. Latency=64. Min Gnt=2.Max Lat=20.
I/O at 0xfce0 [0xfcff].
Bus 0, device 14, function 1:
Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 1).
Master Capable. Latency=64.
I/O at 0xfca8 [0xfcaf].
Bus 0, device 15, function 0:
Ethernet controller: D-Link System Inc RTL8139 Ethernet (rev 16).
IRQ 11.
Master Capable. Latency=64. Min Gnt=32.Max Lat=64.
I/O at 0xf800 [0xf8ff].
Non-prefetchable 32 bit memory at 0xfedffc00 [0xfedffcff].
==============the only place this card shows up!
Bus 0, device 16, function 0:
PIC: PCI device 00ff:0800 (rev 255).
Master Capable. No bursts. Max Lat=8.
==============I'm assuming that Bus 0, device 16 is 00:10.0 in the lspci below
Bus 1, device 0, function 0:
VGA compatible controller: NVidia / SGS Thomson (Joint Venture) Riva128 (rev 16).
IRQ 9.
Master Capable. Latency=64. Min Gnt=3.Max Lat=1.
Non-prefetchable 32 bit memory at 0xf0000000 [0xf0ffffff].
Prefetchable 32 bit memory at 0xee000000 [0xeeffffff].

And from /proc/ioports:
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0213-0213 : isapnp read
02f8-02ff : serial(auto)
0320-0323 :
0350-0353 :
0376-0376 : ide1
0378-037a : parport0
03c0-03df : vesafb
03f6-03f6 : ide0
03f8-03ff : serial(auto)
0a79-0a79 : isapnp write
0cf8-0cff : PCI conf1
7000-701f : Intel Corp. 82371AB/EB/MB PIIX4 ACPI
8000-803f : Intel Corp. 82371AB/EB/MB PIIX4 ACPI
f800-f8ff : D-Link System Inc RTL8139 Ethernet
f800-f8ff : 8139too
fca8-fcaf : Creative Labs SB Live! MIDI/Game Port
fca8-fcaf : emu10k1-gp
fcb0-fcbf : Intel Corp. 82371AB/EB/MB PIIX4 IDE
fcb0-fcb7 : ide0
fcb8-fcbf : ide1
fcc0-fcdf : Intel Corp. 82371AB/EB/MB PIIX4 USB
fcc0-fcdf : usb-uhci
fce0-fcff : Creative Labs SB Live! EMU10k1
fce0-fcff : EMU10K1

And I don't see a thing that screams hey, i'm that ^%$ PCI8255 card in this
listing.

Rebooted to FC3RC5, an lspci -vv snip:

00:10.0 PIC: Unknown device 00ff:0800 (rev ff) (prog-if 00 [8259])
Subsystem: Unknown device 00ff:0800
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop+ ParErr+ Stepping+ SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort+ <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (2000ns max), Cache Line Size ff
Region 0: I/O ports at <ignored>
Region 1: I/O ports at <ignored>
Region 2: I/O ports at <ignored>
Region 3: I/O ports at <ignored>
Region 4: I/O ports at <ignored>
Region 5: I/O ports at <ignored>
Expansion ROM at <ignored>

I also did some hex dumps, and that 00:10.0 device shows
$FF 00 00 08 in a repeat pattern for 256 bytes according
to mc's hex display. Do we have an endian problem here?

BTW, that version of mc sucks when the big one when
running in an X screen. It can't find the border chars it
needs & leaves trash all over its screen. It needs an alias
in .bashrc:
alias mc='mc -a'
which fixes that. I'll fix it if I can find the right
.bashrc. :-)

Anyway, whats this patients prognosis doc? Is it terminal and I
should I try to find another donor here?

Or figure on buying a different translator setup that would let
me use the parport? Something with a bunch of 5804's on it?

Or the lm296 maybe?

In the meantime the missus says its time to go out to eat :)
I'll go get those links you gave me later this evening if I'm
awake enough, these night shifts tend to screw up my body's
schedule.

[Paul]

Hi Gene

A repeat pattern of FF 00 00 08 right across the 256 bytes sounds very suspect
to me - The data here should be matching the contents of the PCI card's
configuration registers.. I would recommend trying the card in a newer
computer (as Mark recommended) and see if anything changes.
A final solution would be to try the card in a friends computer (with M$
installed) and test it with the utilities on the CD - If the card fails this
final attempt, then it could be faulty.

From the docs you sent over, the card does not use interrupts, nor should it
suffer from big/little endian problems.

Regards, Paul.

Post by Gene Heskett
I also did some hex dumps, and that 00:10.0 device shows
$FF 00 00 08 in a repeat pattern for 256 bytes according
to mc's hex display.  Do we have an endian problem here?

[Gene Heskett]

Post by Paul
Hi Gene
A repeat pattern of FF 00 00 08 right across the 256 bytes sounds
very suspect to me - The data here should be matching the contents
of the PCI card's configuration registers.. I would recommend
trying the card in a newer computer (as Mark recommended) and see
if anything changes. A final solution would be to try the card in a
friends computer (with M$ installed) and test it with the utilities
on the CD - If the card fails this final attempt, then it could be
faulty.

Well, I haven't imposed on the neighbors yet, but when its inserted
in this machine, the lspci -vv report is significantly different,
as follows:

01:09.0 Ethernet controller: Unknown device 00ff:0200 (rev ff)
Subsystem: Unknown device 00ff:0200
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop+ ParErr+ Stepping+ SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (500ns max), Cache Line Size ff
Region 0: I/O ports at <ignored>
Region 1: I/O ports at <ignored>
Region 2: I/O ports at <ignored>
Region 3: I/O ports at <ignored>
Region 4: I/O ports at <ignored>
Region 5: I/O ports at <ignored>

And there was no resource clash detected by the bios here. Note the change
from 00ff:0800 to 00ff:0200 in the vendor:product above.

And how did it get to be an ethernet controller?

That machine has another pci slot, right under a steel bar,
and which probably shares the IRQ's with the adjacent AGP
slot, one of the 2 reasons I haven't tried it in the other
slot, but now will, and if that then shows the :0200 product
code, I'll go visit the neighbors with it and cd in hand
and see what I can learn under losedows. We're good
friends, we share the same date for a wedding anniversary
and are always handing the other a "hand cooler". I also
load all his deer hunting shells. I occasionally claim
to be a JOAT, but with 70 years on this body & mind, its
beginning to be a bit difficult to maintain that image. :)

That visit should confirm one way or the other as to
whether the card itself is fubar'd.

[Gene Heskett]

On Sunday 07 November 2004 00:16, Gene Heskett wrote:
Yeah, I know, its considered poor form to reply to your own posts..

Post by Gene Heskett

Post by Paul
Hi Gene
A repeat pattern of FF 00 00 08 right across the 256 bytes sounds
very suspect to me - The data here should be matching the contents
of the PCI card's configuration registers.. I would recommend
trying the card in a newer computer (as Mark recommended) and see
if anything changes. A final solution would be to try the card in
a friends computer (with M$ installed) and test it with the
utilities on the CD - If the card fails this final attempt, then
it could be faulty.

Well, I haven't imposed on the neighbors yet, but when its inserted
in this machine, the lspci -vv report is significantly different,
01:09.0 Ethernet controller: Unknown device 00ff:0200 (rev ff)
Subsystem: Unknown device 00ff:0200
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop+
ParErr+ Stepping+ SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B-
ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (500ns max), Cache Line Size ff
Region 0: I/O ports at <ignored>
Region 1: I/O ports at <ignored>
Region 2: I/O ports at <ignored>
Region 3: I/O ports at <ignored>
Region 4: I/O ports at <ignored>
Region 5: I/O ports at <ignored>
And there was no resource clash detected by the bios here. Note the
change from 00ff:0800 to 00ff:0200 in the vendor:product above.
And how did it get to be an ethernet controller?
That machine has another pci slot, right under a steel bar,
and which probably shares the IRQ's with the adjacent AGP
slot, one of the 2 reasons I haven't tried it in the other
slot, but now will, and if that then shows the :0200 product
code, I'll go visit the neighbors with it and cd in hand
and see what I can learn under losedows. We're good
friends, we share the same date for a wedding anniversary
and are always handing the other a "hand cooler". I also
load all his deer hunting shells. I occasionally claim
to be a JOAT, but with 70 years on this body & mind, its
beginning to be a bit difficult to maintain that image. :)
That visit should confirm one way or the other as to
whether the card itself is fubar'd.

[Paul]

Hi Gene

And whereas if vendor:product was 00ff:0800 in the bottom pci slot,
now it 00ff:0100, while it was 00ff:0200 when installed in this
machine.  Now IF and thats a big if, we were actually accessing that
cards bios correctly, this shouldn't change, or am I making an
invalid assumption about how pci works?  I'm still reading on the
stuff Paul sent links to.

The Vendor:Device ID should certainly NOT change when moving the card to a
different slot. The configuration data space is (to all intents) read only
and is set up at the time of manufacture...

However, the /etc/sysconfig/network-scripts dir is empty, both on the
booted cd and in /dev/hda5/etc/sysconfig so even though it loads the
8139too module, there is no networking.

The BDI install won't enable networking until an IP address is set - This is
usually obtained from a DHCP server on the local network.

Regards, Paul.

[Gene Heskett]

Post by Paul
Hi Gene

And whereas if vendor:product was 00ff:0800 in the bottom pci
slot, now it 00ff:0100, while it was 00ff:0200 when installed in
this machine.  Now IF and thats a big if, we were actually
accessing that cards bios correctly, this shouldn't change, or am
I making an invalid assumption about how pci works?  I'm still
reading on the stuff Paul sent links to.

The Vendor:Device ID should certainly NOT change when moving the
card to a different slot. The configuration data space is (to all
intents) read only and is set up at the time of manufacture...

Ok then, the next test is to take it to the neighbors losedows box and
see what happens. I'm beginning to think the card (or its bios
extension) is duff myself.

Post by Paul

However, the /etc/sysconfig/network-scripts dir is empty, both on
the booted cd and in /dev/hda5/etc/sysconfig so even though it
loads the 8139too module, there is no networking.

The BDI install won't enable networking until an IP address is set -
This is usually obtained from a DHCP server on the local network.

My local network is all fixed ip's, set in the /etc/hosts file (which
I haven't setup yet, thanks for reminding me, and it probably
explains why I can ping this machine from that one when booted to
FC3, but I can ssh into it from here). I'll go take care of that
little detail right now. Yup now I can ping everything. While
booted to FC3 that is... Now to copy that to the debian
partitions /etc/hosts too.

Since the contents of the live cd boot were copied to /dev/hda5/var,
I've taken that line out of the debian boots fstab, it seems to fix
quite a few boot time errors. So now the 2 installs have only
the /boot partition in common. Progress is being made toward a
working installation I do believe.

Post by Paul
Regards, Paul.

[Gene Heskett]

On Sunday 07 November 2004 14:26, Gene Heskett wrote:

Here we go again, relying to my own message. :(

I took it to the neighbors box, probably a win2000, its about a 5 year
old Compaq. The hardware installer could see that there was a card
there, but couldn't find any drivers for the card on the disk, and
although the gui that shows the ports and their read/write buttons
and status ran, it ran with a pre-opening of the main screen box
saying that it couldn't find the driver either.

So at this point I have NDI if the card works or not, as there is
neither Visual Basic nor Visual C on that box. Some spyware I think,
haven't we been told that Ad-Aware has a spybot in it?

Anyway, thats backwards progress AFAICS. :-(

Time to dig thru my receipts and call the US dealer I do believe.

Post by Gene Heskett

Post by Paul
Hi Gene

And whereas if vendor:product was 00ff:0800 in the bottom pci
slot, now it 00ff:0100, while it was 00ff:0200 when installed in
this machine.  Now IF and thats a big if, we were actually
accessing that cards bios correctly, this shouldn't change, or am
I making an invalid assumption about how pci works?  I'm still
reading on the stuff Paul sent links to.

The Vendor:Device ID should certainly NOT change when moving the
card to a different slot. The configuration data space is (to all
intents) read only and is set up at the time of manufacture...

Ok then, the next test is to take it to the neighbors losedows box
and see what happens. I'm beginning to think the card (or its bios
extension) is duff myself.

Post by Paul

However, the /etc/sysconfig/network-scripts dir is empty, both on
the booted cd and in /dev/hda5/etc/sysconfig so even though it
loads the 8139too module, there is no networking.

The BDI install won't enable networking until an IP address is set
- This is usually obtained from a DHCP server on the local
network.

My local network is all fixed ip's, set in the /etc/hosts file
(which I haven't setup yet, thanks for reminding me, and it
probably explains why I can ping this machine from that one when
booted to FC3, but I can ssh into it from here). I'll go take care
of that little detail right now. Yup now I can ping everything.
While booted to FC3 that is... Now to copy that to the debian
partitions /etc/hosts too.
Since the contents of the live cd boot were copied to /dev/hda5/var,
I've taken that line out of the debian boots fstab, it seems to fix
quite a few boot time errors. So now the 2 installs have only
the /boot partition in common. Progress is being made toward a
working installation I do believe.

Post by Paul
Regards, Paul.

[Stephen Wille Padnos]

Hi there.

Two things, vaguely related:

First, I don't think there is a BIOS on this card. The Xilinx chip is
a programmable logic chip, which is providing the PCI interface and glue
logic (and which could also provide a BIOS, but that seems unlikely),
and the ULN2803 is an open collector output driver. This isn't really a
problem (the lack of BIOS), since this card doesn't really do anything
without user software.

Second, the Delphi directory had an .EXE in it - dp8255.exe - I think
this is the delphi demo program already compiled. You might try to run
that at your neighbor's. It's hard-coded for $F300, so set the jumpers
for that address. Of course, it could also be a self-extracting
archive, so who knows?

- Steve

[everything snipped, since I'm not really replying to this email]

[Gene Heskett]

Post by Stephen Wille Padnos
Hi there.
First, I don't think there is a BIOS on this card. The Xilinx chip
is a programmable logic chip, which is providing the PCI interface
and glue logic (and which could also provide a BIOS, but that seems
unlikely), and the ULN2803 is an open collector output driver.

Yes, you can jumper its inputs to any bit of the first 8255 portA I
believe.

Post by Stephen Wille Padnos
This isn't really a problem (the lack of BIOS), since this card
doesn't really do anything without user software.

I've found some linux drivers for a multiple 8255 card, but this cards
address decoding is rather sparse instead of consecutive, wasting the
top 12 of each 16 addresses.

I'm collecting those and will put them onto that machine and see if I
can actually get a response, like from dpci8255.tar.gz I've modified
that code, but I don't seem to be able to get past gcc since there is
no 'main' defined in the modules code.

But this isn't working as a test on this machine, primarily because
this kernel is 2.6.10-rc1-bk15, and the code seems to have been built
on a 2.4 system, so the module is an invalid format. It just might
work on the BDI system as I think thats still a 2.4 kernel.

But thats tomorrows project, its getting sleepy out. And Makefiles
(its not in that archove) were never my strong suit even if I have
hacked a fair amount of code over the last 25 years.

Is there a set of options I can give gcc from the cli that will make
it output a module? I scanned thru the manpage without its reaching
out and touching me the first time. And now I've done it twice.

Gotta get samba going so I can move this stuff. :-)

Post by Stephen Wille Padnos
Second, the Delphi directory had an .EXE in it - dp8255.exe - I
think this is the delphi demo program already compiled. You might
try to run that at your neighbor's. It's hard-coded for $F300, so
set the jumpers for that address. Of course, it could also be a
self-extracting archive, so who knows?

That one would not even load, some .dll was missing according to the
error msg. And the card was set for $F300. Lemme wander thru it
with mc in the hex mode just for grins.
The first .dll named is MSVBVM60.DLL, not on that box.
Then next one is KlibDRV.dll which is on the cd, in that same
directory
The last .dll is VBA6.DLL, also not on that box.

So we missed 2 out of three times since that machine doesn't have
anything like a basic on it.

Post by Stephen Wille Padnos
- Steve

[everything snipped, since I'm not really replying to this email]

Humm, coulda fooled me, looks exactly like a reply to me :-)

[Stephen Wille Padnos]

Post by Gene Heskett

Post by Stephen Wille Padnos
Hi there.
First, I don't think there is a BIOS on this card. The Xilinx chip
is a programmable logic chip, which is providing the PCI interface
and glue logic (and which could also provide a BIOS, but that seems
unlikely), and the ULN2803 is an open collector output driver.

Yes, you can jumper its inputs to any bit of the first 8255 portA I
believe.

Post by Stephen Wille Padnos
This isn't really a problem (the lack of BIOS), since this card
doesn't really do anything without user software.

I've found some linux drivers for a multiple 8255 card, but this cards
address decoding is rather sparse instead of consecutive, wasting the
top 12 of each 16 addresses.

Not quite. This card throws away the top three bytes of each 32-bit
DWORD - only the low byte is sent on to the card. So, it uses 1, skips
3, uses 1, skips 3, etc. (addresses $xx00, $xx04, $xx08, $xx0C are used)

Post by Gene Heskett
I'm collecting those and will put them onto that machine and see if I
can actually get a response, like from dpci8255.tar.gz I've modified
that code, but I don't seem to be able to get past gcc since there is
no 'main' defined in the modules code.

Right - modules don't have a main (since they're not programs - but you
knew that :)

Post by Gene Heskett
But this isn't working as a test on this machine, primarily because
this kernel is 2.6.10-rc1-bk15, and the code seems to have been built
on a 2.4 system, so the module is an invalid format. It just might
work on the BDI system as I think thats still a 2.4 kernel.
But thats tomorrows project, its getting sleepy out. And Makefiles
(its not in that archove) were never my strong suit even if I have
hacked a fair amount of code over the last 25 years.
Is there a set of options I can give gcc from the cli that will make
it output a module? I scanned thru the manpage without its reaching
out and touching me the first time. And now I've done it twice.

Nope. At least, not gcc options. You can get a module by using the
kernel build system (on 2.6, I'm not sure about 2.4). I don't remember
the exact options, but it's something like kbuild
SUBDIRS=/path/to/my/module or something like that.

Post by Gene Heskett
Gotta get samba going so I can move this stuff. :-)

Post by Stephen Wille Padnos
Second, the Delphi directory had an .EXE in it - dp8255.exe - I
think this is the delphi demo program already compiled. You might
try to run that at your neighbor's. It's hard-coded for $F300, so
set the jumpers for that address. Of course, it could also be a
self-extracting archive, so who knows?

That one would not even load, some .dll was missing according to the
error msg. And the card was set for $F300. Lemme wander thru it
with mc in the hex mode just for grins.
The first .dll named is MSVBVM60.DLL, not on that box.
Then next one is KlibDRV.dll which is on the cd, in that same
directory
The last .dll is VBA6.DLL, also not on that box.
So we missed 2 out of three times since that machine doesn't have
anything like a basic on it.

Those DLLs may be available from M$ as the VB6 runtime or something similar.

Post by Gene Heskett

Post by Stephen Wille Padnos
- Steve

[everything snipped, since I'm not really replying to this email]

Humm, coulda fooled me, looks exactly like a reply to me :-)

Well - I guess I'm a fool, then :)
- Steve

[Gene Heskett]

Post by Stephen Wille Padnos

Post by Gene Heskett

Post by Stephen Wille Padnos
Hi there.
First, I don't think there is a BIOS on this card. The Xilinx
chip is a programmable logic chip, which is providing the PCI
interface and glue logic (and which could also provide a BIOS,
but that seems unlikely), and the ULN2803 is an open collector
output driver.

Yes, you can jumper its inputs to any bit of the first 8255 portA I
believe.

Post by Stephen Wille Padnos
This isn't really a problem (the lack of BIOS), since this card
doesn't really do anything without user software.

I've found some linux drivers for a multiple 8255 card, but this
cards address decoding is rather sparse instead of consecutive,
wasting the top 12 of each 16 addresses.

Not quite. This card throws away the top three bytes of each 32-bit
DWORD - only the low byte is sent on to the card. So, it uses 1,
skips 3, uses 1, skips 3, etc. (addresses $xx00, $xx04, $xx08,
$xx0C are used)

Thats odd decoding to say the least. I've used the 8255 before, a
decade plus back up the log to be sure, but in that case the
registers were at $ChipAddress+(0,1,2,3) 0,4,8,C? doesn't make
sense...

Post by Stephen Wille Padnos

Post by Gene Heskett
I'm collecting those and will put them onto that machine and see if
I can actually get a response, like from dpci8255.tar.gz I've
modified that code, but I don't seem to be able to get past gcc
since there is no 'main' defined in the modules code.

Right - modules don't have a main (since they're not programs - but
you knew that :)

Yup :)

Post by Stephen Wille Padnos

Post by Gene Heskett
But this isn't working as a test on this machine, primarily because
this kernel is 2.6.10-rc1-bk15, and the code seems to have been
built on a 2.4 system, so the module is an invalid format. It
just might work on the BDI system as I think thats still a 2.4
kernel.
But thats tomorrows project, its getting sleepy out. And Makefiles
(its not in that archove) were never my strong suit even if I have
hacked a fair amount of code over the last 25 years.
Is there a set of options I can give gcc from the cli that will
make it output a module? I scanned thru the manpage without its
reaching out and touching me the first time. And now I've done it
twice.

Nope. At least, not gcc options. You can get a module by using the
kernel build system (on 2.6, I'm not sure about 2.4). I don't
remember the exact options, but it's something like kbuild
SUBDIRS=/path/to/my/module or something like that.

Post by Gene Heskett
Gotta get samba going so I can move this stuff. :-)

Post by Stephen Wille Padnos
Second, the Delphi directory had an .EXE in it - dp8255.exe - I
think this is the delphi demo program already compiled. You might
try to run that at your neighbor's. It's hard-coded for $F300, so
set the jumpers for that address. Of course, it could also be a
self-extracting archive, so who knows?

That one would not even load, some .dll was missing according to
the error msg. And the card was set for $F300. Lemme wander thru
it with mc in the hex mode just for grins.
The first .dll named is MSVBVM60.DLL, not on that box.
Then next one is KlibDRV.dll which is on the cd, in that same
directory
The last .dll is VBA6.DLL, also not on that box.
So we missed 2 out of three times since that machine doesn't have
anything like a basic on it.

Those DLLs may be available from M$ as the VB6 runtime or something similar.

Is that freely distributable? I mean if its the runtime, you would
think it would be part of the basic losedows install, carrying a
license that allows it to be shipped/used with the programs that need
it. Like on this devices cd... Sigh, and its yet another time Bill
deserves a black eye.

Post by Stephen Wille Padnos

Post by Gene Heskett

Post by Stephen Wille Padnos
- Steve

[everything snipped, since I'm not really replying to this email]

Humm, coulda fooled me, looks exactly like a reply to me :-)

Well - I guess I'm a fool, then :)

Chuckle, welcome to the club Steve. But be aware, its not a very
exclusive club, lots of us are charter members. :-)

[Paul]

Hi Gene

The majority of PCI interfaces use a 32 bit data bus whilst the 8255 uses an 8
bit bus... Using the lower byte to transfer data gives us read/writes on a
four byte boundary - With some additional complexity in the PCI bridge chip,
it could be possible to use 32 bit read/writes, but this would push the price
of the silicon up..
With this in mind, it is not unusual to find read/writes being performed on
four byte boundaries.

Regards, Paul.

Thats odd decoding to say the least.  I've used the 8255 before, a
decade plus back up the log to be sure, but in that case the
registers were at $ChipAddress+(0,1,2,3)   0,4,8,C? doesn't make
sense...

[Gene Heskett]

Post by Paul
Hi Gene
The majority of PCI interfaces use a 32 bit data bus whilst the 8255
uses an 8 bit bus... Using the lower byte to transfer data gives us
read/writes on a four byte boundary - With some additional
complexity in the PCI bridge chip, it could be possible to use 32
bit read/writes, but this would push the price of the silicon up..
With this in mind, it is not unusual to find read/writes being
performed on four byte boundaries.
Regards, Paul.

I think I see, Paul. You're saying that the address decodeing is
based on the long word, so if 8255#1 partA would be at $0F30, its
portB would be at $0F34, etc. That takes us up to #2 at $0F40, and
#3 at $0F50 etc etc said the king of Siam. :-)

Conversely a write to $0F31, $0F32 & $0F33 would all put the LSB into
portA, correct? Now it makes sense. I've come from an environment
where every byte counted, or can't you tell? :)

Post by Paul

Thats odd decoding to say the least.  I've used the 8255 before, a
decade plus back up the log to be sure, but in that case the
registers were at $ChipAddress+(0,1,2,3)   0,4,8,C? doesn't make
sense...

I can't recall now if that was an 1802 board, or a Z-80 board where I
built that but they were then both 8 bit data bus devices, so its
moot now anyway. This is 2004 the last time I checked my calendar,
not 1978-9 when I did that. Memory, second thing to go you know.
Probably the 1802, and I was using it to control u-matic tape
machines at that time. IIRC I used most of it to do everything
needed because I was driving the machine as an editor, saving one
generations worth of quality loss in getting a commercial fixed up to
be the aired version. In 1979, that was a big deal! :)

[Mark Pictor]

comments below.

--- Gene Heskett <***@verizon.net> wrote:

<snip>

Post by Gene Heskett
And I just found a new problem. The install didn't
install grub in
the mbr, which is what I would have liked, but I
didn't let it. Then
since its getting rather sleepy out, I figured I'd
do a gracefull
shutdown and attack it again for a few hours
tomorrow. Unforch as
whatever user it left me as, I didn't have
permissions to do a
shutdown. I tried an su - and entered the password,
no dice, ditto
for an su root, bad password. So I hit the power
switch.

On Morphix-based live cds, the root password is reset
to a random sequence on boot. Why? Otherwise every
computer in the world booting morphix would be easily
hackable from the 'net. Lots of zombie machines, and
once they're powered off, there's not a shred of
evidence. Owwwie!

Solution: use sudo; it is set up to work. You can
then change the root password temporarily if you like.
Once it is installed to disk it should keep the
password you set during installation.

<snip>

Post by Gene Heskett

Post by Gene Heskett
Humm, maybe this would be a good time to bite the

bullet and

Post by Gene Heskett
actually make wine work? It might be able to

exercize that code

Post by Gene Heskett
thats in the .exe files. I certainly don't have

any M$ compiler

Post by Gene Heskett
tools available though.

I doubt that hardware drivers are supported by wine.
At least not for PCI, which is highly dependent on the
kernel calls.

Code: their website makes it sound like there is
sample code supplied with the card. If it is for the
driver, and not for talking *to* the driver, it would
contain the vendor and device codes.

Compiler: http://www.bloodshed.net/devcpp.html - gcc
ported to losedows.

Post by Gene Heskett

Post by Gene Heskett
Anyway, I'm poking around, seeing if its got any

ticklish spots :)

Post by Gene Heskett

Post by Paul
You might find the drivers supplied with the card

will produce some

Post by Gene Heskett

Post by Paul
usable information - If not, then it will be a

case of doing a

Post by Gene Heskett

Post by Paul
dump from /proc/bus/pci/00/10.0 (change to suit)

and crafting a

Post by Gene Heskett

Post by Paul
simple test driver with some "best guess"

routines.

a. Are you sure that you're looking at the right pci
slot?
b. Is the pci proc interface enabled in your kernel
config? I *think* this is deprecated... try lspci.

Also, do the DIP switches have to be in a certain spot
for the card to work?

Good luck
Mark



__________________________________
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com

[Gene Heskett]

Post by Mark Pictor
comments below.
<snip>

Post by Gene Heskett
And I just found a new problem. The install didn't
install grub in
the mbr, which is what I would have liked, but I
didn't let it. Then
since its getting rather sleepy out, I figured I'd
do a gracefull
shutdown and attack it again for a few hours
tomorrow. Unforch as
whatever user it left me as, I didn't have
permissions to do a
shutdown. I tried an su - and entered the password,
no dice, ditto
for an su root, bad password. So I hit the power
switch.

On Morphix-based live cds, the root password is reset
to a random sequence on boot. Why? Otherwise every
computer in the world booting morphix would be easily
hackable from the 'net. Lots of zombie machines, and
once they're powered off, there's not a shred of
evidence. Owwwie!
Solution: use sudo; it is set up to work. You can
then change the root password temporarily if you like.
Once it is installed to disk it should keep the
password you set during installation.
<snip>

I did set the root password durng the install. But it was not
accepted when it came time to do the shutdown, and there was no
reboot to the disk install done that I'm aware of. So it was stil
running the LiveCD image AFAIK.

I've little experince with sudo here. I run as root on all my boxes.
Stupid probably, but I'm not directly exposed to the net, there is a
firewall box runnng iptables to go thru, to get to a NATing router
and thence to the DSL modem. I could give you my current outside
address, and you could fool around with satan or nmap without getting
any evidence that there actually is a machine at that address.

Post by Mark Pictor

Post by Gene Heskett

Post by Gene Heskett
Humm, maybe this would be a good time to bite the
bullet and
actually make wine work? It might be able to
exercize that code
thats in the .exe files. I certainly don't have
any M$ compiler
tools available though.

I doubt that hardware drivers are supported by wine.
At least not for PCI, which is highly dependent on the
kernel calls.
Code: their website makes it sound like there is
sample code supplied with the card. If it is for the
driver, and not for talking *to* the driver, it would
contain the vendor and device codes.

You didn't you get that tar.gz I made up from the cd? All that stuffs
there, drivers in VB or VC. I'm building gambas-0.99 right now to
see if it can make any sense out of the vb stuff on the cd.

Post by Mark Pictor
Compiler: http://www.bloodshed.net/devcpp.html - gcc
ported to losedows.

And this runs in a linux environment, taking in losedos code and
outputting ELF? Neat. I'll go take a look. Nope, needs losedos 95
or better. Not a lot of use to me.

Post by Mark Pictor

Post by Gene Heskett

Post by Gene Heskett
Anyway, I'm poking around, seeing if its got any

ticklish spots :)

Post by Gene Heskett

Post by Paul
You might find the drivers supplied with the card

will produce some

Post by Gene Heskett

Post by Paul
usable information - If not, then it will be a

case of doing a

Post by Gene Heskett

Post by Paul
dump from /proc/bus/pci/00/10.0 (change to suit)

and crafting a

Post by Gene Heskett

Post by Paul
simple test driver with some "best guess"

routines.

a. Are you sure that you're looking at the right pci
slot?
b. Is the pci proc interface enabled in your kernel
config? I *think* this is deprecated... try lspci.

I was using lspci -vv, and yes thats enabled.

Post by Mark Pictor
Also, do the DIP switches have to be in a certain spot
for the card to work?

I've tried them at prolly 10 different settings now without effecting
the resource clash message from the bios, but the bios gives me a
choice of hitting F1 to continue, and it does, with no apparent ill
effects. Or did when booting the FC2 install it blew away last
night, and which I'm going to blow away again today after AI play
with the disk partitioning to see if I can dual boot, to morphix or
FC3...

Looking thru whats on the cd, it seems most of the stuff addresses the
card at $0F30, so if the switches have been moved, the code would
have to be changed to accomodate.

Some background on the pci bus at the big dummy level please? How
does one actually do a read or write, at the bare metal level, if
those dipswitches are set to F3, meaning $0F30 for the address
decoder? Assembly nemonics would be fine.

[Paul]

Hi Gene

Add to /etc/apt/sources.list

deb http://ftp.debian.org/debian/ unstable main

Do a

apt-get update

Followed by

apt-get install gambas

No need to compile and find you are missing libx11-dev half way through.


Some usefull background reading on the PCI bus and linux:

http://www.xml.com/ldd/chapter/book/ch15.html - Sample source code from
http://examples.oreilly.com/linuxdrive2/

http://www.science.unitn.it/~fiorella/guidelinux/tlk/node65.html


Regards, Paul.

Humm, gambas  make just bailed out, can't find X11/Xlib.h so I better
send this and see whats fubared.
Thanks for any clues you can relay my way.

[Gene Heskett]

Post by Paul
Hi Gene

[...]

Post by Paul
http://www.xml.com/ldd/chapter/book/ch15.html - Sample source code
from http://examples.oreilly.com/linuxdrive2/
http://www.science.unitn.it/~fiorella/guidelinux/tlk/node65.html

Lots of Thanks Paul, msg printed & I'll get them sometime tomorrow.

Post by Paul
Regards, Paul.

[Mark Pictor]

Post by Gene Heskett

Post by Mark Pictor
<snip>

I did set the root password durng the install. But
it was not
accepted when it came time to do the shutdown, and
there was no
reboot to the disk install done that I'm aware of.
So it was stil
running the LiveCD image AFAIK.
I've little experince with sudo here. I run as root
on all my boxes.
Stupid probably, but I'm not directly exposed to the
net, there is a
firewall box runnng iptables to go thru, to get to a
NATing router
and thence to the DSL modem. I could give you my
current outside
address, and you could fool around with satan or
nmap without getting
any evidence that there actually is a machine at
that address.

try sudo "shutdown -h now" <enter> or simply sudo
<enter>
Ohhh. I think that if you go to the kde menu and
choose Logout, the system shuts down.
<snip>

Post by Gene Heskett
You didn't you get that tar.gz I made up from the
cd? All that stuffs
there, drivers in VB or VC. I'm building
gambas-0.99 right now to
see if it can make any sense out of the vb stuff on
the cd.

Guess I haven't been paying attention.
<snip>

Post by Gene Heskett

Post by Mark Pictor
Also, do the DIP switches have to be in a certain

spot

Post by Mark Pictor
for the card to work?

I've tried them at prolly 10 different settings now
without effecting
the resource clash message from the bios, but the
bios gives me a
choice of hitting F1 to continue, and it does, with
no apparent ill
effects. Or did when booting the FC2 install it
blew away last
night, and which I'm going to blow away again today
after AI play
with the disk partitioning to see if I can dual
boot, to morphix or
FC3...

!!!!!!!!!! The bios doesn't like it? If the bios
doesn't like it, I don't think you will have any luck
with linux. The BIOS is probably disabling it, and
linux is not re-enabling it. (If I set my bios to
HPT372RAID:off, linux doesn't see it. There has to be
some mechanism for this. I'm guessing there's a "Slot
Enable", similar to the common "Chip Enable", and the
BIOS can simply shut off anything that is not
behaving.)

Can you enable "15-16M memory hole" and try again?
I'd focus on either BIOS settings, or try another
computer.

Post by Gene Heskett
Looking thru whats on the cd, it seems most of the
stuff addresses the
card at $0F30, so if the switches have been moved,
the code would
have to be changed to accomodate.
Some background on the pci bus at the big dummy
level please?

I'm afraid I can't help with this.

Post by Gene Heskett
--
Cheers, Gene
"There are four boxes to be used in defense of
soap, ballot, jury, and ammo. Please use in that
order."
-Ed Howdershelt (Author)
99.28% setiathome rank, not too shabby for a WV
hillbilly
Yahoo.com attorneys please note, additions to this
message
Copyright 2004 by Maurice Eugene Heskett, all rights
reserved.

Mark



__________________________________
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com

[Gene Heskett]

On Saturday 06 November 2004 01:36, Mark Pictor wrote:
[...]

Post by Mark Pictor

Post by Gene Heskett
You didn't you get that tar.gz I made up from the
cd? All that stuffs
there, drivers in VB or VC. I'm building
gambas-0.99 right now to
see if it can make any sense out of the vb stuff on
the cd.

Guess I haven't been paying attention.
<snip>

Post by Gene Heskett

Post by Mark Pictor
Also, do the DIP switches have to be in a certain

spot

Post by Mark Pictor
for the card to work?

I've tried them at prolly 10 different settings now
without effecting
the resource clash message from the bios, but the
bios gives me a
choice of hitting F1 to continue, and it does, with
no apparent ill
effects. Or did when booting the FC2 install it
blew away last
night, and which I'm going to blow away again today
after AI play
with the disk partitioning to see if I can dual
boot, to morphix or
FC3...

!!!!!!!!!! The bios doesn't like it? If the bios
doesn't like it, I don't think you will have any luck
with linux. The BIOS is probably disabling it, and
linux is not re-enabling it. (If I set my bios to
HPT372RAID:off, linux doesn't see it. There has to be
some mechanism for this. I'm guessing there's a "Slot
Enable", similar to the common "Chip Enable", and the
BIOS can simply shut off anything that is not
behaving.)

An lspci -vv gets me a fairly voluminous report for device 00:10.0, so
while it may not be init'd by the bios, linux can at least see it,
but reports the bios extension that it contains is not enabled.

Post by Mark Pictor
Can you enable "15-16M memory hole" and try again?
I'd focus on either BIOS settings, or try another
computer.

Humm, I hadn't thought of that, but I will try it. Does linux run ok
with that hole enabled? Its something I always assumed needed to be
a flat addressing scheme for linux to work right.

I've also thought of getting another, faster motherboard for that box,
its an elderly Micro Millineum with a 233mhz PII on it & its video
card is also somewhat fubar too, if the blanker kicks in for a blank
screen, the recovery is to a totally trashed image and you have to
find the mouse pointer and use it to switch windows, at which point a
total redraw fixes things up. It claims its got 16 megs of memory,
but I don't think the top 8 megs is actually there. I've got an old
Diamond SpeedStar A50 in my firewall box that claims 8 megs, but the
sys6326 chipset can only address 4 of them. It works just fine
though. Obviously I'm not a gamer, other than a quick game of
kondike once in a while. :)

Post by Mark Pictor

Post by Gene Heskett
Looking thru whats on the cd, it seems most of the
stuff addresses the
card at $0F30, so if the switches have been moved,
the code would
have to be changed to accomodate.
Some background on the pci bus at the big dummy
level please?

I'm afraid I can't help with this.

Paul came up with some stuff I'll go get later today when I'm actually
awake.

[Mark Pictor]

Post by Gene Heskett
Humm, I hadn't thought of that, but I will try it.
Does linux run ok
with that hole enabled? Its something I always
assumed needed to be
a flat addressing scheme for linux to work right.

No idea, but... your data is already trashed, right?
:P

Post by Gene Heskett
I've also thought of getting another, faster
motherboard for that box,
its an elderly Micro Millineum with a 233mhz PII on
it & its video
card is also somewhat fubar too, if the blanker
kicks in for a blank
screen, the recovery is to a totally trashed image
and you have to
find the mouse pointer and use it to switch windows,
at which point a
total redraw fixes things up. It claims its got 16
megs of memory,
but I don't think the top 8 megs is actually there.
I've got an old
Diamond SpeedStar A50 in my firewall box that claims
8 megs, but the
sys6326 chipset can only address 4 of them. It
works just fine
though. Obviously I'm not a gamer, other than a
quick game of
kondike once in a while. :)

Hmmm. If this system is that old, is it PCI2.1
compliant? that could be a problem. And even if it
claims to be, it may not. See if the bios allows you
to change the pci version, and try it the other way.



__________________________________
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com

[Gene Heskett]

Post by Mark Pictor

Post by Gene Heskett
Humm, I hadn't thought of that, but I will try it.
Does linux run ok
with that hole enabled? Its something I always
assumed needed to be
a flat addressing scheme for linux to work right.

No idea, but... your data is already trashed, right?
:P

I don't think so Mark, although I've yet to see if the dual boot of
FC3 and BDI-Live install works for the BDI side. FC3 once
re-installed, wasn't hurt by the BDI install. Its sitting down there
running FC3 right now. I set it up with a common boot partition, grub
in the mbr, seperate / partitions for everything else except /var and
a shared common swap and /var on a second drive. In theory, it
should work, in practice, darnedifIknow yet. But it should, and I
think I can fix anything thats keeping it from dual booting, I've
been running linux since RH5 in late 97 or thereabouts.

Post by Mark Pictor

Post by Gene Heskett
I've also thought of getting another, faster
motherboard for that box,
its an elderly Micro Millineum with a 233mhz PII on
it & its video
card is also somewhat fubar too, if the blanker
kicks in for a blank
screen, the recovery is to a totally trashed image
and you have to
find the mouse pointer and use it to switch windows,
at which point a
total redraw fixes things up. It claims its got 16
megs of memory,
but I don't think the top 8 megs is actually there.
I've got an old
Diamond SpeedStar A50 in my firewall box that claims
8 megs, but the
sys6326 chipset can only address 4 of them. It
works just fine
though. Obviously I'm not a gamer, other than a
quick game of
kondike once in a while. :)

Hmmm. If this system is that old, is it PCI2.1
compliant? that could be a problem. And even if it
claims to be, it may not. See if the bios allows you
to change the pci version, and try it the other way.

Thats not available, but phoenix claims that the version 4 (newest)
release is a lot better on their website. Probably pure propaganda
though. :)

OTOH, I did not see anyplace to dl a later bios image when browsing
the MCP (was Micron Millinia). They did, when I entered the serial
number, know exactly that machine though.

[Mark Pictor]

The pci config registers contain some data to tell the
system about the card:
Vendor ID, Device ID - identifies the make and model
of the chip

Subsystem Vendor, Subsystem Device - same as above,
except if the chip has been repackaged (i.e. a Netgear
NIC with a Realtek chip) they will be different.

Device type - this tells the system if the device is a
video, NIC, IDE, etc.

If one time it thinks the card is ethernet, and
another time it thinks it's RAID, then this config
data must be totally screwed up (i.e. it's the random
power-on register contents)

If the card has a bios, it may be ignored if it's
missing the magic signature. IIRC some bioses look
for it, some don't, some fail silently, some give an
error. You may be able to grab the data and execute
it with a bios utility... but this will take some work
obviously.

I wonder how easy it would be for Futurlec to forget
to program the flash?

Good luck.
Mark



__________________________________
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com

[Gene Heskett]

Post by Mark Pictor
The pci config registers contain some data to tell the
Vendor ID, Device ID - identifies the make and model
of the chip
Subsystem Vendor, Subsystem Device - same as above,
except if the chip has been repackaged (i.e. a Netgear
NIC with a Realtek chip) they will be different.
Device type - this tells the system if the device is a
video, NIC, IDE, etc.
If one time it thinks the card is ethernet, and
another time it thinks it's RAID, then this config
data must be totally screwed up (i.e. it's the random
power-on register contents)
If the card has a bios, it may be ignored if it's
missing the magic signature. IIRC some bioses look
for it, some don't, some fail silently, some give an
error. You may be able to grab the data and execute
it with a bios utility... but this will take some work
obviously.
I wonder how easy it would be for Futurlec to forget
to program the flash?
Good luck.
Mark

And that exact thought has crossed my mind more than once Mark. I've
just this evening sent a 2nd message to futurlec, indicating that I
think the card is defective. The first one hasn't been replied to
and that was wednesday IIRC, but I didn't say it was defective the
first time, just that it was being difficult and that I objected to
the 10% surcharge MC was charging me for the USD<->AUD conversion
when the web pages prices are very plainly in USD.

I found some code in the form of a loadable module that might work on
the bdi's 2.4.25 kernel, so I'll try that tomorrow. The name of the
file I found is dpci8255.tar.gz, a google search should spit it out
quicker than I could post it here. The srcs are there, but no
Makefile. And no contact info for the author either. Gawd I hate
reinventing wheels.

[Jim Fong]

Gene,

I took a look at the board schematic for the PCI-8255 and it is based on a
Xilinx XC95108 CPLD. This is a medium sized logic chip and is way to small
to hold a full PCI bridge DMA core. This is one reason why linux doesn't see
the board correctly. I'm pretty sure the CPLD is used to map the 8255
chips within the PC's 64K standard I/O address space. The dip switches can
be used to map the board at address F100H through F500H.

I think you can forget about the vendor device ID's etc. Probably isn't any
official ID's burned into the CPLD and isn't needed since this board doesn't
adhere to the full PCI specification anyway. It uses DIP switches to set the
board address and "Plug and Play" won't work here.

You should be able to use GCC to access the board, something like this.

baseaddress = 0xf100;

outb(baseaddress+0xc0, 0x90); //set 8255 Control PORT for data
direction. PORT1 input, PORT2 and PORT3 output

data = inb(baseaddress); //read data from 8255 PORT1
outb(baseaddress+0x4, data); //write data to 8255 PORT2
outb(baseaddress+0x8, data); //write data to 8255 PORT3

you may need to use iopl to open up (baseaddress + 0x0) through
(baseaddress + 0x2C) under linux. It's been a long time since I did some I/O
device driver code under linux. Older 2.2 kernel, don't know if it is the
same under the newer versions.

If I had access to some of the source code examples that came with the
board, I can quickly tell if the above is correct or not.

Jim

[Paul]

Hi Jim

From what I understand of the PCI specification, at least one BAR register is
required to allow the IO to be mapped in to a usable address range. Even if
the device does not implement the full bridge functionality, the space to
store the bare minimum of config data shouldn't be too great.

If the Vendor:Device IDs are indeed missing, this makes autodetection
difficult and a driver would have to rely on the slot number being passed
instead...

Gene: What ever information you can get from from the manufacturer regarding
the config registers will be a big help. Some sample code for a Linux system
would be even better as long as it includes any setup routines.


Regards, Paul.

Post by Jim Fong
took a look at the board schematic for the PCI-8255 and it is based on a
Xilinx XC95108 CPLD. This is a medium sized logic chip and is way to small
to hold a full PCI bridge DMA core. This is one reason why linux doesn't
see the board correctly.   I'm pretty sure the CPLD is used to map the 8255
chips within the PC's 64K standard I/O address space.  The dip switches can
be used to map the board at address F100H through F500H.
I think you can forget about the vendor device ID's etc. Probably isn't any
official ID's burned into the CPLD and isn't needed since this board
doesn't adhere to the full PCI specification anyway. It uses DIP switches
to set the board address and "Plug and Play" won't work here.

[Gene Heskett]

Post by Paul
Hi Jim

[Ray Henry]

If Jim is correct that this card looks like 3 8255s plugged into IO
space we're all working to hard to try to figure it out. You should be
able to point DIO_Exercise.tcl at that base address and see an 8255
somewhere between base and the second 8255 address. Once you find the
first port down in ordinary IO space, you should be able to write a
config to the fourth port and have a workable chip emulator. Then you
can use the exerciser to twiddle bits.

I've done a similar thing with PCI 8255 emulators from Measurement
Computing but that card has a full PCI bridge and my computer tells me
its memory address. I started with one of the board modules available
on the web. Once the chip is configured using that module, I could
write directly to it with the exerciser. I'm told I need to add a
disclaimer, "professional driver (or wild assed amateur), do not try
this at home on a real machine."

This will NOT allow for rtai manipulation of the card but at least you
will know whether the card itself works. If yes, then start writing an
EMC specific module for it.

Ray

Post by Jim Fong
Gene,
I took a look at the board schematic for the PCI-8255 and it is based on a
Xilinx XC95108 CPLD. This is a medium sized logic chip and is way to small
to hold a full PCI bridge DMA core. This is one reason why linux doesn't see
the board correctly. I'm pretty sure the CPLD is used to map the 8255
chips within the PC's 64K standard I/O address space. The dip switches can
be used to map the board at address F100H through F500H.
I think you can forget about the vendor device ID's etc. Probably isn't any
official ID's burned into the CPLD and isn't needed since this board doesn't
adhere to the full PCI specification anyway. It uses DIP switches to set the
board address and "Plug and Play" won't work here.
You should be able to use GCC to access the board, something like this.
baseaddress = 0xf100;
outb(baseaddress+0xc0, 0x90); //set 8255 Control PORT for data
direction. PORT1 input, PORT2 and PORT3 output
data = inb(baseaddress); //read data from 8255 PORT1
outb(baseaddress+0x4, data); //write data to 8255 PORT2
outb(baseaddress+0x8, data); //write data to 8255 PORT3
you may need to use iopl to open up (baseaddress + 0x0) through
(baseaddress + 0x2C) under linux. It's been a long time since I did some I/O
device driver code under linux. Older 2.2 kernel, don't know if it is the
same under the newer versions.
If I had access to some of the source code examples that came with the
board, I can quickly tell if the above is correct or not.
Jim

[Gene Heskett]

Post by Ray Henry
If Jim is correct that this card looks like 3 8255s plugged into IO
space we're all working to hard to try to figure it out. You should
be able to point DIO_Exercise.tcl at that base address and see an
8255 somewhere between base and the second 8255 address. Once you
find the first port down in ordinary IO space, you should be able
to write a config to the fourth port and have a workable chip
emulator. Then you can use the exerciser to twiddle bits.

Hum, this looks like I need a bag of led's & a test card to plug into
one of the 34 pin headers. The 8255 should be able to sink enough to
turn on an led. I'll go see what I can find at the shack. Anyplace
else is a 40 mile or more drive for me.

Post by Ray Henry
I've done a similar thing with PCI 8255 emulators from Measurement
Computing but that card has a full PCI bridge and my computer tells
me its memory address. I started with one of the board modules
available on the web. Once the chip is configured using that
module, I could write directly to it with the exerciser. I'm told
I need to add a disclaimer, "professional driver (or wild assed
amateur), do not try this at home on a real machine."

Aww, gee, that takes all the fun out it, Ray :)

Post by Ray Henry
This will NOT allow for rtai manipulation of the card but at least
you will know whether the card itself works. If yes, then start
writing an EMC specific module for it.
Ray

Post by Jim Fong
Gene,
I took a look at the board schematic for the PCI-8255 and it is
based on a Xilinx XC95108 CPLD. This is a medium sized logic chip
and is way to small to hold a full PCI bridge DMA core. This is
one reason why linux doesn't see the board correctly. I'm pretty
sure the CPLD is used to map the 8255 chips within the PC's 64K
standard I/O address space. The dip switches can be used to map
the board at address F100H through F500H.
I think you can forget about the vendor device ID's etc. Probably
isn't any official ID's burned into the CPLD and isn't needed
since this board doesn't adhere to the full PCI specification
anyway. It uses DIP switches to set the board address and "Plug
and Play" won't work here.
You should be able to use GCC to access the board, something like this.
baseaddress = 0xf100;
outb(baseaddress+0xc0, 0x90); //set 8255 Control PORT for data
direction. PORT1 input, PORT2 and PORT3 output
data = inb(baseaddress); //read data from 8255 PORT1
outb(baseaddress+0x4, data); //write data to 8255 PORT2
outb(baseaddress+0x8, data); //write data to 8255 PORT3
you may need to use iopl to open up (baseaddress + 0x0) through
(baseaddress + 0x2C) under linux. It's been a long time since I did
some I/O device driver code under linux. Older 2.2 kernel, don't
know if it is the same under the newer versions.
If I had access to some of the source code examples that came with
the board, I can quickly tell if the above is correct or not.
Jim

[Jim Fong]

For a simple PCI card, you only need about 64bytes to store the ID info.
This can easily fit in the CPLD.

Just looking at the board schematic, I don't see the PCI IDSEL signal being
used anywhere on the board. This makes it even harder for autodetection to
work right....

Or it could be the schematic I'm looking at is a old revision or may not
even be the right one. Just the bare minimum of PCI signal lines are even
connected to the Xilinx CPLD.

Jim

-----Original Message-----
Sent: Monday, November 08, 2004 5:49 AM
Subject: Re: [Emc-users] non-progress for Futurlec PCI8255 card
Hi Jim

[Gene Heskett]

Post by Jim Fong
For a simple PCI card, you only need about 64bytes to store the ID
info. This can easily fit in the CPLD.
Just looking at the board schematic, I don't see the PCI IDSEL
signal being used anywhere on the board. This makes it even harder
for autodetection to work right....
Or it could be the schematic I'm looking at is a old revision or may
not even be the right one. Just the bare minimum of PCI signal
lines are even connected to the Xilinx CPLD.
Jim

I wasn't terribly impressed with the reproduction of that schematic
myself, looks like a scan done on a pretty low-res scanner. I've got
a 100 dollar epson 1250u that will blow whatever they used right out
of the water. It might be ok if it was blown up about 4 to 16x & had
a little touchup here and there. Too bad I can't figure out a way to
get it into the gimp & make a real printout.

Post by Jim Fong

-----Original Message-----
Sent: Monday, November 08, 2004 5:49 AM
Subject: Re: [Emc-users] non-progress for Futurlec PCI8255 card
Hi Jim

[Jim Fong]

They did a poor PDF conversion. The schematic I'm looking at is dated
13-MAY-2003 ET-PCI8255. Is yours the same? I did convert it to jpeg but it
didn't come out any better.

The design of the board is pretty interesting since it is a nice hack to
implement a PCI interface using only about 26 bus signal lines. Not much
more then a simple ISA interface design. I would live to see the Xilinx HDL
code that implements the bus timing to get this to work so simply.

Jim

Post by Gene Heskett
I wasn't terribly impressed with the reproduction of that schematic
myself, looks like a scan done on a pretty low-res scanner. I've got
a 100 dollar epson 1250u that will blow whatever they used right out
of the water. It might be ok if it was blown up about 4 to 16x & had
a little touchup here and there. Too bad I can't figure out a way to
get it into the gimp & make a real printout.

[Gene Heskett]

Post by Jim Fong
They did a poor PDF conversion. The schematic I'm looking at is
dated 13-MAY-2003 ET-PCI8255. Is yours the same? I did convert it
to jpeg but it didn't come out any better.
The design of the board is pretty interesting since it is a nice
hack to implement a PCI interface using only about 26 bus signal
lines. Not much more then a simple ISA interface design. I would
live to see the Xilinx HDL code that implements the bus timing to
get this to work so simply.
Jim

Is that super critical for writes JIm? Reads maybe unless somebody
has built a serious fire under the current crop of 8255's to speed
them up. My guess is that it takes a several cycle wait state to
give the 8255 time to drive fully the bus. Maybe even for the write
cycle too. Probably he mumbles to hisself... OTOH, I haven't looked
up the bus timeings on an 8255 since 1979 or thereabouts. I know
this stuff gets regular shrinks, and speed comes free with the
shrink.

Did you see the spec sheet on that cd, its actually an 82C55, with
only 2.5 ma of drive available per pin. That sucks big time. And I
hope its enough to drive the lm278's that will run the motors. Time
to break out that cd too I guess and check that limitation out.

Paul, I also see, now that I've tried (and failed) to make the
schematic actually readable) that the dipswitch is on the 2nd LSB of
the address, eg $F300, not $0F30 for the defaults. So the 8255 ports
are at $F300, $F304 for PartA & portB of the first one, and $F310 etc
for the second one etc. OTOH, that probbaly means I could put it
below the seriel ports at $0278 by putting it at $02. Or is there
something else reserved there on the average mobo?

Also, in this machines bios, I can reserve whole 4k pages of memory
from the $Cxxx and $Dxxx ranges, should I put it in one of those
reserved areas after I reserve one of them?

[Jim Fong]

Post by Gene Heskett
Is that super critical for writes JIm? Reads maybe unless somebody
has built a serious fire under the current crop of 8255's to speed
them up. My guess is that it takes a several cycle wait state to
give the 8255 time to drive fully the bus. Maybe even for the write
cycle too. Probably he mumbles to hisself... OTOH, I haven't looked
up the bus timeings on an 8255 since 1979 or thereabouts. I know
this stuff gets regular shrinks, and speed comes free with the
shrink.

I'm referring to the PCI bus timing implementation in the Xilinx
programmable logic chip. The PLD chip takes care of the timing between the
much faster PCI bus and the sloooooower 8255 8bit interface bus. I'm just
interested on how the designer did that. If I knew, I can make super simple
PCI cards for my own interface projects. I have a bunch of Xilinx chips
here.

Post by Gene Heskett
Did you see the spec sheet on that cd, its actually an 82C55, with
only 2.5 ma of drive available per pin. That sucks big time. And I
hope its enough to drive the lm278's that will run the motors. Time
to break out that cd too I guess and check that limitation out.

I built several 8255 ISA bus cards about 15 years ago using regular 8255. I
forgot how much current they can put out but I probabaly still have a bunch
of them in my junk pile of parts. I wrote the interface code using Microsoft
Quickbasic and later C.

Post by Gene Heskett
Paul, I also see, now that I've tried (and failed) to make the
schematic actually readable) that the dipswitch is on the 2nd LSB of
the address, eg $F300, not $0F30 for the defaults. So the 8255 ports
are at $F300, $F304 for PartA & portB of the first one, and $F310 etc
for the second one etc. OTOH, that probbaly means I could put it
below the seriel ports at $0278 by putting it at $02. Or is there
something else reserved there on the average mobo?

I still think the dip switches sets the board direct I/O address range in
the same region as the original IBM PC 16bit 1/O address map. In this case
0xf100, 0xf200, 0xf300, 0xf400 or 0xf500.

The serial ports are normally located at 0x0278 and 0x0378.
Parallel ports at 0x0278, 0x0378 and 0x03bc.

Try accessing the 8255 card like a standard parallel port. Set the DIP
switches for 0xf100 and write a control byte (0x90) to location 0xf10c.
Then send out a byte to 0xf104 and my guess is that the bits on the 8255
chip#1 port PB2 will toggle.

Jim

[Gene Heskett]

Post by Jim Fong

Post by Gene Heskett
Is that super critical for writes JIm? Reads maybe unless
somebody has built a serious fire under the current crop of 8255's
to speed them up. My guess is that it takes a several cycle wait
state to give the 8255 time to drive fully the bus. Maybe even
for the write cycle too. Probably he mumbles to hisself... OTOH,
I haven't looked up the bus timeings on an 8255 since 1979 or
thereabouts. I know this stuff gets regular shrinks, and speed
comes free with the shrink.

I'm referring to the PCI bus timing implementation in the Xilinx
programmable logic chip. The PLD chip takes care of the timing
between the much faster PCI bus and the sloooooower 8255 8bit
interface bus. I'm just interested on how the designer did that.
If I knew, I can make super simple PCI cards for my own interface
projects. I have a bunch of Xilinx chips here.

Post by Gene Heskett
Did you see the spec sheet on that cd, its actually an 82C55, with
only 2.5 ma of drive available per pin. That sucks big time. And
I hope its enough to drive the lm278's that will run the motors.
Time to break out that cd too I guess and check that limitation
out.

I built several 8255 ISA bus cards about 15 years ago using regular
8255. I forgot how much current they can put out but I probabaly
still have a bunch of them in my junk pile of parts. I wrote the
interface code using Microsoft Quickbasic and later C.

Post by Gene Heskett
Paul, I also see, now that I've tried (and failed) to make the
schematic actually readable) that the dipswitch is on the 2nd LSB
of the address, eg $F300, not $0F30 for the defaults. So the 8255
ports are at $F300, $F304 for PartA & portB of the first one, and
$F310 etc for the second one etc. OTOH, that probbaly means I
could put it below the seriel ports at $0278 by putting it at $02.
Or is there something else reserved there on the average mobo?

I still think the dip switches sets the board direct I/O address
range in the same region as the original IBM PC 16bit 1/O address
map. In this case 0xf100, 0xf200, 0xf300, 0xf400 or 0xf500.

That would be for the right hand 4 switches, the left hand four
switches can set that initial $f to anyplace including $0. I'd have
to assume that since the parport and seriel ports are at $0278/$378
and such, that one could probably put it at $02x0 as long as you
didn't hit one of the other ports and overlap it. Stay $40 below the
lowest of those 3 builtins and it should be out of everyones way.

Post by Jim Fong
The serial ports are normally located at 0x0278 and 0x0378.
Parallel ports at 0x0278, 0x0378 and 0x03bc.

I believe thats the case here.

Post by Jim Fong
Try accessing the 8255 card like a standard parallel port. Set the
DIP switches for 0xf100 and write a control byte (0x90) to location
0xf10c. Then send out a byte to 0xf104 and my guess is that the
bits on the 8255 chip#1 port PB2 will toggle.
Jim

I wonder if that DIO_Exercise.tcl gizmo will work on a 2.6.8.1 kernel?
The interface has changed and I don't have any test leds hooked up ATM
so its going to be a bit of a wrestling match on my pool table.
Thats where all this is setup right now. Trying to keep a scope
probe attached to something can be a bear with at least 4 sore paws.
Humm, I have a scrap card with a 34 pin card edge pattern, and some
old floppy cables for 5.25" drives, that would be a lot easier to
hookup. Construction time I think. But running leds is going to be
a problem with the limited output source or sinking abaility of those
82C55's, only 2.5 ma per pin.

Post by Jim Fong
-------------------------------------------------------
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[Stephen Wille Padnos]

[snip]
I wonder if that DIO_Exercise.tcl gizmo will work on a 2.6.8.1 kernel?
The interface has changed and I don't have any test leds hooked up ATM
so its going to be a bit of a wrestling match on my pool table.
Thats where all this is setup right now. Trying to keep a scope
probe attached to something can be a bear with at least 4 sore paws.
Humm, I have a scrap card with a 34 pin card edge pattern, and some
old floppy cables for 5.25" drives, that would be a lot easier to
hookup. Construction time I think. But running leds is going to be
a problem with the limited output source or sinking abaility of those
82C55's, only 2.5 ma per pin.

There is the test LED on the back of the card - they say in the manual
that you should be able to hook it up to one of the pins on the PORTA
open drain outputs and use it for diagnostics.

- Steve

[Gene Heskett]

Post by Stephen Wille Padnos

[snip]
I wonder if that DIO_Exercise.tcl gizmo will work on a 2.6.8.1
kernel? The interface has changed and I don't have any test leds
hooked up ATM so its going to be a bit of a wrestling match on my
pool table. Thats where all this is setup right now. Trying to
keep a scope probe attached to something can be a bear with at
least 4 sore paws. Humm, I have a scrap card with a 34 pin card
edge pattern, and some old floppy cables for 5.25" drives, that
would be a lot easier to hookup. Construction time I think. But
running leds is going to be a problem with the limited output
source or sinking abaility of those 82C55's, only 2.5 ma per pin.

There is the test LED on the back of the card - they say in the
manual that you should be able to hook it up to one of the pins on
the PORTA open drain outputs and use it for diagnostics.
- Steve

There is indeed two leds on the back of it, and one on the board
itself, and all 3 are lit. I have NDI what the one labeled test is
actually hooked to as there are no jumpers installed in that block
near the back panel end of the card, nor are there any jumpers
soldered in.

[Gene Heskett]

Post by Stephen Wille Padnos

[snip]
I wonder if that DIO_Exercise.tcl gizmo will work on a 2.6.8.1
kernel? The interface has changed and I don't have any test leds
hooked up ATM so its going to be a bit of a wrestling match on my
pool table. Thats where all this is setup right now. Trying to
keep a scope probe attached to something can be a bear with at
least 4 sore paws. Humm, I have a scrap card with a 34 pin card
edge pattern, and some old floppy cables for 5.25" drives, that
would be a lot easier to hookup. Construction time I think. But
running leds is going to be a problem with the limited output
source or sinking abaility of those 82C55's, only 2.5 ma per pin.

There is the test LED on the back of the card - they say in the
manual that you should be able to hook it up to one of the pins on
the PORTA open drain outputs and use it for diagnostics.
- Steve

And I forgot, even after a full reinstall, the /usr/local/emc dir tree
seems to be not quite as intended. I found that DIO_Exercise.tcl
script ok, but its looking for
a /usr/local/emc/tcl/scripts/plat/norealtime/some_file_in_that_directory
that doesn't exist. So of course it won't run. There is a plat dir
one level up toward the /, but it doesn't have a norealtime subdir in
it either. Was my CD fubar, or is this an installer glitch? I also
couldn't find it when booted to the cd so I suspect the iso itself
maybe needs tweaked.

Anyway, no networking etc, but its booting again from the hard drive.

[Ray Henry]

Post by Gene Heskett
<s>
And I forgot, even after a full reinstall, the /usr/local/emc dir tree
seems to be not quite as intended. I found that DIO_Exercise.tcl
script ok, but its looking for
a /usr/local/emc/tcl/scripts/plat/norealtime/some_file_in_that_directory
that doesn't exist. So of course it won't run. There is a plat dir
one level up toward the /, but it doesn't have a norealtime subdir in
it either. Was my CD fubar, or is this an installer glitch? I also
couldn't find it when booted to the cd so I suspect the iso itself
maybe needs tweaked.

A directory named emc/plat/nonrealtime is a link to the plat/version of
linux that is installed. It's made the first time emc runs. But it
does have to run once in order to build this and a realtime link to the
rtai or whatever directory. These are used for convenience in pointing
stuff to the location of these directories across diffferent installs.

Ray

[Gene Heskett]

Post by Ray Henry

Post by Gene Heskett
<s>
And I forgot, even after a full reinstall, the /usr/local/emc dir
tree seems to be not quite as intended. I found that
DIO_Exercise.tcl script ok, but its looking for
a
/usr/local/emc/tcl/scripts/plat/norealtime/some_file_in_that_direc
tory that doesn't exist. So of course it won't run. There is a
plat dir one level up toward the /, but it doesn't have a
norealtime subdir in it either. Was my CD fubar, or is this an
installer glitch? I also couldn't find it when booted to the cd
so I suspect the iso itself maybe needs tweaked.

A directory named emc/plat/nonrealtime is a link to the plat/version
of linux that is installed. It's made the first time emc runs.
But it does have to run once in order to build this and a realtime
link to the rtai or whatever directory. These are used for
convenience in pointing stuff to the location of these directories
across diffferent installs.
Ray

Humm, well, that would explain that then. But how about the missing
link target for /etc/modules.conf, is that also self generated by
running emc one time?

[Ray Henry]

Post by Gene Heskett
<s>
I wonder if that DIO_Exercise.tcl gizmo will work on a 2.6.8.1 kernel?

Nope. Gotta be an EMC cause it uses iosh -- an EMC program. Paul tells
me he is nearly there with the mods to emc1 so that it will compile
under 2.6.

Ray

[Jim Fong]

Post by Gene Heskett
That would be for the right hand 4 switches, the left hand four
switches can set that initial $f to anyplace including $0. I'd have
to assume that since the parport and seriel ports are at $0278/$378
and such, that one could probably put it at $02x0 as long as you
didn't hit one of the other ports and overlap it. Stay $40 below the
lowest of those 3 builtins and it should be out of everyones way.

Hmm I didn't notice that before. I didn't see anything in the manual
regarding those 4 switches on the left.

I think I will buy one of these cards to play around with.

Jim

[Gene Heskett]

Post by Jim Fong

Post by Gene Heskett
That would be for the right hand 4 switches, the left hand four
switches can set that initial $f to anyplace including $0. I'd
have to assume that since the parport and seriel ports are at
$0278/$378 and such, that one could probably put it at $02x0 as
long as you didn't hit one of the other ports and overlap it.
Stay $40 below the lowest of those 3 builtins and it should be out
of everyones way.

Hmm I didn't notice that before. I didn't see anything in the manual
regarding those 4 switches on the left.
I think I will buy one of these cards to play around with.
Jim

That might be helpfull to everyone in the long run, Jim.

Paul, I had to re-install and I have a couple of questions.
I put it all on /dev/hda5 and have 2 problems.

1. The /etc/modules.conf is a link to /MorphixCD/etc/modules.conf
It doesn't exist, so among other things I can copy over the
network-scripts dir from FC3, but cannot achieve networking because
it isn't loading the 8139too.o module, or any other module for that
matter.

2. The

Post by Jim Fong
-------------------------------------------------------
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users