PDA

View Full Version : Homebrew single board Altair with SD floppy emulator



xprt
September 29th, 2010, 11:49 AM
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.

Chuck(G)
September 29th, 2010, 01:56 PM
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?

xprt
September 29th, 2010, 02:31 PM
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.

glitch
September 29th, 2010, 02:50 PM
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.

xprt
September 29th, 2010, 03:44 PM
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.

Chuck(G)
September 29th, 2010, 03:51 PM
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!

xprt
September 29th, 2010, 05:17 PM
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.

pavery
September 29th, 2010, 06:11 PM
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

Chuck(G)
September 29th, 2010, 06:30 PM
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.

xprt
September 29th, 2010, 06:35 PM
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.

glitch
September 29th, 2010, 06:49 PM
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.

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.

Chuck(G)
September 29th, 2010, 10:13 PM
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.

xprt
October 1st, 2010, 05:48 PM
4MB?!

640KB ought to be enough for anybody.

xprt
October 7th, 2010, 11:31 AM
If you wanted to provide the extra status indicators, I suppose you could decode opcode fetches as well as the INTA signal.

I found this page:
http://resume.robert.weathergreen.com/projects/mpu-85.htm

He says he generated the interrupts enabled signal. I wonder how he did it.

rweather
April 11th, 2011, 05:49 PM
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.

xprt
April 27th, 2011, 10:47 AM
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.