Running TRSDOS on Z180 & eZ80

[WSM]

I wanted to clarify, do you have more than one of these for sale?

I only have the one EZ80F910200KITG available. However, I've seen them appear on eBay for reasonable prices and some of the Asian sites appear to MAYBE have them available.

 

[danielbooneamerica]

Agreed there is a difference between different development board iterations. At this point, I am really only using one serial port and not taking advantage of many of the new features offered by eZ80 processor or its development board. I can slip by on about any eZ80 platform including an eZ80 I found in existing commercial products.

The specific development board you posted I can easily provide a binary load to anyone wanting to experiment with this project.

Today I have been testing more commands and cannot get over how fast it is. Everything is pretty much instantaneous.

For example, to use many new peripherals/features on eZ80, some changes must be made to TRSDOS memory map etc. For now, if using some new feature means changing LOWCORE memory map I error on side of keeping map unchanged.

Later I will convert this work to take advantage of newer processor features and when I do, all bets are off what may change in LOWCORE.

For example, many drivers and other code needs modified and moved into memory past 1st 64k to extended memory. This will free up more LOWCORE in TRSDOS. I think you have already done this for CPM which is a very smart idea.

Interrupt structure, clocks etc all will make a big change once I convert to full 24-bit version (24-bit is what I call version using eZ80 features).

It should not be a problem for correctly written apps as they should never be directly accessing LOWCORE memory anyway.

I think using a product you already have built, and working is a great idea. You also have CPM ready to run for these products which adds to its versatility.

As those who have had experience using TRSDOS and a modem to host bulletin boards etc, TRSDOS can be made to work quite well out a serial port. In fact, back in the day(s) many BBS were TRS-80s running host software at 300 baud, 1200 if you were lucky. No doubt this 5,000% increase in speed could host a heck of a BBS. I have considered making a direct login to my TRS-OS development available via a website. It's all about time.

But yes, development kit you mentioned will work. I can assist anyone who wants to use this to test and experiment with this project. Thank you.

 

[mdh]

A friend and I wrote a bbs doing just that. I wrote the assembly portion that did som enhancements to basic to prevent the program from being broken by break key, and if it was, it immediately put run in the command line buffer and errand the bbs, which first thing it did was hang up the phone. Fun times!

 

[danielbooneamerica]

When I start BASIC included with TRSDOS 6 I get strangest error message.

Few diagnostic facts I have been able to gather are;

BASIC is not accessing video memory directly etc. but is using API.

I suspect because of licensing it will only run on a TANDY TRS-80 computer. I suspect BASIC is reading some I/O port to verify it is on a TRS-80 machine.

I do not have facilities for trapping I/O using something like an emulator, but if anyone can check if BASIC directly reads and writes an I/O port we can patch that out.

If not with time I will get around to fixing it.

Here is the really cool looking error message:
-----------------------------------

Problem fixed, MS BASIC supplied with TRSDOS 6 now loads and executes like lightning.

 

[danielbooneamerica]

What hardware is this intended to run on? Where is the code available?

Soon, I hope to make an executable download available.

 

[mdh]

I can be a tester, if I can figure out how to transfer files to my ez-Min Ez80 based system. maybe If I put it on a flash card in Cp/m format…

 

[WSM]

... if I can figure out how to transfer files to my ez-Min Ez80 based system.

All of my systems, including the Min-eZ, are shipped with a version of PCGET which can be used to download files via XMODEM on the second serial port. HyperTerm, TeraTerm etc. can be used on the Min-eZ's UART 1 and the file can be stored on RAMdisk, either of the internal flash drives or on an SD card. Instructions are in the $ReadMe.txt file.

 

[danielbooneamerica]

This simple program executed with MS BASIC supplied with TRSDOS 6:

1 cls
5 print time$
10 for a=0 to 65535
20 next a
30 print time$
40 end

Takes 3 seconds using actual eZ80 @ 50 Mhz.
With TRS-80 emulator using a PC it takes 72 seconds.

Not sure if someone can test on actual model 3/4.

Thanks

 

