• Please review our updated Terms and Rules here

Running TRSDOS on Z180 & eZ80

danielbooneamerica

Experienced Member
Joined
Mar 3, 2020
Messages
407
Location
Wayne National Forest
Regarding my efforts to execute TRSDOS SYS1-13 on newer hardware.

update......it works on eZ80 now.

I refer to my project as TRS-OS.

Booted TRS-OS using eZ80 @ 50mhz no wait states.

Using memdisk drives and 50 MHz clock it's screaming fast.

Testing out things that will and will not work without patch modification.

when you issue dir or device command it is done before you can blink.

It took a new BIOS and LOWCORE but it works.

I also want to create a version for the slower Z180.

One of the great things is......both these chips have so many built in controllers and peripherals that very little is needed to support the CPU. These CPUs fall into SOC (system on a chip).

After all these years of work I almost fell out of chair 1st time I typed DIR and it worked.
 
Congrats. Sounds fun.

How much chance is there of random TRS-DOS applications running on such a platform? Don't most of them rely on a memory mapped TRS-80 display? (I don't know much about TRS-DOS). How was the transition from 64x16 to 80x24 done?
 
Congrats. Sounds fun.

How much chance is there of random TRS-DOS applications running on such a platform? Don't most of them rely on a memory mapped TRS-80 display? (I don't know much about TRS-DOS). How was the transition from 64x16 to 80x24 done?
I guess I should have clarified by stating TRSDOS 6 sys1-13 but then again, I dont think LDOS 5 has sys1-13.

TRSDOS 6 so 80x24 display not 64x16.

Yes 1920 bytes video RAM to hold screen. I currently communicate with model using a terminal.

Not sure what is meant by 'random applications' but properly written applications for TRSDOS 6 work. Some screens fly by so fast delay loops dont even come close.

Anyone have a list of applications already known to run on model 2, 4 & 12?

Model 3 is not an animal I am interested in tackling.
 
Last edited:
Not sure what is meant by 'random applications' but properly written applications for TRSDOS 6 work.
As I said, I don't know enough about TRSDOS. I'm not familiar with it on a low level at all. On, say, a CP/M system, most of the CP/M software used the BIOS to do things like print to the screen, etc.

I didn't know how many TRS programs used the same facility vs leveraging the fact that they "knew" they had a memory mapped display terminal.

Similarly, how did programs that were used on a 64x16 original Model 1/3 series adapt to an 80x24 screen, again, assuming that they were using the video memory directly rather than whatever BIOS structure TRSDOS presents.

I assume that BASIC leveraged the BIOS to read the keyboard and write the screen, and that the BIOS had a LOCATE primitive for cursor positioning, but how many BASIC games, for example, PEEK/POKEd the screen memory directly.

I mean, maybe your system has the video memory and all that working already. This sounds like, at a glance, TRSDOS working on a non-TRS-80 Machine, or are you just trying to plug in a different CPU in to a TRS-80 system?
 
CP/M is not a fair comparison. CP/M is not a real OS but a collection of subroutines.

TRSDOS is an advanced OS using overlays and BIOS that promoted and encouraged writing portable code that would work across several hardware platforms.

I don't have any information how to convert from lower screen sizes to larger.

TRSDOS 6 supported 24x80 so that is all I had to concentrate on.

As a programmer I don't see an issue with adapting screens but I didn't need deal with that issue.

Under TRSDOS 6 BASIC would not be able to peek/poke video even on a real model 4.

I think TRSDOS is far more advanced than what you are thinking. CP/M is not a comparison.
 
As a programmer you can see where designers of TRSDOS was influenced by OS of the day, UNIX.

BY OS of the day I mean computer science students of that time were studying UNIX as a new alternative to IBM OSs that normally dominated universities. I have realtime experience in this part of living the dream.

Randy Cook envisioned a OS for microprocessors that was similar and had no absolutes but everything was virtual.

