Image Map Image Map
Results 1 to 8 of 8

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

  1. #1

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

    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.

  2. #2
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    30,672
    Blog Entries
    20

    Default

    .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.

  3. #3
    Join Date
    Aug 2010
    Location
    Gateway to Yosemite
    Posts
    10

    Default

    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

  4. #4
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    30,672
    Blog Entries
    20

    Default

    Quote Originally Posted by LGriffin View Post
    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).

  5. #5

    Default

    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?

  6. #6

    Default

    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

  7. #7
    Join Date
    Aug 2010
    Location
    Gateway to Yosemite
    Posts
    10

    Default

    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

  8. #8

    Default

    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.
    Attached Files Attached Files
    Last edited by Dr_Acula; September 13th, 2010 at 11:55 PM.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •