![ToToTEK.COM Forum Index](templates/subSilver/images/logo_phpBB.gif) |
ToToTEK.COM Help & Support Forum
|
View previous topic :: View next topic |
Author |
Message |
Oerg
Joined: 12 May 2007 Posts: 78
|
Posted: Sat Dec 08, 2012 7:55 pm Post subject: Tototek MD-Pro & co with PCI Parallel ports EXPLAINED |
|
|
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 |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
Chilly Willy
Joined: 08 Feb 2009 Posts: 174
|
Posted: Mon Dec 10, 2012 2:15 am Post subject: |
|
|
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
Code: | void
ttt_init_io (unsigned int port)
{
#if (defined __unix__ || defined __BEOS__) && !defined __MSDOS__
init_conio ();
#endif
port_8 = port; // original code used 0x378 for port_8
port_9 = port + 1;
port_a = port + 2;
port_b = port + 3;
port_c = port + 4;
parport_print_info ();
init_port ();
} |
That's where your insert the PCI fetched base values. I imagine there are very different routines for Windows vs linux on getting the PCI bases. I should look into the linux side...
And doing so, I see it's probably easier to change things in src/misc/parallel.c. The Tototek code uses outportb and inportb, both of which are in parallel.c. In fact, look at inportb...
Code: | unsigned char
inportb (unsigned short port)
{
#ifdef USE_PPDEV
int ppreg = port - ucon64.parport;
unsigned char byte;
switch (ppreg)
{
case 0: // data
if (parport_io_direction == FORWARD) // dir is forward?
{
parport_io_direction = REVERSE; // change it to reverse
ioctl (parport_io_fd, PPDATADIR, &parport_io_direction);
}
ioctl (parport_io_fd, PPRDATA, &byte);
break;
case 1: // status
ioctl (parport_io_fd, PPRSTATUS, &byte);
break;
case 2: // control
ioctl (parport_io_fd, PPRCONTROL, &byte);
break;
case 3: // EPP/ECP address
if (!(parport_io_mode & IEEE1284_ADDR)) // IEEE1284_DATA is 0!
{
parport_io_mode |= IEEE1284_ADDR;
ioctl (parport_io_fd, PPSETMODE, &parport_io_mode);
}
read (parport_io_fd, &byte, 1);
break;
case 4: // EPP/ECP data
if (parport_io_mode & IEEE1284_ADDR)
{
parport_io_mode &= ~IEEE1284_ADDR; // IEEE1284_DATA is 0
ioctl (parport_io_fd, PPSETMODE, &parport_io_mode);
}
read (parport_io_fd, &byte, 1);
break;
case 0x402: // ECP register
printf ("WARNING: Ignored read from ECP register, returning 0\n");
byte = 0;
break;
default:
fprintf (stderr,
"ERROR: inportb() tried to read from an unsupported port (0x%x)\n",
port);
exit (1);
}
return byte; |
That's the linux code (which uses USE_PPDEV). Looking at this, it looks like this should work on a card just fine. See how it takes the address of the port set in ttt_init_io and works back to which register it is and then uses ioctl to handle the register?
Here's the Windows code:
Code: | #elif defined _WIN32 || defined __CYGWIN__
return input_byte (port);
|
You can see which platform the ucon64 devs use.
So Windows needs work on the outportb/inportb routines, while linux should work. I can't test that as I don't have a PCI parallel port board. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
dbjh
Joined: 02 Aug 2003 Posts: 167
|
Posted: Sat Apr 29, 2017 1:57 am Post subject: |
|
|
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. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
dbjh
Joined: 02 Aug 2003 Posts: 167
|
Posted: Wed May 31, 2017 2:26 am Post subject: Enabling EPP through the ECP Extended Control register. |
|
|
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. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|