Monthly Archives: March 2012

Hi! Welcome to my little piece of the Net

Hello. My name is Rick Tewell and I am the Director of Engineering for Fujitsu Semiconductor America. My goal with this site is to write about all things “embedded engineering”…things like hardware design, software development, 2D & 3D graphics, GUI / HMI design, etc. I plan to also share things that I have found on the Net that I find interesting (and hope you do to) relative to all that stuff.

So, I often get asked by people – “How did you get involved with the type of engineering you do?” So, if you have a few minutes, go grab yourself and cup of coffee or tea and let me tell you a story. It is my first “real world” engineering project…and looking back on it, it was pretty interesting.

The date is sometime in 1984. The IBM PC was still fairly new and the XT had just arrived on the scene. For some reason, my geeky tech buddies and I found this computer called the Sanyo 550 in Byte magazine and went out and bought one. Probably because it was an inexpensive IBM PC “clone” and we didn’t have much money. It turned out that it was a “floppy disk only” machine. By that time, however, you could plug a hard disk controller and hard disk into the IBM PC/XT…in fact several companies were selling the controller and hard drive combos. So, we bought a “kit”. It was a whopping 10 Megabytes and was wicked expensive, but it was the absolutely coolest thing in the world. As an aside, the company making the hard drives was named “Rodime.”

Sanyo 550 – IBM PC Clone

Much to our dismay, we found out that you couldn’t plug a hard drive controller into the our brand new Sanyo 550! It just wasn’t possible. Why you ask? Because to our shock and horror…we discovered that there were no standard PC card slots in the machine – remember the old 8-bit ISA connector?

Original IBM PC insides

Original 8-bit PC Card Slot

Well…it turns out that Sanyo thought it might be nifty to not actually USE that connector in their PC clone, but rather use a dual row pin header instead. Most likely for cost reasons. Dual row pin headers are CHEAP.

Good ole’ dual row pin header

Now…we had to plug the hard disk controller below somehow into that dual row pin header. Here we are, a couple of 19 and 20 year old engineering students facing our first real world engineering challenge.

Western Digital Hard Disk Controller

The answer was obvious…we needed an adapter of some sort. Something that would plug into the dual row header and have a PC bus slot connector on the other side. Either that, or solder 64 wires from the dual row pin header connector to the card edge connector of the hard disk controller. Don’t think that we didn’t actually consider that…because we did.

We contacted a company that specialized in connectors and ordered what we needed as a “prototype”. Much to our surprise, the company flew from their location in Illinois to Nashville, Tennessee and drove out to our “office” with the prototypes. Well…they were surprised as well. A couple of kids basically in a garage. We were working in a “shop” connected to an office complex…so we, at least, had that. I could all but see the deflated looks on their faces when they realized that we weren’t some big company working on the next great thing for the PC world.

The connectors worked great (although they did sit in the Sanyo 550 kind of awkwardly). Our next great surprise came when we found out that the darn firmware on the Western Digital disk controller was pretty reliant on DMA and IRQs. Funny thing though, the Sanyo 550 didn’t have a DMA (Intel 8237) or IRQ (Intel 8259) controller. Go figure. That means that simply put, there was NO way, even though it was now electrically connected that the Sanyo 550 that it was going to work with that hard disk controller. If we could FIX this problem somehow, then that would be a GREAT market and the start of a great little company. Sell disk controllers and hard drives to the blossoming PC clone market! We would be millionaires within the year!!!! Then, reality set in.

You have to understand, that at that time, we had NO idea what a 8237 or 8259 actually was. All we knew was that the hard disk controller was electrically connected to the Sanyo 550 and nothing was happening. We saw the pretty little disk controller firmware message and then nothing…not even a blinking cursor. So, we called Sanyo and Western Digital. We finally got through to some folks at Sanyo who kindly sent us their schematics while the folks at Western Digital asked a lot of fresh questions about who the heck was calling them and why were we bothering them. After reviewing the Sanyo 5500 schematics and referencing the connector, we determined that there was a problem. A couple of key components were missing (yes…the DMA and IRQ controllers) from the Sanyo 550 – in fact the lines were labeled “no connects” on Sanyo’s dual row pin header disaster of a PC expansion slot thing. We determined this by cross referencing the FANTASTIC IBM PC/XT documentation that you were able to get at that time…complete with schematics and even FULL BIOS SOURCE CODE!!!! in “when times were simpler” 8088 assembler. It was a purple book (which I still own) and is still a whole lot of awesome geeky goodness.

The AWESOME PC Technical Reference Manual

