Running TRSDOS on Z180 & eZ80

[mdh]

So I have a MinEz 1.2xm @MB + 0 (all that was available at the time), so how do I get TRSDOS running on it?

 

[lowen]

The Agon Light 2 could be an interesting porting target, since it also runs an eZ80F92. 50 Euros and available for pre-order from Olimex.

(I am a fan of WSM's cased products; I have a Min-Z Z180 system from Bill as well as a Min-eZ on the way. This board would be a true 'Model 5' with a real keyboard port and a VGA output.)

 

[whartung]

The Agon Light 2 could be an interesting porting target

That's a very interesting little machine. I like how they use the high speed serial interconnect to the I/O coprocessor. 384Kbps seems pretty high for the bandwidth to the CPU, but I guess it has a native serial port to handle it. Curious about the protocol they use over it.

 

[WSM]

Off topic but for clarification:

384Kbps seems pretty high for the bandwidth to the CPU, but I guess it has a native serial port to handle it.

The eZ80F92 specification states that it's UARTs are capable of 1.25 Mbps and they also includes 16-byte FIFOs. With 8-bit serial that's 125 KB/sec which gives 160 T states per byte for plenty of processing. The Agon documentation also states that it uses flow control.

The real issue becomes what baud rates both of the two processors can generate and agree to use. If the user wants "standard" serial baud rates, the eZ80F92 would be limited to 230,400 baud due to it's divisor capabilities.

 

[danielbooneamerica]

So I have a MinEz 1.2xm @MB + 0 (all that was available at the time), so how do I get TRSDOS running on it?

I am not familiar with all of Circle M revisions but I do know it requires a certain level BIOS etc. These are questions best for WSM.

As far as TRS-OS, Circle M is including it with new sales and soon it will be available for download from my website including future updates. https://www.danielpaulmartin.com/home/research/

 

[danielbooneamerica]

The Agon Light 2 could be an interesting porting target, since it also runs an eZ80F92. 50 Euros and available for pre-order from Olimex.

(I am a fan of WSM's cased products; I have a Min-Z Z180 system from Bill as well as a Min-eZ on the way. This board would be a true 'Model 5' with a real keyboard port and a VGA output.)

Hello Lowen, thank you for post.

Agon looks like a nice board but I want to point out $50 euro might not be that much better than Circle M. That was 50 euros. Circle M prices are in $. Sales to USA may have a heafty VAT tax.
But it is a nice board and one of the few eZ80 boards. Lots lots Z80/Z180 but few eZ80. But it is growing fast.

Regarding 'true model 5'. Model 5 is a pipe dream. It can be what you want it to be. Who knows what a next release would have looked like.

Maybe cassette, maybe color but then again maybe no to all this. I think one thing they would have knew even then was that everything that made TRS-80 great was dead.

Cassette....it was there from beginning of TRS-80 but even Radio Shack knew use and sales of tape for audio let alone computer was dead.

Mono, dead. Color was future and yes you could put color on a TRS-80 but it was not going to make existing base of software automatically color.
They were not really writing new games etc for TRS-80. It is true some business software like Deskmate would have made use.

Market for a computer that looked like a TRS-80 dead. At one time a selling point of the TRS-80 was it came all in one package. No plugging cables and worry of buying correct add ons. It was already in one package. Later attitudes changed and a modular setup was desired.

This list could go on and on. Myself I think the future they saw was using a TRS-80 connected online to a larger computer or locally to XENIX systems while at same time able to run things like deskmate locally. Who knows what would have happened.

To me Model 5 is not one computer but a series. One computer can never be everything to everyone. So like other computer designs of the past I feel the model 5 should be a series of machines and OS releases.

Model 5T, Tiny yet powerful. /released/
Model 5M, Upgrade from Tiny model and both only need USB connection to PC for power. /released/
Model 5E Educational system currently under development with what you wanted Lowe, keyboard/video. /under development/
Model 5U To be announced.

Also note, bank memory is really needed to run advanced TRS-80 apps. It will not be possible for M5T & M5M to ever have this capability.
However without bank memory allows us to have basically a system running on one chip.

Models starting with M5E will support bank memory.

Sorry I have been having some health problems and its taking me longer to respond.

 

[dustyzebra]

Zilog dev tools are great when using C, well almost great. It is not geared toward a large project done in assembly. In fact its assembler does not accept labels that were used in TRSDOS.

Misosys products used labels that works on most all assemblers except Zilog.

Zilog ZDS do not produce good reports of labels, line numbers, where label was defined etc.

Sadly, all they want to discuss is C, or that's been my experience with their support line. Now that it changed hands again support is almost non-existent.

Sad what happened to a once great company.

I agree completely and I would love to play around with eZ80 SBC's and related stuff. Zilog is a sad story in microcomputer history. Especially since it was pushed aside by Intel's crappy chip designs (btw, I am one of those that hate Intel's mneumonics prefering Zilog's. Oh and lower case also).
Assembly programmers can and are some picky people. Worse than your average C programmer (IMO anyway).

 

[dustyzebra]

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?

On the Model II/16, their was a very well done version of CP/M called Aton CP/M. It used some bank switching to give a TPA of about 52k. I loved it over TRSDOS althou I still used TRSDOS a lot. Once Tandy (and MS finally released Xenix for the 16, I dumped TRSDOS completely even thou Xenix was still a bit buggy.

 

[lowen]

Hello Lowen, thank you for post.

Agon looks like a nice board but I want to point out $50 euro might not be that much better than Circle M. That was 50 euros. Circle M prices are in $. Sales to USA may have a heafty VAT tax.
But it is a nice board and one of the few eZ80 boards. Lots lots Z80/Z180 but few eZ80. But it is growing fast.

Bill (WSM) does good work. I have a Min-Z from a couple of years ago and I just received a Min-eZ last week. Nice build quality.

The Agon system, however, has a VGA output as well as local keyboard, and is more of a standalone system, where the Min-eZ is a tethered system that requires a USB-capable system as a terminal. Nothing wrong with that, of course, it's just not standalone.

Regarding 'true model 5'. Model 5 is a pipe dream. It can be what you want it to be. Who knows what a next release would have looked like.

Actually, there is a pretty good guess out there now what a rumored Model 5 might have been, on Matthew Reed's trs-80.org, but I'm pretty sure you're already familiar with that page. But, back in reality, the model # of 5 is already taken in TRSDOS 6, by the 4P.

Also note, bank memory is really needed to run advanced TRS-80 apps. It will not be possible for M5T & M5M to ever have this capability.
However without bank memory allows us to have basically a system running on one chip.

Yes. The eZ80's 64K bank size (using MBASE as if it were an MMU) isn't very compatible. I have an untested idea how to do it with minimal hardware and using only MBASE to do the bank selection, but, as I said, it's untested. I have four or five eZ80F91 AcclaimPlus dev modules on which to try it out, eventually. Health issues in the family and the death of my MIL have drastically curtailed hobby activities.

But the essence of my idea is to define the memory addresses like this:

fxuprmem = GPIO_OUTPUT_PINx #Fixed Upper Memory, named after the Model 4 control signal Can be 0 or 1

if address[15] == fxuprmem :
    address[16:23] = [0,0,0,0,0,0,0,0] #or whatever MBASE you would like; 
                                       #driven by eight bits of a GPIO port, allowing the shared 32K to be in any MBASE page.
else :
    # Note that it is completely sufficient to do nothing here, but
    # it will waste half of your RAM
    address = address[0:14]+address[16:23]+[0] #Shifting A16-A23 down one, pad 0

Drive fxuprmem with a GPIO output, feeding one side of an XOR, and A15 on the other side. Use an eight-bit multiplexer, with the A-side grounded to all zeros (or tied to eight GPIO outputs), and the B-side being the addresses (the eighth bit, A23, can be just tied to ground, since it would always be zero). Connect the XOR output to the selector input of the mux (pay attention to the selector's logic level and adjust the definition of fxuprmem accordingly). Downshift the output addresses by one from the input addresses, making A15 get the value of A16, A16 getting the value of A17, etc. As I say, untested, but should work. You then set the MBASE to the bank number. This effectively 'shadows' half of the address space seen in any particular 64K page to either the upper or lower 32K of the page where MBASE equals 00H.

Models starting with M5E will support bank memory.

Cool.

Sorry I have been having some health problems and its taking me longer to respond.

I know how that is; just now getting back up to speed on projects after the trainwrecks called 2020, 2021, and 2022. My sympathies; I hope things go well with you.

 

[WSM]

Lowen: I understand what you're thinking of doing with the multiplexing but one thing you'll need to be very conscious of is the speed/timing of a 50 MHz eZ80. Basic timing only leaves about 11 ns for external address decoding plus the actual memory access. Typical multiplexor / memory combinations would force the addition of a wait state which could REALLY slow down this pipelined processor.

Also note, bank memory is really needed to run advanced TRS-80 apps. It will not be possible for M5T & M5M to ever have this capability.

One thing to remember is the relative speed of the eZ80 vs Z80. A 32K LDIR takes just under 2ms on a 50 MHz eZ80 which is very roughly about 2000 instructions on a 4 MHz Z80. Certainly not an ideal technique to be copying the common or bank area but definitely workable, especially if there isn't a lot of bank switching, and it doesn't take any external logic. The only question would be whether the applications are well behaved and always call a system API to do the bank switching.

 

[danielbooneamerica]

I think I know where you are going on bank switching with block move but it wont work.

Good idea but bank switching must take place at interrupt speed and then some (already in interrupt and then do additional switching).

All of this connects to a comment I made over last year about reading where someone suggested bypassing API to make your code run faster.

I can think of 2 good reasons this is a dumb idea.

1. Roy Soltoff tells us more than once, in fact several times in each document he wrote on this subject----> no matter what resist temptation of bypassing API.
2. If reason 1 isnt enough, reason 2 is it wont work.

----One thing to remember is the relative speed of the eZ80 vs Z80. A 32K LDIR takes just under 2ms on a 50 MHz eZ80 which is very roughly about 2000 instructions on a 4 MHz Z80. Certainly not an ideal technique to be copying the common or bank area but definitely workable, especially if there isn't a lot of bank switching, and it doesn't take any external logic. The only question would be whether the applications are well behaved and always call a system API to do the bank switching.----



If you do this your code may not be compatiable with future releases of dos and in fact may not work with older loads. Example lots of things moved in lower memory during various releases of TRSDOS 6.x.
You might get by with calling a routine or two directly some of the time, but one day!!!!!

Lets take an example. You decide that those disk i/o calls are slow and you want to make faster so you try calling disk i/o routine directly. Great it goes and returns so what is problem?
One day you will have a FReD thing or a real HD etc and ask for I/O on a drive. You call it and bypass API.

That API call you did not do does many things but one thing that is very important was always call bank 0 in on entry to API,

Now your file open routine you called and bypassed API needs disk I/O and calls disk driver for FReD. You had driver for your HD/FReD in high memory. Drivers are only loaded somewhere in first 64k.
Guess what, its not there and your program bombs system. Some other bank is switched in and o/s calls address pointed to by DCT but driver is not there.

For some reason bank 1 was switched in, you bypassed API and bank 0 was not called in and bank 1 still resident. Where is your driver now?

When you return from API it restores the bank you had when first entering API. This way your program returns to where it was with hardware banks where you had them.


What does this have to do with what we are talking about? You face same problem on interrupts.

Bank switching is one of the fastest things your computer can do (I mean to say big bang for one instruction).
It is as near instant as you will be able to do. One I/O instruction and boom 32k switch. I am sure wsm or lowen could tell us exact ns.

Now one more issue. Video memory must override bank. Example you have bank 1 loaded and switch video bank. Now video overlays upper 2k of 32k bank and when you close video it restores that portion. Using hardware bank switching of video it happens in one instruction.

Block moving of banks would work if not needed at such high frequency. I did play with this idea but gave it up. When running and doing work it spent too much time tossing data back and fro.

 

[danielbooneamerica]

Bill (WSM) does good work. I have a Min-Z from a couple of years ago and I just received a Min-eZ last week. Nice build quality.

The Agon system, however, has a VGA output as well as local keyboard, and is more of a standalone system, where the Min-eZ is a tethered system that requires a USB-capable system as a terminal. Nothing wrong with that, of course, it's just not standalone.



Actually, there is a pretty good guess out there now what a rumored Model 5 might have been, on Matthew Reed's trs-80.org, but I'm pretty sure you're already familiar with that page. But, back in reality, the model # of 5 is already taken in TRSDOS 6, by the 4P.


Yes. The eZ80's 64K bank size (using MBASE as if it were an MMU) isn't very compatible. I have an untested idea how to do it with minimal hardware and using only MBASE to do the bank selection, but, as I said, it's untested. I have four or five eZ80F91 AcclaimPlus dev modules on which to try it out, eventually. Health issues in the family and the death of my MIL have drastically curtailed hobby activities.

But the essence of my idea is to define the memory addresses like this:

fxuprmem = GPIO_OUTPUT_PINx #Fixed Upper Memory, named after the Model 4 control signal Can be 0 or 1

if address[15] == fxuprmem :
    address[16:23] = [0,0,0,0,0,0,0,0] #or whatever MBASE you would like;
                                       #driven by eight bits of a GPIO port, allowing the shared 32K to be in any MBASE page.
else :
    # Note that it is completely sufficient to do nothing here, but
    # it will waste half of your RAM
    address = address[0:14]+address[16:23]+[0] #Shifting A16-A23 down one, pad 0

Drive fxuprmem with a GPIO output, feeding one side of an XOR, and A15 on the other side. Use an eight-bit multiplexer, with the A-side grounded to all zeros (or tied to eight GPIO outputs), and the B-side being the addresses (the eighth bit, A23, can be just tied to ground, since it would always be zero). Connect the XOR output to the selector input of the mux (pay attention to the selector's logic level and adjust the definition of fxuprmem accordingly). Downshift the output addresses by one from the input addresses, making A15 get the value of A16, A16 getting the value of A17, etc. As I say, untested, but should work. You then set the MBASE to the bank number. This effectively 'shadows' half of the address space seen in any particular 64K page to either the upper or lower 32K of the page where MBASE equals 00H.



Cool.



I know how that is; just now getting back up to speed on projects after the trainwrecks called 2020, 2021, and 2022. My sympathies; I hope things go well with you.

Yes I did notice in source 4p was called model 5.

I have read stories of what model 5 might have had, but if you ever worked for a large company, which Tandy almost was, what is on drawing board dont always make it to final product. It is all an interesting discussion. I sometimes roll this around while laying awake tossing who shot JFK, were Beatles played backwards really sending a message and was my parents right AC/DC destroyed youth of USA? But I soon fall asleep and next day I go back to dreaming of my model 5. Was I to put a smile face after any of this let me know?

I did notice RS had called 4p in source model 5. I was already into this project and had in my brain model 5 and for some reason calling it 6 didnt seem to fit. I just stayed with 5. Then I had 5 seperate products supported in my line.

M5Tiny
M5Mini
M5Development
M5Educational
M5Universal.


Jesus, now you have me on a roll. I envision this line way I was trained in IBM classes @ university. IBM 360/370 series was not a success because they were more powerful than other computers but it was because they were produced as a family of products designed to work together.

In fact US Navy could not use IBM 360 on A4 Skyhawk simulators because 360 was not fast enough. XEROX (remember people that invented pointing device?) produced SIGMA series that ran 360/370 software. Big difference was 360/370 went to memory fetching data/instructions in bytes. SIGMA series had a full 32 bit data bus. Each memory access was full 32 bits in same time others fetched one byte. Of course it costs a whole lot more to build SIGMAs than 360/370s but SIGMA series was excellent for scientific research in real time simulation. There is a really neat video on youtube showing a SIGMA controlling traffic in LA. And guess what? They still build CPU today that will still run SIGMA software for legacy devices military and who knows who else still support. If I remember correctly IBM data bus to memory was either 8 or 16 bit where at that same time SIGMA was 32.

IBM 360/370 was a family of products that worked together and could share software. XEROX built some hot computers but they were not a family that tried to be everything to everybody. IBM did try to be everyhing to everybody (banking, production, business, time sharing, government etc). This made IBM support of that product line grow and grow.

Todays budget dont allow for building a large hobby eZ80 that is everything to everyone.
Perhaps a series of smaller SBC wih each one trying to fit a nich is a better idea. But keep idea of them all working together as a family and sharing software and support devices.

I totally agree that had RS produced next model 5/6 it would have had built in video/keyboard/printer ports etc.

So far, first 3 models of my 5 point plan do things outside box of traditional TRS-80 series. 3 models greatly increases flexibility of product line. True it would be nice to have something that looks like a Model 4 sitting on a desk being produced new (not sure where you would get a floppy, parallel printer, tape drive etc) but it is also nice to this same thing running on a product with footprint size of sugar packet, inside your wind turbine as you connect via wifi.

Again, it is going to take a series of products to be everything to everybody and there will still be people who want something that it dont have but I dont have a budget to build M5-Supercomputer!

 

[danielbooneamerica]

I have been meaning to post this for some time and now is as good as time as any.

I have said I am running TRSDOS 6.3 and I dont think that is correct.

Unless someone corrects me, last release of TRSDOS is 6.2.
Later Logical Systems sold LSDOS 6.3 and that was last release.

I have loaded into my project RAM drives an exact copy of 6.3. I got original diskette out and refreshed my memory.
I purchased 6.3 from logical systems and it is loaded on a logical system diskette. Still has my service number wrote on diskette with marker.

So my project loads provided on M5M & M5T are running directly from my Logical Systems 6.3 diskette and says LSDOS ready.

Unless someone corrects me, there was never a TRSDOS 6.3.......maybe its time for TRSDOS 7 release.

 

[lowen]

Lowen: I understand what you're thinking of doing with the multiplexing but one thing you'll need to be very conscious of is the speed/timing of a 50 MHz eZ80. Basic timing only leaves about 11 ns for external address decoding plus the actual memory access. Typical multiplexor / memory combinations would force the addition of a wait state which could REALLY slow down this pipelined processor.

That's why I said 'the essence ' in my post. And I was hoping you'd reply, since you have way more real-world experience with a 50MHz eZ80 than I. And I am conscious of the speed here, as well as my inexperience building things for that speed. That's a big part of the reason it's untested.

You are very correct to mention that 11ns is a significant challenge. Perhaps a pair of address buffers, just for A15-A23, would work better. Select one for the common bank case; select the other for the switched bank case. And there are other ways of doing a selectable inversion; an XOR is just one.

EDIT: this is a case where simple programmable logic might be the best case. For 2MB of RAM you only need 21 bits of addressing; it may be that something like an ATF22V10 could work. That's available with propagation as fast as 5ns. That's cutting it close, since you would then need 6ns RAM.

It might just simply not work at 50MHz. But it should work at 20.

One thing to remember is the relative speed of the eZ80 vs Z80. A 32K LDIR takes just under 2ms on a 50 MHz eZ80 which is very roughly about 2000 instructions on a 4 MHz Z80. Certainly not an ideal technique to be copying the common or bank area but definitely workable, especially if there isn't a lot of bank switching, and it doesn't take any external logic. The only question would be whether the applications are well behaved and always call a system API to do the bank switching.

It's easy enough to test the applications; try them on a Model II with a second 64K running the Model III/12 version of LS-DOS 6. This is really easy using the trs80gp emulator. If they run correctly on the Model II then they use the API.

As to the switching rate and frequency, it's a matter of profiling calls to the @BANK SVC.

I think the performance hit of LDIR-based common area switching might be worse than a wait state would be. But to know for sure we would need to profile application use of @BANK.

 

[lowen]

I have been meaning to post this for some time and now is as good as time as any.

I have said I am running TRSDOS 6.3 and I dont think that is correct.

Unless someone corrects me, last release of TRSDOS is 6.2.
Later Logical Systems sold LSDOS 6.3 and that was last release.

Correct, there never was a TRSDOS 6.3. Frank Durda's LS-DOS 6.3.1 source code reconstruction page goes into some detail on this.

There was, however, an LS-DOS 6.2. The source for that is out there; this is the OS that was rebranded by Tandy as TRSDOS 6.2. I had a physical LS-DOS 6.2 for Model II on single sided eight inch disk; I sent it to pski for archival.

The prior versions, 6.0 and 6.1, only survive, as far as I know, in TRSDOS form.

It's version 6 for a reason. TRSDOS 1.x for the Model I was first (yes, Model I), written by Randy Cook. TRSDOS 2.x for the model I followed. When DosPlus came out, to show the 'plus' it was given version 3.x by it's developer, Micro Systems Software.

Then Randy Cook put out VTOS, with a 4.x version number.....

And Lobo drives commissioned LDOS, with a version of 5.x.

LS-DOS 6 is the direct descendant of LDOS 5.

Since Tandy had picked LDOS for the hard disk OS for the Models I and III it was a short leap to use LS-DOS for the Model 4, and just rebrand it as TRSDOS.

 

[lowen]

Again, it is going to take a series of products to be everything to everybody and there will still be people who want something that it dont have but I dont have a budget to build M5-Supercomputer!

I think the course you're taking using the Min-eZ and kin is a reasonable thing to do. The audience is too small to justify the expense of anything larger.

I just mentioned the Agon as being a potential additional porting target, filling a slightly different niche.

By targeting hardware that has a broader appeal, like with the Min-eZ being one of, if not the fastest non-emulated CP/M-80 systems ever made, or with the Agon, which has the clout and manufacturing scale of Olimex behind it, you can concentrate on what you really want to do, which is improving LS-DOS in software.

EDIT: there will and can never be an all-encompassing system that meets everybody's needs. Well, unless you're talking about the trs80gp and SDLtrs emulators, that is....

 

[WSM]

Lowen: I think zero wait bank switching may be achievable with either 2 external SRAMs and/or the very careful use of fast logic, whether LVC, FET or possibly something like a Lattice ispMACH 4000V CPLD with 2.5ns Tpd. I'm tied up for a few days but will reply privately after I've had a chance to think some more about it.

Good idea but bank switching must take place at interrupt speed and then some (already in interrupt and then do additional switching).

Interrupt code on the eZ80 is entered in ADL mode and thus has full access to all 16 MB of memory without any need for copying banked data. While a user application might add interrupt routines for timers or UARTs, I wouldn't foresee them switching banks while waiting for an interrupt. Moreover, this user code would already need to be customized for use with eZ80 peripherals.

f you do this your code may not be compatiable with future releases of dos and in fact may not work with older loads.

I think you're misunderstanding where I would envision the copying to take place. If an application is well behaved, it calls an API to switch banks and thus the copy only takes place within the customized portion of operating system code and not within application code. A new release of dos will always require a rework and/or integration of peripheral specific OS code but it would not require any change to application code.

 

[lowen]

Lowen: I think zero wait bank switching may be achievable with either 2 external SRAMs and/or the very careful use of fast logic, whether LVC, FET or possibly something like a Lattice ispMACH 4000V CPLD with 2.5ns Tpd. I'm tied up for a few days but will reply privately after I've had a chance to think some more about it.

Looking forward to it! You have my email.

 

[danielbooneamerica]

I think you're misunderstanding where I would envision the copying to take place. If an application is well behaved, it calls an API to switch banks and thus the copy only takes place within the customized portion of operating system code and not within application code. A new release of dos will always require a rework and/or integration of peripheral specific OS code but it would not require any change to application code.

No I follow your idea but let us consider why I abandoned the idea.

Every time the heart beats, 60 times a second we are;
1 saving current resident bank.
2 ldir bank 0 in.
3 execute interrupt handler.
4 swap bank 0 back out.
5 restore original bank.

During this time and any other time, on each API call/exit we basically repeat above procedure.

In addition we need swap 2k video bank when needed and if resident during interrupt or API call we must make sure it is handled correctly.

I can think of at least one example of contention created by this that would result in deadlock. It could be avoided with more elaborate coding, but this list is growing and growing. Problem with a long list is we have very limited space to fit this all in.

Example, in hardware if i have bank 2 switched in and then switch in video, all is cool.

But let us say I then want bank 1 available and do a switch. In hardware video would still be resident and overlay new bank number. But in proposed ldir system that would not be the case.

Like I said I did code this in early versions of TRS-OS and did my swapping at exactly the same time original LSDOS did hardware switch. It would work but now well.

60 * (32k * 4) per second bytes swapped using LDIR +plus video and api calls swaps. If you still think it is doable, I could code up an experimental model for your testing.

And BTW....while we are in swap code, interrupts are disabled thus real time interrupts would suffer greatly as we would spend a lot of time in swap code.

 

[danielbooneamerica]

Interrupt code on the eZ80 is entered in ADL mode and thus has full access to all 16 MB of memory without any need for copying banked data. While a user application might add interrupt routines for timers or UARTs, I wouldn't foresee them switching banks while waiting for an interrupt. Moreover, this user code would already need to be customized for use with eZ80 peripherals.

Yes, I understand we have 16 mb but our task at hand is to make existing TRS-80 software run.

There are several apps I know of and more I don't know of, that uses bank memory.

It is not feasible to recode each app to use 24 bit addressing.