I have a NorthStar Horizon running Lifeboat CP/M. Everything works and the 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.
The code is trivial; I have source code for the ROM on the original 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.
John Crane wrote: > I have a NorthStar Horizon running Lifeboat CP/M. Everything works and the > 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.
> I have a NorthStar Horizon running Lifeboat CP/M. Everything works and the > 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
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
Sounds like it would require a bit more work to handle memory mapped I/O. The result would be a non-standard Horizon. Doable, but probably not worth the time right now. Thanks for the info!
-John
"Barry Watzman" <WatzmanNOS...@neo.rr.com> wrote in message
> The code is trivial; I have source code for the ROM on the original > 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.
> John Crane wrote: >> I have a NorthStar Horizon running Lifeboat CP/M. Everything works and >> the 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.
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.
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
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.
John Crane wrote: > Sounds like it would require a bit more work to handle memory mapped I/O. > The result would be a non-standard Horizon. Doable, but probably not worth > the time right now. Thanks for the info!
> -John
> "Barry Watzman" <WatzmanNOS...@neo.rr.com> wrote in message > news:he1ce5$ov0$1@news.eternal-september.org... >> The code is trivial; I have source code for the ROM on the original >> 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.
>> John Crane wrote: >>> I have a NorthStar Horizon running Lifeboat CP/M. Everything works and >>> the 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.
>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.
>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.
>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
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.
>> 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
>> 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.
>> 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
<WatzmanNOS...@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.
>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.
>John Crane wrote: >> Sounds like it would require a bit more work to handle memory mapped I/O. >> The result would be a non-standard Horizon. Doable, but probably not worth >> the time right now. Thanks for the info!
>> -John
>> "Barry Watzman" <WatzmanNOS...@neo.rr.com> wrote in message >> news:he1ce5$ov0$1@news.eternal-september.org... >>> The code is trivial; I have source code for the ROM on the original >>> 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.
>>> John Crane wrote: >>>> I have a NorthStar Horizon running Lifeboat CP/M. Everything works and >>>> the 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.
<WatzmanNOS...@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.
A Programmed PROM is used for I/O port decoding. This is different from 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.
Alli...@localhost.net wrote: > On Wed, 18 Nov 2009 22:49:16 -0500, Barry Watzman > <WatzmanNOS...@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
>> 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.
>> John Crane wrote: >>> Sounds like it would require a bit more work to handle memory mapped I/O. >>> The result would be a non-standard Horizon. Doable, but probably not worth >>> the time right now. Thanks for the info!
>>> -John
>>> "Barry Watzman" <WatzmanNOS...@neo.rr.com> wrote in message >>> news:he1ce5$ov0$1@news.eternal-september.org... >>>> The code is trivial; I have source code for the ROM on the original >>>> 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.
>>>> John Crane wrote: >>>>> I have a NorthStar Horizon running Lifeboat CP/M. Everything works and >>>>> the 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.
<WatzmanNOS...@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.
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.
John Crane <john_crane...@yahoo.com> wrote: > 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?
>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)
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.
> On Fri, 20 Nov 2009 17:49:51 -0600, "John Crane" > <john_crane...@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)
>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.
>>>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)
|
