ToToTEK.COM

[Oerg]

Hi,

Today we're going to be looking at the question:

Why won't my MD-Pro work with my PCI Parallel port card?

Actually, let's back up for a second.

In itself, the PCI parallel port cards claim to be (and mostly are) IEEE 1248 compatible, which is the specification for ECP/EPP based parallel ports.

There is a configuration register set, as defined by the specification, that should be at Base_Addr+0x400, whereby 0x402 is the ECR, the Extended Control register. In this register, you tell the parallel port that you'd like to put it in EPP mode, and some other things crucial for this thing actually doing what you want it to do.

Under Windows 9x operating systems, these PCI cards can be (and will be) remapped to legacy address spaces (0x278, 0x378) by the drivers.

Modern Windows and Linux OSs won't let you do that of course, so we have a problem there already, that the OS assigns adress spaces by PnP.

This actually shouldn't be a problem, since the card is still compliant to the EPP spec, just at a different address range. Ucon64 and co even support arbitrary port numbers (I've checked in the sources).

This, therefore, should absolutely work just fine.

It doesn't.

Why?

Well, because the implementations made by the main Parallel Port Chip makers (Oxford, Sunix, etc.) make no sense. They decided to ignore the fact that the parallel port's configuration registers are supposed to be at the base register + 0x400, and instead get this adress range assigned by the OS *as well*, and have a few base register IDs in the PCI configuration space tell the base adress instead.

This means, the chance that the config registers are exactly 400 bytes above the base adress, are slim to none. The registers are all there, just not where they're supposed to be.

Check this out:



Here the order is REVERSED. The config regs are 400 bytes *before* the base adress.

I've checked the documentation of two of those chips, they both have the registers containing the adress spaces in the same place within PCI configuration space. The only way to get the MD Pro working properly is to patch ucon64 to *poll* these registers, and take appropriate action based on these values.

I might be working on that soon.

Cheers!
Eric

[Chilly Willy]

It makes sense as far as a PCI board goes... everything is allocated dynamically according to where there is space and what else in in the system. It sucks as far as backwards compatibility goes... what parallel port makers SHOULD have done is made all the regs one single resource with backward compatible spacing inside that one block. Naturally, no one does.


As for editing ucon64, you want the latest from the cvs, not the source on their home page, which is years out of date. The instructions on getting the cvs code is also years out of date. You need to go straight to the sourceforge page to get the proper info:

http://sourceforge.net/scm/?type=cvs&group_id=12381&source=navbar

That allows you to check out the latest ucon64. Then in src/backup/tototek.c, you need to change the ttt_init_io() function. It's currently

[dbjh]

Just to prevent people who will read this thread for the first time from getting the wrong idea: I have updated uCON64 and it is now possible to specify the offset of the Extended Control register in uCON64's configuration file. The changes are in CVS. If you cannot compile yourself you will have to wait until the next release (uCON64 2.1.0). At least on Windows I could have made it automatic, but I did not want to basically copy what this port of inpout32.dll does. And I prefer a solution that works on the other platforms as well. I am not able to test with an MD-PRO as I do not own one. I am curious about any issue with this feature.

[dbjh]

For the record, Oerg assumed that EPP *has* to be enabled through the ECP Extended Control register. However, as this post appears to suggest, that is not always required. The system Armathrillo was using has its Data register at address 0xDF00 and the Extended Contol register at address 0xDE02. So, clearly not at offset 0x402 (relative to 0xDF00). He also had to have both EPP and ECP enabled in the configuration software that came with his PCI parallel port card before he could use the official software with his Super Flash.
The only other reason I can think of why a parallel port does not appear to work with an MD-PRO (or GG-PRO, PCE-PRO, Super Flash or SMS-PRO) is the way the EPP Time-out bit needs to be cleared. The latest WIP build of uCON64 (available from http://ucon64.sourceforge.net) uses 3 ways while the official software uses 1. If a parallel port chipset happens to require one of the other 2 the official software may not be able to communicate with the device. I have no idea whether those other ways to clear the EPP Time-out bit are at all common.