2

Nascom computers had a wide range of software distributed in EPROM; as the Z80 didn't really have very good support for relocatable code, however, this means that each program is required to be installed at a particular location. As a choice of 0xD000 seemed to be particularly popular (likely because the built-in monitor has a shortcut for executing the program at this location) there are many conflicts in software at this address, particularly the NAS-DOS operating system, and a variety of programming languages (e.g. BLS Pascal, the predecessor of Turbo Pascal).

How did users of these computers handle software with conflicting addresses? I presume they didn't generally open up the system and swap multiple chips in and out (the system used 2716-type 2KiB EPROMs, so a program like BLS Pascal, which was roughly 16KiB, would have been distributed on 8 of them). Were there add-ons that made switching EPROMs easier? Or some other solution?

Improve this question
4
  • People did write relocatable code for the Z80. You had relative jumps (limited to 1 byte range) and you could do tricks like pushing a 16 bit register onto the stack and then returning.
    – mikado
    Oct 24, 2018 at 19:47
  • @mikado - yes, it's possible ... but is this something that was done? Also, I know that at least some of the Nascom software used jump tables so that it could easily be patched to run at new addresses, but don't know how widespread this practice was.
    – Jules
    Oct 24, 2018 at 19:52
  • I suppose another obvious technique was to write a "jump table" into a fixed location in RAM and make all the calls to ROM locations via that.
    – mikado
    Oct 24, 2018 at 20:01
  • You can implement manual bank switching by soldering ROMs piggy-pack onto each other and select between their /CS lines with a switch and a pullup resistor.
    – tofro
    Oct 24, 2018 at 21:23

2 Answers 2

Reset to default
2

As a choice of 0xD000 seemed to be particularly popular (likely because the built-in monitor has a shortcut for executing the program at this location)

AFAIR this was added in the second version of the NAS-SYS monitor, as a service for the parallel delivered new ZEAP editor/assembler (*1,2), not so much for general purpose (*3).

there are many conflicts in software at this address, particularly the NAS-DOS operating system, and a variety of programming languages (e.g. BLS Pascal, the predecessor of Turbo Pascal).

The conflict may not be as real as you may assume. Software isn't all the same, nor is its usage situation.

  • For one, people who bought a ROM based PASCAL system don't neccessary switch for a different one ur another language on a daily base - if at all. These decisions where usually long term. Nervous flipping between versions and even more so languages is a rather new issue (*4).

  • Especialy the conflict with DOS isn't one, as people adding Disk drives and DOS in ROM, of course switch for a more flexible, disk based software (*5). After all, why permanent wasting precious address space for a compiler that can as well be loaded into RAM - and removed after it done its task.

  • Last but not least, next to all ROM application software was also available on cassette (includng BLS Pascal), to be loaded into RAM (*6). With Pascal (or some extended BASIC) installed the situation was no diferent form any other system in the need to load an assembler from cassette to write some subroutine in all comfort (*7,8).

I'm prety sure, that many of the seamingly conflicts will vanish when thinking it from common usage szenarios of back then.

*1 - Conveniant named Z80 Editor-Assembler Package

*2 - The older version was made to work with the original NASBUG.

*3 - Similar J was reserved to start BASIC residing at E000h

*4 - Remember the computer/manufacturer and language wars? People were comited to their environment way more than today.

*5 - The ROM Pascal, like the BASIC, only supported cassette as storage - not realy useful with disks.

*6 - Thanks to Jules for reminding me about that.

*7 - Then again, instead of going thru all of this, one wrote it by hand and poked it from the HLL program later on.

*8 - Not to mentioned, that one of the claims of Pascal was to generate code good enough to not needing any Assembly modules :))

Improve this answer
2
  • I can certainly see that your second point is true. You wouldn't want to use software that will only store your work on tape after spending more money than the computer itself cost on a disk drive for it, but I'm less convinced about the first. Taking BLS Pascal as an example, it has a rather near system for integrating with functions and procedures written in assembly language ... But how would you use that when the most popular assembler was also located at the same address?
    – Jules
    Oct 25, 2018 at 8:07
  • @Jules I never claimed the points to be absolute, just explaining the majority. RL will always bring some installations with colliding requirements. Since Pascal is the main language the user decided, the amount of Assembly would be minor, wouldn't it? Loading one from cassette (same way one would run all other programs, including the ones compiled by the ROM Pascal) wouldn't be a big deal - like on a C64 without disk or any other similar machine. One of the interesting parts about the NASCOM is an unusual large number of available assemblers for a machine sold so little.
    – Raffzahn
    Oct 25, 2018 at 8:51
2

Actually, a lot of code was supplied on tape, sometimes with relocators etc. Also the Z80 is not bad at relocatable code. The NAS-SYS monitors helped this relocatability substantially by clever use of the Z80 RST instructions (these are essentially single byte 'calls' to low memory locations (RST 8, RST 10H, RST 18H etc). These were used in NAS-SYS to access most monitor utility functions (I/O etc) and also provided a 16-bit relative call feature (this allowed large programs to be completely relocatable if all calls used the Monitor RCAL restart). Most of the code I wrote at the time made use of this and could be loaded anywhere with no code changes. The RCAL restart was slower but took the same space as a regular call.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.