[gp2000]

The timings on trs80gp will be the same as the real machine:

Model 4, best case: 72 seconds
Model 4 will full wait states: 92 seconds
Model 3: 156

Model 3 is about what I'd expect. Half the speed and then a bit slower yet since Model 4 has a more efficient BASIC.

 

[WSM]

Takes 3 seconds using actual eZ80 @ 50 Mhz.

Having done a bit of eZ80 benchmarking, I found the 50 MHz version to typically be the equivalent of a Z80 at about 170-195 MHz. I simply used STOPWATCH and eZ80 run times of about 10 seconds. One of the problems using the internal real time clock (1 second resolution) and short run times is it can produce a nearly 200% error i.e. just over 1 second could be reported as 3 seconds.

I did a few runs of that loop under MBASIC 5.21 and typically got about 1.8 seconds. Adding a 10 times outer loop confirmed it to be less than 1.8.

 

[danielbooneamerica]

I ran this several times and it came up 11 seconds each time...not a scientific benchmark but it's an idea.

Using emulator 4 minutes and 10 seconds.

print time$
for a = 1 to 10000
b = sqr(a)
next a
print time$

 

[WSM]

Your eZ80 times make me wonder what else might be going on in your system or if you're executing from flash or possibly RAM with significant wait states. Admittedly under CP/M and MBASIC 5.21, I repeatedly get 6 seconds plus a few hundredths.

Four minutes + 10 seconds on a 4 MHz Z80 would be 250 * 4 or 1000 seconds on a 1 MHz Z80.
1000 / 6 = 167 i.e. eZ80 at 50 MHz being equivalent to a Z80 at 167 MHz which I believe to be more reasonable.

 

[danielbooneamerica]

Your eZ80 times make me wonder what else might be going on in your system or if you're executing from flash or possibly RAM with significant wait states. Admittedly under CP/M and MBASIC 5.21, I repeatedly get 6 seconds plus a few hundredths.

Four minutes + 10 seconds on a 4 MHz Z80 would be 250 * 4 or 1000 seconds on a 1 MHz Z80.
1000 / 6 = 167 i.e. eZ80 at 50 MHz being equivalent to a Z80 at 167 MHz which I believe to be more reasonable.

I ran this program using a terminal set at 9600 baud. It only prints time, twice but still this takes time.

This code, takes 1 second every time.

10 da$=date$:ti$=time$
20 for a = 1 to 1000
30 b = sqr(a)
40 next a
45 da1$=date$:ti1$=time$
50 print da$,ti$
60 print da1$,ti1$

This program uses max one second on eZ80. Not sure what actual model 4 will show.

 

[WSM]

On an 11 second run, the baud rate isn't that significant and actually insignificant in your revised code. Your times show your eZ80 system to be the equivalent of a Z80 at about 91 MHz whereas my various benchmarks have always been in the range of 167-195 MHz.

Since your eZ80 times are more than twice mine, I'll repeat my unanswered questions:
- Is any of your code running from flash memory (internal defaults to 4 wait states, external = ? waits)?
- Is your RAM set to use wait states? I use zero and that's where CP/M and MBASIC run on my system.
- Has PHI been checked to be 50 MHz? Most F91 systems use the PLL programmed with a multiplier value.

 

[danielbooneamerica]

On an 11 second run, the baud rate isn't that significant and actually insignificant in your revised code. Your times show your eZ80 system to be the equivalent of a Z80 at about 91 MHz whereas my various benchmarks have always been in the range of 167-195 MHz.

Since your eZ80 times are more than twice mine, I'll repeat my unanswered questions:
- Is any of your code running from flash memory (internal defaults to 4 wait states, external = ? waits)?
- Is your RAM set to use wait states? I use zero and that's where CP/M and MBASIC run on my system.
- Has PHI been checked to be 50 MHz? Most F91 systems use the PLL programmed with a multiplier value.

I would agree that UART should not make that big a difference but it does.

I am running from RAM.

I dont think i have WS set but I will check.