He did not make that dream come true during his time at RS but Roy Soltoff did make this dream come true.

Roy had to manage best be could for models 1/3 trying to maintain backwards compatibility but model 4 TRSDOS 6 was pretty much a clean drawing board..... almost.

Never call any subroutine or OS function directly....there is a API to do this.
 
I no longer think of drives....I now think of them as VOLUMES. This enables forward future thinking when it comes to how we look at where are files reside. Like in days of physical drives, files must reside somewhere but 'drives' are history.

But that does not mean drives do not exist as virtual devices. Virtual can be done one of 2 ways. Simulate or emulate. Either way is done using hardware, software or both.

TRSDOS was designed and does exist on more than just RS hardware (just not called TRSDOS). I do not know a lot about this, but I understand Soltoff supported another hardware manufacture of Z80 systems back in the day. Same OS but different machine.

PC had some good ideas and I have tried to roll some of those into this project.

> Remember starting in safe mode?
> Windows provides update facility to update system with system updates.
> BIOS setting date/time on clock.
> BIOS maintains tables mapping storage.

OK so using some of these ideas, as it stands now my TRS-OS startup screen looks like this.

+-----------------------------------------------+
| |
| Date:00/00/00 Time:00:00:00 |
| |
| Boot volume:DiskDISK |
| Kernel: TRS-OS 7.0.0 |
| Serial #172839465 |
| |
| Auto command: n |
| SYSGEN: n |
| BREAK enabled: y |
| |
| 1. <NORMAL> Start OS normally. |
| 2. <UPDATE> Run system updates. |
| 3. <SAFE> Prompt sysgen auto debug etc. |
| 4. <BIOS> Edit volume tables etc. |
| 5. <RTC> Management tables for VOLUMES|
| 6. <POST> Run self tests. |
| 7. <DEBUG> Start debugger. |
| 8. |
| 9. |
| |
+-------------------------------------------------+
Function desired? 1

Starting-background-multitasking.
Executing_initialization_chain....finished.
IPL complete.

Auto_command:>_
No_AUTO_command
TRSDOS Ready

I copied above boot screen directly from terminal. Some formatting was lost posting here but it gives idea what things look like as of now.

Starting normal as in above example would then load a sysgen if is exists then executes any auto command.

Safe mode prompts if you want to load sysgen if it exists, run auto exec command or start debug.

This BIOS boot screen provides facilities for setting clock or running some POST tests I wrote.

Lastly. eZ80 has 16MB of RAM. This BIOS maintains sets of tables that describe storage above FFFFh. Starting at 10000h-FFFFFF tables describe how this storage is divided into partitions.

Here TRSDOS drives exist as FLASH or RAM VOLUMES. In above boot example, a DiskDisk file created using Misosys DISKDISK program, is used as boot volume.

These tables describe among other things, where volumes exist in storage and their size etc. DISKDISK files can then be loaded into these volume partitions.

In above example it contained a copy of 180k TRSDOS 6 boot diskette.

On this VOLUME, SYS0 is ignored.

During new IPL process that make hardware ready to execute sys1-13, TRSDOS drive code tables (DCT$) is loaded with new DCT$'s mapping drives to VOLUMES.

New drivers to make FLASH and RAM appear as TRSDOS drives was written for TRSDOS and work like lightning.

I dont know why the 'little face' is in IPL screen, it converted something to that when posting on web.

Its been fun.
 
Last edited:
You can use [CODE] .. [/CODE] tags to preserve the formatting.

I think I've reconstructed what you posted; a shame not to see it in its full glory.

