I’m still here…

…I’ve just been busy working on some really cool paleotechnology projects. Dr. Rosen came across an article about a microprocessor course built around students creating their own 8086-based computer. He asked me what I thought about it — and my first thought was “Can I sign up, even though I’m not an undergrad?”

Since then, I’ve been working on coming up with a working computer design that EET students could have a chance of building in one ten-week term. (Drexel is on the quarter system.) Since nearly all modern PCs are based on x86 architecture, Dr. Rosen suggested that, like the course described in the article, we design the course around an 8086 computer. Here is the design. (Caveat lector: I haven’t completely built this one — let alone debugged the design. It almost certainly has multiple bugs. Consider it pre-alpha.)

Upon further reflection, Dr. Rosen pointed out that this design (rather complex, not to mention costing perhaps $250 in parts) was probably too ambitious for a one-term undergrad class. He asked what I thought we could do to simplify the design. I pared it down, removing the RS232 subsection and making a few other minor changes — but it became apparent to me that an 8088-based design would be significantly simpler and less expensive. Continuing this line of reasoning, I figured that a Z80-based design would be simpler still. (The Z80-based Timex-Sinclair 1000, after all, uses a total of only four ICs.)

Here is the Z80-based design. (Again, this has not yet been completely built, let alone debugged. Should we go with this design and build it, I will post complete plans here.)

Posted in Digital, DrACo/Z80, Drexel | Leave a comment

Nothing but ‘Net

OK; I’m going to have to turn in my Paleotechnologist Card — or at least cross out the “Paleo” part — but this is pretty cool. I’m on the Amtrak, connected to the ‘Net via Internet sharing on my HTC Mogul — connected via Bluetooth PAN. Cool, especially using this connection to access my desktop back in PHL via Remote Desktop.

It seems to me that devices like the Mogul are the first of a new class of device. With connectivity via cell, WiFi, and Bluetooth, in addition to USB etc, it can handle cell phone calls, the usual Internet functions (POP, SMTP, HTTP, SSH, FTP yada yada) — and can also act as a router/NAT proxy. Not bad for a pocket-size gizmo.

Now if they could only improve the battery life. I wonder if it’ll make it to FBG?

Edit: Nope. The battery gave up just past Washington. It was fun while it lasted, though.

Posted in Current Events, Digital, Digital Citizenship | Leave a comment

VSI gauge progress

The first CHComm-based instrument is starting to take shape. A Futaba servo connected to a PIC16F877a (yeah, I know — gross overkill — but it was handy) to make a VSI gauge. At this point, it works intermittently; it seems to only register changes of the hundreds’ place; I really need to get an LCD on it to help diagnose what’s going on.

On the bright side, it’s up to 9600 baud, from 2400, so that helps.

Getting the PIC to properly multitask while communicating with the serial port is an interesting proposition. Right now, the main loop provides constant position pulses to the servo while polling the serial port line every 500us or so, to see if a start bit has been received. I’m leaning towards a 2-MCU solution for each gauge, though — one to handle comms and one to run the servo. That way, the servo MCU would be guaranteed a very short data-update cycle, rather than allowing for a potential stoppage should something happen to the serial line. (Servos act strange when their position pulses are interrupted.)

Posted in Coding, Digital, PIC Microcontrollers | Leave a comment

CH Comm works!

Just finished testing CH Comm — it works, both with FS2004 and FSX! A whole interesting list of FS data can be exported to the RS232 port in standard format. This should make it fairly straightforward to create PIC-based instruments.

At this point, the next steps are:
* Try to get RS232 comms working reliably at a higher speed than 2400 baud — preferably 115200, even if this means a dedicated MCU to handle the comms (which it probably will.)
* Go through the CH Comm .ini file to pare down the output to what is needed (all this data takes an appreciable fraction of a second to export at the default 9600 baud — which would make for poorly-responding instruments.
* Choose one or two parameters for a PIC to read, and display them on a LCD or via a servo.

Posted in Coding, Digital, PIC Microcontrollers | Leave a comment