<< Previous | Home | Next >>

34 Pin IDC to 25 Pin Female D-Sub floppy drive pin mapping for Magic Super Griffin

(and probably MGD2, etc)

I cracked open my Magic Super Griffin today after finding an old external floppy drive (FDD) that I wanted to hook up to it. I was expecting to have to look at chip pinouts and signals to figure out which pins were which on the 25-pin connector but to my surprise there was space on the motherboard for a 34pin IDC connector. So the signals can and pinout could be taken directly from that. The FDD controller chip on the SMG, for reference, is a socketed (!) Motorola MCS3201FN - http://www.datasheetarchive.com/pdf-datasheets/Datasheets-111/DSAP0039438.html. The datasheet reveals that the controller can handle up to 1.4M drives too.

\ 13 12 11 10 09 08 07  06 05 04 03 02 01 /
 \  25 24 23 22 21 20 19 18 17 16 15 14  /

The pins above are taken looking directory at the female pin (cable) side of the D-Sub connector.

The pins of the IDC connector are numbered from left to right, vertically, from the component side of the board.

01 02
03 04
33 34

The pin mapping is thus:

D-Sub  - IDC    - Signal     
01     - 01,03,...,33 - GND        
02     - 08           - /INDEX     
03     - 26           - /TRK00     
04     - 28           - /WPT       
05     - 30           - /RDATA     
06     - 34           - /DSKCHG    
07     - NC           - NC         
08     - NC           - +5V        
09     - NC           - NC         
10     - NC           - NC         
11     - 16           - /MOTEB     
12     - 22           - /WDATA     
13     - 24           - /WGATE     
14     - 02           - /REDWC     
15     - 32           - /SIDE1     
16     - 18           - /DIR       
17     - 20           - /STEP      
18     - 01,03,...,33 - GND        
19     - 01,03,...,33 - GND        
20     - 01,03,...,33 - GND        
21     - 01,03,...,33 - GND        
22     - 01,03,...,33 - GND        
23     - 01,03,...,33 - GND        
24     - 01,03,...,33 - GND        
25     - 01,03,...,33 - GND        
Shield - 01,03,...,33 - GND

With the above information I'm now able to make a suitable cable to connect up any standard PC floppy disk drive. I don't know which model drives are actually compatible. Though I would suggest checking out the Datasheet for the FDD controller chip. If you have any success please let me know so I can share the information with others.

BTW, If you didn't know already a Super Magic Griffin is a PC Engine console backup unit. With it you can load dumped ROM images into the SMG and then run them on your PC Engine console. The unit is basically a ROM emulator with FDD and Parallel I/O connections. They were manufactured by Front Fareast Co. Ltd. (Taiwan).

No-Fuss Tomcat 5.5 installation on OSX 10.5 (December 2009)

After a bit of googling on the topic I couldn't find a decent guide of how to install Tomcat 5.5 on OSX.  Here's how I did it.

Download the apache-tomcat-5.5.28.zip zip file from 'Core' section of the Tomcat 5.5 download page from here: http://tomcat.apache.org/download-55.cgi
Download the apache-tomcat-5.5.28-admin.zip zip file from the same page

Open a terminal window.

# perform following operations as root
sudo su -

# unpack tomcat
cd /Library
unzip ~/downloads/apache-tomcat-5.5.28.zip
unzip ~/downloads/apache-tomcat-5.5.28-admin.zip
mv apache-tomcat-5.5.28 Tomcat5

# remove the holding page for the message about the admin webapp not being included by default
rm -rf /Library/Tomcat5/webapps/ROOT/admin

# create tomcat group and user
dscl . -create /groups/tomcat
dscl . -create /groups/tomcat Password "*"
dscl . -create /groups/tomcat PrimaryGroupID 498
dscl . -create /groups/tomcat RealName "Apache Tomcat Users"
dscl . -create /users/tomcat
dscl . -create /users/tomcat Password "*"
dscl . -create /users/tomcat UniqueID 498
dscl . -create /users/tomcat PrimaryGroupID 498
dscl . -create /users/tomcat RealName "Apache Tomcat Server"
dscl . -create /users/tomcat NFSHomeDirectory /var/empty
dscl . -create /users/tomcat UserShell /usr/bin/false

# Hide the tomcat user (and all other users with a UniqueID less than 500) from the Mac OS X GUI
defaults write /Library/Preferences/com.apple.loginwindow Hide500Users -bool true

# fix permissions
cd /Library
chown -R tomcat:tomcat Tomcat5
chmod +x Tomcat5/bin/*.sh

# use a text editor to create a launch script
mate /Library/LaunchDaemons/org.apache.tomcat5.plist

paste in the following xml content and save the file

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">

Configure the tomcat users

mate /Library/Tomcat5/conf/tomcat-users.xml

paste in the following xml content and save the file

<?xml version='1.0' encoding='utf-8'?>
  <role rolename="tomcat"/>
  <role rolename="role1"/>
  <role rolename="manager"/>
  <role rolename="admin"/>
  <user username="tomcat" password="tomcat" roles="tomcat"/>
  <user username="both" password="tomcat" roles="tomcat,role1"/>
  <user username="role1" password="tomcat" roles="role1"/>
  <user username="admin" password="secret" roles="admin,manager"/>

Finally, start tomcat

launchctl load -w /Library/LaunchDaemons/org.apache.tomcat.plist

You can now start your browser and point it to:


You can login to both the manager application and the admin application using the username: 'admin' and the password: 'secret'

Creating GMock expectations for methods that have a closure as a parameter

If like me you want to test as much of your grails/groovy application as possible then at some point you'll need to create a unit test for a method that accepts a closure as an argument.  GMock has the ability to use a 'match' closure to check to see if the arguments passed o your mock object are what you expect.  The example from their site is:

mockLoader.put("test", match { it > 5 }).returns("correct")
play {
    assertEquals "correct", mockLoader.put("test", 10)

The play closure calls the mockLoader instance's put method and the second parameter is passed to the match closure and if that closure returns true the value returned by the mockLoader instance will be the string 'correct'.

I had a method like this which I wanted to call and needed to mock out the deviceCriteria object and have the return value of the call to 'get' always return a fixed value so that other code in the test would behave correctly for the rest of the test.

protected Long countDevicesForLicense() {
    grails.orm.HibernateCriteriaBuilder deviceCriteria = Device.createCriteria()
        eq("license", this)
        projections {
            countDistinct "id"

The gmock test for this looks like this:

 * Tests that a device cannot be added to a license that cannot have more devices added to it
void testAddDevicesToFullLicense() {
    def deviceCountResult = 10
    def mockDevice = mock(Device)
    mockDevice.static.createCriteria().returns( mock(grails.orm.HibernateCriteriaBuilder) {
        get(match { arg ->
            arg instanceof Closure

    play {
        License license1 = new License(name: 'Full', maxDevices: 10)
        Device device1 = new Device(name: 'Test device')
        assertFalse license1.canAddDevice(device1)

Here, the canAddDevice() method internally calls the countDevicesForLicense() but as this is a unit test, not an integration tests no database is available so using a real HibernateCriteriaBuilder object would fail.  Thus we either have to mock out the database objects or create a partial mock.  And before anyone says anything - yes, a partial mock here would be better, but that's for another day.

So, the code above sets up an expection on the createCriteria static method of the Device domain class which says the method must be called and when it is called it returns a mock grails.orm.HibernateCriteriaBuilder object that has a 'get' method which should always return the value assigned to 'deviceCountResult'.

If you just tried:


then you'd find the expectation for the 'get' method would fail.

The important point is the match closure that checks to see if the argument passed is a Closure.

Hope this helps!