Incidentally, it was :D which became the smilely face.
Code:
+-----------------------------------------------+
|                                               |
| Date:00/00/00 Time:00:00:00                   |
|                                               |
| Boot volume:DiskDISK                          |
| Kernel: TRS-OS 7.0.0                          |
| Serial #172839465                             |
|                                               |
| Auto command: n                               |
| SYSGEN: n                                     |
| BREAK enabled: y                              |
|                                               |
| 1. <NORMAL> Start OS normally.                |
| 2. <UPDATE> Run system updates.               |
| 3. <SAFE> Prompt sysgen auto debug etc.       |
| 4. <BIOS> Edit volume tables etc.             |
| 5. <RTC> Management tables for VOLUMES        |
| 6. <POST> Run self tests.                     |
| 7. <DEBUG> Start debugger.                    |
| 8.                                            |
| 9.                                            |
|                                               |
+-----------------------------------------------+
Function desired? 1

Starting-background-multitasking.
Executing_initialization_chain....finished.
IPL complete.

Auto_command:>_
No_AUTO_command
TRSDOS Ready
 
mean, maybe your system has the video memory and all that working already. This sounds like, at a glance, TRSDOS working on a non-TRS-80 Machine, or are you just trying to plug in a different CPU in to a TRS-80 system?

I guess it's pretty much been said but to put it succinctly, TRSDOS 6.0, and the TRS-80 Model 4's "native" mode, is pretty much related to Model I/III TRSDOS (and the Model I/III hardware model itself) in name only. (You can think of the situation as being broadly similar to the compatibility, or near lack of it, between the "consumer" TRS-80s and TRSDOS on the separate Model II/12 line. ) There's very little direct software compatibility; LDOS 5.x for the I/III shares a lot of similar concepts and implements some similar OS-level APIs with TRSDOS 6.x so in theory at least you can write a piece of software which compiles to run on either platform without a ton of special case-ing, but generally speaking if you wanted to run "existing" software on your new Model 4 you did it by booting a Model III DOS on it. (Which reconfigured the hardware to emulate a Model III in pretty much all respects.)

(There were some less-than-successful attempts to create "hybrid" OSes that essentially ran in Model III mode but enabled features like the 80x24 screen; I'm pretty sure there were versions of MultiDOS and maybe DOSplus that tried this, but don't quote me on that?, but outside of BASIC these would only run software patched to understand the changes.)

Anyway, Model 4 software was *supposed* to use the OS APIs instead of direct hardware access, so well behaved software should in theory run on almost any Z-80-adjacent machine if you port the OS to it and the memory map isn't fundamentally incompatible. (So far as I'm aware you could probably make it go on most later CP/M-capable Z-80 machines that have a linear 64K memory map and bank-switched or otherwise not-conflicting video/terminal handling, but there's probably a little more than that. Programs that rely on memory bank switching for more than 64k will have further requirements I'm sure.) There are exceptions to this "well behaved" rule, but it's not like the I/III, where probably the vast majority of software would count as "Ill-behaved" in the "relies on banging on the hardware directly" sense.
 
You can use [CODE] .. [/CODE] tags to preserve the formatting.

I think I've reconstructed what you posted; a shame not to see it in its full glory.

Incidentally, it was :D which became the smilely face.
Code:
+-----------------------------------------------+
|                                               |
| Date:00/00/00 Time:00:00:00                   |
|                                               |
| Boot volume:DiskDISK                          |
| Kernel: TRS-OS 7.0.0                          |
| Serial #172839465                             |
|                                               |
| Auto command: n                               |
| SYSGEN: n                                     |
| BREAK enabled: y                              |
|                                               |
| 1. <NORMAL> Start OS normally.                |
| 2. <UPDATE> Run system updates.               |
| 3. <SAFE> Prompt sysgen auto debug etc.       |
| 4. <BIOS> Edit volume tables etc.             |
| 5. <RTC> Management tables for VOLUMES        |
| 6. <POST> Run self tests.                     |
| 7. <DEBUG> Start debugger.                    |
| 8.                                            |
| 9.                                            |
|                                               |
+-----------------------------------------------+
Function desired? 1

Starting-background-multitasking.
Executing_initialization_chain....finished.
IPL complete.

Auto_command:>_
No_AUTO_command
TRSDOS Ready
Hey, thanks for the fix and yes it looks great.

I want in future to make a load format module of this project available to those wanting to try it out on an eZ80.

One reason eZ80 & Z180 is so attractive is that as a programmer, I know what peripherals and their addresses are on every platform. SBCs based on Z80 can have serial ports, counters etc but each platform will be different from another unless some standard is followed.

This means when I get a Z180 version running it will actually run on a model 4 with Z180 accelerator card.

However, before I can proceed with allowing others to run this, I must come up with a policy to honor everybody copyrights.

If anyone ever looked at LOWCORE you would notice some very intense code for handling TRS80 file system. It is something that evolved over the years into a very tight solid piece of software.

I have reached out a couple of times to copyright holder(s) for permission to reuse some old code and how to properly handle this. I never received any reply leading me to believe there is no interest.

I do not feel right unless some proper notice is worked up and explored. There are ways around this as most anyone wanting to run this project already has a copy of TRSDOS containing this code.

In a telephonic conversation with Bill @ LSI one time (about 1986) he told me any future versions should replace current directory system with perhaps a multi-level directory.

I have given some thoughts to this but not made a decision yet. If current file system were to be disjointed from this OS and replaced with another it would finally fulfill come of Randy Cooks visions.

BTW...outside of memdisk there are almost no applications that use bank memory on a TRS80, some but I can only think of a couple. Memdisk is a great use of banks.

I stated in past I read somewhere on web someone was saying just ignore TRSDOS API and call things directly in memory. This is worst TRS80 advice I have read on web yet. This is a disaster under TRSDOS for several reasons.....code portability is least of your worries.

In THE SOURCE you will see OS code make calls to OS subroutines but that is different. Until you understand why and what differences are, you better steer clear of any advice like this. Far far away ;-)

Model 3 is different and not really related to this project. It is true that a lot of code in TRSDOS 6 API was code brought over from LDOS 5.x (I wasnt there but Timm Mann website makes a statement like this, and he was there ;-)

There is no reason to think if Tandy would have built a model 5 that there would have been backwards compatibility with models 1 or even 3.

Same source is used to produce TRSDOS for 2, 12 & 16 so it's fairly compatible.

Also, I read one time that Randy Cook would intentionally change locations and addresses of subroutines and functions to intentionally keep developers from calling routines directly but rather encouraged use of a API to access system functions.

If anyone were to study 6.2 vs 6.3 you will find some things moved.
 
Last edited:
There is no reason to think if Tandy would have built a model 5 that there would have been backwards compatibility with models 1 or even 3.

This article which sums up some of the rumors for the never-got-very-far-in-development Model 5 says Model III backwards compatibility would have been retained, with a soft-loaded ROM mechanism as used in the 4P. Of course that's by no means authoritative, but frankly, I can't imagine a "Model 5" without classic TRS-80 compatibility being a particularly viable product. The vast majority of the TRS-80's home, educational and game software library was written for the older machines, abandoning backwards compatibility would have meant dumping one of the few selling points a "new" Z80-related computer would have had in 1985+.

(It basically would have been like Apple trying to sell the Apple IIgs, circa 1986, if the only Apple II-family software it could run was 80-column ProDOS software, anything that required DOS 3.3, 40 column video modes, etc, IE, Apple II+ compatibility, was verboten. Kind of think that would have been a hard sell.)

More importantly, of course, any real "Model 5" would have used the Z800, or possibly some Z180-style chip, which wouldn't have the same issues with backwards compatibility as the eZ80, so there wouldn't have been any problem with retaining Model III mode. The costs of including it are trivial, especially if you implement it 4P-style so you eliminate the need for a physical ROM. You just need a few gates to switch the memory map and a programmable video chip, both of which any real Model 5 certainly would have had. Maybe if Tandy *had* built the "Model 5" and it had miraculously lasted into the 1990's or later Model III mode would have eventually died out in some successor model, but no way it would have not been on the feature list in the 1980's.
 
