• Please review our updated Terms and Rules here

Northstar NST utility & ASM80

litterbox99

Experienced Member
Joined
Aug 8, 2010
Messages
103
I recently bought another Imsai with a Northstar like Disk Controller
and a pair of Shugart 400's. I have been unable to boot from any
of the disks that came with the unit. In an attempt to create my
own disks I came across Dave Dunfields NST utility.

My first step is to create the Monitor Rom, as supplied, to help simplify
things. I have never used an assembler before, but I'll give it a try.

I created the HDM80.HEX (Intel format) file so I can burn it into an
EPROM, however it looks like the hex file contains more than I need
for my programmer.

Is there a command line switch that just allows output of the hex data
with out the extra information ? Or will I have to parse it myself ?

:20F800003E03D303D3033E77D3033E4ED3033E37D3033118F8C330F92E3EDB03E601CA1A81
<snip>
:02F9E00048F9E4
:00000001FF <-not sure about this


To me it looks like :20F80000 could be removed, I know F800 is the addy but
I don't know what the extra two zeros are for, as well as the :20 at the beginning
of the string. Also, may I assume the last two chars of the string are the checksum ?

I don't understand what the last line is either :00000001FF.

For now I'd like to get the monitor Rom up and running and
sort the rest out later.

Thanks

Todd


 
Here is a link to the Intel Hex Format.

http://pages.interlog.com/~speff/usefulinfo/Hexfrmt.pdf

I have used Dunfield's NST (disk image transfer) software and his NSI (image file creation/alteration) program quite a bit. His latest version of the NST software has two options. One option allows you to upload the I/O stub to a micro with a working Northstar DOS system by using the Northstar Monitor program on the Northstar DOS system. He also has an option to upload the I/O stub software containing a minimum Northstar DOS system to a micro which does not have a working DOS. NST will talk to either single or double density controllers, but you need to know which you have.

Both options assume that your disk controller and floppy drive(s) are working, and unless they are, NST won't be of much use. Have you been able to determine if your controller and floppy drive is loading anything to $2000 - $29FF? Since you have a front panel which will allow you to display memory you should be able to see if anything gets loaded there. Try a disk marked "DOS" and see if a jump to $E900 will trigger floppy drive 1 to try to load DOS from the disk. If the disks are not readable, I can probably help -- but if the hardware is not working, I won't be of much help.
 
I'll take a look at the Intel Hex Format PDF, I did review some of my other
Eprom files in Intel format and I am starting to understand....

After powering up the Imsai, I deposited a bunch of 0's starting @ $2000
to clear the RAM, then I booted from disks labeled DOS, nothing is being wrote
to the $2000 range :-(

On non DOS disks, while attempting to boot, I can monitor a pulse stream
with my logic probe on the 'read data' line of the floppy drive, but what
happens when it gets to the controller... who knows. This tells me the
drive is reading something from the disks.

Since I know nothing about the controller (Micro Applications P/N 2100) and
have found no doc's, I'm in the dark. I did score a Northstar MDC-A4 controller
from ebay (untested of course) that should arrive sometime this week.

For now, I'll keep playing with the Rom monitor.

So much fun working with unknown hardware !
 
Ok, well it looks like I do not have to parse or truncate the
hex file created by ASM80 as I thought in my first post.
All the info in the hex file is needed for the Intel format.

I just didn't understand...
 
Had some minor success tonight :)

I was able to create Dave Dunfield's bootstrap
ROM Monitor and it works !

Whoopee ;-)
 
I have had major success today :)

Due to a recent ebay purchase, item # 220681462950
I was able to take a closer look at my drives. The drive I
assumed working, was actually the worst drive...

Using this device I was able to step up/down the read head,
engage the drive motor and check drive speed. If I had the
very hard to come by alignment disks, I could have done more.

I had a stepper issue with one drive, so I went on to the next.
After some cleaning of the rails and adjusting the speed, I can
now boot on half the disks.... the others I can list the files.

I was in N* DOS ! using a old tecra 730xcd laptop running
procomm 4DOS. The ver of DOS is very simple to what I am used
to, but I did load basic and run star trek, I just can't remember how to
play lol.

Very Cool, I can't say how happy I am :)
 
Last edited:
I have had major success today :)

{snip}

I was in N* DOS ! using a old tecra 730xcd laptop running
procomm 4DOS. The ver of DOS is very simple to what I am used
to, but I did load basic and run star trek, I just can't remember how to
play lol.

Very Cool, I can't say how happy I am :)

Congratulations -- you have come a long way since you acquired this machine.

Yes, N* DOS was primitive, but for some operations that could be an advantage. The Northstar Monitor program, which you should find on one of the DOS diskettes, can be used for further investigation and alteration of your system. It will have a name like Mxxxx, where xxxx is the load address. Let me know if you need docs on this.

Which disk controller card are you using? What version of North Star DOS did you find on your diskettes?
 
I'm using the N* controller MDC-A4. The DOS disks are ver 4.2,
one disk had a ver STDOS 4.1.

I am experiencing stability issues...It was rock solid last night.

Sometimes it won't boot from the floppy, so I don't know if
it's a bad floppy cable or an issue with procomm flaking out
on Win98. I have heard of broken com ports in windows. I
may boot from a floppy with Dos 6.22 and see what happens.

Also,

The memory board at $2000 - $3FFF flakes out. I'll try swapping
that board out later, but now I'm frustrated, so I'll walk away for
tonight.

One step forward, two steps back ;-)
 
another update !

It's been stable tonight, so I have been loading
and running some basic games I found on a disk.

Some run and some don't... Very basic at most, but
entertaining.

I need to learn about file types and load addy. I'm just
poking around for now, but I need to learn this ver of dos/basic.
 
I need to learn about file types and load addy. I'm just
poking around for now, but I need to learn this ver of dos/basic.

File type 0 = undefined (default) -- used for files (such as DOS itself) which are not loaded or processed by DOS programs
----- (DOS is loaded by the bootstrap loader in ROM) It must be located at disk address 4 (track 0 sector 4)
File type 1 = binary program file -- requires a hex address in the catalog entry to specify its load address
File type 2 = Basic program file -- contains a Basic program represented as tokens -- saved/loaded by N* Basic interpreter
File type 3 = Basic data file -- file created/opened/closed/read/written by Basic program -- format defined in Basic program
----- other file types were used by various programs, or could be defined by the user
----- on double density systems, bit 7 of the file type byte in the catalog entry was set to indicate a double density file

Note: it was common practice to define a type 0 file located at disk address 0 with a length equal to 4 sectors and with a name ending with a colon -- for example UTILITY: -- this file "overlays" the disk catalog sectors, and was used as a "Volume Header" in today's terminology. This was the first file defined after initializing the diskette, and you never wrote anything to it. It just served to identify the disk contents.

DOS is located at $2000 to $29FF on single density systems, and at $2000 to $2CFF on double density systems.

The load address of a program file was usually $2A00 on single density DOS systems, and $2D00 for programs on double density DOS systems. "Special" programs, such as debuggers, might be loaded in low memory, at $1000 for example (if you had memory located there), or at the top of memory (just below your disk controller firmware and/or video card memory). This was system dependant.

If you don't have N* DOS documentation, get back to me.
 
Last edited:
Back
Top