• Please review our updated Terms and Rules here

TRS80 Model 5

Z280 is 12.5MHz rated, but in practice has run overclocked to a bit over 14, with the crystal at twice that frequency.

Z380 runs up to 18.

Z8S180 is rated up to 33MHz, some have run the P112's Z80182 (Z8S180 core) at 49MHz.

eZ80 is significantly faster, but has some issues that the others do not, like the I/O device overlap (but only if A is 0 or B is 0, depending upon which I/O instruction we're talking about). Z280 puts on-chip I/O in a whole separate I/O address bank, and Z380 requires the use of special I/O instructions to access on-chip stuff, so no overlap. And, yes, eZ80 is optimized for static RAM. Ok, so need an old-school DRAM controller... Sounds like a job for an FPGA with the same SDRAM controller used by Will Sowerbutt's socz80 system, then the limitation is more the eZ80's 16MB limit.

Z380 has all the signals already generated to operate FPM or EDO DRAM, and 128MB or more wouldn't be hard. (EDIT: from the hardware point of view.... if I remember correctly, LS-DOS 6 @BANK has a hard limit of 256 32K banks, or a total of 8MB.... I personally wrote an extended @BANK that could take up to 32 banks, and I know how to extend that to 256, but the bank number is passed in an 8-bit register....)

Z280 is slower, but far more featureful; I would love a 50MHz Z280!

Now, about software.... What I've mulled over actually is a compatibility layer for something like Fuzix or UZI280 that would allow LS-DOS 6 programs to run, much like there's a CP/M shim for at least one of the UZI variants....

What many of us TRS-80 fans forget is that the legacy Model I design just isn't really that great, and the Model 4 is a bit hobbled by that, in my opinion..... The Model II is actually a much better design.... Or the MAX-80, for that matter, which forgoes a lot of the Model III hardware compatibility but still could run a lot of stuff thanks to LDOS5's abstractions, and even has its own LS-DOS 6 port, MaxDos.

So, there are several possibilities here, and I personally plan to have fun with all three. I will probably put the 'glue' into an older Altera MAX7000S device, simply because I have them and the tools to work with them, and then port to Atmel/MicroChip ATF1508AS, which is current production and available in 5V or 3.3V families.

For that matter, Z280RC has a MAX7000S device, and the design is open.... For that matter, a TRS-80 compatibility board for RC2014 would be really cool, a modern take on http://www.classiccmp.org/dunfield/t80s/index.htm
 
Last edited:
Here I can see part of problem;

1) We were talking about 128k board hardware using mailbox for model 4 emulation, but now we are talking about model 3, I am sorry I missed that.
2) My TRS80 experience is inversely proportional to yours, I have only used model 3 mode 2% of time.
3) Roy seen the future because he was not a self taught programmer but had formal education and could see future. Multitasking was added and done in a systematic way using a REAL TIME PROCESSOR subsystem. This is well thought out and coded. It in itself if perhaps hardware independent as it is. OS uses some background tasks and other applications use others. Roy made a super app named PROWAM which I think needs multitasker running. All this said it also supports tasking like you think of for Unix. Yes it can multitask on foreground tasks but I know of no software that was wrote to do this except privately developed software (like me) However Roy did write double duty which switches foreground tasks when user selects swap. With more banks of RAM it could be a large number of these foreground tasks and even automate switching between them.

It is an area i have high interest and have developed more advanced scheduler software for TRS80 as in real life one hat i wore was system programming of scheduler on MVS. I feel I can make a scheduler contribution that executes under sys13,

4) did Roy make official system calls in LDOS like LSDOS for multitasking? I am not sure.

I have been thru every bit and byte of LSDOS and tested extensively. Some of the things they did I still wonder why they did it that way. I have been thru every bit and byte 100 times over and likely need to do it 500 more times before I could begin to really understand it all. Endless nights of coding has produced a new lowcore/bios/sys0/ior.