So, now all we needed to do was to get the “source code” to the Western Digital Hard Drive Controller’s ROM BIOS. This code was programmed into an EPROM and installed on the hard disk controller board. So, now we needed some MORE things. We needed the source code from Western Digital. We needed some blank EPROMs, some tool to program them, and as it turned out an ultraviolet erase thing so we could erase and reprogram the EPROMs. Oh…we also needed a tool to pull the EPROM out of the board. I tried to do it with a pocket knife and the thing popped loose from the board and jumped deep into my finger…VERY painful. We had to order a new hard drive controller after that incident.

Western Digital final provided us the source code – a very nice guy who worked for Western Digital at the time named Jerry Little, accommodated us. We agreed to give Western Digital back the changes we made to their code in return for them giving it to us in the first place. That is when we found that we needed even MORE things, like Microsoft’s Macro Assembler. The source code was written in 8088 assembler. To our amazement, Microsoft’s Macro Assembler and Linker was actually provided from Sanyo with MS-DOS! Can you believe it? The Macro Assembler, Linker and even a Debugger (conveniently named Debug) came with the OS!

Sanyo 550 MS-DOS and included software

After a short time of work, we modified the Western Digital hard disk controller’s firmware to support polled operation (to get around the lack of IRQ support) and programmed I/O instead of DMA suppport. The hard drive controller started working! We could go into the firmware’s menu system and low level format the hard drive (required in those days) and build the bad block table! We were ECSTATIC! The only problem was that the version of MS-DOS from Sanyo had NO hard drive support at all. It had NO IDEA how to deal with a hard drive. Obviously, we were going to have to modify the operating system code to make this work. At this point, one might wonder “didn’t you just want to give up?” Amazingly enough, the thought never crossed our minds. We called Sanyo and asked them for the source code to MS-DOS. I guess enough years has now passed and the legal risk is gone…but Sanyo actually sent us the source code to their version of MS-DOS. Can you believe it?

In those days, MS-DOS was comprised of two primary kernel modules. MSDOS.SYS and IO.SYS. IO.SYS was the collection of device drivers that allowed MSDOS.SYS (the actual kernel) to talk to the outside world. In this case, the outside world was mostly communicated to via the BIOS built into the actual computer. IO.SYS would simply translate MSDOS requests into requests for the BIOS. So, the device driver that would support a hard drive simply wasn’t present inside of IO.SYS. We then thought about modifying the floppy disk driver to control the hard drive…that should be easy, right?

MS-DOS architecture

When we went to compile IO.SYS, much to our surprise a module called “sysinit” was missing. It just wasn’t there and you couldn’t build IO.SYS without it. We contacted Sanyo and apparently somebody there had come to their senses and they said “we can’t give you that.” To which I replied, “You gave us everything else!” The Sanyo engineer then simply said “we can’t and won’t send you sysinit…sorry” and he pretty much hung up. It was pretty bleak at that point. My partner in this caper suggested that we should just write a device driver and add it to CONFIG.SYS to handle the hard drive. It seemed at this point that this was the only way. We could read and write all day long to the hard drive, we just needed to teach MS-DOS how to do it. We had the floppy disk driver as a reference…how hard could it be? I found a great little book called “Writing MS-DOS Device Drivers” that had JUST been published.

Writing MS-DOS Device Drivers

With this book in hand and the sample device drivers out of IO.SYS from Sanyo, I proceeded to write my very first device driver. I got the device driver completed and working, but we came across another little problem. In order to use the hard drive, it had to be LOGICALLY formatted. In other words we had to write a file system to it so DOS could manage the files. Even though we had a hard drive device driver working, MS-DOS STILL couldn’t see the hard drive. I learned quickly about the File Allocation Table (FAT) file system that Microsoft was using, and I learned about clusters and directory entries and all sorts of things that it never occurred to me at the time I would need to know. We ended up having to actually write a hard disk FORMAT utility since clearly one didn’t come from Sanyo with their version of MS-DOS. I will NEVER forget the day that all of a sudden after ALL we had been through to make a hard drive work on a Sanyo 550, we ended up with a very simple “C:” on the screen. I then copied a file from the floppy to ‘C’ drive and MS-DOS responded with a very polite: “1 file(s) copied.”

I know this is going to sound NUTS…but it was an absolute RUSH. For me, that was my game winning touchdown or my series winning home run. It was amazing. At that moment in time, I knew that whether or not I got paid to do this stuff THIS is what I was going to do. Luckily, they pay people to do this kind of stuff…and since that day in 1984 I have done a LOT of stuff…

Deploying 3D Objects on Embedded Devices – source code

Here is the source code to Cube01 referenced in the article:

[sourcecode language="javascript"]

PImage img;

void setup() {
size(640, 480, P3D);
img = loadImage("cube.png");
noStroke();
}

void draw() {
background(0);
noFill();
translate(width / 2, height / 2, 360);
rotateX(map(mouseY, 0, height, -PI, PI));
rotateY(map(mouseX, 0, width, -PI, PI));
textureMode(NORMALIZED);
beginShape(TRIANGLES);
texture(img);
DrawVertices();
endShape();
}

void DrawVertices() {
// f 1/1 2/2 3/3
vertex(-10.000000, 0.000000, 10.000000, 0.9988, 0.3344); // 1/1
vertex(-10.000000, 0.000000, -10.000000, 0.9988, 0.6648); // 2/2
vertex( 10.000000, 0.000000, -10.000000, 0.6681, 0.6648); // 3/3
// f 3/3 4/4 1/1
vertex(10.000000, 0.000000, -10.000000, 0.6681, 0.6648); // 3/3
vertex(10.000000, 0.000000, 10.000000, 0.6681, 0.3344); // 4/4
vertex(-10.000000, 0.000000, 10.000000, 0.9988, 0.3344); // 1/1
// f 5/5 6/6 7/7
vertex(-10.000000, 20.000000, 10.000000, 0.3359, 0.6668); // 5/5
vertex(10.000000, 20.000000, 10.000000, 0.6663, 0.6668); // 6/6
vertex(10.000000, 20.000000, -10.000000, 0.6663, 0.9992); // 7/7
// f 7/7 8/8 5/5
vertex(10.000000, 20.000000, -10.000000, 0.6663, 0.9992); // 7/7
vertex(-10.000000, 20.000000, -10.000000, 0.3359, 0.9992); // 8/8
vertex(-10.000000, 20.000000, 10.000000, 0.3359, 0.6668); // 5/5
// f 1/9 4/10 6/11
vertex(-10.000000, 0.000000, 10.000000, 0.0007, 0.6666); // 1/9
vertex(10.000000, 0.000000, 10.000000, 0.3347, 0.6666); // 4/10
vertex(10.000000, 20.000000, 10.000000, 0.3347, 0.9992); // 6/11
// f 6/11 5/12 1/9
vertex(10.000000, 20.000000, 10.000000, 0.3347, 0.9992); // 6/11
vertex(-10.000000, 20.000000, 10.000000, 0.0007, 0.9992); // 5/12
vertex(-10.000000, 0.000000, 10.000000, 0.0007, 0.6666); // 1/9
// f 4/13 3/14 7/15
vertex(10.000000, 0.000000, 10.000000, -0.0000, 0.3340); // 4/13
vertex(10.000000, 0.000000, -10.000000, 0.3344, 0.3340); // 3/14
vertex(10.000000, 20.000000, -10.000000, 0.3344, 0.6658); // 7/15
// f 7/15 6/16 4/13
vertex(10.000000, 20.000000, -10.000000, 0.3344, 0.6658); // 7/15
vertex(10.000000, 20.000000, 10.000000, -0.0000, 0.6658); // 6/16
vertex(10.000000, 0.000000, 10.000000, -0.0000, 0.3340); // 4/13
// f 3/17 2/18 8/19
vertex(10.000000, 0.000000, -10.000000, 0.3370, 0.3347); // 3/17
vertex(-10.000000, 0.000000, -10.000000, 0.6652, 0.3347); // 2/18
vertex(-10.000000, 20.000000, -10.000000, 0.6652, 0.6662); // 8/19
// f 8/19 7/20 3/17
vertex(-10.000000, 20.000000, -10.000000, 0.6652, 0.6662); // 8/19
vertex(10.000000, 20.000000, -10.000000, 0.3370, 0.6662); // 7/20
vertex(10.000000, 0.000000, -10.000000, 0.3370, 0.3347); // 3/17
// f 2/21 1/22 5/23
vertex(-10.000000, 0.000000, -10.000000, 0.6681, 0.6679); // 2/21
vertex(-10.000000, 0.000000, 10.000000, 0.9996, 0.6679); // 1/22
vertex(-10.000000, 20.000000, 10.000000, 0.9996, 0.9980); // 5/23
// f 5/23 8/24 2/21
vertex(-10.000000, 20.000000, 10.000000, 0.9996, 0.9980); // 5/23
vertex(-10.000000, 20.000000, -10.000000, 0.6681, 0.9980); // 8/24
vertex(-10.000000, 0.000000, -10.000000, 0.6681, 0.6679); // 2/21
}

[/sourcecode]