Zerosquare

AlexH : as a matter of fact, my job is designing hardware too, so I think I'll manage. But thanks for the help proposal anyways

 

CJ : thanks, I'll definitely include your bypass code.

The "BJL emulation" part is already planned. Check the FAQ for details

 

I thought about the CD-bypass feature too ; I'm not sure if we'll have enough space to include it (we only have a few kilobytes for the code), but if we can we'll do so

Yes, in reality the prices will be lower, because we will be manufacturing much more than 10 cartridges. The price I gave above is a maximum

 

We know it can add up to a lot of money in total. One solution is to ask for prepayment, or at least a money deposit, for preorders. That way you'll know how much persons are going to order, and you'll have some money from the start

Did you mean to say for 10 boards, each one would costs ~15 Euro? (+ shell, manufacturing etc?)

Yes. 1.5 euro per board would be nice, but unfortunately, there's no way we can get those prices

It's statements like that which make people think you guys are condescending -- I offered something I'd already done as a suggestion, and your response is that it is a pointless thing to do - implying that I wasted my time. I'm sure you didn't mean it that way.

Not at all, I think we misunderstood each other there

 

There's something I'm not sure I understand. Do you have an independent serial number in the BIOS in addition to the flash chip unique number ? I thought you used the flash chip number only, since it identifies the hardware directly and it's hard to counterfeit. Or maybe the BIOS number is generated from the flash chip number in some way ?

 

I should have been more clear in my reply. The crux of the matter is that your Skunkboard and our flash cart have different design philosophies, and things that are justified for one of them may not be so for the other :

 

If I'm not mistaken, the Skunkboard is primarily a development tool. Serialized Skunkboards make sense because the hardware supports it natively, and this feature can be useful for developers who want to release betas versions to a few persons, without the risk of their game being released without their consent.

 

On the other hand, our cart has been designed as a way for developers to make it easy to release cartridge games. We added support for using it as a "generic flash cart" because it didn't cost anything extra, but it's not the primary use, and it's not really intended as a development tool either. Reflashing will probably be slower than on the Skunkboard (because it uses parallel port communication instead of USB, and I think the flash chip we use takes longer to erase -- I'll have to compare the datasheets), and the Skunkboard's USB port is definitely more convenient.

 

One of the consequences is that we never intended to support serialization, and the design choices reflect that. The flash chip doesn't include a serial number, and there is no safe place to store a self-created unique number. Of course it would be possible to include one in the BIOS, but :

- it wasn't designed to be secure, so anyone can overwrite it. We may even release the source, which makes security-by-obscurity pretty moot.

- it wasn't designed to be protected, or even present : developers may want to write the standard header (or their own code) in this area. Additionally, it can be corrupted / erased if the flashing process fails for some reason, such as power loss (and sector locking is not possible, because we'd like to be able to use both "top-boot" and "bottom-boot" devices, as stocks of both variants tend to fluctuate). This means that even in "normal usage", it's easy to end up with the serial number being erased, with no way of knowing what it originally was.

 

To sum it up, while serializing is useful for the Skunkboard, I don't think it's relevant for our flash cart. And I prefer no to offer it at all, instead of using a implementation I consider flawed

But if developers really want this feature, we could implement it.

You could just burn it into the BIOS like we did if your users demand it.

Yup, but there's no real protection forbidding anyone from reflashing it with anything. So I think it would be pretty pointless.

 

Any of you guys near Paris? I'll be out there next week.

Neither SCPCD nor I are, unfortunately, but maybe someone else from Jagware will be

 

Since all original games had to use Atari's eeprom code, would it be possible to write a tool that scans a rom, finds the eeprom code (if it's always the same source it should compile to the same binary) and replaces it with a compatible one for the new chip?

Yes, it should be possible. Thanks. I'll look into that.

 

Or just make the general commercial release use the 128b eeprom, and have the 2k one available for developers doing bulk releases.

That's another option in case the solution above doesn't work for some reason.

I've checked the EEPROMs' documentation, and it appears that the 2 kilobytes ones are not directly compatible with the 128 bytes ones, after all

 

The problem is that I thought all of them had the same number of address bits, and that higher bits were just ignored for smaller devices. But it's not the case : the number of address bits to send depends on the size of the EEPROM. It's easy to fix in new programs, but it means that older games won't work with larger EEPROMs.

Tursi : the Flash chip we're using doesn't include a serial number or any other unique identifier (we couldn't use the Atmel chip you used in the Skunkboard, because it is no longer manufactured).

 

Starcat : yes, the EEPROM chip is the standard 128-byte one. But compatible chips with the same pinout and sizes up to 2 kilobytes exist, and they're not very expensive. That means we could offer a version with more memory, if there is enough interest ; or maybe we could only manufacture this version, if the standard Atari EEPROM code is compatible with larger devices (I don't know what happens in this case, we'll have to test it).

 

Larger (up to 128 kilobytes) EEPROM chips also exist, but they're not directly compatible, so it's not something we will look into unless there is considerable demand.

Also another thought, if you could find a way to get manuals and boxes printed, Jagware could become the new one-stop source to help developers create cart releases of their games.

Maybe Matmook and Reboot can offer some advice there ?

 

General

What is it ?
It is a 4 megabytes reprogrammable Jaguar cartridge, also known as a "flash cart".

What is it used for ?
The main use is allowing homebrew developers to release cartridge versions of their games. It can also be useful to people who don't have an Alpine Board/Atari Flash Cart/Skunkboard, to run cartridge-based games or betas.

What's the point, since blank cartridge PCBs already exist ? / If this is meant for building cartridges, why make it programmable more than once ?
The whole point is price and availability. The standard blank PCBs need special EPROMs chips that are expensive and hard to find, whereas this new cartridge uses modern parts that are cheap and readily available. Since Flash memory chips (which can be rewritten many times) are now cheaper than EPROMs, we thought we might as well make it reprogrammable.

Are cart shells included ?
It will depend on what people want ; we have a way to get them for a reasonable price.

What is the current status of the project ?
Hardware has been finalized and shown to work. Software is being worked on, and prices are being negotiated with suppliers.

When will it be available ?
When it's done -- no hard schedule, sorry

Does this mean the JagCF project has been cancelled ?
Not at all. These are separate projects with different goals. The JagCF is still being developed.


Pricing and ordering

How much does it cost ?
We don't know for sure yet, since it will depend on the sales volume (electronic parts can be much cheaper when bought in bulk), and we have yet to get a quote on the assembly (soldering and shipping costs. For information, for 10 boards, the PCB and parts alone add up to less than 15 € (approx $19). A cart shell adds a few euros.

How many units will you manufacture ? Do I need to preorder right now ?
No need to hurry -- we'll take preorders once we know the final prices. There won't be a limit on the number of carts either ; we'll manufacture based on the number of orders.

Will you ship worldwide ? Will you accept PayPal ?
Yes to both.

Can I get a discount if I buy several carts at once ?
Unfortunately, no. Our profit margin will be very low, so we can't afford to offer discounts.


Hardware and support software

How is it programmed ?
By plugging it into the Jaguar, connecting a BJL cable to the second controller port, and running a flashing program on a PC.

Will I need a BJL-modded Jaguar, a JagCD, or something else for this to work ?
No. The cart will include the necessary code for communicating with the PC (like the Skunkboard does), so you won't need anything apart from the BJL cable.

My PC doesn't have a parallel port to plug the BJL cable into. Why didn't you include a USB connector on the cart ?
Because USB is complicated to support, and would have made the price significantly higher ; since one of the project's goals was to make the cheapest design possible for large releases, we decided not to include it. At this time, the cart requires a parallel port, either built-in or on a PCI/PCIe/PCMCIA/PC Card/ExpressCard. We're currently working on adding support for USB-based parallel port adapters, but it is too early to confirm if it will work.

What operating systems are going to be supported ?
Windows (from 98 to 7) and Linux.

What about Macintoshes ?
If the support for USB parallel ports works (as Macs don't have a built-in parallel port), and if we can find someone to port and maintain the code, it may be possible.


Usage

Will betas / commercial games work on this device ?
First, an important note : commercial games are not officially supported, and respecting copyright and other applicable laws is the user's responsibility. We don't condone or accept any liability for any illegal usage of this device.
That said, technically, the cart has a lot in common with the Skunkboard, meaning that the expected compatibility is about the same : most games will probably work fine.

Can I use it to play BattleSphere / BattleSphere Gold ?
See above. (oh, and by the way : it has not been tested, but we have reasons to believe it will not work).

Can I use it to run BJL games ? To create a cartridge version of a BJL game ?
Yes, both uses will be supported.

Can I use it to run CD games ?
In general, no.

Do game saves work ?
Yes.


For developers

Is any unauthorized software list / unique identifier / copy-protection hardware... included ?
No, as these features would have made the cost higher (and we don't think they're very useful or effective, anyways). If you need them, we suggest using a Skunkboard or manufacturing your own carts.

I don't want my games to run on this device.
No problem. Contact us, and we'll give you technical information on how to detect the cart and block it.

Can it be write-protected once it has been programmed ?
Yes. The included communication code can be removed after use, and there is a solder pad on the PCB which prevents any writes to the flash memory if it's enabled. Keep in mind that a motivated used could reverse both of these operations, though.

In what ways is it different from a "real" cartridge ?
The main difference is that the bus is only 16-bit wide instead of 32, and that the read accesses are 5 cycles instead of 10 -- the same as the Skunkboard. The EEPROM for saves works just like the one in commercial cartridges. The header (from $800000 to $801FFF) is not available, as it is used for the PC communication code ; the MEMCON setup value is also different to account for the different bus width and read cycle length.

Is there a way to program a large number of those boards quickly ?
Not really. Putting the contents to be programmed on a CD and using the JagCD could be a solution, but it remains to be seen if it's actually faster, not to mention the JagCD's flaky reliability.

Happy birthday Fredifredo !

 

External links :

Freescale 68K series page
Freescale (formerly Motorola) is the manufacturer of the 68000 processor in the Jaguar. You'll find the official technical documentation on this page.

Matthias Domin's Jaguar page
Very complete webpage with extensive information about the hardware aspects of the Jaguar. Includes the Jaguar hardware schematic, cartridge schematics, and information about BJL and other hardware modifications, the JagLink and compatible devices, analog controllers, light guns, mice, rotary controllers, CD encryption, cartridge EEPROMs, and more.

Jag-UDG
Dumps of various system ROMs and special cartridges (boot ROM, JagCD ROM, Stubulator, Flash cartridge and Memory Track), and information about making Jaguar CDs.

Sinister Developments Jaguar Development Resources
Sources of Sinister's MOD files player, and of the game Painter.

Bastian Schick's homepage
Home of the BJL development kit. Includes the BJL ROM image, uploader programs for DOS, Linux and the Atari ST/TT/Falcon, and various demos with sources.

Hill Software (local mirror)
You can find the original Jaguar SDK here, as well as ready-made development environment for Windows, Linux and MacOS X. There is also a CD version of the BJL ROM and a GUI frontend for the Skunkboard tools.

The Removers
Development environment and support libraries to create Jaguar programs easily in C, with examples.

Swap d0's development tools
Jaguar development suite for BeOS, with sources : BJL loader, assembler, debugger and disassembler. There's also an image compression routine.

ray's 16/32 bits Atari page
CRY image viewer for the ST (look in the 'Miscellaneous' part). There is also a lot of code which is not Jaguar-specific but nonetheless very interesting (data packing, wavelet image compression, 3D algorithms, etc.).

Reboot projects
Universal Loading System (convert any BJL program into a self-bootable CD in just a few minutes), CD encryption with the Skunkboard, Atari ST version of the BJL uploader patched to work correctly with large files, Jagtopia (CD-based encryption bypass).

LinkoVitch Atari Jaguar's page
Detailed guide (with photos) on how to install the BJL ROM into your Jaguar. There's also a Jaguar CD repair guide.

How to do the BJL Mod
Another BJL modding guide.

Atari Museum - Jaguar section
Cartridges and CDs encryption tools, cartridge mechanical drawings, sources of the CD BIOS and VLM, information on unreleased projects (JagModem, MPEG decoding board, Atari 2600 emulator, Jaguar 2, Panther).

The Jaguar Underground Documentation
The first independent attempt at documenting the Jaguar. Pretty much obsolete now that the official docs are available, but you never know...

The Jaguar Server home page
As the title says, this is the home page for the old Jaguar Server computer-to-Jaguar link. It's been superseded by BJL for a long while, and the link is provided for historical purposes.

Else Engineering's JagLink II
Information about the JagLink II, and how to program for it.

No Fragments 9: Jaguar Freeware
Random public Atari Jaguar files, some are development-related. The whole CD is also available as an ISO image.

Project Tempest
A pretty fast Jaguar emulator, but not very accurate. It is no longer developed. Note : if something doesn't run with Project Tempest 0.95, try the 0.5 version from this page instead : it works better in some cases.

Virtual Jaguar
(Windows binaries)

A more accurate but much slower Jaguar emulator. Still developed, but not updated often.

Jagulator
Another emulator ; it was considered abandoned since 2001, but a new version has been released by its author in June 2011.

Skunkboard home page
Home page for the Skunkboard cartridge, where you can find the latest BIOS and software, as well as a support forum.

Robert Demming's Atari page
Jaguar CD Creator (program to make creating Jaguar CDs easier), information on how to convert a standard JagCD into a developer JagCD, and an illustrated guide for installing a switch to support 5 different boot ROMs.

JagMod
Jaguar Cinepak Tools for Windows (a GUI program to create Cinepak video CDs).

SubQMod's Console and Emulator Development
Home of SMAC and SLN (open-source replacements for ALN and MAC).

Patched version of SLN by DrTypo
Fixes some bugs in the original version of SLN.

The cartridge boot process
Info and disassembly of the cartridge boot code.

JiFFI
Tool to convert Jaguar programs from and to different formats (Jaguar Server, BJL, ROM, CD).

WinFLASH
Windows tool for uploading software to the official Atari Flash carts.

Templates for manuals, boxes and overlays
For those who want to make games that fit on the shelf next to the official ones

Replacing the Jaguar cartridge port by OMF
For people who break their cartridge port like Zerosquare

The Favard Jaguar development kit
An early homebrew development kit that was made by the Favard brothers.

RMAC / RLN
Reboot's open-source replacements for MAC and ALN.

JRob's SPU
A sound library that supports CD audio mixing.

U-235
LinkoVitch's sound engine, graphics converter and RISC disassembler.

Fujiology - Jaguar section
An archive of Atari-related files collected by Lotek Style of TSCC.
Lots of stuff, but mostly mirrors of what's available elsewhere.

This topic is a repository for all files, tools and links that are useful for Jaguar development. Click on the titles to download the files.
If you think something is missing, find a broken link, or have a suggestion to improve it, don't hesitate to post.

(work in progress, unsorted as of now)

Developer documentation (contributed by Starcat and Jon Matthieson)
These are scans of the paper documentation which was included in the Jaguar's SDK. They are believed to be the most up-to-date version available.
Beware : the archive also includes the Techref v8 file made available by John Mathieson in 2001 ; while it is more convenient to use, it appears to be an older version.

JAGUAR.INC
JAGUAR.INC is the include file which contains hardware registers and constants definitions. You'll need it to program in assembler or C.
This version has a changelog dated 05/16/1995 and is believed to be the latest one.

JagView (contributed by dox)
JagView is an utility to find and display uncompressed Jaguar pictures embedded in a ROM file (or as separate files). 8-bit, CRY and RGB formats are supported.
Beware : it is known to display slightly wrong colors in some circumstances.

Lo_inp
An updated BJL uploader which works under Windows 2000/XP, as well as Windows 9x and Linux. Sources included.

Jaguar Image Converter
A modern and more flexible replacement for TGA2CRY. Sources included.

bmp_cry, 8bit_to_bmp , view_jag
Quick-and-dirty programs to view and convert pictures to and from Jaguar formats. Sources included.

Virtual Jaguar 1.0.7 with BIN files support
Virtual Jaguar 1.0.7, patched to allow the loading of straight BIN files, and compiled for Windows.

Orion's GPU/DSP debugger
What it says in the title Sources included.

The Removers Library's Q & A
Question and answers about the Removers' C library.

Mindebug
The core of a Jaguar remote debugger using BJL. Can also be used as a basis for reliable bidirectionnal BJL communications. Sources included.

Encrypting CDs using the BJL cable
How to encrypt CDs if you don't have any JagLink or serial cable.

Cartridge dumping tool
Allows you to dump Jaguar cartridges, including flash carts. Sources included.

Workaround for the UART bug
How to use the network without crashes. Sources included.

Jagpads, teamtaps, rotaries and other controllers
Single topic about the different type of controllers and the way to support them.

Jagfiles (contributed by Curt Vendel)
Lots of source code from games, mechanical drawings, various Atari documentation, etc.

Atari Showroom (Jaguar section)
A local mirror of Glenn Bruner's former site. Lots of technical information about Jaguar hardware, both common and rare. Includes schematics, Tom & Jerry netlists, Alpine-related documents, etc.
Thanks to Glenn Bruner for providing the files!

JagDev
A mirror of CTS' former site. A few dev tools there, and some 3D stuff.
Some files are unfortunately missing.

Universal cartridge header (contributed by Glenn Bruner)
The cartridge header that can be added in front of any ROM code to allow it to run on non-modded Jaguars.

MPEG cartridge documents (contributed by Glenn Bruner)
Technical documents related to the MPEG 1 decoding cartridge that Atari planned (but never released).

Adding a rotary on a standard Jagpad

Cartridges mechanical drawings / dimensions

Fastboot header for carts (contributed by Tursi)
A special header for cartridges that speeds up the boot process.

The Jaguar Server home page
A mirror of Roine Steinberg's Jaguar Server page. (A few images are missing, unfortunately)

Flare II Jaguar technical reference manual (pre-Atari, 1992)
For archeology buffs, the oldest version of the docs.

Don't bother GT, I dealt with it (see the original post)

 

My reply :

 

We would need to see what the Flash version looks like, of course, but it's very probable it can be ported to the Jaguar.

You can tell him to read this topic (in French) for more info.

 

"Jagtopia is a system for booting CDs. It will allow you to boot both unencrypted & encrypted Jaguar CDs.

 

There are two versions, one is CD-based & the other is a binary. The CD version is an encrypted disc that will boot, allow you to swap the disc for another, then boot it. The binary can be run from your skunk or BJL Jaguar & boots either type of CD.

 

Check the site http://reboot.atari.org to learn more & grab the download that suit you best." (sh3-rg)

The German gaming website neXGam just published a pretty in-depth and well-illustrated interview of the Reboot gang. The interview has been published in both German and English.

 

Here it is.

Great and informative post, Tyrant

 

You see, now this kind of thing is EXACTLY why Atari needed another 6 months of testing on the Jaguar. For the sake of A SINGLE DIODE! they made the C1-3 bits be all locked into the pause button (push pause and C1, C2 and C3 all go low too).

The Jaguar needed more testing for sure, but I'm willing to bet the reason why they removed that diode was to save a few cents on each controller

 

I believe Starcats point-and-click will have support for bus (Atari) mice, when it comes out. Also there is the Balloons light gun demo, but guns read differently again.

Matthias Domin's Impulse (which should be released soon) is going to support mice and rotaries controllers, too.

 

In this they are identical to how Atari mice work (although I'm not sure how bus mice appear to the system, there might be a processor on the keyboard to help with them).

Yes, on the ST(E)/TT/Falcon, the keyboard processor does count the pulses for you ; you can simply ask it how much the mouse has moved.

 

One question though: Does BSG support the same rotary controllers as those you build or are they different? I'd assume that the wiring and mode of operation is totally different.

Yes, they're totally different. The controllers supported in BSG are analog joysticks, and only work on early Jaguars that included the ADC chip. The rotary controllers supported by Tempest 2000 are, well, rotary things which you can rotate endlessly in both directions, and work on all Jaguars.

 

P.S. Mods, there is another thread on the rotary in this forum. Maybe we should merge both threads into a bigger one that talks about all kinds of inputs on the Jaguar?

Done

I've also merged Fadest's topic about rotary controllers, and an old topic by GT Turbo about detecting teamtaps.

OK, since Tyr of the Arcana asked me about it, I think it's better for me to release the info I have rather than wait until it is finished (which may never happen, since I seem to be involved in too many projects )

 

First, some basic facts about interlacing (with a few simplifications to make it easier to understand) :

 

- a standard TV picture is interlaced. That means that the lines are not refreshed in sequence (0, 1, 2, 3...), but alternatively : first the even ones (0, 2, 4...), then the odd ones (1, 3, 5...), then the even ones again, etc. A set of lines, either odd or even, is called a field. A complete picture, made from two consecutive fields, is called a frame. Consequently there are 50 (60 in NTSC) fields displayed per second, but only 25 (30 in NTSC) frames.

 

- the Jaguar, like almost every console before it, outputs non-interlaced video by default, since it's easier to generate and generates less flicker for sharp graphics. It means that instead of alternating between and even lines, it only outputs fields containing even (or odd) lines. In this case, each frame is made of a single field. So you get twice as many frames per second (50 or 60), at the expense of half the vertical resolution (since you only use every other line).

 

- unfortunately, there's no definitive agreement on how the lines should be numbered ; depending on the book/website, the convention used isn't always the same. In particular, the lines you call "even" may be called "odd" (and vice-versa) by someone else. To avoid confusion, instead of using those terms, I'll call the field which contains the first (from top to bottom) line of the picture top field, and the other bottom field.

 

Now, the code. This stuff is old, and I'd need to delve into it again to understand exactly how it works. I'll try to post an example program when I have time.

 

First you need to enable interlacing by rewriting some video registers (the ones the Atari documentation tells you not to touch ) :

    move.w      CONFIG, d0
    andi.w      #16, d0
    bne.s       Init60HzI
                                     
    Init50HzI:
    move.w        #0, HC   
    move.w        #1, VC    
    move.w      #624, VP    
    move.w      #614, VEB  
    move.w      #619, VS    
    move.w        #4, VEE  
    move.w       #40, VBE  
    move.w      #614, VBB  
    move.w      #850, HP   
    move.w      #1749, HS   
    move.w      #787, HEQ   
    move.w      #600, HVS  
    move.w      #1709, HBB
    move.w      #153, HBE   
    bra.s       Suite

    Init60HzI:
    move.w        #0, HC   
    move.w        #1, VC   
    move.w      #524, VP  
    move.w      #512, VEB   
    move.w      #518, VS   
    move.w        #5, VEE   
    move.w       #30, VBE  
    move.w      #512, VBB  
    move.w      #844, HP    
    move.w      #1743, HS   
    move.w      #780, HEQ   
    move.w      #595, HVS   
    move.w      #1697, HBB  
    move.w      #118, HBE   

    Suite:
    stop        #$2700

This code should really be rewritten to accept different resolutions, but it should be enough to start testing.

 

From now on, you can test whether the current field is the top one or the bottom one by testing bit 11 of the VC register :

- if it's clear : top field

- if it's set : bottom field

 

If you use the 68K VBL interrupt, you also need to dynamically alter the value of the VI register, otherwise the interrupt won't trigger :

- for top field : VI must have bit 0 cleared (even value)

- for bottom field : VI must have bit 0 set (odd value)

 

Remember that when the VBL interrupt triggers, the next field hasn't begun yet. So you have to set VI correctly for the next field, not the current one.

Which means that at the start of your VBL interrupt, you should set VI to an even value if bit 11 of VC is set, set it to a odd value otherwise.

 

I'll try to add additional information when I find time, and probably a test program. Anyways, feel free to ask questions in the meantime !

Mr Zerosquare sir, I think I love you! Thanks!

Hum, I... like you too

 

The 74HC245 fits the bill.

Only 6 of it's 8 lines are used, and the output enable pins are wired always on, which as I understand it, means that the driver will either drive the lines high or drive them low.

Correct.

 

What is confusing me is the arrangement of the diodes and pull up resistors on the input side of the LS244. My best guess is that the pull up resistor keeps the line high unless the Jag is driving the line low and the corresponding button is pressed, but I'm not entirely sure I understand how.

Correct. It's called wired-AND diode logic.

 

Also I think there's an error on Steven Moss' diagram: pins 14 and 6 seem to be the wrong way round.

Yes, there's an error in the PDF : pin 6 and 14 of the 74HC244 have been swapped.

 

You can use the description in the official docs and the pad schematic from the Jaguar FAQ if you prefer, as they're easier to read :

Q: What's the wiring schematic for the Jaguar controller?

A: Uwe Roeger (uwer@aragon.bb.bawue.de) reverse-engineered the Jaguar
   controller port and dissected a Jaguar controller to provide the
   following circuit diagram:

   Padport 4  Padport 3  Padport 2  Padport 1
   (yellow)   (orange)   (red)      (brown)               74HC244
     |          |          |          |                   ______
     |          |          |          |         R1 4k7   |      |
     |          |          |          |          |       |      |  Padport 6
   Pause -------|----------|----------|----------+----- 2| -|)- |18- (blue)
     |          |          |          |                  |      |
     |      +---|------+---|------+---|------+  R2 4k7   |      |
     |      |   |      |   |      |   |      |   |       |      |  Padport 10
    "A"--|<-+  "B"--|<-+  "C"--|<-+  Opt -|<-+---+----- 4| -|)- |16- (black)
     |          |          |          |                  |      |
     |      +---|------+---|------+---|------+  R3 4k7   |      |
     |      |   |      |   |      |   |      |   |       |      |  Padport 11
   Right-|<-+  "1"--|<-+  "2"--|<-+  "3"--|<-+---+----- 6| -|)- |14- (grey)
     |          |          |          |                  |      |
     |      +---|------+---|------+---|------+  R4 4k7   |      |
     |      |   |      |   |      |   |      |   |       |      |  Padport 12
   Left -|<-+  "4"--|<-+  "5"--|<-+  "6"--|<-+---+----- 8| -|)- |12- (l.blue)
     |          |          |          |                  |      |
     |      +---|------+---|------+---|------+  R5 4k7   |      |
     |      |   |      |   |      |   |      |   |       |      |  Padport 13
   Down -|<-+  "7"--|<-+  "8"--|<-+  "9"--|<-+---+-----11| -|)- |9-- (pink)
     |          |          |          |                  |      |
     |      +---|------+---|------+---|------+  R6 4k7   |      |
     |      |   |      |   |      |   |      |   |       |      |  Padport 14
    Up --|<-+  "*"--|<-+  "0"--|<-+  "#"--|<-+---+-----13| -|)- |7-- (white)
                                                         |______|

              Padport 9: Ground (violet) -- Pin 1,10,15,17,19 on 74HC244
              Padport 7: +5 VDC (green)  -- Pin 20 on 74HC244

   SYMBOL KEY
   ==========
     --|<--   1N4148 Diode
       +      Wire connexion
     Rx 4k7   Standard resistor, 4700 Ohms, .25 Watts (all resistors are
                pull-ups; i.e. tied to +5VDC on one end)

   Padport numbers correspond to those on a standard 15-pin SUB-D plug.  The
   colors of the wires may be different in other versions of the controller.

Happy birthday to both