I think you said using RTC for timing such things can be off 100%, maybe that is it, its off 100%. Instead of 1 second to calculate all square roots between 1 and 1000 maybe it is taking 0 seconds, IDK.

Again this is not meant as a bench mark just a general indicator. Clearly when I run this same thing on real model 4 or emulator there is a huge difference.

Being interpreted BASIC many things are happening here such as garbage collection, moving bytes around, math etc.

This brings me back to points I have made before about speeding up TRSDOS without making modifications to OS. Many times in LOWCORE it is sufficient to use a do nothing loop of 256 to let BUS SETTLE etc.

This is no ways near long enough using an eZ80.

Then you are faced with making longer loops and that requires more memory for counters.

I have decremented a 16 bit counter in assembly and it burns right thru it. Since there is not one spare byte in some places to lengthen loops that creates new problems to be solved.

Time delays such as:

ld b,0
loop: nop
djnz loop

Seem to be all cached up in eZ80 and executes blindingly fast. You would need to do this loop thousands of times to get same desired effect as a real model 4. I guess you would only need long delays if interfacing to older legacy peripherals.

As I said, I can decrement a 16 bit number to 0 and not even notice delay. Try a loop using 32 bit numbers on real model 4.

TRSDOS 'pause' SVC would need to be rewritten to take advantage of eZ80 programmable timers.

I have macros for my assembler that lets me do things like for/next.

This loop causes about 1 second delay just long enough to read a few lines on screen.

cpu_dly     FOR        1,10,1
cpu_dly_1 FOR        1,65535,1
                NEXT    cpu_dly_1
                NEXT    cpu_dly

FOR START,END,STEP

This loop counts 10*65535 and I get a delay of about 1 second.

FOR            MACRO    START,STOP,STEP
            SCOPE
            ld        HL,($1)
            ld        ($4),HL
            JR        $5
$4            DW        0                    ; I hold count when running (+8).
$1            DW        START                ; Start count from xx (+10).
$2            DW        STOP                ; Stop when equal or greater than STOP (+12).
$3            DW        STEP                ; Step to increment by (+14).
$5            equ        $
            ENDMAC


NEXT        MACRO    pointer

            ld        hl,(pointer+8)                ; POINTER
            ld        bc,(pointer+14)                ; STEP
            add        hl,bc
            PUSH    HL
            LD        BC,(pointer+12)                ; STOP LIMIT.
            OR        A                            ; Clear carry flag.
            SBC        HL,BC
            POP        HL
            jp        nz,pointer+3
            JP        M,pointer+3                    ;>
            endmac

 

[WSM]

I was going by your original references of 11 seconds for 10,000 iterations vs 250 seconds on the 4 MHz emulator and 6 seconds on my eZ80 when also using interpreted BASIC.

I have no idea what it is or why you'd need to do "BUS SETTLE" loops with the eZ80. I've had no bus issues at 50 MHz (20 ns cycle). When porting an OS to different hardware, I believe removing this kind of useless delay is reasonable, perhaps by conditional assembly. For accurate timing of things like 'pause' it is best to use a hardware timer which unlike timing loops is not affected by interrupts. If you're pressed for space you could use an ADL mode CALL to relocated and expanded code.

A 32-bit decrement loop takes a LONG time since the following code took about 5.75 MINUTES on my eZ80. At 24-bits it would be about 1.34 seconds.

          LD   BC,0
          LD   DE,0
LOOP:     DJNZ $
          DEC  C
          JR   NZ,LOOP
          DEC  E
          JR   NZ,LOOP
          DEC  D
          JR   NZ,LOOP

 

[danielbooneamerica]

I was going by your original references of 11 seconds for 10,000 iterations vs 250 seconds on the 4 MHz emulator and 6 seconds on my eZ80 when also using interpreted BASIC.

I have no idea what it is or why you'd need to do "BUS SETTLE" loops with the eZ80. I've had no bus issues at 50 MHz (20 ns cycle). When porting an OS to different hardware, I believe removing this kind of useless delay is reasonable, perhaps by conditional assembly.

Hello WSM! Bus settle comment has to do with discussions had here about preserving TRSDOS source as is or a rewrite.

