• Please review our updated Terms and Rules here

Basic boot loader for an IMSAI

L

litterbox99

Experienced Member
Joined
Aug 8, 2010
Messages
103
Now that my SSM IO4 card is working, I've been trying to
find a boot loader for Basic. There's a youtube video of an
Imsai loading basic, displaying incoming bits on the 'programmed
output' LED's that would be perfect for my needs, but no code is listed.

I've been googling and reading for days now and the only thing I have
found is loading Basic on an Altair.

http://www.solivant.com/

It looks like this is specific to certain Altair I/O boards the way it's
coded in the second stage, but I gave it a try anyway.

I changed to code to reflect my I/O ports and removed the code
to initialize the serial card as the SSM uses AY3-1015D.

Here's my code and comments as I understand it;

0010 0001 21 041 lxi H, 0FAEH ;Set stack to
1010 1110 AE 256 ;L = AE
0000 1111 0F 017 ;H = 0F

0011 0001 31 061 lxi SP, stack ;Set top of stack
0001 1010 1A 032
0000 0000 00 000

1101 1011 DB 333 input ; Check status bit from port;
0000 0010 02 002 ; port #2

0000 1111 0F 017 rrc ; Move accumulator right one bit
1101 0000 D0 320 rnc ; Return if no carry

1101 1011 DB 333 input ; get the char from port;
0000 0011 03 003 ; port #3

1011 1101 BD 275 cmp L ; Does char L = lead in string AE ?
1100 1000 C8 310 rz ; yes - loop back to get another char
0010 1101 2D 055 dcr L ; no - decrement the counter in L

0111 0111 77 167 mov M, A ; store the character in RAM @ HL

1100 0000 C0 300 rnz ; loop to get another until L = 0
1110 1001 E9 351 pchl ; jmp to start of program we just read.

0000 1011 0B 013 dw loop ; prime the stack with the
0000 0000 00 000 ; address of the top of the loop.

For the most part, I understand whats going on here, except for how does
the RNC & RZ know where to return to ? I'm assuming it jumps back to
lxi, sp. I also don't know why the stack is set to 032, 000.


Running this program yields no results and single stepping, it lets lost in
the weeds when it loops back and passes 1A.

I'm using Tera Term and can send data to and from the serial card
and display it on the PC, so I'm sure it's not a communication issue.

Another question is, where the flow control ? When I send a binary file
from Tera Term, it just dumps it out. Shouldn't it take it in one byte at a time
as the program loops checking for status bits & looking for the leader string AE ?

If there is a alternative way to load Altair 3.2 4k Basic, I'd like to know.
 
Let's look at the original code:

Code: 
 0000 3E03              mvi     a,3
 0002 D310              out     10h
 0004 3E19              mvi     a,19h
 0006 D310              out     10h
 0008 21AE0F            lxi     h,0faeh
 000B 311A00    loop:   lxi     sp,1ah
 000E DB10              in      10h
 0010 0F                rrc
 0011 D0                rnc
 0012 DB11              in      11h
 0014 BD                cmp     l
 0015 C8                rz
 0016 2D                dcr     l
 0017 77                mov     m,a
 0018 C0                rnz
 0019 E9                pchl
 001A 0B00      stack:  dw      loop

