Software for Altos8000 (Was: So what do I do now?)

[dspeirs]

I am not totally sure where to post this - please forgive if not really in correct forum

A couple of months ago i was approached by the father-in-law of a good friend. He has a software business that deals in gas station management, that he started about 30 years ago. In his early days he had stuff running on an ALTOS 8000 platform - now it is all on linux servers etc.

However he got a wild hair up his butt he wanted an Altos8000 to show off in his headquarters as memorabilia of his company.

So he found one somewhere. It did not work. That's when he approached me.

After pulling out my hair (and i have very little to pull) for a couple of months, i have the machine successfully booting CPM 2.21. I have a working Altos diagnostic disc, and a working CPM boot disc constructed (THANKS to bitsavers for image files!!!!! and to Dave Dunsfield for his IMD tools!!!!!)

I am able to successfully format discs, make boot copies, run memtest etc. My CPM knowledge is very rudimentary, but I can get this far.

So my question is, what now?

He has given me some discs that presumably had his early software on them - only a couple have anything readable on them.

Some of these have files with an .ovl extension. Does anyone know what these files might be? Or how to use them?

Does anyone know of techniques for recovering data from bad discs?

How do you load software into a machine like this?

Is getting a disc the only way?.

Is there a file transfer protocol where software could be loaded from the rs232 port? I see a program called FTP.COM on one the discs that could be read. Does anyone know what this does, or how to use it? I run it - it just puts up the character 'w' over and over.

Does anyone have a guess at what the original programmers would have been using as far as language and compiler on a machine like this? circa 1979-1980 I believe.

 

[Chuck(G)]

.OVL was a convention (but a naming convention only) for program overlay files. In other words, you have 64K of RAM, so you read in pieces of a program to do specific things. They "overlay" old code. They're not usable by themselves; they have to be loaded by another (usually .COM) program. This is the way things worked before virtual memory.

Serial RS232 transfer using XMODEM/ZMODEM/YAM/Kermit, etc. was very common, particularly when it involved dialups to BBS systems.

Languages used were most likely assembly, PL/M and sometimes C, Pascal or Modula-2. DRI also had a PL/I compiler; COBOL and FORTRAN were also very common. For business-type programs, CBASIC or BASIC/E were often used.

My suggestion is that you verify the alignment on the drives that you're using. 8" floppies in general are very reliable and a mere 20 or 30 years shouldn't bother them.

 

[LGriffin]

I agree with Chuck(G), verify alignment. The program I like for recovering disks (all disks) is Spinrite by Gibson Research;

http://www.grc.com/cs/prepurch.htm

The problem would be getting the drives on a PC or Linux machine.

FTP stands for File Transfer Protocol, and will transfer files via RS232 ports. You will need a Null modem cable.

Larry

 

[Chuck(G)]

I agree with Chuck(G), verify alignment. The program I like for recovering disks (all disks) is Spinrite by Gibson Research;

Wrong filesystem and physical media encoding (e.g. 256 byte sectors). Spinrite won't help you.

The best way to go about aligning is with an AAD (analog alignment diskette) and and oscilloscope. There were also digital alignment diskettes with address headers on a track located at varying offsets. Sometimes you can simply tweak the alignment manually until things come into line (hint: when the service manual says "rotate the stepper body", they mean rotate very slightly--less than a couple of degrees).