Keyboard driver is slick as snot and has uses today for keyboards on z80 hardware projects not just for scanning keyboards. In fact I used it for scanning when a phone extension went off hook in a very large business one time. Other contractor had quoted almost 10k to build a device for a special job. I bid $600 and put a model 4 motherboard inside a PC case. Used keyboard interface and scanning software to scan phone lines. One day after I left they opened it up and realized it was some TRS80 board inside a PC case, it really ruined their day. One of many vendors days I have ruined with a TRS80.

Video driver, they knew more about video display and format processing than I do.

Mass storage drivers, mass storage is another thing I have lots of experience with and i hope to leave a contribution here. My goal is that we can connect to a PC and it appear as drives to us. We can then under program control select which directory to story or drives, which drive to mount etc. Possibility are limitless. One thing I like about using LSDOS for security is that there is not a lot of viruses developed for z80 and trsdos/ldos/lsdos or my NXTDOS or sometimes I call it DAMDOS. My wife usually prefaces anything i do with damn.

I am as old as dirt and getting older. My health is not good and not getting better. So this is a personal ad, that is my reason for being here.

Married programmer looking for energetic hardware guy on side that can hook me up with hardware to run my software.

Folks, lets get this done. I got TRSDOS/LSDOS covered if someone works on LDOS. We need hardware. It is sad there is so much duplication of projects. Some hardware like the LISP board I spoke of has everything we need except one main feature we need, bank memory. Seems to me it would make sense TRSDOS/LSDOS/LDOS/CP/M/LISP/ETC we should all use same board for many reasons but one reason to reduce costs for everyone. Like the PC we all need one agreed architecture for Zilog.
 
I should probably quote in this reply, but quoting and using a phone to post are at odds.... And, apparently makes it easy to post duplicates... Sorry about that, see the post below.....
 
Last edited:
I was looking thru some documentation one day and thought I read Roy is Dr. Soltoff but perhaps it was another Soltoff.
I am not sure what prompted his interview with national archives but he is an accomplished programmers. I was looking inside LDOS manual and it says.

The following persons were members of the team that made LOOS possible:
Bill Schroeder PROJECT LEADER
Roy Soltoff SYSTEMS ANALYST
Chuck Jensen
Doug Kennedy
Dick Konop
Tim Mann
 
I should probably quote in this reply, but quoting and using a phone to post are at odds.... Anyway, a few things:
1.) The LS-DOS SVC structure via RST 28H was available for LDOS5. The actual address to CALL was documented, but even TRSDOS 2 for Model I and TRSDOS 1.3 for Model III used the RST 28H hooks for overlay loading... Set bit 7 of A on LS-DOS 6 and call the SVC handler and you do the same thing.... LDOS5 just added the vector table and SVC handler.

2.) Roy, like me, has his bachelor's in an electrical engineering discipline, and that's why it's as well engineered as it is.

3.) Well, this is a hobby, so people tend to build what they want using what they have on hand, and what they find interesting at the moment. Now, having said that, I would be willing to put some priority on it for hire...but I'm not holding my breath.... :)

4.) Speaking of LS-DOS porting, the Model II/12 LS-DOS 6 sure could use some love, and with trs80gp emulating Model II.... :)

5.) LS-DOS abstracts character I/O well enough that a bankless port for the MakerLISP or an outright bankable port for either CPU280 or Z280RC, using the UART for console would be really really cool. I could probably arrange for a working Z280 board for you in the short term. There are pros and cons for each, but in both cases the hardware is available NOW. I seem to remember someone working on an LS-DOS port right now to a non-TRS-80 SBC, if I remember correctly it's to the Z80-MBC2, but the source isn't public yet.

6.) Kim Watt did a bunch of the work on the pre-release LS-DOS 6.2 for Model II.....

7.) EDIT: MAXDOS-6.... See http://www.vcfed.org/forum/showthread.php?64444-Lobo-MAX-80-MAXDOS-6
 