world is a complex place with lots of opinions. It dont seem opinions of that era felt there would be much interest in late 70s mono games and software.

At that time people paid 5 times the price just to play same game avail in mono, in new color.

I dont see a model 1 or 3 library as much of a selling point of that time. People were dropping that fast. Software they developed for schools was only thing hanging in there on TRS80 but their MSDOS machines were trying to replace schools trs80 as fast as possible.

A model 5 would probable been for smart terminals or small (very small) business model. Tandy had developed a large library of small business software written in COBOL that was perfect for small businesses not needing larger multiuser systems. I doubt for kids playing games at home. Model 3 business software was pretty well outdated with newer model 4 business software.

Even in link you provided it says 'detachable' keyboard. This would not be a model 3 memory mapped scanned keyboard.

Making a Z800 switch memory mapped i/o and roms in and out would have been no small task. It has a far more complex bus system and would have required very complex circuits to switch all these modes. Yes it could be built to have memory and I/O models etc, keyboard controllers that did all these modes and a new mode for hopefully a more advanced keyboard etc but again everything is about costs.

A model 1 mode with speeds matching, then a model 3 matching mode and then model 4 in addition to some new model 5 mode? It would have all been about costs. Maybe it would have ran model 1 software, maybe not. They were going to slow a Z800 to 2mhz? If not little of that software would run.

If you read about Z800 and develop with it, you will note that just matching clock speed would not do it. It would be very complex getting model 1 or 3 software to run correctly without patches and that would be a huge undertaking for old mono software people of that time had lost interest in.

Tandy was rapidly trying to replace their school systems with MSDOS.

Model 4 showed they were moving away from all this memory mapped stuff anyway; address space is for RAM and RAM is for programs.

But, again, this project has nothing to do with models 1/3.

Using TRSDOS in embedded projects would not have any compatibility with models prior to model 4 and really not much to do with model 4, except, that is where I started.
 
Last edited:
Even in link you provided it says 'detachable' keyboard. This would not be a model 3 memory mapped scanned keyboard.

The 4P has a keyboard connected by a cable and is still just a dumb matrix, if you wanted it "detachable" you could certainly put a plug on it. But even lacking that it would have been relatively trivial to emulate the memory mapped keyboard. Presumably a "Model 5" would have used gate array/ASICs to shrink the part count, and even with discrete parts you can fake the memory mapped keyboard of a I/III using a matrix switch IC updated by your keyboard controller.
Making a Z800 switch memory mapped i/o and roms in and out would have been no small task. It has a far more complex bus system and would have required very complex circuits to switch all these modes.

How would this make the bus more complex? The Z800 did fail in part because it was "clumsy" to use compared to the Z80 because of the required demultiplexing, but so does the 8088/8086; presumably the same solution would have been used, which is just slap the demultiplexing logic in front of the CPU and present a "clean" bus to all the peripherals anyway. There's nothing about the actual mode switching that would have to be more complex than how the Model 4 does it, which is literally just jam a couple bits into the correct I/O ports. (Which of course trigger latches that switch between a couple different setting in the memory decoder and video circuits. A single GAL can handle this job.) If a Z180/HD64180 derivative had been used instead then even the multiplexing issue goes away.

