• Please review our updated Terms and Rules here

AlphaMicro Systems AM1000, AM1200, & maybe AM100L drive replacement

OK, bumping this thread.

Over the weekend I turned to my own AM-1000E and AM-1200 (both with dead hard disks) to see if I could get them to boot with the disk images on a BlueSCSI. The short version is yes, with some adjustments: disable SCSI parity, disable SCSI-2, Xebec quirks, enable unit attention. But this upgrade turned up in the AM-1000, which I was not expecting: an Interlink Systems' 68030 accelerator board. I thought it was weird on the self test that it reported 8MB of memory, which sounded enormous for an AM-1000. And, well, it's all on this board as SIMMs. In fact, the jumpers suggest it can take up to 16MB of RAM (!!).

There are some very weird things with this unit, however, the major one being that it freezes trying to start memory parity. I disabled this by monkeypatching the INI right on the disk image and it will boot to the dot prompt, but JOBALCing more than one job will cause AMOS 1.4 (at least) to report a corrupt "0.0" version number.

The AM-1200 has its own issues: at least one bad port and I think its 5.25" floppy drive is probably messed up. I need to reecondition it. But it works where the AM-1000E fails, above.

I suspect there is a driver for the accelerator and I bet it was on the Maxtor SCSI drive that came with the machine, but the Maxtor is super dead. It seems to have terminal stiction and won't respond to any of the typical voodoo tricks; it tries hard to spin up, fails, and immediately powers down. Could be a bad motor. I could try to gin up a stub driver to turn on the '030's I-cache (the SYSTEM word does not indicate that AMOS 1.4 has detected it as an '030) but I don't think that would fix the PARITY issue.

Does anyone know of a driver for these? Interlink Systems seems to be long dead, at least that incarnation of it. Or maybe I just get a regular 68000/68010 and see if the problems persist.

Alternatively, I wonder if AMOS 2.3a could sense and configure the card. The only problem there is that this AM-1000E has the old B00 boot PROMs (pre-B02), so it can't boot an extended format image. If someone has a working AMOS 2.3a disk image suitable for a BlueSCSI or ZuluSCSI, I'd sure appreciate it. Otherwise I guess I'll have to piece one together and see if it will start from a tape streamer.
 

Attachments

  • PXL_20250920_212443150.jpg
    PXL_20250920_212443150.jpg
    2.9 MB · Views: 5
Aaaaaand ... it is in fact a Dimension-030 board. I did try to patch the CACR but it doesn't seem to do anything when I turn on the instruction cache. By itself a simple FOR-NEXT loop in BASIC runs about twice as fast on this board than on the AM-1200, though, even without it.

The only place I've found a mention of this is in AMUS.LOG 12/92 and I don't have the rest of the issue!

Code: 
        search sys
        search syssym
        search trm

        phdr -1,,

        supvr
        lword ^H4e7a1002
        dcvt 0,ot$trm
        type <... >
        bset #0,d1
        bset #3,d1
        bset #4,d1
        lword ^H4e7b1002
        lword ^H4e7a1002
        dcvt 0,ot$trm
        typecr <>
        lsts #0
        exit

        end
 

Attachments

  • DSCN0751.JPG
    DSCN0751.JPG
    603.1 KB · Views: 2
Al,

At least on the IACC SASI card, I had to write boot proms to replace the ones on the AM100/L, and knowing the AM100/L boot code, if there aren't boot proms on the AM405, I would think the AM100/L proms would need to be upgraded.
 
Al,

I don't know what a CHM's CPU board is?
Is the "ul" up-loading AM100/L prom source code?
 
OK, I finished the restoration on the AM-1000E and AM-1200. Lots of interesting stuff. Got the hard disk resurrected enough to see what was going on, and my Eagle 450 already has TURBO.LIT on it, but TURBO.LIT doesn't like the Dimension card and I still can't get the CACR bits to do anything. On the other hand, a 68010 board in the AM-1200 is a welcome upgrade.

Big thanks to @curbie for the images.

oldvcr.blogspot.com

Refurb weekend double header: Alpha Micro AM-1000E and AM-1200

I've mentioned previously my great affection for Alpha Microsystems hardware, which are rather obscure computers nowadays, but back in the ...
oldvcr.blogspot.com oldvcr.blogspot.com
 
Bumping again. Thanks to the former principal at Birdata I got a replacement E300, or what I thought was an E300. Pretty sure the AM-172 CPU board is shot in my original system, so this arrived, a little dirty but it powers up and went through the self-test with no problems.

So I cracked it open. It has a whole bunch of SIMM cards, and it does not have an AM-172 -- it has an AM-174. There is a big honking heatsinked CPU and an 80MHz crystal. You've probably already guessed: it's an Eagle 300 upgraded to an Eagle 500. Apart from the modern x86 systems I have never seen an SI.LIT benchmark this high:

Code: 
.si dsk0:
   SI--AMOS System Information, (C) Copyright 1990, Alpha Microsystems Inc.
                               Version 3.0(115)-1

               Computer Type: Eagle
              Main Processor: 68040
                Co-Processor: 68882
                 MMU present: Yes
            Operating System: AMOS 2.3A(489)
          Boot PROM revision: Unknown
              Number of SSDs: 1
                Total Memory: 32768 K-bytes
     Resident Monitor Memory: 25245 K-bytes

     Computing Index (CX), relative to AM-100:    83.6
     48 bit FP Index (4X), relative to AM-100:    34.1
Floating Point Index (FX), relative to AM-100/L:  1700.0
          Disk Index (DX), relative to ST-506:    23.4

It's a real barnburner. This will likely be the new ampm.floodgap.com once I clean it up and merge some of the old system into it.
 
Well, raise my rent. I got the old E300 out of storage to see what I wanted to move into what. (It is in much better cosmetic condition because I took good care of it.) Just to confirm DOA, I plugged it back in and forced the self-test to run, expecting to get either an error or the same 2d timeout on the LEDs. This error indicates the CPU board is not working or not responding.

Recall that first generation Eagles have separate I/O and CPU boards - the E100 on, including my E450, have a unified logic board. When I was converting this unit to solid state and was reworking the power connections, I accidentally brought the I/O board up without the CPU board and it would not start again after that. There is no warning in the manual about this, only something about the X-BUS connectors should never be connected wrong. I am concluding this means that they are a tightly matched set.

Well, today instead of giving me the same timeout error, it booted and jumped into the self-test. I connected a terminal and verified everything passes. When I reset it (hard drive has been removed), it goes through the boot sequence looking for a device instead of getting a CPU board timeout.

So now to ponder how it pulled a Lazarus on me. I stored it without the lithium battery and it's been offline for several months, so I'm wondering if that was enough to get the I/O board FPGAs to reset. I know from Rod Hewitt that these early Eagles dynamically reprogram the FPGAs on every boot from the ROMs, and maybe being offline for so long with no power was enough to completely wipe them. Perhaps the partial power up left them in a scrambled state and it was unable to communicate with the CPU board. I'd ask Rod directly but he passed away a few years ago.

I'm also now wondering what I should do with this E500. It's a really fast machine but I am happy to have my original Alpha Micro back in action even if I don't know why.
 
You must log in or register to reply here.
Back
Top