Last edited:
So far the MODEL 5 wish list has;

very fast CPU running very fast executing code with 0 wait states.
Serial port x2.
SPI port.
VGA.
keyboard.
lots of RAM.
FLASH BOOT & DISK.
*Very important* TRS80 style bank memory & lots of it, think big people.
Raspberry Pi that could tri-state the CPU and take over bus and all peripherals, running whatever you wanted in emulation or could just act as a Linux box.
in Model 4 mode the Pi would act as a floppy emulator when needed.

Model 3 mode.
LISP community support.
CP/M community support.
RC2014 community support.
 
So, I've been thinking about this project a bit more, and to keep out feeping creaturism I would want to simplify things a lot. Also, at this point we're not really talking vintage any more, but more like a retrobrew project, and once I have a more concrete design (even if it's just a schematic) I will probably post on the retrobrewcomputers.org forum the technical details, with just a pointer from time to time posted here. So I'll apologize for the length of the post first..... EDIT: I forgot a newer eZ80 design out there; check out https://hackaday.com/2020/02/23/a-z80-computer-at-the-next-level/for some inspiration as to what this 'Model 5' could become.

I see as a practical matter the following as being feasible:
1.) eZ80 at 50MHz. This isn't hard, but picking which eZ80 to use might be. I have stock of the F91, but that might not be the best choice.

2.)Zero WAITs. At 50MHz this means address-active to data-active access times of less than 20ns, and that's much harder; while a DRAM interface wouldn't be terribly hard, getting 20ns from address on bus to data on bus will be. Even the very latest DDR4 DRAM still has a CAS latency to the first word of over 7ns, and to get RAM that is reasonably placed on a hobbyist board (meaning, in practice, no BGA parts; TSOP, SOJ, and QFP would be reasonable) you're going to go back to DDR or even SDR SDRAM, and those have CAS latencies in the 20ns neighborhood. I would probably stick with SRAM, which is available in 2MB SOJ packaging and is relatively inexpensive and simple to work with. 8 2MB SOJ packages wouldn't take up too much board area, and would max out the 24-bit address range of the eZ80. If you want more, you need an MMU, and more board area. Board area would need be kept as small as possible for cost reasons.

3.) SPI. This is easy with eZ80, and makes a lot of the other items easy as well, including SD card support and the WizNET TCP/IP offloading Ethernet modules. SPI works with a lot of devices.

4.) UART and GPIO. Also easy with any of the eZ80 variants.

5.) VGA, keyboard, and banking. I group these together simply because the same basic glue logic that does the bank mapping is also responsible for the video RAM and keyboard array mapping in the Model 4. I would probably take an older, smallish, FPGA such as a Spartan 3 or 6, or a Cyclone IV, or similar as the base. There are several designs to translate either PS/2 or USB keyboard scan codes to the keyboard matrix for the keyboard, and mapping 2K of video RAM for text-mode VGA is a common-enough beginning FPGA project out there. For the banking, I have a rough design to make the first 32K of RAM shadow every 64K MBASE page so that using MBASE as the bank number would be useful (and I have a neat trick to cause that to not waste half of the RAM size, too). Banking/MMU for more than 16MB is possible, but LS-DOS 6 limits you to 8MB anyway.

6.) Using a microcontroller du jour as a 'systems management engine' of sorts. This I'm not excited about, honestly. If anything, I would grab another eZ80 as a system supervisor, or maybe go cheap and use a Blue Pill or any of a number of STM32 chips. But, there is a RasPI console processor for the RC2014, so it's not like it wouldn't be doable. The Z80-MBC2 shows one way to do it, and is very simple.

7.) Floppies. Emulating WD1793 in a Blue Pill or in another STM32 chip would be an interesting exercise if you really want floppies, or the footprint for the WD1773 as used in the gate-array 4s wouldn't be a hard thing, and could be an option.