Note that the code is position-sensitive, so if you just tossed the first eight bytes of initialization code and began toggling the remaining code in at 0000, everything will be in the wrong location (which is what had me puzzled. If you want to get rid of the initialization code, just replace it with 8 NOP instructions.

What the code does is to read bytes in reverse order, starting at location 0FAE until AE bytes have been read, at which time, the code transfers to location 0F00. There's a clever little gimmick for skipping over bytes as well.
 
Thank you for the input !

I added the 8 NOP's and now when I single step through the
code, it proceeds as far as the RNC, jumps down to dw loop, and
then back up to 000C 1A 00. Shouldn't it jump back to 000B lxi, SP ?

It looks like I may have a status bit issue.

Currently DAV (pin 4) from the UART is strapped to D0 (pin 9) on W1,W2.

I'll keep plugging away...
 
Chuck, yes..

I must have missed something the first time, so I re-entered the program
and it started to loop correctly.

After MANY attempts to send the tape file to the Imsai, I had yet to see
any kind of activity on the front panel that it was receiving data.

After screwing around for several hours I decided to change the ports on my SSM card
to match the ports in the original code (20,21). I had my I/O card and the code set for
ports 0, 1. I the realized that MAYBE the 2nd stage loader was coded for ports 20, 21
so I changed it back.

I ran the code again with the new changes and now I can see activity on the
front panel that it was receiving data !

Keep in mind that I am not doing anything with the A12 - A15 switches as mentioned
on the web site before I run the loader. My I/O card is not listed and I guess I don't
understand it either.


I examined the data in 0F00 and compared it with the octal dump of the loader
provided on the solivant web site. It doesn't match up. Most of it is correct, but
certain octal numbers are changed.


The Left set of numbers are from the original 2nd stage loader &

the right set of numbers are what is in my memory.

For example;

363 - 263
333 - 233
172 - 072
332 - 232
312 - 212
377 - 277
312 - 212

Do you see the trend ?

I thought I was dropping bits, so I went down to 1200 baud, but
the anomaly remained and was consistent throughout the octal dump.

I'm a bit blurry eyed from doing all these conversions from hex-oct-bin
and from flippin' these darn paddles all day....

I'm gonna have a few Jack & coke's now.
 
Last edited:
Take a look at your serial card settings. I'd first make sure that they were set to 8 data bits, no parity, 1 stop bit. If that didn't work, I'd try 8 data bits, odd parity, 1 stop bit.
 
My com port & card are set up as 8N1, I'll try changing
the parity in the morning...my last day of vacation :-(
 
For what it's worth, most folks tend to talk in hex, particularly on 8-bit machines. I don't mind working in hex or octal--at one point in my career, I had to alternately switch between 64 bit words in hex and 60 bit words in octal. For me, octal works well on systems that use a multiple of 3 bits as their word size and hex for those with word size a multiple of 8 bits. I never understood DEC's loyalty to octal, even on their 16 and 32 bit machines. On the other hand, 12 bit words seem to sit well in either radix.

I'll add that octal sort of makes sense on the 8080-type CPUs as the instructions decode a bit more naturally. But remember instructions in hex is one fewer digit per word to remember.
 
This morning with a much clearer head I tried your suggestion of odd parity.
In fact, I tried all possible iterations of stop bits, parities and what not.....
I even tried sending just the 2nd stage loader. No joy. Same results as in my
previous post.

Then I powered down and restarted the Imsai, set the start
address to 0F00 and manually deposited FF to this location, my
result was BF.

Looks like I have a memory card issue in the 0F00 - 0FFF range
as all FF deposits were BF. When I reached 01000 it deposited
the FF correctly.

I guess I can stop chasing my tail with the loader and dig into
my 8k Godbout Econoram II memory card (big sigh)
 
Ok, well I'm back.

I managed to score a few 2102 memory chips and identified
their location on my 8k memory board. Now when I run the
1st stage loader, the 2nd stage loader is placed properly
in memory at 0F00. I verified the data stored at 0F00 and
I am no longer having issues as mention in my above post.

I'm trying to load basic in steps... First I toggle in the 1st stage
loader, then just load the 2nd stage loader, verify and then
send the basic file.

Still no joy :-(

The first & second stage loaders are intact in memory.

When I try to load basic, it fails and sends a stream of "M's" to
Tera Term. Looking back at the Solivant web site it is mentioned
that "M's" indicate a failure to store bytes into memory or running
out of memory. I have an 8k memory board and I think this should
be enough, otherwise I may still have issues with my memory board
in a certain address space.

I don't have a monitor or an OS yet, but is there a simple memory
test program I could toggle in to see if I'm fighting a memory issue
or something else ?
 
litterbox99 said:
I don't have a monitor or an OS yet, but is there a simple memory test program I could toggle in to see if I'm fighting a memory issue
or something else ?
Click to expand...

Sure, what's the range of memory that you'd like to test?

This all reminds me of the problems I had with the MITS ^%$#@ 4K DRAM boards.
 
I would use another procedure to load basic, but the solivant is the only
one I've seen. There's a youtube video where a guy has an Imsai that
loads Altair basic via serial port, it even shows the incoming data on the
programmed output LED's. This would be ideal as I can see it loading,
otherwise, it's a bit harder to see it on the front panel with semi dim
address LED's. Unfortunately, he doesn't have any code posted.

As far as a memory range, 0000 - 1FFF would work for my 8k board,
but I may as well have something to test to entire 64k range.

I'll admit this 8k econoram II has been a bit %$#@! flaky !
It worked fine in the lower range, small programs that I toggle
in, but as I'm finding there are issues in other areas. 2102's are
not as easy to come buy and considering this board has 64
memory chips along with 64 IC sockets that may be questionable,
it will be a challenge to diagnose. I'll replace a few 2102's and
it will take care of one range, but then as I progress, I find more
memory areas that are bad.

The cost and time to hunt down and replace bad IC's and sockets
may make it cost effective to repair. I would prefer a memory board
with minimal component count. I do have an Eprom/Ram board from
the s100 web site, but as of now I can only get the Eprom section
to work, the RAM side is giving me some difficulties.

I'll take a look at the memory test PDF, looks like it's made to
fit in a ROM, thats ideal as I can burn Eprom all day long.
I've never used and symbolic editor or assembler. I've simply
found code segments and hand converted them to binary or
convert to hex for an Eprom burn. Since this memory test
prg is bigger than I'm used to, is there a utility/editor I may
use to enter this prg and net me an output in hex I can use
to burn an Eprom ?

Again, thanks guys for all your help !
 
It seems that the comprehensive memory test is no longer available at the link above. In the interest of keeping this information available, it was found at the internet archive and that file is uploaded here:
 

Attachments

  • A Comprehensive Memory Test for the 8080.pdf
    4.4 MB · Views: 6
You must log in or register to reply here.
Back
Top