But before that, make sure drive heads are clean and the rest of the drive is in good shape (e.g. the drive belt isn't slipping).

 

[Dr_Acula]

Re "Is there a file transfer protocol where software could be loaded from the rs232 port?"

I use xmodem. It is written in assembly and has had a timing loop adjusted so it gives up after about 20 seconds (2 seconds or 200 seconds are not so useful!). Over at the N8VEM project we had a huge problem with file transfers until one clever person got xmodem working. We have not had much luck with any other protocols (ymodem, kermit etc) - the code is just too complicated. But you can do a lot of clever things with xmodem - eg write a batch loader in visual basic to send over all the files (say) that you need for wordstar.

To get xmodem working on your machine you would need an RS232 port and also the port number (usually a number from 0 to 255). There will also be another port number (usually one above or below this) that is the status port - ie 'is a byte available?'.

You then need to put these two numbers in the xmodem code and recompile.

That presumes you have a compiler of course!

But - how do you get the xmodem code over? One way is to turn it into hex, and send it over using PIP. Hopefully you have a working copy of PIP. And hopefully it receives data from the reader port (RS232 port) when you ask it to receive from there. You can also send a text file over with PIP and so hopefully you can get the source code of xmodem over without having to type it all out by hand.

There are a lot of 'chicken and egg' situations that can come up here. For the N8VEM we ended up building an EPROM with PIP and XMODEM on it. That was enough to get things started, but you might not even have that much. Have you got LOAD.COM and PIP.COM on the disk?

 

[dspeirs]

Yes, I have a working copy of PIP.com, load.com and also several versions of FTP.com where some of the versions have numbers... i.e ftp41.com

what compiler? there is asm.com? what language is xmodem written in?

In fact here is a dir of one of the discs.

A>dir B:
B: DISKDEF LIB : DISKSTAT COM : PIP COM : SUBMIT COM
B: XSUB COM : ED COM : ASM COM : DDT COM
B: LOAD COM : STAT COM : DUMP COM : MOVCPM COM
B: FTP48 COM : FTP31K COM : CPMSETUP COM : MODE COM
B: CBIOS20 COM : CPM64 COM : CBIOS40 COM : FTP12 COM
B: FTP COM : FTP24 COM : FTP41K COM : CBIOS64 COM

I think this disc was labled cpm2.4???

the other CPM disc 2.21 are basically the same but do not have ftp.com

 

[LGriffin]

Starting with the disks. The latest version of version 2 of CP/M, I believe was .23, CP/M Plus was ver 3. That's not a full copy of CP/M on that disk. I don't think those are version numbers on the files, I could be wrong. I'm thinking they indicate the amount of TPA. The numbers are too far apart for version.

btw I would not mix the files on the two disks.

Xmodem was in the "Public Domain", and distributed via RCP/M. As with most programs in "Public Domain" it's written in assembler, there where a few exceptions. Convention was that the program, source code, and documentation was distributed in a library (.LBR) file. The convention also was the the program was compatible with CP/M as distributed by Digital research.

PIP could be used to transfer programs via RS232. I've done it, it was a royal PITA. Xmodem would be the way to go.

Larry

 

[Dr_Acula]

Attached is one of the xmodem variants I'm using. I've got a few copies with different timing, and one of them has been changed so it saves to MP/M user 1 instead of the default user 0.

Anyway, this is the vanilla flavoured version.

Scroll down and you will find this bit of code
.IF EXTMOD
MODCTLP:.EQU 06DH ; PUT YOUR MODEM STATUS PORT HERE
MODSNDB:.EQU 20H ; YOUR BIT TO TEST FOR SEND
MODSNDR:.EQU 20H ; YOUR VALUE WHEN READY
MODRCVB:.EQU 01H ; YOUR BIT TO TEST FOR RECEIVE
MODRCVR:.EQU 01H ; YOUR VALUE WHEN READY
MODDCDB:.EQU 02H ; CARRIER DETECT BIT *** DSR change status bit
MODDCDA:.EQU 00H ; VALUE WHEN ACTIVE *** 0 = no change since
MODDATP:.EQU 068H ; YOUR MODEM DATA IN PORT
MODDATO:.EQU 068H ; YOUR MODEM DATA OUT PORT
MODCTL2:.EQU 0C1H ; SECOND CONTROL/STATUS PORT.
.ENDIF ; END OF EXTERNAL MODEM .EQUATES

You need to change three values:
MODCTLP
MODDATP
MODDATO

those last two will possibly be the same.

You might also need to check which bits are set when a byte is available. The above settings are for a 16450 uart (and equivalents).

If you have PIP working, maybe you can PIP this over as a text file?

PIP needs ^Z at the end to signify the end of a file, but as it so happens, this text has been xmodemed back and forth a few times between a PC and a CP/M board, and there happens to be a whole lot of filler ^Z characters at the end (I renamed it as a binary file and used a hex viewer).

Then I guess you need a compiler. I tried ASM.COM and it is giving an error on all sorts of things, mainly the .EQU and .DB (which I know some assemblers like to use without the dot).

I get endlessly confused between the syntax of .MAC vs .ASM and which compiler works for which. The above has been compiled using cross compilers (RASM and TASM) and there will be a compiler that will work on a real board.

These were some notes I made for .MAC files
; changing from tasm mnemonics - replace all $nn with nnH
; remove . in front of equ
; remove : in equ lines
; must have a CR/LF after END
; use zasm.sub with supersub
; eg supersub zasm myfile (where myfile is called myfile.mac but do not put the
; mac in the instruction - m80 knows it is implied)
; zasm.sub is the following two lines
;M80 =$1 /Z/C/L/M
;L80 $1,$1/N/E

; UART 16C450 SERIAL IS ATTACHED TO THE SECOND IO BASE ADDRESS

IO_Y0 EQU 60h
IO_Y1 EQU 68h
IO_Y2 EQU 70h
IO_Y3 EQU 78h

UART0 EQU IO_Y1+0 ; DATA IN/OUT
UART1 EQU IO_Y1+1 ; CHECK RX
UART2 EQU IO_Y1+2 ; INTERRUPTS
UART3 EQU IO_Y1+3 ; LINE CONTROL
UART4 EQU IO_Y1+4 ; MODEM CONTROL
UART5 EQU IO_Y1+5 ; LINE STATUS
UART6 EQU IO_Y1+6 ; MODEM STATUS
UART7 EQU IO_Y1+7 ; SCRATCH REG.


Now, the xmodem one has dots in front of the EQU, so it won't be M80 and L80.

Hmm - let me think. Maybe you need to cross compile this on a PC using TASM, create the .COM file, send it back to me, I can run UNLOAD on it and convert it to a .HEX file and you can then use PIP to get the .HEX file over and then use LOAD to convert it back to a .COM.

There must be a better way than this. I need to ponder this a bit more...

Addit: I'm at work now but I had some ideas on the drive to work - I think the SIMH is going to be useful as you can do fast compilation and the CPM2.2 disk has L80 and M80 etc. So maybe download that and get it working. Also TASM - and if you can't find that I can post a copy. I think UNLOAD.COM is on one of the MPM disks but I can send you a copy. Then you should have enough to do your own compilation and at least be able to create a HEX file that you can PIP over to the board.