I have always argued trying to keep intact is useless.

There are places in original source where djnz $ is used to delay, comments such as let it settle a bit would follow. My point is if a delay is still needed there is no way an 8 bit counter would have same effects when running on eZ80. In this code there is not one spare byte just to try increasing delay.

More bytes can be made available but since some poorly written software reads or writes bytes directly in keyboard driver, I have tried not to change any memory maps of lowcore.

But I cannot imagine why anyone would want to build a new system and put a floppy controller on it, you cannot even get new drives anymore. Might even be hard pressed to find parallel printers that's affordable anyway.

Next and more specific, speed would directly affect keyboard driver. Since there is no keyboard controller and CPU is host/host adapter & interface it has many timing counters.

I can only imagine if left unchanged and clock on model 4 was speed up to 200 mhz what it would be like. I suspect when you hit a key on keyboard you would get a stream of that key. There is a repeat counter for keys, it is timed for 4 mhz Z80. If that took a 50x boost in speed everything would be affected and likely not work.

There is no way to keep source intact unless you operate it at very near exact same specifications it was designed for.

This is one reason I have not yet programmed eZ80 taking advantage of its advanced interrupts and peripherals etc. Doing so will require changing lowcore memory map. For properly written programs this should have no effect but for this first version I am trying to keep it as compatible as possible even for poorly written software.

As far as 32 bit counter taking awhile to decrement I have same results. I had corrected my post but I think my correction had not reached you by time you posted your reply.

16 bit counters eZ80 burns up, 32 bit takes awhile longer.

 

[danielbooneamerica]

I am preparing a binary load for download. Those wishing to be a part of field testing please PM me.

This binary file will contain TRS-OS and also TRSDOS OS. TRS-OS provides BIOS and services to load and execute TRSDOS.

I have shaken tree of many commands on this platform, and they work fine, or as far as I have tested.

Examples include, AUTO, BASIC, FREE, DEVICE, DIR, FREE, DUMP, SYSGEN, etc. Things like TAPE100 and COM/DVR load but there is no hardware to talk with.

Drives are lightning-fast RAM drives. This test version will contain two 360k drives already in load file. Thus, it is similar to have a model 4D with two 360k drives.

Using diskdisk utility from Misosys you can create 5", 40/80 cyl, single or double sided drives on a real TRS-80. This file can then be directly loaded into RAM memory starting at address for that RAM drive. In reverse diskdisk volumes in RAM can be saved as a file and directly loaded back into a TRS-80.

Two very important Misosys utilities that every TRSDOS installation should have is diskdisk and overdrive.

Overdrive is very important to have on your installation and load at every boot. This will save a great amount of wear and tear on your legacy real hardware drives. MTBF is directly proportional to use. Overdrive will cut your disk accesses and vibration of heads seeking between directory and overlays dramatically.

These diskdisk's residing in RAM are referred to as volumes. Volumes reside in slices (partitions) of RAM or other non volatile storage.

Video memory. For now, I simply reserved 1920 bytes of high memory and let video driver do what it has always done. So far of all I tested, I have found no Radio Shack program, Misosys, BASIC etc that attempts to write directly to video RAM. They all use API to speak with video thus are redirected out serial port.

There are a few exceptions such as utilities or programs that more directly manipulate hardware. Roy Soltoff software seems to all use API unless he needs to bypass for a technical reason. Software generated via compilers all use API.

One program that does not work correctly is HELP. There are some issues I am working on, it needs some TLH (tender lovin help).

There is no need to use things like MEMDISK since I provide new RAM drives. I designed my drivers to as closely as possible. mimic floppy drives in RAM. I use $FD as driver name to keep things as compatible as possible with legacy versions.

In future I can free up a lot more driver memory and lowcore but for now I wanted to keep on exact memory boundaries as original 6.3 dos.

One thing I could not do now is provide 60 hz RTC interrupts. Yes we have a built in RTC for date and time but in order to create interrupts from PRT I would need to shift some things in lowcore. For this first release and to keep things as exact as possible with original 6.3, I have chosen for now to leave real time interrupts off. Small trade to keep memory map intact.