(And unlike the eZ80 the Z180 can have its internal I/O moved to at least mostly non-conflict with the Model I/III with a single configuration command, so there wouldn't be any need to remap external I/O at all.)

A model 5 would probable been for smart terminals or small (very small) business model.

Which puts the whole thing in the proper perspective; by the time the Model 5 could/would have existed an 8088-based PC was selling for the same price or less and avoids this whole mess.

Really I think what Tandy probably should have done is whip up a Z80 card to plug into a Tandy 1000 and run TRS-80 software. It still surprises me this didn't exist, it would have been pretty trivial.
 
For all
The 4P has a keyboard connected by a cable and is still just a dumb matrix, if you wanted it "detachable" you could certainly put a plug on it. But even lacking that it would have been relatively trivial to emulate the memory mapped keyboard. Presumably a "Model 5" would have used gate array/ASICs to shrink the part count, and even with discrete parts you can fake the memory mapped keyboard of a I/III using a matrix switch IC updated by your keyboard controller.


How would this make the bus more complex? The Z800 did fail in part because it was "clumsy" to use compared to the Z80 because of the required demultiplexing, but so does the 8088/8086; presumably the same solution would have been used, which is just slap the demultiplexing logic in front of the CPU and present a "clean" bus to all the peripherals anyway. There's nothing about the actual mode switching that would have to be more complex than how the Model 4 does it, which is literally just jam a couple bits into the correct I/O ports. (Which of course trigger latches that switch between a couple different setting in the memory decoder and video circuits. A single GAL can handle this job.) If a Z180/HD64180 derivative had been used instead then even the multiplexing issue goes away.

(And unlike the eZ80 the Z180 can have its internal I/O moved to at least mostly non-conflict with the Model I/III with a single configuration command, so there wouldn't be any need to remap external I/O at all.)



Which puts the whole thing in the proper perspective; by the time the Model 5 could/would have existed an 8088-based PC was selling for the same price or less and avoids this whole mess.

Really I think what Tandy probably should have done is whip up a Z80 card to plug into a Tandy 1000 and run TRS-80 software. It still surprises me this didn't exist, it would have been pretty trivial.


I think what is meant by 'detachable', is like a PC...keyboard not physically attached to PC except by cable. Being able to unplug was needed also.

But if all these things are simple, trivial and no problem; it was never done.

I wish someone would, if they did, I would be happy to make a version for their project.

To my knowledge I am only person to actually create a system that executes TRSDOS, that actually works other than original authors. Again, TRSDOS has no knowledge of i/o addresses. My system executes sys1-13 without being recompiled. That is because OS has no knowledge of i/o system. There is a few exceptions.

And yes, I have made bank memory on this eZ80 project (32k banks) with no additional hardware other than CPU itself.

In the 2 decades I have worked on this I have come across graveyards of abandoned projects, but none were ever finished. Everyone would start out going to build a board with features and backwards compatibility you mention above but projects never went very far, mostly just talk.

I feel like I have invested thousands of hours and had to solve a million technical problems to get this running.

Again, a new system has no need of using same I/O ports or addresses of older models (unless again your project wants to support 1/3). Read Roy Soltoff programmers guide to TRSDOS. Never ever ever us an absolute address. Not in i/o or memory.

Tandy would probably gone with an emulator under MSDOS for 1/3. That was popular at that time. I knew a company that even made an emulator for MICRODATA 1620 to run under MSDOS during that era. It would have been easier just to have rewritten their application.

I doubt RS was ever really serious about building anything, probably just talk.

And yes, even if on Z800 you made all these memory maps there would be enormous timing problems keeping it all from working. Massive patching of old software would be needed.

Just trying to bring CPU clock down to 2 mhz NOT would do it.

Yes, 4P keyboard is on a cable. Absolute max length for that cable and it still work. It had always been a problem getting cables to work at that speed and length. Yes, a better cable and more complex design could make an address line scanned keyboard work, but again, there is this cost thing.

Lots and lots of man hours to make all this work when a clean new design like model 4 would not have all these issues just so you could run 13 Ghosts in model 3 mode.

Again, one reason this project has nothing to do with 1/3. I just said maybe model 5 would run 1/3 and maybe it would not have.
 
Last edited:
CP/M is not a fair comparison. CP/M is not a real OS but a collection of subroutines.
Is there a document contrasting CP/M and TRSDOS outside of simply what commands they use? As in their internals and what make TRSDOS stand out in contrast to CP/Ms "collection of subroutines"?
 
Back
Top