Embedded Files
7/25/20
We cleaned the exterior and interior of the chassis. Other than being a little dirty and dusty the system is in very good condition.
Since system may not have been powered on for years or even decades, the first project is to reform the capacitors in the power supply. If you don't reform the capacitors before powering on the system you will very likely destroy the capacitors. We connected a laboratory power supply to each of the filter capacitors in the power supply and slowly brought the lab supply voltage up to the system's operating voltage while monitoring the current. There is an additional +8VDC filter cap installed that is a monstrous 25,000 uF @ 30VDC, in addition to the 4x 3,300 uF 16VDC caps on the filter board.
The filter caps for the +10V supply draws about 12mA when we increase the lab supply voltage by 1V, and the current drops to 4mA after a few minutes. Once the current drops to a minimum we can increase the lab supply voltage again. It finally settled at 14mA of leakage at 8.0VDC. Some of the leakage is through the D1 rectifier bridge, some through the 4x 3,300 uF caps, some through the 25,000 uF cap, and some through the front panel. Good enough to move onto the other voltages.
The second +8VDC supply has just 2x 3,300 uF @ 15VDC caps. It leaks 25mA at 2.0VDC at the start. As we increased the voltage the lab supply went into current limit mode at 100mA and would not go above 5VDC. We increased the current limit and the data LEDs on the front panel lit when the lab supply voltage got above 5VDC. With the lab supply at 8.0VDC the current is 500mA.
The +16VDC settled at 1mA leakage, and the -16VDC also settled at 1mA leakage.
Time to power it on and see if the transformers and diodes are OK. We connected the system to a Variac and slowly increased the AC voltage. Nothing smoked, and the fans started running when we got to about 65VAC. We continued increasing the AC voltage and stopped at 120VAC. Still no smoke.
The backplane voltages should be about +8VDC, and +/-16VDC. On this system the +8VDC was actually 13.9VDC, the +18VDC was +19.1VDC, and the -16VDC was -18.4VDC. The +8VDC is quite high, but will be regulated down to 5V on the boards. The larger than normal voltage drop through the on-board regulator will make the regulators run very hot. We put a 25Ohm resistor across the +8VDC output and the actual voltage dropped to 13.09VDC with a 0.5A load. The +8 supply can make 8A, so we need a bigger load. Connecting 3x 25Ohm resistors results in 12.36VDC.
With the CPU, RAM, SIO, and Diskette controller installed the +8VDC is +11.8VDC. Still quite high. It measured 8.24VDC in Altair #1. The other voltages were +16.6VDC and -17VDC.
When we were fiddling with the front panel we noticed that toggle switch for bit 12 doesn't toggle. We will try to fix it with some contact cleaner, and maybe replace it with one of the spares that came with the first Altair.
The CPU and static RAM board work OK in Altair #1. In Altair #2 the address LEDs are counting and the CPU won't stop. Looks like we need to fix the front panel and replace switch #12.
The boot ROM in the floppy controller starts at 0xF400. I connected the drive to the controller with a short cable, changed the drive select from #1 to #0, and started the CPU. The drive select LED went on, so the CPU is running and some of the floppy controller is working.
8/8/20
We looked at the +8VDC unregulated power supply today and see if we could determine why the output voltage is so high. There are actually two +8VDC power supplies; one from Transformer #1 that supplies 8A to the backplane, and a second from one winding of T2 that supplies 1.2A for the front panel. The schematic says that T1 should supply 7.5VAC RMS, and T2 should supply 8VAC RMS. T1 is actually supplying 10.7VAC, and T2 is actually supplying 14.1VAC RMS. There is only one set of input taps on the transformers, so the only thing that we can do is use a Variac to lower the input AC voltage, or run it as it is and let the onboard voltage regulators run hot.
When the system is powered on the processor is in a random state. The normal procedure is to hold the Stop/Run switch in the Stop position and momentarily press the Reset switch. The Stop/Run switch has no effect on the LEDs. Holding Stop and pressing Reset results in the MEMR, MI, and WO LEDs on, the data LEDs on, and the Address LEDs counting. Pressing RUN turns the STACK LED on, and then pressing STOP turns the STACK LED off. None of the other switches on the front panel have any effect.
You can see the front panel bad behavior here.
The RESET* signal on the backplane goes low when the RESET switch is pressed, so that is OK.
The RUN signal on pin 71 of the backplane is low (inactive) at power on, and stays low after Pressing RESET & STOP. Pressing RUN causes the RUN signal go high, and then pressing STOP makes the RUN signal go low, so that is also OK.
The PRDY signal is always high. It looks like it should only go high when the RUN/STOP flip-flop is in the RUN state, or you do a Single Step, Examine, or Deposit. We looked at the output of the SN7430 IC O. The output is high, which indicates that one of the inputs is low (active). I can set the state of the RUN* signal on pin 12 high by pressing the STOP switch. Pin 11, SS* is high. Pin 5, EXM NNX* is high. Pin 6, EXM* is low (active). The EXM* signal should be high except when the EXAMINE switch is pressed. IC V pin 10 output is low, and pin 11 input is high so that IC is probably OK. The EXM signals on IC U pin 6 output is high (active), and pin 4 input is low, and pin 5 input is kind of low, about 1.5V. The kind of low signal needs to be investigated. The SN7473 (the schematic says SN74L73) IC J pin 8 output is 1.5V, and pin 9 is low. Pin 8 should be at +5V if pin 9 is low, so this IC is likely bad.
We replaced IC J with a NOS part, and while we were soldering we replaced the toggle switch for address bit-12 with a spare that came with Altair #1. Now the CPU will halt and run when the STOP or RUN switch is pressed.
EXAMINE looks like it is doing an EXAMINE NEXT, and it is not loading the address switched. DEPOSIT is doing something, but needs further investigation.
8/15/20
Time to find out why we can't EXAMINE or DEPOSIT.
The signal from the EXAMINE switch goes into the SN74123 Retrigerable Monostable Multivibrator IC L to get debounced, and then goes into SN7473 JK Flip-Flop IC J which is wired as a 2-bit counter. The signal on the SN7402 IC R pin 6 looked OK, so the switch and the debounce circuit is working OK.
We connected the 'scope to pins 12, 13, 9 & 8 on IC J so we can see if the 2-bit counter is going through the EXAMINE steps. After pressing the EXAMINE switch we can see the counter go through the four step sequence for an EXAMINE. These counter outputs control the Processor Ready (PRDY) signal on the backplane, and gate signals on the databus to make the processor chip perform a JMP instruction to the address contained in the switches.
We looked at outputs of IC U & T and IC A, B, C, D and E to see if the JMP instruction and switch addresses were getting onto the databus. First we see IC T pin 6 go low, then IC W pin 10 go low, then pins 4 & 6 of IC C and pins 4 & 2 of IC D go low. These are the bits for the JMP instruction. Then IC U pin 11 goes high which gates the lower 8 switches onto the databus, then IC U pin 8 goes high which gates the upper 8 switches onto the databus, then PRDY is driven low to stop the CPU. Those signals all looked OK. We noticed that IC W pin 2 was also active when the EXAMINE switch is pressed and was driving all of the data lines low when only the bits for the JMP instruction should have been driven low. This signal should only be active when EXAMINE NEXT is pressed. IC U pin 3 was active when EXAMINE is pressed. IC U pin 2 has signals on it when EXAMINE is pressed, but the low signal (EXM NXT) on IC U pin 1 should have prevented the signals on pin 2 from propagating to pin 3. We replaced IC U, the SN7400, with a new part, and now we can EXAMINE, EXAMINE NEXT. DEPOSIT, and DEPOSIT NEXT.
We were able to toggle in a little program and run it, and single-step the CPU. It looks like the front panel is fully functional.
We connected the Micropolis floppy diskette drive cable to the Micropolis Floppy Diskette Controller, inserted a 16-sector hard-sectored floppy diskette, set the address switches to 0xF400, pressed RESET, EXAMINE, and then RUN. This runs the floppy diskette bootloader stored on the diskette controller. The head loaded with a clunk and the drive select LED turned on. We could see activity on the front panel LEDs as it tried to boot from an empty diskette. We connected laptop running a terminal emulator to SIO port 1, but could not see anything on the terminal.
We toggled in a 2SIO echo program, but could not get anything to echo on the terminal emulator. We single-stepped the program and it looks like there is always a character in the receive buffer. We will need to do some debugging on the 2SIO board next Saturday.
We should also toggle in and run a RAM test program to make sure the RAM board is OK.
8/22/20
Last week we fixed the front panel and did some initial testing on the CPU and RAM. We even tried the floppy controller to see if it would try to boot. It tried, but the floppy diskette was blank so it didn't get far. Once we get the serial console port working we can download a program that will copy a diskette image from a laptop to the floppy drive.
We studied the schematics of the 2SIO board looking for how the RS-232 signals are wired to the rear DB-25 connectors on the back of the chassis. We connected a DB-9 to DB-25 cable from a laptop to the Altair, and looked to see where the transmit data from the PC showed up. The transmit and receive signals were reversed so we had to insert a null-modem between the Altair and the laptop to get the RS-232 signals in the right place.
We toggled in the 2SIO loopback program from Mike Douglas and ran it. It looks like it is behaving the same as last week where it thinks that there is always a character in the input buffer. Single-stepping the loopback program shows that all of the bits in the 6850 ACIA are on. This should not be true.
We used the 'scope to verify that the address configuration on the 2SIO is correct. Pin 3 on IC P goes low when an IN or OUT instruction is executed which drives pin 9 (CS2*) of the 6850 ACIA. Pin 10 on IC T goes high and low when the program is single stepped which drives pin 11 (RS) of the 6850 ACIA. Pin 12 of IC S goes low when an OUT instruction is executed, which drives the pin 13 (R/W) of the 6850 ACIA.
We can see pin 1 (1CLK) of IC V, the SN7473, go low when the I/O address matches and then pin 13 (1Q*) of IC V goes low. This puts the CPU in a Wait state for 500 ns. Then the PWAIT backplane signal goes high, gets inverted by IC U, and drives pin 2 (CLR) of IC V low, which clears the flip-flop and drives pin 13 (1Q*) of IC V high, which releases the PRDY signal on the backplane.
The signal from pin 8 of IC P is going low to enable the bus driver chip IC A. We looked at the signals on pins 11 & 12, and 13 & 14 of chip A, the SN74367 bus driver . It looks like the data signals from the 6850 ACIA chip are not being driven onto the backplane. The input signals to IC A, that are the data from the 6850 ACIA, are at 2V, so it is in an indeterminate state and the data read from the 6850 ACIA shows up as all ones.
We swapped the two 6850 ACIA ICs, but it didn't change the behavior of the data signals.
8/29/20
Last week we tested all of the logic that is used to decode the I/O address on the S-100 bus, and the logic that selects one of two 6850 ACIA on the 2-SIO board, and which register in the ACIA is the target of the I/O instruction. All of that seemed to be working OK.
We checked the transmit/receive clock frequency. It is running at 19200 KHz. When the ACIA divides this by 16 it will be configured for 1200 baud.
During a IN instruction that reads the Status Register in the ACIA it looks like the ACIA is not driving the local data bus that gets driven onto the S-100 bus. I think that it is unlikely that both of the ACIAs are defective, so we will look at the signals that cause the ACIA to do something.
ACIA Selection Signals
RegisterSelect (pin 11), connected to A0 on the backplane
ChipSelect0 (pin 8) , tied to +5V so it is always active
ChipSelect1 (pin 10), connect to A1 on the backplane, inverted for ACIA 1, not inverted for ACIA 2
ChipSelect2/ (pin 9), formed from a good match on address lines A7-A2 and either SINP or SOUT on the backplane
Read/Write (pin 13), connected to SOUT on the backplane, determines if we are reading or writing a register in the ACIA
Enable (pin 14), Enables the ACIA's I/O bus
RegisterSelect is going low when pin 3 of IC P goes low. This will select the Control/Status Registers.
ChipSelect0 is tied high to +5. We checked it, and it is OK.
ChipSelect1 is driven by pin 4 of IC Q. When pin 8 of IC O goes low, pin 4 of IC Q goes high, which is what we want.
ChipSelect2/ is driven by a match on the address lines A7-A2 and either SINP or SOUT. We want the first serial port to be at address 20 octal, so A7 low, A6 low, A5 low, A4 high, A3 low, and A2 low. This combination is wired by jumpers connecting to IC O. Pin 8 of IC O goes low when the Address Bus is 20 octal, so that is OK. Pin 3 of IC P is going low when a IN 020 is executed. This drives the ACIA CS2/ signal, which is what we want.
Read/Write is going high when pin 3 of IC P goes low. This selects the Status Register.
Enable is going high when pin 3 of IC P goes low.
Pin 8 of IC P is going low when pin 3 of IC P goes low. This will enable the bus driver chips A, B, and C.
All of these control signals looks OK, so the Status Register data should be coming out of the ACIA. When data is written to the Control Register the internal data bus signals go to 5V. When data is read from the Status Register the internal data bus only goes to between 1V and 2V. This is above the 2.0V logic high level when the Status Register is read so all of the bits read from the Status Register are are ones. The ACIA datasheet says that the output high voltage is only 2.4V.
We tried the 2SIO board and the ASR33 teletype from Altair #1 with the echo program and it works OK. The voltage levels from the ACIA look the same as on the 2SIO from this Altair.
We replaced the first ACIA with a new chip that I bought on eBay. The old chip was missing pin 12, Vcc, and some of the other pins were ready to fall off.
I toggled in a little program that reads the status register. Bit 0 that indicates Received Data Register Full is always on. I toggled in the echo program. On the terminal emulator it constantly writes the last character received back to the terminal. Typing another character changes the character being streamed to the terminal emulator. This shows that the Transmit Data Register and the Receive Data Register are working, and the clock is OK, but we have a problem in the status register.
We also found that entering a 1 echos a 1, but entering a 2 echos a 3, so bit 0 on the data bus is stuck on.
We connected the 'scope to the S-100 data bus bits and the corresponding bits on the ACIA data bus to check if both are working. We toggled in a program that wrote alternating 1s and 0s to the ACIA Transmit Register. It looks like wither IC A or ICB, a SN74367 bus driver chips is bad. I ordered 10x on eBay and should have them next week.
9/5/20
We bought some new SN73367 bus drivers chips. From the 2SIO schematic we can see that IC A and IC B are the ones that receive and transmit bit 0 to/from the ACIA, so we will replace both. Our usual procedure is to cut the IC leads next to the plastic case and the heat the solder connection and pull the IC pin out. When we cut IC B pin 9 the pin fell out of the PCB. The PC trace and the plated through hole for pin 9 were not connected to the PC trace. If we had seen that first we could have just jumpered the connection from pin 9 to the trace and probably had a working 2SIO.
You can see the broken trace going to IC A pin 9 at the top right. Many of the pads, traces and plated-through-holes for IC A are damaged. We replaced IC A and IC B and then use wire-wrap wire to repair the connections. We changed the first serial port's baud rate to 2400 while we had the soldering iron hot. We toggled in the 2SIO echo program and it works!
We modified the 2SIO echo program for the second serial port and reconfigured the terminal emulator for 300 baud. The second serial port works too!
We connected the Micropolis diskette drive, toggled in a bootstrap program, and tried to download PC2FLOP using Tera Term. Every time the byte at 0x105 should have been a 0x03 but was 0xCD. It looks like the bootloader was getting 6 bytes and then skipping one byte. We can probably fix this by adding a delay after each character is sent. We used an ancient Microsoft terminal emulator that we use to download diagnostic programs into the DEC machines. This time PC2FLOP loaded correctly. We ran it, and it asked which floppy diskette we wanted to use, we entered drive 0, and it said that the drive is not ready. Looks like that is the debugging project for next week.
We opened the floppy case to see if the motor was running. It runs all the time. Then we noticed that we had not latched the door on the floppy drive correctly so the floppy was not spinning. We ran out of time this week, so next week we will increase the serial port speed to 9600 baud, and then try to make a bootable MDOS floppy.
9/13/20
The project for today is to make a bootable MDOS floppy by downloading it through the serial console port on the 2SIO board. Last week we increased the first serial port's speed from 300 to 2400 baud. Today we will try 9600 baud. We are leaning towards using a LSI ADM3A terminal as the console, and it will work at 9600 baud. It is possible to modify the 2SIO to run at 19200 baud, which the ADM3A also supports.
We found another Micropolis floppy drive in the museum's warehouse connected to a TEI S-100 bus system. We borrowed it from the TEI so we can test it with the Altair. We can also test the Micropolis floppy controller and other boards from the TEI system in the Altair to make it easier to get the TEI running. We have a North Star S-100 bus system in the warehouse, so that might be one of our next projects.
We changed the jumper for the first serial port on the 2SIO board to 9600, toggled in the 2SIO echo program, configured the terminal emulator for 9600 baud, and it works! That should bake downloading the MDOS floppy disk image a lot faster.
We toggled on the bootloader, loaded the PC2FLOP program, ran Terra Term, ran the program starting at 0x0100, told it to use floppy drive 0 and the first serial port, and sent the diskette image using the XMODEM. It looks like it transferred the diskette image file and wrote it to the floppy. We hit CR on Terra Term and the prompt from PC2FLOP was displayed again.
We started the CPU at 0xF400, the Micropolis ROM location. It activated the diskette, the pattern of lights on the front panel is changing and repeating, but MDOS is not booting.
The bootloader was not erased when we tried to boot MDOS, but PC2FLOP was changed, most likely by trying to boot from the floppy. We reloaded PD2FLOP, and resent the diskette image using XMODEM and Terra Term. This time we got a message that it could not write sector 9 on the diskette. Time to try another diskette.
When it sends the diskette image to the Altair, it sends 57216 bytes or 223 256 byte sector images.
On the second try it loaded part of the diskette image and attempted to write it to the floppy. It ran for many minutes and never downloaded more of the diskette image. We tried a third diskette with the same results. We tried the first diskette again and it failed on sector 7 this time. We can see the WAIT LED on the front panel flashing several times per second, it stops for a while and flashes again, Maybe the sectors are being written when the WAIT light is flashing? We will try more diskettes. With another diskette the WAIT light does not flash.
We borrowed the terminator resistor from the single-density drive and put it in the double-density drive. That didn't make any difference.
We swapped the double density drive for the single-density drive and wrote an MDOS diskette using PC2FLOP. This time we could see the WAIT LED flashing many times and we could see the floppy diskette head stepping towards the hub. After a number of tracks it downloaded more of the diskette image and wrote more on the floppy. Since this diskette drive only has 35 tracks and the double-density drive has 77 tracks, nothing will be accomplished by by writing more than 50% of the diskette image. We stopped the diskette writing process, set the address on the console to 0xF400, the starting address of the boot ROM, and started the processor. We were rewarded with "MICROPOLIS MDOS VS 4.0 - COPYRIGHT 1978" printed on the terminal emulator. So, now we know that everything but the double-density diskette drive work OK. This MDOS diskette will work OK as long as we don't try to access a track beyond track 48.
MICROPOLIS MDOS VS 4.0 - COPYRIGHT 1978
>FILES
DIR 03 0000
RES 03 0014
MDOS 0C 001A
LINEEDIT 14 000E
ASSM 14 0012
SYMSAVE 14 0003
FILECOPY 14 0003
COPYFILE 14 0004
DISKCOPY 0C 000B
DEBUG-GEN 14 0020
SYSQ1 04 0005
SYSQ2 04 0007
BASIC 0C 0050
FEATURES 0C 0003
UTILITY 10 0006
>BASIC
MICROPOLIS BASIC VS 4.0 - COPYRIGHT 1978
READY
PRINT "HELLO WORLD"
HELLO WORLD
READY
PRINT 1 + 2
3
READY
Next week we will try cleaning the head in the double-density drive.
9/19/20
The worm drives for the floppy drives are shown below. The 35 track is on the left, and the 77 track is on the right.
We disassembled the double-density to look at the head, hoping that it was dirty and causing the read/write problems. No such luck, the head was clean. We cleaned the optical sensor for the sector holes and the head with alcohol.
The double-density drive didn't come with a ribbon cable or a terminator resistor pack. We tried the 77-track drive with the ribbon cable and terminator from the single-density drive, but there was no improvement. When we try to boot from this drive it constantly recalibrates. When we try to write a diskette image to the 77-track, the drive recalibrates and just sits on track zero. Time to look for sector pulses.
I didn't see sector pulses U10 pin 4. U10 probably has a leaky input because the sector signal on pin 3 only goes from ground to 1.5V and doesn't trigger U10. I added a 10k resistor across R16 and now the 77 track floppy works. I was able to write the 77 track image and boot from it. I ordered some 74LS14 parts to replace U10.
So now we have working 35 track and 77 track floppies. If I modify the ribbon cable we can connect both floppies to this system.
9/26/20
Mike Douglas made 35 track and 77 track CP/M 2.2 diskette images for use with an Altair with a 2SIO and a Micropolis floppy controller and diskette drive. After some operator error issues (mine) we made physical floppies from the images and were able to boot CP/M 2.2.
CONFIG Version 3.9
(C) 1980 Lifeboat Associates
Your CP/M console is now configured.
Returning to CP/M with patches in memory.
Type SAVEUSER to permanently save on disk.
CP/M2 on Micropolis
32K Vers 2.20B
(C) 1980 Lifeboat Associates
A>DIR
A: DIAG COM : SYSGEN COM : LS COM : CONFIG COM
A: ASM COM : DDT COM : PC2FLOP COM : ED COM
A: LOAD COM : PIP COM : STAT COM : SUBMIT COM
A: XSUB COM : SETCPM COM : SAVEUSER COM : COPY COM
A: MBASIC COM : MEMR COM : MEMR DOC : R COM
A: USER ASM : READ-ME DOC : LIFE ASM : PCGET COM
A: PCPUT COM : OBASIC COM : RANTEST BAS : BASDEMO COM
A: BASDEMO DOC : BASDEMO BAS : XFER COM : DUMP ASM
A: NSWP COM : MOVCPM COM : FLOP2PC COM : DUMP COM
A>
We bought some SN74LS14 parts so we can replace the chip (U10) that we think is defective in the 77 track floppy drive. Replacing the SN74LS14 didn't improve the behavior of the 77 track drive. It works OK with the 10k resistor in parallel with the 100k pullup on the sector phototransistor, so I left it.
I added another connector to the floppy-controller ribbon cable so we could connect both floppy drives. I booted MDOS from the 77 track drive and it can see files on the 35 track drive.
10/10/20
Today we will try to program some 2708 EPROMS using the Cromemco ByteSaver board from Altair #1. The Micropolis floppy controller uses memory addresses range F400-F7FF. The By teSaver normally uses the address range E000-FFFF, so that conflicts with the floppy controller. I changed the address range for the ByteSaver to C000-DFFF so it would not conflict with the floppy controller. The Tanner 64k RAM board has the address range F000-F7FF deactivated so it doesn't conflict with the floppy controller. We now need to deactivate the address range C000-DFFF so it doesn't conflict with the ByteSaver, which unfortunately we can't do on the Tanner RAM board.
We disabled the RAM on the Tanner board from E000-F7FF, installed the ByteSaver configured for the address range E000-EFFF, and tried to boot CP/M. It was worth a try, but it didn't work.
This system came with four other RAM boards. A combination of a Godbout EconoRAM VII and a PSS RAM8 will cover the range of 0000-7FFF which is what we need for the 32k CP/M that we are running. The PSS RAM8 works OK. The Quantronics MM8 works OK. The MITS 4k Static works OK. The Godbout EconoRAM VII can be read, but deposit doesn't work.
We put the Godbout EconoRAM VII on an extender board so we can look at the signals from the S-100 bus. All of the address buffers, U9, U10, and U11 work OK. Found a bad MM5257N-3L 4k x 1 static RAM chip. A replacement might be difficult to find.
The CP/M BYTESAVE program written by Martin Eberhard expects the ByteSaver to be at E000-FFFF so I need to change the program source code and reassemble it.
10/17/20
I bought ten 2708 EPROMs on eBay. If eight of them work OK then we should be able to program an 8k BASIC loadable image in them.
I looked for a replacement MM5257N-3L 4k x 1 static RAM chip, but did not find any. Mike Douglas suggested using a TMS40L44NL-25-4K Static RAM instead. I found some on eBay, and bought one for about $7.
I replaced the defective RAM chip on the Godbout EconoRAM VII. We tested it with the front panel and it looks like it is working now.
We tried to boot CP/M and MDOS, and neither of them boot. We put the 64k RAM back in the system and it will still not boot CP/M or MDOS.
I suspected a problem with the serial console, so I toggled in the echo program. It doesn't echo. I used the 'scope to probe the RS-232 signals from my laptop and found that the data from my PC was on DB-25 pin 3 and should have been on pin 2. A quick check verified that I forgot to put the null-modem device on the serial console cable. I really should make a dedicated serial cable for this machine.
I installed the 24k Econoram VII and the PPS RAM8 memory boards in place of the Tanner 64k memory board, and the 32k version of CP/M 2.2 booted.
I installed the Bytesaver board with installed four blank 2708 EPROMs. Used PCGET to transfer the first 8k BASIC EPROM image to CP/M, and ran BYTESAVE, configured it for the Bytesaver at address C000, loaded the EPROM image into the buffer, and programmed the first EPROM. It looked like it was programming, and after a few minutes it said that the whole EPROM contained 0xFF, so it did not program. This is the first time we tried the Bytesaver, so I am not surprised that it didn't work.
For next week the project will be debugging the Bytesaver board and getting the 8k BASIC EPROMs programmed.
10/24/20
We are back to working on the 8K Bytesaver after being diverted onto other restoration projects. It looks like the +30V programming voltage is missing. It looks like Q10, the MPS6560 transistor that makes +30VDC from +5VDC is not right. The voltage drop base-collector is 0.85V and base-emitter is 1.6V. I ordered a replacement on eBay, so we will replace it next week.
We had a great discussion on the S-100 Bus forum on Vintage Computer Forum about how this power supply works. The schematic for newer version of the Bytesaver includes the transformer windings, but some in the discussion forum said that the schematic was wrong. I tried, unsuccessfully, to LT SPICE simulate the power supply.
We received the replacement MPS6560 transistors. We tested the beta for the 25 transisistors that I bought. The very first transistor out of the bag had reasonable diode drops, but had a beta of 5. The remaining transistors had beta values in four clusters, about 50, 100, 150, and over 200. We picked a transistor with a beta of 150 to repair the power supply. The 30VDC programming power supply now works.
Using the CP/M program bytesave we were able to program a 2708 EPROM
Byte count: 0400
EPROM Power on, ready (Y/N)? y
Programming............................................................
Verifying
Total errors: 0
Q10 Base when the programmer is idle.
Q10 Collector when the programmer is idle.
Q10 Base and Collector when programming a 2708
We programmed 8k BASIC into 8x 2708 EPROMs. We had one bad EPROM from the 10x that we bought on eBay. We reset the Bytesaver's address to E000, and removed the floppy disk controller. When we started the processor at E000 it looked like it loaded BASIC, but there was nothing on the serial console. The last socket in the Bytesaver is not working, but I don't think that it is needed. We will fix the last socket next week.
11/7/20
We looked at the first few bytes of each EPROM in the Bytesaver and compared it to the expected values from the binary image files. The last socket is actually working OK. The first hundred bytes are supposed to be 00, and we thought that was a sign that the socket was not working. We also noticed that the EPROM at address F400 had an extra byte at the beginning, and the remaining 1023 bytes were shifted by one byte. This offset was introduced when we split the 4x 2k EPROM images into 8x 1k images. We erased and reprogrammed the EPROM, but BASIC still does not load.
When we start the BASIC EPROM image at 0xE000 a little loader copies the rest of the EPROMs to RAM, and then jumps to the BASIC loader that is part of the EPROM images copied to RAM. It looks like the BASIC loaders are running, and within a second the machine stays running. The INP light is on, but dim, so it looks like it is waiting for serial port input. There is nothing on the terminal screen, and pressing a key has no effect.
We single-stepped through BASIC to get to the IN instruction, 0xDB. We found an IN instruction at 0x055D-0x055E. It is reading the serial port 0x78. The 2SIO address in this system is set to the default value of 0x10, so it will not work with these EPROM images. The OUT instruction is an 0xD3.
I asked Mike Douglas about the wrong serial port address and he reminded me that you need to set the sense switches to tell the BASIC loader which serial port you have. Oops.
To start BASIC from the EPROMs in the ByteSaver we need to set the switches to 0xE000, press EXAMINE, Set the switches to 0x1000, and press RUN. We were rewarded with:
MEMORY SIZE?
TERMINAL WIDTH?
WANT SIN-COS-TAN-ATN? YES
14980E+01 BYTES FREE
ALTAIR BASIC REV. 4.0
[EIGHT-K VERSION]
COPYRIGHT 1976 BY MITS INC.
OK
11/14/20
We used this system to check the EPROMs containing the BASIC paper tape image for Altair #1. Two had the incorrect contents, so we erased two other EPROMs and programmed them. Now all eight EPROMs contain the correct contents and BASIC works OK.
Page updated
Report abuse