View Full Version : Basic boot loader for an IMSAI

January 1st, 2011, 06:44 PM
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.


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.

January 1st, 2011, 09:03 PM
Let's look at the original 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.

January 2nd, 2011, 10:43 AM
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...

January 2nd, 2011, 11:18 AM
Yup, double-check your code. There shouldn't be any way to get to 000C with the code above.

January 2nd, 2011, 06:54 PM
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.

January 2nd, 2011, 08:14 PM
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.

January 2nd, 2011, 08:26 PM
My com port & card are set up as 8N1, I'll try changing
the parity in the morning...my last day of vacation :-(

January 2nd, 2011, 08:36 PM
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.

January 3rd, 2011, 11:05 AM
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)

January 16th, 2011, 10:45 AM
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 ?

January 19th, 2011, 12:05 PM
I have had mixed luck with the solivant procedure myself. It has worked once or twice, but not predictably.

January 19th, 2011, 12:12 PM
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 ?

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.

January 19th, 2011, 12:28 PM
This may take a while to toggle in, or you can feed it through the serial port....but it works. (link below to an article by Frank McCoy)

http://vintagecomputer.net/cisc367/Microcomputer%20SCCS%20Interface%20September%20197 7%20A%20Comprehensive%20Memory%20Test%20for%20the% 208080.pdf

January 19th, 2011, 05:35 PM
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 !

January 19th, 2011, 06:22 PM
This may take a while to toggle in, or you can feed it through the serial port....but it works. (link below to an article by Frank McCoy)

http://vintagecomputer.net/cisc367/Microcomputer%20SCCS%20Interface%20September%20197 7%20A%20Comprehensive%20Memory%20Test%20for%20the% 208080.pdf

This looks cool ! I may try to OCR it or some sort of pdf to text.

I'll share whatever I come up with.