Help & Support Forum
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Tototek MD-Pro & co with PCI Parallel ports EXPLAINED

Post new topic   Reply to topic    ToToTEK.COM Forum Index -> MD-PRO Flash Cart
View previous topic :: View next topic  
Author Message

Joined: 12 May 2007
Posts: 78

PostPosted: Sat Dec 08, 2012 7:55 pm    Post subject: Tototek MD-Pro & co with PCI Parallel ports EXPLAINED Reply with quote


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.


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.

Back to top
View user's profile Send private message
Chilly Willy

Joined: 08 Feb 2009
Posts: 174

PostPosted: Mon Dec 10, 2012 2:15 am    Post subject: Reply with quote

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.
Evil or Very Mad

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:

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

ttt_init_io (unsigned int port)
#if     (defined __unix__ || defined __BEOS__) && !defined __MSDOS__
  init_conio ();

  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...

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);
    case 1:                                     // status
      ioctl (parport_io_fd, PPRSTATUS, &byte);
    case 2:                                     // control
      ioctl (parport_io_fd, PPRCONTROL, &byte);
    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);
    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);
    case 0x402:                                 // ECP register
      printf ("WARNING: Ignored read from ECP register, returning 0\n");
      byte = 0;
      fprintf (stderr,
               "ERROR: inportb() tried to read from an unsupported port (0x%x)\n",
      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:

#elif   defined _WIN32 || defined __CYGWIN__
  return input_byte (port);

You can see which platform the ucon64 devs use. Laughing

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
View user's profile Send private message

Joined: 02 Aug 2003
Posts: 167

PostPosted: Sat Apr 29, 2017 1:57 am    Post subject: Reply with quote

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
View user's profile Send private message

Joined: 02 Aug 2003
Posts: 167

PostPosted: Wed May 31, 2017 2:26 am    Post subject: Enabling EPP through the ECP Extended Control register. Reply with quote

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 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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    ToToTEK.COM Forum Index -> MD-PRO Flash Cart All times are GMT
Page 1 of 1

Jump to:  
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