Since we have a date/time RTC, DOS will still know date/time. There will be a few things in DOS that will not work without 60 hz RTC. Couple examples are commands to place time in upper right corner of screen, type ahead buffer and I have a couple other things I need to double check.

TRSDOS 6 was released with full blown multitasking built in OS, this needed 60hz interrupts. Thus, any apps that made use of this multitasking will not function for now. PROWAM may use real-time interrupts I don't remember.

Once I move to a new version then I will feel free to change things in lowcore. I will then start supporting eZ80 interrupt structure. For this version it is more about compatibility.

A BIOS setup is provided with allows you to maintain RTC date/time.

I am using eZ80f91 Acclaim development board from Zilog. However, since eZ80 is pretty much a SOC, most any hardware using eZ80 that you can fill first 1 MB with this binary load file then reset should work.

It is one reason I have always been jealous of CP/M community. They been running it on most anything that has a Z80. Modular design allows OS to be reconfigured for different hardware.

I have known for over 30 years that most all software for TRS-80 uses API for video because over 30 years ago we used one set of TRS-80s over a phone line remotely running a small businesses. All of Radio Shack business programs used API (inventory, profile 4, payroll, general ledger etc).

Poorly written software or games probably won't work. You can examine memory starting at F800h and see if it did write anything to video RAM.

Future versions will support a separate bank for video.

Again I cannot stress enough to read Roy Soltoff, creator of TRSDOS 6 words, do not bypass API.

Want to crash a system and write buggy software? Bypass API! Want an example of a bug you will spend years chasing.....sometimes it crashes and other times it dont.....here is an example.

API always ensures stack integrity and switches bank 0 in. What happens one day you call a routine directly and it needs a driver that is now in high memory but you have bank 0 switched out. DOS will now jump to some driver in bank 0 but bank 2 is resident. Your program just crashed and that type bug is hard to find. Same thing with stack in wrong place. There are other details but this is not place for all that.

Also I am working on making BREAK key on remote terminal work correctly. As a fix for now if you double tap escape key on terminal it will force DOS to abort currently running app. This is not a real break key but it does solve for now getting in a loop you cannot get out of.

I will be fixing break key.

There are many details more than I can type here.

This first experimental release is for study and research. Point of this study is to further improve a version that mimics a machine TRSDOS can run on. Again, TRS-OS provides services to support TRSDOS running on different hardware.

I may also make Z180 version but more I work with eZ80 I can see it is superior in many ways. Big giant difference is 24 bit linear memory address space. Banks are banks are banks. A system really needs both, large linear address space and additional bank space.

Bank space has a huge advantage in that it is near instantiations switching in and out. One out instruction and new bank is available.

This allows for interrupts to always have bank 0 resident. Remember about using API? When you make a call directly then hardware receives an interrupt, depending on which call you made directly in OS and PC is now executing in lowcore, you are in deep do do.

Once I get a version that will as closely as possible run original TRS-80 software then we will release this as a good as its going to get version (or at least as good as it will get from me).

Myself I am using my versions to control hardware in home automation.

It has been a long road since I first typed ? 1+1 on a TRS-80 at my local Radio Shack in 1978.

 

[Twospruces]

Would be interesting to see if you could run TRS-80 inside the Brother Powernote or Super Powernote.

Z180 based..

Brother Super PowerNote Reverse Engineering

Reverse engineering a Z180 powered word processor from the mid 1990s. Inspired by a similar project that ported a CP/M clone to an old Brother typewriter with similar hardware.

hackaday.io

 

[danielbooneamerica]

Would be interesting to see if you could run TRS-80 inside the Brother Powernote or Super Powernote.

Z180 based..

Brother Super PowerNote Reverse Engineering

Reverse engineering a Z180 powered word processor from the mid 1990s. Inspired by a similar project that ported a CP/M clone to an old Brother typewriter with similar hardware.

hackaday.io

There is no reason a version could not be made to run on this hardware.