8.) Debugging interfaces. eZ80 can do JTAG with full boundary scan support, as will programmable logic; so JTAG is essential. The ZDI embeds a full in-circuit emulator (ICE) into the chip itself, with a few caveats due to the pipeline (breakpoints, for instance, have some restrictions thanks to the pipeline), so you want ZDI support, and a second eZ80 could perform that function rather well. You can then even say that you have 'dual eZ80s @50MHz in you TRS-80 clone' as a 'bragging' point if you'd like.

9.) Expansion. I would likely just use the RC2014 bus for any expansion, as then you open up many options. Of course, the Model III/4 external I/O connector would likely need to be supported. And using programmable logic means that adding a peripheral to the core glue would be relatively easy.

So, this is a skeleton for a project; you need some surface-mount PC routing experience and a good design with a schematic in something like Eagle or KiCAD to get started. Plasmo, if he were interested, could do this in a very short amount of time, but he has other projects he's doing. I am capable of doing this, but I'm not retired yet, so my time is limited.

And, finally, the name. Well, the model number of 5 is actually already taken as far as LS-DOS 6 is concerned (that's the 4P). I have a catchy name thought up, but I need to run it by a lawyer friend beofre I post publicly to make sure I'm not stepping on anybody's trademark.

Thanks for the fun mental exercise; this project is one of several possible projects I'd like to do; like I said, I personally want to do up a Z380 simply to say that I've done it, and then there are the two Z80-socket-plugin upgrades I'm designing as well (Z180 and Z280, as both can drive the DRAM refresh fine and should be drop-in upgrades that can simply plug in to the Z80 socket and run). With the eZ80 the landscape is different; the TRS-80 hardware could just have a pair of sockets to plug in an existing eZ80 module, or it could plug in as a daughterboard to the headers on the eZ80 dev boards for prototyping.... in any case I'm going to start with hardware I already have in hand.....
 
Last edited:
danielbooneamerica said:
Is there no development kit for 280/380 available from Zilog like for eZ80?
Click to expand...

There is a Z380 evaluation board, but it's expensive. Look for part number Z8038000ZCO, around $500. There is also a Z80382 board, but it's even more unobtainium. That's part of my motivation, in fact, to build something myself that could become the basis for a Dev board. There's a photo of the official Zilog Z380 board at https://www.mikrocontroller.net/attachment/331910/Z80380EvalBoard.JPG

No current Dev board for Z280, either. Plasmo's Z280RC would be a good substitute for an official Dev board, and the price is reasonable from him.
 
danielbooneamerica said:
Also about Tim [Mann]. I am sure most of you are aware he wrote a emulator for TRS80. I have this and it works VERY well. A few bugs but minor. I am sure as time goes on he will refine even more. Only people like Tim, Bill & Roy have that inside intuition about big picture of TRS80 to write a good emulator. Man if Tim makes a development kit one day the possibilities. Like I was thinking if you could start more than one emulation at a time then network them together on PC in a virtual network or just other great ideas.

If you have not supported Tim with a purchase please do so and lets pray he keeps releasing more advanced emulators.
Click to expand...

You're referring to xtrs. I agree with you that it's great software. I maintain the Debian package for it and have made some minor contributions over the past 20+ years.

Unfortunately Tim is not currently (visibly) active with xtrs. He merged a bunch of changes (most to the man pages) from me a couple of years ago but there have not been any commits since 2018.

My inference is that he has big goals for an xtrs 5.0 (the current version is 4.9d), such as a GTK+ interface and Exatron Stringy Floppy emulation, but just hasn't yet been able to get those goals to completion.

Myself, I think there's no crime in busting into double digits for a minor version number; I'd like to see a 4.10. :D

I've written what I call the "World's Dumbest Profiler" for the program counter and stack pointer, and once I've got it wired up to zbx (xtrs's internal monitor/debugger) I may find the energy to shove it into a proper Debian package release.

Anyway, you can catch up on xtrs as Tim left it at its GitHub repository. Some of the "unreleased" changes since 4.9d have been in the Debian package for years (because they came from me), but none of the actually cool stuff.

I would find Model II support tremendously exciting, personally.

https://github.com/TimothyPMann/xtrs/
 
@danielbooneamerica, you wrote that your model 5 should have colour, if the colour capabilities were compatible with the coco, even using a 6809 for drawing, it might be possible to merge trs 80 model 4 and coco software.
 
danielbooneamerica said:
All over internet I see a wide range of discussion of what a Model 5 should have if it were to be built, what Radio Shack thought next model should have and what users would like to have.

Now here we are all these years later and we have no replacement TRS80 computer nor do we even have an agreed upon design.

All that being said i thought i would start a wish list.

* Note this is a hardware list only. We can assume drivers to support hardware would be developed also.

eZ80 CPU running @50Mhz executing code with 0 wait states.
Serial port.
SPI port.
VGA.
keyboard.
lots of RAM.
FLASH BOOT & DISK.
*Very important* TRS80 style bank memory & lots of it, think big people.

....this is a start.
Click to expand...

As result of this discussion, I have come to agree the eZ80, due to its I/O addresses being fixed for on chip peripherals, would always be in conflict for model iii. Model 4 using TRS/LSDOS could be made to work using behaved software.
 
mnbvcxz said:
@danielbooneamerica, you wrote that your model 5 should have colour, if the colour capabilities were compatible with the coco, even using a 6809 for drawing, it might be possible to merge trs 80 model 4 and coco software.
Click to expand...

I know nothing about coco but if this idea works i am all about adding as many goups as possible to using this board.

I guess you are saying use coco as video processor and when wanted run coco software also?
 
danielbooneamerica said:
I know nothing about coco but if this idea works i am all about adding as many goups as possible to using this board.

I guess you are saying use coco as video processor and when wanted run coco software also?
Click to expand...
Yes, exactly.
The hitachi version of the 6809 runs faster and has additional instructions.
 
Last edited:
Hello TRS80 community! I am writing you today about some of my earlier posts regarding new DOS version running on Zilog eZ80 CPU platform(s).

Before I have asked how many people were interested in next version of LS/TRSDOS 6 (would that be 7?). I am happy to report interest level is zero. Of course this is vintage forum not development forum.

I get collecting computers; I have collected other things in my life and understand about wanting original etc. I am not sure why anyone would want a TRS80 compatible in hardware. Most anything you want will run with some of these great emulators we have available. Hardware is a different story.

If you were to have next hardware progression of TRS80 then it would logically run all MODEL I, III, IV software in addition to having some new mode such as MODEL V. It would seem a new model would be backward compatible with previous models and include some new model.

I suppose there could be lots debate what new model hardware would look like had RS done it. But I think to say it’s safe to say --- it would be smaller, faster and bigger. If you needed hardware to access old media to recover data/programs etc might be a good reason to build something compatible but again this is not the case. Internet is full of used TRS80 computers that can be purchased and read old HD or floppies but again much of this could be done with available PC tools. All this being said I do not see a reason to build a MODEL V.

But if that is what you really wanted to do I have researched with aid of some talented engineers what would be best approach and design for this problem. Not saying it is only way it can be done but following description would be a clear path to having a machine that you could insert a TRSDOS 1.3,5.3.6.3 and press reset.

If machine is to be 100% binary compatible then you must do what RS did. Use same or 100% binary compatible processor at same speed and using same memory/video maps. If you alter any of these then it is not going to be 100% binary compatible. Example, some model iv’s when upgraded with faster Z80 or upgrades like xlr8 required patches to OS for proper operation. One problem is timing is done in software for things like delays, keyboard etc. If you have any change in speed then it’s highly likely you are no longer 100% compatible and some level of patching will have to be done.

Model IV used a processor that was not only pure binary compatible but software could change system clock to set needed speed. But just like 4P not every new system is 100% backward compatible. It had different boot ROMs and things like cassette port had changed. Life changes and things move on.

I suspect over time it would have become less important to emulate all older models. Example if RS still built this line of computers today it would probably not be a high demand that newest model still runs model 1 software. As time progressed, less and less model 3 users would still need supported etc. Usually if it does not cause design bottlenecks or cost dollars its ok to keep.

So you follow all these circles and it comes back to what do you want to do? Build a speed demon? Well most all your old software is not going to run. Build a memory giant? None of your old software could gain advantage in having this memory. Build a machine that runs all your old software unchanged? That is possible but not easy for model 1/3. If program was wrote for model 4 then it should move to a new machine easy but if wrote for model 4 and wrote by someone that didn’t know how to program, it will not port so easy (like bypassing SVC mechanism).

My life in simulation taught me one thing. Most anything including human brain can be tricked. Computers beg to be tricked. They are such controlling and controllable machines. I do not know much about model 2/12 but I think there are some lessons there about using more than one CPU. Keep that in mind while we go down this road.

I don’t know if you have seen videos on YouTube of Apollo spacecraft computer restoration. To keep this story short, engineers can trick this computer into thinking it is in a spacecraft descending to moon and then execute all its old flight software. It has no way of knowing it’s not in a spacecraft, tickle its I/O and that’s all it knows. A Zilog Z80 CPU has no way of knowing if it is mounted in a real MODEL IV or not….. if you tickle if right.

This brings me back to a DOS 7. Most all of you seem interested in running, using and learning about existing versions of TRSDOS but not necessarily picking up where that stopped and going forward. I get that but my interest is moving forward from where it stopped. I crafted a version down to where it almost runs with just one chip, eZ80.

Using built in memory and peripherals you can build a system on a chip. Yes it runs an OS very similar to LS/TRSDOS and even binary compatible with some old programs. But video is done in this case by a console terminal, disk using RAM/FLASH drives and GPIO can access about any hardware you want if you write software to do it.

I have tried in recent years to find someone to build these simple eZ80 hardware boards needed but there have been challenges in finding person(s) to help with complex projects and keep them focused. I raised money to pay for prototype boards and wanted first version to be eZ80 (which from inception was NOT to be backwards compatible) version which would allow me to complete a DOS version using this processor. A new but much more powerful version of DOS using this processor while NOT binary backwards compatible, was my goal. But they really could not focus and kept thinking in terms of building something backward compatible and of course I already had researched and worked with Zilog on this and knew we could not overcome I/O address conflicts. I had hope however. At one time one of the engineers from Zilog thought he knew of a way to trick eZ80 into remapping onboard I/O to new addresses, but it turned out not to be.

Most operating systems have more than one version. That is not unusual. Different version for each platform. Each having advantages and disadvantages. Most companies do not have just one hardware platform for their OS and not just one binary version of its OS for all its hardware. Even RS had more than one version of TRSDOS for more than one hardware platform.

eZ80 will run TRSDOS 6 compatible software just fine! TRSDOS 6 software was never to talk directly to hardware. All communication to hardware is done via OS SVC calls. OS communicates with hardware via BIOS. Windows has finally gotten around to following TRSDOS 6 ideas!

TRSDOS programmers guides, books, manuals etc tell you over and over, NEVER manipulate hardware directly but only using SVCs. I don’t remember where, but once I saw someone giving the dumbest TRSDOS 6 programming advice I ever read. They were saying SVCs were slow etc and call these routines directly using call statements and ignore SVC mechanism. There is so many things wrong with this statement it’s not worth debunking and demonstrates armature programming. I normally look kind of funny at people whom tell me to ignore advice of systems creator. Also by bypassing system SVCs and calling routines directly you break all the mechanisms in place to make sure correct system state is maintained. For example making sure correct memory bank is switched in at correct time and switched back when done.

If programs are written correctly under TRSDOS 6 they should run fine on an eZ80 version of this TRSDOS.

Solution: Radio Shack already demonstrated this. A computer with more than one processor is solution. One portion using Z80 or correct binary compatible Z180 running at clock speed as close to possible as original (unless were patching dos). This clock speed could be under software control but if you are running old software with timing for a 4 Mhz machine you gotta slow your roll somehow.

This processor should communicate with a more powerful processor. Booted one way Z80/Z180 is master of show. Booted other way the more powerful processor can run show. I would think of more power processor as being HOST and Z80/Z180 is more like dedicated application processor. I think this is basically how you can describe how RS big brothers to model 4 worked.

Since RS design engineers clearly demonstrated more intelligence and product insight when designing PCs than IBM PC engineers, I suspect RS may have had some multi CPU boards as their next step for businesses.
Since TRSDOS is an intelligent overlay driven OS and not a simple collection of subroutines like CP/M it would have been developed to support multi processors with time.

If you will imagine a Z80/Z180 with its I/O attached to a host processor. A simple interface between two CPUs, each time Z80 read/writes I/O this data comes from or goes to host processor then forces an interrupt to host. Host CPU then becomes a peripheral acting as disk, keyboard, video etc. A simple interface can act as R/W registers between these CPUs. Anytime Z80 writes or reads one of its 256 I/O ports this would force an interrupt to other CPU.

TRS80 also used memory mapped I/O. Several approaches could be used to solve this. Only way that will make a 100% binary compatible machine, is to mimic this map exactly. Map memory mapped I/O to host CPU.
Example host CPU literally presses keys on TRS80 keyboard (or that’s what *ki driver thinks anyway) using memory mapped I/O. In fact Z80 should have its entire 64K memory mapped as dual port ram (I think 64kX8 DPR is on one chip now) and occupy some 64k space in host eZ80 address space. With eZ80 able to read/write/monitor entire 64k address space of Z80, host would have total control over memory Z80 sees (except bank). Z80 should still have bank memory and that bank memory would not be directly available to host CPU. TRS80 video RAM will still need to be supported and host CPU must be able to read and even write to this RAM.

I promise you, the programs you are trying to run can only see two things….memory and I/O, nothing else. Trick memory and I/O into thinking its 1978 and its mounted in a Model I and it will be happy and run. Using this coprocessor method the eZ80 would mimic any I/O device the TRSDOS Z80/Z180 sees. In fact this can all be done so that not one byte would need changed.

Yes there are a few problems that need solved here and code to be wrote but, it is one of nearest 100% pure emulation/simulation model you are going to get. It’s all about fidelity of simulation.
eZ80 could have interface added to add about any card such as floppy controller to read actual old floppies or even read/write TRS80 I/O bus. But trust me if you can fool Apollo flight computer into thinking it’s in lunar landing and on its way to moon you can fool a Z80 into thinking it’s in a RS computer, it’s not that complicated.

So for me it’s kind of where community wants to go. I can provide DOS versions for Z80/Z180/eZ80 etc and configured in lots of ways. Sometimes we know when our own internal watchdog timer is getting ready to expire and I have a desire of passing my body of work onto younger fertile minds.

About half my life was spent in simulation for fighter aircraft and obese commercial aircraft, other half was IT background. I am willing to work with interested parties in a project to at least produce some working model. Again I am interested in creating newer versions of DOS but need hardware platforms for this to run on. If it is a project that also runs older software to make everyone happy I am good with that too. You have to be careful however when you try building something that is everything to everybody.

As an example I am adding a set of floating point routines to DOS. I think I can make these run in bank memory and called using system SVCs. Running in bank memory will keep us from using any precious memory in our 64K window.

I am really excited that I was given permission to roll these tested floating point routines into my favorite DOS. Here are some of the features it will have in Z80 assembler.

Complete library of routines including the basic 5 functions (+, -, *, /, squareroot) as well as trigonometric functions (sine/cosine/tangent), inverse trig functions (arcsine, arccosine, arctangent), hyperbolic functions (sinh/cosh/tanh), inverse hyperbolics functions, logarithms, exponentials, comparison, and rand:

f24 - These are 24-bit floats modeled after IEEE-754 binary32, removing one exponent bit and 7 significand bits. These are well-suited to the Z80-- the operands can be passed via registers allowing the routines to have a small memory and CPU-time footprint, while still having 5 digits of precision. NOTE: f24toa converts an f24 float to a string that can be displayed. This is found in the conversion folder.

f32 - an IEEE-754 binary32 format (the classic "single")

single - Represent all IEEE-754 binary32 numbers, but the layout of the bits is different (keeping all exponent bits in one byte) and represents 0/inf/NaN differently allowing slightly more numbers to be represented.

extended - These are 80-bit floats providing 19-digits precision. These are quite fast all things considered.

I don’t know about you but this all gets my blood pumping.

My decisions from this point forward will be driven by feedback. I can assist financially and/or technically with TRS80 compatible and if there is no interest I am at least interested in hiring someone just to fab a board for me to develop future software on.

My main need is a platform that provides bank memory. 32K bank memory 8000h-FFFFh. This platform should be designed with idea that it could accept different processors with minimal changes (Z80/Z180/eZ80 etc).
For example I added to this discussed DOS, a scheduling system similar to what I used under MVS for handling workload/job loads. I have other things I am interested in but, running 13 Ghosts in model 3 mode is not one of them.

In addition I am looking for someone to take over when my watchdog expires.

I welcome discussion on this subject if anyone is interested.

Daniel
 
I think by the time a new TRS 80 model could be released, it would have already been hopelessly outdated. The era of the Commodore Amiga, Atari ST, Apple Macintosh, and PC AT and it's clones had already started. Another totally proprietary system would have had a hard time taking hold in such a competitive marketplace. Tandy did the right thing by shifting away from their proprietary designs, and embracing the PC clone. Even Atari and Commodore jumped on the PC clone bandwagon.
 
animekenji said:
I think by the time a new TRS 80 model could be released, it would have already been hopelessly outdated. The era of the Commodore Amiga, Atari ST, Apple Macintosh, and PC AT and it's clones had already started. Another totally proprietary system would have had a hard time taking hold in such a competitive marketplace. Tandy did the right thing by shifting away from their proprietary designs, and embracing the PC clone. Even Atari and Commodore jumped on the PC clone bandwagon.
Click to expand...


Looking at it thru today's glasses of back then has advantage. All of those systems you listed were proprietary property back then also. There were no open systems as we know it today. In fact Tandy was making it easy to design and add cards while IBM and Mac was trying kill that idea. Two of them developed into a standard after many decades of reverse engineering, courts, markets and things I cannot imagine.

If commodore was still finding a market or Atari then I am sure you could sell a TRS80. The MODEL 4s filled a gap between businesses that were too small for a Xenix system but did not want to be seen running their business on a Commodore. TRS80 line did appear business like and had one big plus, sales and service in most cities across USA and beyond.

In this thread I think we are dreaming that a decision has been made at Tandy let's roll. Top secret development team has been assembled and rumors in market are flying. Now what would this machine have?

Color I think for sure as example.

As far as obsolete before built, well all the machines fit that definition. They all obsolete by time released and relic by time I can afford.

Of course you are right, later in life standard was IBM PC architecture and no business would be seen without it except what at that time the guys they thought odd for using mac.

Look how that became a whole new chapter in our evolution to a single architecture (pretty much).

You are right RS pushed CoCo on home market and made a good margin on them.

Those days. I suppose we are pioneers same way others pioneered auto, air and space. It's fair to say someone somewhere used a TRS80 to help solve many important problems.
 
You must log in or register to reply here.
Back
Top