I know very little about N* machines, but if it uses a separate baud rater generator circuit (seprate that is to the serial chip -- and I seem to rememnber 8251s in there which always use a separate baud rate generator), then a useful trick is to connect a 'scope or frequency counter to the transmit and receive clock inputs on the serial chip. In most cases the buad tate is that freqeuncy/16. It's posisble to program some serial chiss for divide-by-64 (and other values have been used too), but most of hte time its divide-by-16. -tony

The MDS-AD3 is a Double Density controller - you will need single-sided boot disks (with N*DOS a double-sided disk should boot, but you won't be able to correctly access files which occupy sectors on the second side). I assume thats a 64k RAM card - if you put my monitor in the CPU card ROM socket, you will need to make sure that the corresponding area is disabled on the RAM card - You will already have a block disabled at the disk controller (E800-EBFF) and depending on the card, this may include a little "extra" (with my 64K card, 2K is the smaller deselectable chunk, so I have EC00-EFFF disabled as well). By "tries to boot" I assume you mean the drive select light comes on and the heads load (SA-400 has head-load) - To verify that it steps, manually move it out 1/2 way or so with the power off, then power it on - you should see it select and move to track-0. You won't without a boot disk. They are documented in the Horizon System Manual, a PDF of which is available in the "NorthStar Horizon" area of my site. No - the floppy controller has a very small ROM which knows how to seek to track zero, read one sector from the disk into RAM and a fixed location (2000) and jump to it. It does not even initialize, let alone "talk to" the serial console. Without a boot disk, your only option is to make use of the 1K ROM socket on the CPU card - it takes a 2708, but you can build an adapter to use a larger device if you don't have or can't program a 2708 - you can even use something like the Dallas battery-backed-up RAM chips (**) which make erase/program cycles very fast -keep in mind that you don't need it to look pretty - you only need it until you have a boot disk up and running, and you can put the CPU back a couple of slots to allow room for the adapter. (** if you go this route, know that the DS chips have a power-monitor which may not release until after the simple CPU reset circuit - so you may have to power- up and then issue a reset to get it to start properly). The console will probably be at 9600 (unless someone has changed it). Check the jumpers to be sure. As noted above, make sure you can deselect a suitable area of the memory map to make room for the monitor. Remove anything un-necessary when getting the monitor up and running - that means pull the FDC (and the 8" one if you haven't already) - since my monitor does not require RAM, you can pull the RAM card as well - so all you will have in the system at first is the CPU. Set the ROM address, and POJ (power-on-jump) headers to the address where you origned the code for the ROM (I provide a utility that will show you the correct settings for any given address). If the monitor does not "come up", and you have access to a scope, check out the ddress us while it is running - since it will be sitting in a very tight loop, you should see a recognizable pattern - several cycles within the ROM address space (only the lower few address lines should toggle) and one access to the UART I/O address. If that doesn't seem right, then you can use tricks like tying the ROM select to the wait line - it should halt at the startng address of the ROM. Also, with a storage scope and a little patience, you can capture the first few bus cycles - you should be able to see the power-on-jump address at the beginning. ... But this is getting beyond the scope of this reply. Once you see it's running it's polling loop, then you can track down the accesses to the UART to debug it at the hardware level if necessary. Once you get to the monitor '>' prompt, you are well on your way! Put the RAM card back in, and verfy that the monitor still runs (ie: you did de- select a block for it properly) - then use it to write and readback some locations where there should be RAM and confirm that it appears to be there and holds it's content. Then put the N*FDC back in and confirm that the monitor runs - from there, you can proceed to the documentation in my simulator/NST package which should give you enough information to create a boot disk (Assuming the FDC works - debugging that is another excercise). Dave -- dave09 (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Classic Computers: http://www.classiccmp.org/dunfield/