Interesting Horizon Issue
John Crane
wood is nice on the eyes too. However, it won't run the larger CP/M
programs (like Supercalc). The CP/M I'm running is a 48K version and I
suspect that's the problem. I've tried the usual MOVCPM business from 56K
to 50K, but no go. When I try the resultant OS, it locks up. A little
digging showed the boot ROM located way down at E800h. My guess is that's
what's blocking my use of a larger CP/M. Since 8080 code is
non-relocatable, I'd have to find some way to move that ROM somewhere up to
the Fxxxx region to get a bigger TPA. Anybody seen a CP/M utility to move
ROM code like that? Besides altering the code, I'm sure I'd have to tinker
with the controller card & CPU card to adjust the ROMs address and the CPUs
startup address to match. I've got a couple of ROM programmers lying
around, so that part is covered. Or, maybe I'm barking up the wrong tree on
this? Maybe there's some other inherent weirdness in the Horizion that I'm
overlooking.
-John
Barry Watzman
NorthStar single density controller. The problem is getting a new ROM
burned.
[Something in the back of my mind is nagging at me to the effect that
there are two ROMs that need to be changed, because the controller's
ports or something else was memory mapped, so it wasn't just the code
that was an issue).
"Back When", NorthStar actually offered alternate ROMs for just that
purpose, and I had such a set. My recollection is that the cost was
$35. That is of little use now, however.
Herbert Johnson
The Horizon is not particularly "weird". To work on computers of the
1970's, you have to put aside the notion that there is one "normal" or
"standard" way to do microcomputer things - there was not.
The NorthStar Horizon uses memory mapped I/O and so parts of upper
memory space are in use by ROM and hardware - serial ports, the floppy
controller. Review the available NorthStar Horizon hardware manuals,
to see what is in use at what MEMORY locations. That limits where you
can put your ROM, if you choose to reassemble it from source and
create a non-standard Horizon system. There is no "utility" to move
ROM code - how does it know from 8080 or Z80 binary, what's an address
to change, what's data to not change?
Also review the consequences of moving CP/M "up" in memory; that puts
the BIOS, which is above the CCP and BDOS, up in memory and again in
conflict with Horizon hardware. CP/M 1.4 or 2.2 manuals from DRI
discuss that stuff.
All this stuff is in the manuals, which are available online or from
individuals, and from me.
Herb Johnson
retrotechnology.com
don't use my "gmail" address, check my Web site.
Herbert R. Johnson, New Jersey USA
http://www.retrotechnology.com/ retro-technology home pages
-- S-100, CP/M history by "Dr. S-100"
-- other old tech in iron, glass, rock
domain mirror: retrotechnology.net
John Crane
The result would be a non-standard Horizon. Doable, but probably not worth
the time right now. Thanks for the info!
-John
"Barry Watzman" <Watzma...@neo.rr.com> wrote in message
news:he1ce5$ov0$1...@news.eternal-september.org...
John Crane
"Herbert Johnson" <herbrj...@gmail.com> wrote in message
news:b66357cd-5ce3-49bc...@j35g2000vbl.googlegroups.com...
The Horizon is not particularly "weird". To work on computers of the
1970's, you have to put aside the notion that there is one "normal" or
"standard" way to do microcomputer things - there was not.
--- Very true. I should have been more specific. I my opinion, memory
mapped I/O on a 6800/6502 is "standard". It's "Non-standard" on 8080/Z80.
And putting boot code in the Exxx range instead of Fxxx, thereby limiting
TPA is just plain weird engineering. I'd class that as more of a "specific
solution" than a "general purpose computer". Northstar limited their options
by choosing this scheme. But iirc, Northstar had their own DOS and didn't
see/care about the oncoming freight train that was CP/M, at least not
initially. They did, however, see the light at some point and made the
upgraded ROMs Barry wrote about.
The NorthStar Horizon uses memory mapped I/O and so parts of upper
memory space are in use by ROM and hardware - serial ports, the floppy
controller. Review the available NorthStar Horizon hardware manuals,
to see what is in use at what MEMORY locations. That limits where you
can put your ROM, if you choose to reassemble it from source and
create a non-standard Horizon system. There is no "utility" to move
ROM code - how does it know from 8080 or Z80 binary, what's an address
to change, what's data to not change?
--- I feel confident I could code an assembly program to read binary code
and alter all memory references, ferret out unexecutable sections of code -
mark them as data, etc. I just thought than in all the decades CP/M has
been around somebody would have got to it before me. Not re-inventing the
wheel and all that.
Also review the consequences of moving CP/M "up" in memory; that puts
the BIOS, which is above the CCP and BDOS, up in memory and again in
conflict with Horizon hardware. CP/M 1.4 or 2.2 manuals from DRI
discuss that stuff.
-- There's the rub. If I make the move, the machine won't really be a
*Horizon* anymore! Sure, I'd like to run bigger programs. But the
old-machine preservationist inside me tells me such a major change is a bad
idea. And it's all to easy to fire up one of the Osbornes or Kaypros in
storage.
Barry Watzman
There are THREE issues:
1. The code in the boot rom needs to be moved.
2. The I/O ports are memory mapped. THEY need to be moved
3. Having moved those, all of the software (e.g. NorthStar DOS,
NorthStar Basic, CP/M's BIOS) need to be modified to work with the moved
code and I/O ports.
Again, my recollection is (because I did it) that, "back when", for $35
NorthStar would sell you a new set of ROMs and, also, a new NorthStar
diskette with NS DOS and Basic. But good luck getting that today. And
my recollection is that the CP/M for the NorthStar did not include BIOS
source code.
All...@localhost.net
<john_c...@yahoo.com> wrote:
>
>"Herbert Johnson" <herbrj...@gmail.com> wrote in message
>news:b66357cd-5ce3-49bc...@j35g2000vbl.googlegroups.com...
>
>The Horizon is not particularly "weird". To work on computers of the
>1970's, you have to put aside the notion that there is one "normal" or
>"standard" way to do microcomputer things - there was not.
>
>
>--- Very true. I should have been more specific. I my opinion, memory
>mapped I/O on a 6800/6502 is "standard". It's "Non-standard" on 8080/Z80.
>And putting boot code in the Exxx range instead of Fxxx, thereby limiting
>TPA is just plain weird engineering. I'd class that as more of a "specific
>solution" than a "general purpose computer". Northstar limited their options
>by choosing this scheme. But iirc, Northstar had their own DOS and didn't
>see/care about the oncoming freight train that was CP/M, at least not
>initially. They did, however, see the light at some point and made the
>upgraded ROMs Barry wrote about.
>
>
>The NorthStar Horizon uses memory mapped I/O and so parts of upper
>memory space are in use by ROM and hardware - serial ports, the floppy
>controller. Review the available NorthStar Horizon hardware manuals,
The horizon does not use memory mapped IO for anything outside of the
DISK system. All the other IO is IOmapped.
Lifeboard CP/M depending on version used a large part of the NSDOS
disk driver code and it's large. In most system a 52k CP/M is
possible if movcpm works for the supplied version, some didn't. If
you have ram above the disk (disk subsystem obnly blocks 0xe800 to
0xefff) you can put the bios in the upper 4k and CCP and Bdos below it
but it requires hand patching the bios jump table to "leap over" the
FDC. I believe it was S100 Microsystems that described how to do this
and the result was a 56K cpm system.
Among the S100 systems fragmented address spaces was uncommon
but the usual cause was (Ep)rom and most cases it was as high as
possible to allow the greatest unbroken space. More often the rom was
shadowed or banked to allow a full unbroken 64K ram space.
The horizon there was no utility to move the rom code, as the rom code
also did the disk IO (rom was e800/E900 mirrored 256 bytes) and the
rest was (from EA00 to Ef00) was IO space to transfer data and
commands to the controller. If you moved the boot you also had to
burn a new decode rom and the result is easy to do (if you can find
the 256x4 AIM or fuse roms) but then all of the NS* software will not
work and requires a massive amount of work to alter it to work with
the new disk controller address.
Allison
Barry Watzman
address."
I have source code (CP/M .ASM) for both the ROM and a version (pretty
early) of the North Star DOS (it was obtained by disassembly, but it's
complete, reassembled exactly and was even commented). That makes that
part of it easier, just change the ORG statements and reassemble it. I
think that my source code is available on both Herb Johnson's site and
also on Howard Harte's site (since I do not have a web site of my own).
It won't help you with any other North Star software, however (e.g.
North Star Basic), or with the CP/M BIOS.
All...@localhost.net
<Watzma...@neo.rr.com> wrote:
>More of this is coming back to me.
>
>There are THREE issues:
>
>1. The code in the boot rom needs to be moved.
>2. The I/O ports are memory mapped. THEY need to be moved
>3. Having moved those, all of the software (e.g. NorthStar DOS,
>NorthStar Basic, CP/M's BIOS) need to be modified to work with the moved
>code and I/O ports.
Where does the IO ports being memory mapped come from? The serial
ports(both), parellel IO and the interrupt and heartbeat clock logic
all map into the first 8 bytes of IO space (0-7).
I have three Horizons and NONE have the IO memory mapped, the Floppy
controller is something else and that is memory mapped but they also
use the address bus to transfer data for that! And items 1 and 3 are
big time pains if one were to do it. I did and it was less than
useful being an odd NS* horizon.
Allison
All...@localhost.net
<Watzma...@neo.rr.com> wrote:
>Re: "but then all of the NS* software will not work and requires a
>massive amount of work to alter it to work with the new disk controller
>address."
>
>I have source code (CP/M .ASM) for both the ROM and a version (pretty
>early) of the North Star DOS (it was obtained by disassembly, but it's
>complete, reassembled exactly and was even commented). That makes that
>part of it easier, just change the ORG statements and reassemble it. I
>think that my source code is available on both Herb Johnson's site and
>also on Howard Harte's site (since I do not have a web site of my own).
> It won't help you with any other North Star software, however (e.g.
>North Star Basic), or with the CP/M BIOS.
>
I have the sources, didn't back then (1980) and it was a big time
Zresource project.
After doing that and realizing it was interesting but less than useful
I put up a new FDC (IO mapped) and and it was also double density
with both 8 and 5.25" capability as space was more of an issue.
I still keep two of the Horizons stock one is single density and the
other double. The third one has a lot of non-NS* boards and is
one of my day to day machines.
Allison
Barry Watzman
the firmware PROM.
Note, I'm not familiar with the Horizon or Advantage, but am talking
here only about the NorthStar MDS disk controller (which was sold
separately and also used by these systems). Someone else said, and I
think it was correct, that only the disk controller uses memory mapped
I/O; everything else is conventionally I/O port mapped. I believe, but
do not absolutely know, that this is correct.
All...@localhost.net
<Watzma...@neo.rr.com> wrote:
> the Floppy
>> controller is something else and that is memory mapped
I said it twice.
Also the title is interesting Horizon issue. Not a more specific
NS* MDS issue.
I am very familiar with the MDS board as mine was purchased soon after
it was available as a disk upgrade to my then aging MITS Altair 8800.
It was a few months later I retired the Altair for the far better NS*
Horizon Box and a NS* Z80 card. I also put a NS* MDS in a Netronics
Explorer 8085 that I still have. Now I have at least 5 spare boards
and at elast one of every generation both single and double density
flavors.
Allison
John Crane
But why did they put the ROM @ E800h ? It apparently doesn't extend to
FFFFh, so it leaves a "bald spot" in RAM. What were they thinking? Could
they be economizing by reusing the existing MDS "generic" product; and just
slapped one in their new product - the Horizon? I'm assuming the E800h
address was maybe to leave space for users EPROMs in the Fxxxh range - a
very common thing for Altair users with sore fingertips. This would be
useful for the "generic" S-100 user upgrading an existing front panel
machine, but of no value for a system like the Horizon.
Reminds me of the Sol-20 weirdness...
-John
<All...@localhost.net> wrote in message
news:rm7eg5de8j1ti7eij...@4ax.com...
glen herrmannsfeldt
> But why did they put the ROM @ E800h ? It apparently doesn't extend to
> FFFFh, so it leaves a "bald spot" in RAM. What were they thinking?
Maybe "no one needs more than 58K."
(Sounds like a famous Bill Gates saying.)
-- glen
All...@localhost.net
<john_c...@yahoo.com> wrote:
>OK, got it.
>
>But why did they put the ROM @ E800h ? It apparently doesn't extend to
>FFFFh, so it leaves a "bald spot" in RAM. What were they thinking? Could
Rom is E800/E900 for 512 or 256 bytes. The DD board is e800/512byte
rom and the single density is E800 with a mirror at E900 and is only
256 bytes. That covers rom..
Starting at EAxx and EBxx those are really "commands" to the memory
mapped disk controller. They controll things like Read, Write,
Status, Write Sync , read sync. The re are hole and morrors in the
address range to EFFF.
Memory starting at F000 to FFFF is available for use.
>they be economizing by reusing the existing MDS "generic" product; and just
>slapped one in their new product - the Horizon? I'm assuming the E800h
>address was maybe to leave space for users EPROMs in the Fxxxh range - a
>very common thing for Altair users with sore fingertips. This would be
>useful for the "generic" S-100 user upgrading an existing front panel
>machine, but of no value for a system like the Horizon.
Th MDS preceeded the Horizon. And yes many systems that didnt' shadow
rom put it up at Fxxx range. An example of a machine like that was
the Netronics Explorer 8085 with Rom at F000 (2Kbytes) and ram at F800
(256bytes)
Allison
John Crane
Not to change the subject, but it's nice to see a fellow Netronics fan out
there. I've got an ELF II with RPN BASIC in ROM and the nice metal cases.
I built it in high school and refurbished it 3 years ago. Works great! I
still wish the 1802 had a better way to handle subroutines, though. Sheesh!
SCRT was a joke.
Back in the day, I was seriously considering upgrading to the more
mainstream Explorer 85. But college was looming on the horizon and I
needed something that travelled well. Hence, my Osborne 1.
-J
<All...@localhost.net> wrote in message
news:bg4jg559e3a64k84l...@4ax.com...
All...@localhost.net
<john_c...@yahoo.com> wrote:
>Allison,
>
>Not to change the subject, but it's nice to see a fellow Netronics fan out
>there. I've got an ELF II with RPN BASIC in ROM and the nice metal cases.
>I built it in high school and refurbished it 3 years ago. Works great! I
>still wish the 1802 had a better way to handle subroutines, though. Sheesh!
>SCRT was a joke.
As an 1802 user (never had a commercial machine but built mroe than a
few 1802 based systems) I really like that CPU.
In some ways I'd agree. However I'd point out that when you understand
that a simple machine with simple instruction set (risc like) requires
one to trade coding for somple hardware. PDP-8 also forces
programmers to appreciate what can be hardware but can easily be
code instead.
Actually SCRT looks horrid and reserves registers but execution wise
there are features that are hard to duplicate with other cpus.
What was lacking was a good macro assembler to hide it as coding
and just make it a macro.
The 1805 made that a hardware instruction.
>Back in the day, I was seriously considering upgrading to the more
>mainstream Explorer 85. But college was looming on the horizon and I
>needed something that travelled well. Hence, my Osborne 1.
I bought the Explorer 8085 to debug a Horizon barely 6months okld that
took a lightiing hit. The front panel Altair was largely useless for
that. I still have that. And the NS* was revived and it's still
working to this day.
Allison