• Please review our updated Terms and Rules here

Homebrew single board Altair with SD floppy emulator

X

xprt

Experienced Member
Joined
Sep 28, 2010
Messages
159
Location
Silicon Valley
I thought some folks here might be interested in a hobby project I worked on and wrote up here:

http://mini-altair.tripod.com/

(Sorry for the ads.)

It's an 8085 single board computer intended to be compatible with the original Altair software.

It runs all the Altair BASICs: 4K, 8K, 12K Extended BASIC, Disk BASIC. It also runs Altair DOS and CP/M.

Instead of a ROM chip, I used a microcontroller to pre-load the RAM. The microcontroller can also do the functions of a front panel: examine and deposit to memory, jump to address and single step. I never added the lights and switches, however.

Something that may be unique is the SD card floppy emulator emulates the 88-DCDD floppy system, which allows it to run the Altair Disk BASICS and Altair DOS unmodified. It uses the FAT32 format so disk images can be transfered easily. It is basically just 3 chips: a microcontroller chip with a regulator and a buffer. This could easily be adapted to an S100 board.

Some may find it distasteful, but the board is a combination of some 1970s chips with modern flash programmable LSI chips. It is wirewrap construction with some fine pitch surface mount parts thrown in.

It was an interesting project. I found debugging the disk emulator to be quite challenging. Breakpoints don't work too well with multiple CPUs doing time-critical operations. I found myself disassembling the Disk BASIC code and running through it in my head to debug it.

Any questions, comments, criticisms are welcome.
 
It's not quite a MITS 8800, is it? You use an 8085 CPU, which implements the RIM and SIM instructions (as well as about 15 other instructions), which produce very different results on the 8080 chip used on the Altair. Not trying to pick nits too hard, just trying to be honest. :)

After I built my 8800, one of the first programs I wrote was one to enable and disable interrupts so a capacitor hooked to the front panel EI LED could be fed into an audio amplifier and produce primitive music.

How would I run that program on your board?
 
You've got me there. The 8085 is obviously not hardware compatible with the 8080.

The 8085 has no status output for IE or for STACK for that matter.

I've thought about trying to run the Fool on the Hill thing, but never got around to it. Since my clock speed is 3MHz instead of 2MHz I guess the pitch would be off.
 
Excellent project, though! I've been playing around with the 8085 quite a bit lately, largely because anything I write in Assembly with my Kaypro II can be (more or less) easily ported to the 8085 SBC.

Could you post more information on the floppy emulator? It would be interesting to move it over to a S-100 board.
 
The Version 3 page of the website has pictures, a screen shot, the schematic and the source code for the disk emulator.

For porting to an S100 board, I guess you would need to add the usual: a 5V regulator, some buffers for the data bus and some address decoding logic.
 
If you wanted to provide the extra status indicators, I suppose you could decode opcode fetches as well as the INTA signal.

What strikes me as being curious is that Vince Briel's microcontroller-based Altair mini-replica may actually be close to the real thing, software-wise.

Still ,you did a fine job and have earned ample bragging rights!
 
Yes, I guess that's possible to decode the status indicators with logic as you've described. My front panel micro-controller could do it in single stepping mode as well, but it would slow things down a lot.

In practice, I don't think the IE or STACK lines were used much, except for turning on LEDs.
 
Hi, on your website under Version 1 you state:
"The Z80 was not chosen because it is not 100% software compatible with the 8080A. The original Altair Basic won't run on the Z80."

I didn't realise that. Can you tell me more? Do you know which 8080A instructions have different results on a Z80?

Thanks
Philip
 
It's kind of interesting that the 8080A and 8086 both have status indicating when the stack is being addressed, but the 8085 doesn't (the 8008, of course, didn't put the stack in memory space). One could imagine that the stack status could be used to force addressing to RAM even when code is running out of ROM.
 
I believe the Z80 treats the parity bit differently from the 8080. The Z80 redefines the parity bit as an overflow bit for math operations.

Apparently for Altair 4K BASIC version 3.2 checks the parity bit with JPO (Jump Parity Odd) after a math operation, maybe in order to be clever and save a few instructions. This would cause a Z80 to hang.
 
Chuck(G) said:
It's kind of interesting that the 8080A and 8086 both have status indicating when the stack is being addressed, but the 8085 doesn't (the 8008, of course, didn't put the stack in memory space). One could imagine that the stack status could be used to force addressing to RAM even when code is running out of ROM.
Click to expand...

You could also use the stack indicator to keep the stack in its own 64K memory space. This would allow the stack to grow without worry as to overwriting program/data memory, or running into ROM, et c. It's interesting to consider how using this feature might affect buffer overflows, or "stack smashing," exploits in modern software.
 
In fact, the 8086 (and NEC V50) puts out a status that identifies the segment register being used. So, one could have 4MB of directly-addressable memory on an 8086 if one handled the segment register management. Sad that no hardware or application seemed to use that feature.
 
Funny you should ask... I had to go back to the schematics from 1981 to refresh my memory. Yes, as someone earlier had speculated, I used a flip-flop and decoded the EI (set) and DI (reset) instructions. sInta or reset can also reset the flipflop. I did this project under contract for the "new IMASI" back in 1980. I got the approval Mr. Fischer to publish details of the MPU-85, so the schematics may become public one day soon.

Actually, the main reason for generating the IE signal was for 8214 (PIC) compatibility. Unfortunately I never had the chance to test it.
 
You still have the schematic after 30 years! Fantastic.

I don't quite see the reason for the 8080's INTE signal in the first place, except to provide the visual indicator on the front panel. If interrupts are disabled, the INT input will be ignored anyway.

I guess it could prevent a transient interrupt from being latched if interrupts are disabled, which might present a compatibility issue if you didn't generate the INTE signal.
 
You must log in or register to reply here.
Back
Top