This software is an emulator for Alpha-Micro 68000-based computers.
It is copyright by Michael Noel and licensed for non-commercial hobbyist use under terms of the "Q public license", an open source certified license. A copy of that license may be found here.
There exist known serious discrepancies between this software's internal functioning and that of a real Alpha-Micro 68000-based computer, as well as between it and the Alpha-Micro manuals describing the functionality of real Alpha-Micro 68000-based computers, and even between it and the comments in the code describing what it is intended to do! Use it at your own risk!
Reliability aside, it isn't the intent of the copyright holder to use this software to compete with current or future Alpha-Micro products, and no such competing application of the software will be supported.
Alpha-Micro and other software that may be run on this emulator are not covered by the above copyright or license and must be legally obtained from an authorized source.
Finally posting SOMETHING ! With so much to do I expect I'll be posting regular updates for quite awhile.
NEW in this (0.72c) update:
Not very reliable, Not well tested yet. Poor documentation.
Wow - This is gonna be a long list! Here's my current 'top ten', loosely ordered.
4. FIX throws a '?trap exception' as soon as you press return to single
step. I think this indicates an issue with my trap processing but have not
tracked it down yet. FIX no longer throws the exception, and mostly works
(setting/clearing breakpoints, going to breakpoints, going to line with cursor,
etc) but RETURN (for single step) doesn't work yet.
5. AMOS/L complains about "?Improper SSD" during boot, particularly in AMOS/L systems beyond 1.3c.
...
8. VTAM/tskman/fake i/o incompatibilities At least partially fixed,
TSKMAN piece untested.
9. VUE "line 25" sometimes uncleared on exit. Turns out this isn't a VAM problem! Same thing happens
on my real AM-1200. VUE sometimes fails to clear last screen line on exit when it is showing MENU...
VAM is a Linux 'ncurses' application, Installation is compile the source on the target machine.
Tested targets include Cygwin and Fedora Linux 40. I use it native under Microsoft Windows 10 with VMware and WSL.
I also use it on Android phones and tablets using Termux ('native' & with Fedora Linux 39).
Download & untar the source, and change to that folder.
$ tar -zxf vam68-072c.tgz
$ cd vam68
Compile the source.
$ make
Run it!.
$ ./am1200
What's this message?
"boot failed! Problem with 'dsk0-container' ?"
dsk0-container is the name of the file that represents DSK0 (potentially thru DSK31) in the emulator.
Sadly, Alpha Micro has declined to authorize me to distribute AMOS/L for use with VAM, so you will need to obtain a copy yourself: from Alpha Micro directly, from your dealer or most probably from your own real Alpha Micro computer.
There are a variety of ways to obtain a copy from your own computer. The way I did it was to connect a ZuluSCSI 'red' card to my am1200's external disk interface, then used the ZuluSCSI's "create image files" feature to image the am1200's hard drive onto the ZuluSCSI's SD card. I then took the SD card out of the ZuluSCSI, inserted it into my PC, copied the image file to the VAM directory and I was good to go!
The ZuluSCSI red card is inexpensive (from about $50 new on eBay) and also provides an excellent replacement for your real hard drive if that's getting unreliable (as many are at this age). Of course it's much quieter and lighter weight than the old HD. That and a new quiet fan and my old am1200 is now less than ½ its original weight, near inaudible, and boots much faster. Using the ZuluSCSI sdcard this way also provides a great way to swap large files (or large numbers of files) between my real am1200 and VAM.
On my PC the container file obtained as above is HD0_am1200.hda in the same directory as VAM itself. VAM references it by way of a symbolic link to dsk0 container:
$ ln -s HD0_am1200.hda dsk0-container
Included with VAM is a set of container utilities: VDKCLEAR, VDKCOPY, VDKSHOW, and VDKXCHG. These utilities reference the container(s) using 'utlnn-container' names. I use a symbolic link to associate utl0 container with the above dsk0 container:
$ ln -s dsk0-container utl0-container
Containers contain one or more images of AMOS/L 'disks', and the VDKxxxx utilities are used to display and manipulate those images.
VDKSHOW Displays the disk images within containers. Below showing utl0-container on my system.
$ vdkshow 00 amosl 1.3c with C at 000000512 to 031504384, Len 31503872, BM=3846 - 01 mine at 031504384 to 063008256, Len 31503872 - 02 at 063008256 to 094512128, Len 31503872 - 14 amosl 2.3a at 441054720 to 472558592, Len 31503872 - 15 AlphaC at 472558592 to 504062464, Len 31503872
Left to Right on the first line...
| image number | image label | starting block offset | last block offset | number of blocks | bitmap size |
|---|---|---|---|---|---|
| 00 | amosl 1.3c with C | 000000512 | 031504384 | 31503872 | 3846 |
The labels are the same as shown on an AMOS/L 'mount' command.
VDKCLEAR Clears (writes all zeros to) disk image, except leaves volume labels alone, and will leave the bitmap of the first image alone.
$ vdkclear 2 from is 2 = 2 00 amosl 1.3c with C at 000000512 to 031504384, Len 31503872, BM=3846 - 01 mine at 031504384 to 063008256, Len 31503872 F- 02 at 063008256 to 094512128, Len 31503872 - 14 amosl 2.3a at 441054720 to 472558592, Len 31503872 - 15 AlphaC at 472558592 to 504062464, Len 31503872 Does this look right? ENTER to continue, or ^C to abort
VDKCOPY Copies one disk image to another.
$ vdkcopy 0 2 from is 0 = 0 to is 2 = 2 F 00 amosl 1.3c with C at 000000512 to 031504384, Len 31503872, BM=3846 - 01 mine at 031504384 to 063008256, Len 31503872 T- 02 at 063008256 to 094512128, Len 31503872 - 14 amosl 2.3a at 441054720 to 472558592, Len 31503872 - 15 AlphaC at 472558592 to 504062464, Len 31503872 Does this look right? ENTER to continue, or ^C to abort
VDKXCHG Swaps two disk images.
$ mike@Razer:~/new1200$ vdkxchg 1 2 from is 1 = 1 to is 2 = 2 00 amosl 1.3c with C at 000000512 to 031504384, Len 31503872, BM=3846 F- 01 mine at 031504384 to 063008256, Len 31503872 T- 02 at 063008256 to 094512128, Len 31503872 - 14 amosl 2.3a at 441054720 to 472558592, Len 31503872 - 15 AlphaC at 472558592 to 504062464, Len 31503872 Does this look right? ENTER to continue, or ^C to abort
Notice these utilities do not show what they did. You are expected to do a VDKSHOW afterwards if you fear something unexpected may have happened
BTW the WD16 version of VAM also understands this same container file format and provides the same VDKxxxx utilities to manage them.
Another note: the VDKxxxx utilities can operate on images between containers as well as within containers. For example I can copy files between the above displayed utl0 (pointing to HD0_am1200.hda) container and a 2nd container referenced by utl16 (pointing to HD0_wd16.hda) simply by creating the link to the 2nd container
$ ln -s HD0_wd16.hda utl16-container
And using VDKCOPY as follows to copy the 1st image on the 2nd container to the 2nd image on the 1st container.
$ vdkcopy 16 2
THIS ONLY WORKS IF THE CONTAINERS HAVE COMMON BITMAP SIZES !!!
Final note: you'll notice that the first image in these containers start at 512, not zero. The record at offset 0 is some kind of 'self defining' information AMOS/L uses to get the image size and count. I've not figured that out: VAM (and the VDKxxxx utilities) do not use this first record indeed it is not always present! - but instead do a fast disk scan on each startup to obtain the information. This scan depends on the bitmap of the first image not being corrupt.
Do not confuse these container files with the DSK directory also in the VAM folder. The DSK directory has the AMOS/L files VAM may need to boot arbitrary AMOS/L system images.
$ ls -R DSK
DSK/0/1/4: AMOSL.INI RSSR.LIT VAMGET.LIT VAMPUT.LIT VAMSTK.LIT VTAM.LIT VTARUN.LIT DSK/0/1/6: ANSI4.TDV MA300.IDV VAMFEF.DVR VTAM.IDV DSK/0/10/1: ANSI4.M68 MA300.M68 VAMGET.M68 VAMPUT.M68 DSK/0/10/2: VAMFEF.M68 DSK/0/2/2: VAMXXX.CMD VAMZZZ.CMD DSK/0/7/1: DUMP.HLP FIX.HLP HALT.HLP RSSR.HLP VAMSTK.HLP VTAM.HLP
This directory structure contains files VAM will use as needed as overrides to files on your AMOS/L disk image. So for example DSK/0/1/4/AMOSL.INI (corresponding to DSK0:AMOSL.INI[1,4]) will be used if VAM starts up with
Am1200 ini=amosl.ini OR if ini= is unspecified!
In the am1200.ini file (discussed further down in this doc) regardless of whether or not your disk image has a DSK0:AMOSL.INI[1,4].
Similarly DSK/0/1/6/VAMFEF.DVR (corresponding to DSK0:VAMFEF.DVR[1,6]) will be used if VAM starts up with
Am1200 dvr=vamfef.dvr
In the am1200.ini file regardless of whether or not your disk image has a DSK0:VAMFEF.DVR[1,6].
NOTE that this regardless of whether or not your disk image has a copy behavior is a change from past versions that only accssed the DSK system file if the files were not present on your AMOS/L disk image. This change makes it easier to use a 'clean' (real machine) image in VAM, as all the overides can be in the DSK structure. And it simplifies changes to the AMOSL.INI file as mistakes are much easier to correct.
Also note: that case is significant in this DSK file structure: all file and directory names must be either all upper case or all lower case - mixed case names are not yet supported. Finally note that 'PPN' numbers in this DSK file structure are octal: Don't, for example, make a DSK/0/1/8 directory!
You probably won't need to mess with the DSK structure, but after you have successfully booted AMOS/L you may want to copy some of the files onto your AMOS/L image for more direct access. This can be accomplished by using the VAMGET utility to copy files from the DSK structure and load them into memory, then using SAVE to save the memory copy(s) to your disk. A VAMPUT utility is supplied to copy memory modules to the DSK structure. Syntax for the VAMGET and VAMPUT utilities is similar to the standard LOAD and SAVE commands.
Also, WRT changes or additions to the DSK structure, be aware linux and windows line endings may differ. HINT - AMOS/L uses CRLF line ending; that would be DOS-like in Linux speak. You should review the man page for dos2unix for more information on recognizing and handling this issue if it arises. You may also see strange last characters in transfered files - typically null or ^Z.
VAM is configured using the am1200.ini file in the HOST system, same directory as VAM itself. It is copiously commented. Comment lines start with a '#'. Commands are on one line but may be continued with a trailing '\'. Case is not significant nor is white space. Commands in the am1200.ini file are:
AM1200 parameters associated with the monitor to be loaded.
Am1200 \
ini=filename1 \
dvr=filename2 \
mon=filename3 \
autobm
filename1 is the name of the system initialization file, defaults to AMOSL.INI (or whatever is in the loaded monitor). It will be located in DSK0:[1,4].
filename2 is the name of the system disk driver file. It defaults to none (whatever was MONGEN'd into the loaded monitor). If specified it will be located in DSK0:[1,6].
filename3 is the name of the system monitor file. It defaults to AMOSL.MON. It will be located in DSK0:[1,4].
Autobm specifies that the bitmap size embedded in the loaded monitor will be overridden by that determined by the VAM disk driver on startup. If specified it will apply even to the driver loaded by filename2. Noautobm may also be specified (and is the default) to leave whatever is in the disk driver alone.
TELNET parameters associated with VAM's built in telnet server.
telnet \
port=number \
allow1
A telnet connection is in parallel with one of VAM's ncurses screens. Those ncurses screens are referenced by FNUM (sorry, I've no recollection of why I called them that) with FNUM=1 being the AMOS/L's first job, FNUM=2 being the second, etc. The telnet server is optional. If you don't want to use it omit or comment it.
number is number is the port number your telnet client will use to connect to VAM. For example, if number is 12345 then an appropriate telnet command (using the default linux telnet application) might be
$ telnet localhost 12345
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Connected to VAM am-1200 emulator @ fnum=3
Assuming you were connecting from your own PC. Notice the fnum=3 at the end of the last line: this tells you the connection is to the 3rd job on AMOS/L.
VAM normally will not allow a telnet connection to fnum=1. This is to provide some security for the local user who is assumed to be using JOB1=TRM1=fnum1. But you (said local user) may want to use the telnet connection yourself say for the ability to 'roll back' the screen or copy/paste larger blocks and you can override VAM's usual denial for your session by specifying allow1.
Also note that it may be possible to specify what fnum to connect to. How this is done (or if it's possible at all) depends on the telnet client you are using. I use the Windows TERATERM client rather that the default Windows or Linux client, and in TeraTerm 5.2 this is done on the TCPIP selection under the SETUP menu. Observe the @fnum1 after the vt100 in the term type entry below causing fnum1 to be passed to VAM which will then attempt to select fnum=1.
RAM parameters with Read-Write memory.
Ram \ base=number1 \ size=number2
Specifies the location and size of a block of read-write memory. You can define as many blocks as you like but more than one would be unusual Typically base=0 and size=128k minimum, 15m maximum. The shipped version of am1200.ini has 4m, matching a real am1200.
ROM parameters with Read-Only memory.
Rom \ base=number1 \ size=number2 \ image=filename
Specifies the location and size of a block of read-only memory. You can define as many blocks as you like but more than one would be unusual. filename specifies a file in the host file structure (but not in the DSK structure) to be loaded into this address space. VAM ship with this commented, and does not include any rom image files.
Having established your container link(s), run it again!
./am1200
It booted - right?
If not contact me & I'll try to help you figure out why...
One feature that may help is the POST (Power On Self Test) option. Specify it like this;
./am1200 -P
Shutdown
Press ALT-H to get a list of ALT commands. Note that ALT-F will get you to the front panel. At the front panel you can use tab or arrow keys to select the reset or power switches. Press enter with one selected and the indicated operation will be performed (after a confirming dialog).
So to shutdown press ALT-F, enter, Y
The system you run this in needs to have relatively good NCURSES support.
Within AMOS all the control keys should work. Esc should work. The Arrow keys, Insert, Delete, Home, End, PgUp, and PgDn should work.
Watch out for ALT keys. ALT-T toggles instruction tracing. ALT-S toggles instruction stepping. ALT-R resumes from stepping. ALT-F shows the "front panel". ALT-1 shows the first terminal screen, ALT-2 the second terminal screens, ... up to 10 terminal screens can be defined with the tenth being ALT-0 ALT-Z repaints the screen if it gets messed up (like with trace/step info). ALT-(anything else) displays a list of ALT commands
Things are defined in the am1200.ini file. See that file for further instructions. Also note am1200.ini is only the default initialization file, if you want to use another (for example if you have several different configurations you want to be able to start) you use the -f startup flag: for example, to startup using a warm boot configuration (that you create) you could type
./am1200 -f warm.ini
Console output is to one of the NCURSES panels associated with a terminal (ie, the ALT 0-9 screens discussed above). Traces go to STDERR. If you want to try a trace but don't want it mixed with your screen, start the emulator with
./am1200 2>am1200.log
Then all the trace output goes into a file. Watch out - it gets huge very very fast. It "wraps" at a certain point but that's an "undocumented" feature, and there is also a "user" trace facility, but I'm not ready to try and document that yet either.
CUT and PASTE works with the console windows iff the console or xterm the emulator is running in supports it. Be careful of PASTEing more than a few lines; AMOS may not be able to process characters so fast which can cause a crash (in AMOS, not VAM).
Send me an email (mikenoel37@gmail.com) telling me what you did, what happened, and why you don't think that should have happened. For example: "I compiled and ran xyz.bas and it crashed saying it couldn't open file aaa.bbb, but aaa.bbb was there like it was supposed to be and this program and file work on my real AM-1200". So far I'm pretty prompt getting back to people who tell me about problems, hopefully that will continue...
Were you a software developer in the AM-1200 heydays? Still have a copy of your pride and joy laying around? Why not let others remember with you! Let me post a copy for use with the emulator. All donations welcome!