• Please review our updated Terms and Rules here

AlphaMicro Systems AM1000, AM1200, & maybe AM100L drive replacement

Should be no probem at all. In fact you can do it 99% right now with the WD16 version - all but running the .LITs.
Use VDKSHOW to peruse your SD image then mount it as a subsys in WD16 & copy as you like. The WD16 container has a bunch of empty 30+ meg logicals (like 60000 free blocks each).
The WD16 version also has TAPDIR, TAPFIL, & FILTAP support so you can use it to migrate your SD images to your host window or linux file system.
 
I'm in the process of learning python for it's rapid development capabilities, getting though the tutorials and using them to start my local documentation should take me all summer, but I'll grow tired of tutorials and need a break, and I'll use that time to set up VAM. Goody, goody, goody.

Hi both Classic and Mike.

curbie
 
Hi Mike,

I'm winding down my second pass at learning python, it takes me a few passes, I thought I'd start setting up VAM/L before I start the next pass. I run Ubuntu and have read "VAM/68 Readme" a few times which seems pretty straight forward, any last minute tips before I start, or just follow the yellow-brick road?

I've never run run VAM/100 before.
curbie

 
Mike, just to check - what were the exact steps you took with your AM-1200 to image the disk to the Zulu? Unless I'm looking in the wrong place (very probable), I can't see in their documentation how to image an existing hard disk to the Zulu automatically, only how to create a new blank image.

The same step should work for my 2.3a Eagle boxes, which is why I'm verifying.
 
Mike, just to check - what were the exact steps you took with your AM-1200 to image the disk to the Zulu? Unless I'm looking in the wrong place (very probable), I can't see in their documentation how to image an existing hard disk to the Zulu automatically, only how to create a new blank image.

The same step should work for my 2.3a Eagle boxes, which is why I'm verifying.
The zuluscsi doc is nearly as bad as my own, but if you google "zuluscsi initiator" you should find what you need on github. Hint: the "red" card is the rp2040.
Wish I could say "exactly" what I did but that was over a year ago; I doubt I' d correctly recall all the steps.
 
Ha! Well, I did get an RP2040 ZuluSCSI to test this out with. I haven't done it to the Eagle yet (probably will start with the E450 since the E300 is serving users as we speak) but I did attempt it with my MacIvory III workstation which I needed to clone anyway. I set the initiator DIP to on, connected it to the drive and to power (I used the internal SCSI), turned everything on, saw it slow blink for a few seconds while it enumerated SCSI IDs and then listened to it tick along as the LED blinked quickly. Eventually the ticking stopped and the LED went back to a slow blink. I powered off, looked at the log on the SD card and saw it had copied all 4GB. It literally was that easy.

On the AM systems it may be as straightforward as connecting it to the external SCSI port due to the way the bus is wired, though you'd need to power on the drive without powering up the system, of course. My MacIvory III system is just a IIci otherwise, so I only had to pull the ROM select jumper to lobotomize it. For the E450 I might use an external power supply to run the drive separately.
 
yet another. This one - 0.72 - finally has input echo working!
In getting 'real' i/o to work in the VAM 68000 emulator I noticed some of AlphaMicro's interface drivers use 68000 interrupt vectors (like the AM100L using INTV0=^H068) but some use 'user interrupt levels' (like the AM300 using AMV=3). Closer inspection shows these 'user interrupt levels' are resolved to table addresses using something like (AM300 case)

LEA A1,INTRPT ; index the interrupt routine
MOV A1,^H<11C-<AMV*4>> ; store interrupt address in table

Certainly this is not functionality for which the 68000 has native support. I speculate AlphaMicro added an MC68901 (or similar) multifunction periphal (MFP) chip to handle this.

I know at some point the hypothetical MFP has to generate a real 68000 interrupt of some kind so the CPU will know to do something. But what interrupt? I'm guessing that's the main thing I need to know to 'support' that MFP - but is there more I haven't considered?

First Side Note: VAM's current AM300 implementation uses a modified AM300 interface driver (MA300) that uses the 68000's real interrupt vector 4 (ie, 2nd line of above code changed to

; MOV A1,^H<11C-<AMV*4>> ; store interrupt address in table
MOV A1,^H070 ; now using level 4 (was floppy)

At some point I'd like to incorporate support for the hypothetical MFP into VAM so that it can use unmodified AM code.

Second Side Note: Apparently there was an AlphaMicro document "AMOS Terminal Service System User's Guide" which may delve into such questions, but I've been unable to locate it on the web. Does anyone have a copy?
 
The only document I have that makes reference to the Terminal Service is AMOS Monitor Calls chapter 7 (04010A00.pdf, DSM-00040-10). However, that just contains the monitor calls, of course, and no description of the hardware or system implementation.
 
The only document I have that makes reference to the Terminal Service is AMOS Monitor Calls chapter 7 (04010A00.pdf, DSM-00040-10). However, that just contains the monitor calls, of course, and no description of the hardware or system implementation.
Was appendix B of that where I found reference to the "AMOS Terminal Service System User's Guide"...
 
Perhaps? "For more specific information on the terminal service system and how terminal drivers may be written, see the AMOS Terminal Service System User's Guide." That particular document is not in my Joomla dump from Birdata or the original Alpha Micro website, though.
 
Perhaps? "For more specific information on the terminal service system and how terminal drivers may be written, see the AMOS Terminal Service System User's Guide." That particular document is not in my Joomla dump from Birdata or the original Alpha Micro website, though.
Probably a manual they once thought to publish but never did. Like the Level7 debugger manual or the ...
 
VAM/68 progress - just a quick post to mention my work on this has slowed way down since mid October. I'm summers in Alaska & winters in Florida but this year Hurricane Milton hit my Florida place pretty hard so I've little time to work on VAM.

Last upload was 9/13/24 (version 0.72c). Known major shortcomings include: (a) FIX not fully functional; (b) 'Hangs' if 'to busy'; (c) wont boot amosl 2.3a. I think timer processing issues are probably resposible for all of them.

Of course source is included so if anyone wants to work on these problems have at it!

Hopefully I can resume my own efforts before I return to Alaska next Spring!
 
Back
Top