System architecture for a Z380 TRS-80 compatible.

[lowen]

So, after a lot of investigation and thought, I have found that it really isn't feasible to make a 100% compatible super TRS-80 using an eZ80F91 as the core. I denied that in myself, thinking that a fast eZ80 would be attractive enough on its own, but this is a vanishingly small group here that would even be interested. I have gradually warmed up to the idea of a Z380 design. The poll I put out last March, and the thread I started way back in 2017, show that the users who really care about upgrades and such also care about 100% Model III/4 hardware compatibility.

So I'm in the early design phases of a Z380 system to be 100% Model 4P compatible (4P, since then it only needs a boot ROM and could then use the MODELx/III files for Model III compatibility).

This poll lists the options I have for this system. I am interested in the group's thoughts on the advantages and disadvantages of each system type.

Thanks in advance!

EDIT: Note that I am planning on making the complete design open source.

 

[Eudimorphodon]

What are you planning to use for the video output hardware? And keyboard input, so far as that goes. (Interface to an actual matrix, or some kind of PS/2 or USB converter?)

 

[bladamson]

Yeahhhh, I was looking at the eZ80 too, but it just doesn't look like it's compatible enough to be a drop-in super-replacement in these old boxen. All those built-in peripherals get in the way.

What are you planning to use for the video output hardware? And keyboard input, so far as that goes. (Interface to an actual matrix, or some kind of PS/2 or USB converter?)

I have a plan for doing that on the Model II, actually. With the way the z80 wait states work, it ought to be trivial to just wire some kind of fast microcontroller's gpio to the z80 bus with a minimum of support logic. Then program it to respond to the same IO ports in the same way, and act like RAM when the vram is paged in. Maybe not 100% compatible as I am sure the timing would be slightly different, but ought to be fine for stuff that isn't super tightly timed. Then can bit bang video and keyboard on other pins. There are several different libraries for bit banging VGA on various uCs, so surely it would be more than possible to bit bang 640x240 TTL monochrome out to the video analog board too.

That'd be the easiest thing for me to do personally anyway, as I don't know a thing about complex cplds or fpgas.

 

[lowen]

First, thanks for the question, because one of the biggest lessons I learned in 2020 is that 'feeping creaturism' is the enemy. I want to be as simple as possible; ideally, I'd like a Z380 CPU, some RAM, a medium-sized FPGA, CPLD, or even discrete logic for glue, boot ROM, and video framebuffer(s), and then the systems management and storage hardware would manage the disk storage, the actual video output, and keyboard input. For 100% 4P compatibility, the keyboard has to present itself as a memory-mapped matrix and the framebuffer has to present the same way.

For the external interface, I would want a USB port for keyboard and maybe storage, and either VGA or some digital output (I would lean towards DisplayPort myself). The systems management hardware will handle the mapping of the USB keyboard to a matrix, similar to Inkey/80, and the mapping of the TRS-80 framebuffer to a region of the output video (I say a region; could be upscaled to the whole screen, could be 'windowed' but I'm wanting to guard against initial feature creep while not painting myself into a corner like the programmers of TRSDOS 1.3 did with disk support). Storage would be emulated FDC and HDD, with DMK and VHD disk images on SD card or similar; I have NO DESIRE to try to build a real FDC board. I'm thinking half a dozen chips, maybe a couple more. I want SIMPLE.

For prototyping I have four Z380 chips, two soldered to carrier boards for breadboarding, and smattering of Altera DE1 and DE2 FPGA boards which have VGA output and PS/2 input. I also have an assortment of STM32 Nucleo boards; the STM32 has 5V-tolerant I/O. Some 74LVC245's and the Z380 can talk to the FPGA on the DE2. The DE2's little brother the DE1 has TRS-80 cred, being the base for the Coco3FPGA project, and Coco3FPGA shows how to accomplish a bunch of this stuff.

For a production board I would want to target the Mini-ITX form factor, making cases, power supplies, etc trivially easy to find. I want SIMPLE: like plasmo's ZZRCC, which is three chips (Z280, RAM, CPLD). Simple is easier to troubleshoot.

If I only ever build and document the prototype, with the code and design open, I would be mostly satisfied; the likely userbase is just too small to get a reasonable return on investment for the amount of time it will take. The response I get here will tell me if it's a feasible product or not; regardless, I'm planning to make it a project for the next year or two.

 

[lowen]

Yeahhhh, I was looking at the eZ80 too, but it just doesn't look like it's compatible enough to be a drop-in super-replacement in these old boxen. All those built-in peripherals get in the way....

For something to drop in to an existing system, you basically have the Z180 (in either Z80180 or Z8S180 form, or even the HD64180) or the Z280. These chips do the RAS-only refresh cycles like the Z80 can and like the DRAM in these old systems needs. Z380 can work with somewhat newer fast-page-mode and EDO DRAM, but does a CAS-before-RAS refresh instead of RAS-only, and thus won't refresh the RAM in the old systems. eZ80 has no dynamic RAM support at all; you'd need a DRAM controller tacked on.

That's part of the reason I'm looking at a whole new, but small and SIMPLE board.

EDIT: And Ian Mavric already does an HD64180 board, the 4cellerator, and I wouldn't dream of competing with him in that segment; Ian's done too much good for the community. A Z280 board is a possibility, though.

 

[pjhacnau]

First, thanks for the question, because one of the biggest lessons I learned in 2020 is that 'feeping creaturism' is the enemy. I want to be as simple as possible; ideally, I'd like a Z380 CPU, some RAM, a medium-sized FPGA, CPLD, or even discrete logic for glue, boot ROM, and video framebuffer(s), and then the systems management and storage hardware would manage the disk storage, the actual video output, and keyboard input. For 100% 4P compatibility, the keyboard has to present itself as a memory-mapped matrix and the framebuffer has to present the same way.

I fully understand the "Get the damn thing going!" sentiment. I just wonder where you see it going after that. Given the Z380 can have a flat 32-bit address space and multiple register banks (just to mention two features) you could do something interesting down the track with it. But for real 4P compatibility you'd just leave it in Z80 mode.

Also, if the end goal is "just" a modern simple 4P, why not just stay with the z180? You could create a "4P + XLR8er" system that way and, with an FPGA, handle everything that was possible with the real hardware. I wouldn't see this compete with the 4cellerator; it's a totally different beast to an exact re-creation of the original.

Not criticising anything here; rather trying to understand your choices.

PJH

 

[lowen]

I fully understand the "Get the damn thing going!" sentiment. I just wonder where you see it going after that. ...

You mention two of the Z380's killer features. The greatly expanded instruction set is another. This is an excellent question, by the way, as too many of my projects have been more "this will be fun to put together" rather than "this will be fun to use." It's like putting together a CP/M 68K machine; what do you do with it once it is together, or is it the perpetual project you're doing mostly to say you're doing something?

Anyway, by sticking with a basic strict 4P compatibility once the boot ROM has finished setup, there is automatically a large archive of software that will just work.

And then this becomes a springboard for other projects, like a newer operating system that could run multiple virtual TRS-80's, a Z380 hypervisor so to speak. But I have had a tendency in the past to make a project so comprehensive and complicated that I don't finish it. But I'm warming up to the idea of at least adding a memory expansion bus; while I doubt I would try for a 4 GB system, 128MB is pretty easy on one 72-pin SIMM.....

Also, if the end goal is "just" a modern simple 4P, why not just stay with the z180? ....

These are excellent points, by the way. The complexity levels of a Z180-based design and a Z380-based design are comparable; there might even be a bigger market for a 33MHz Z8S180 design. It's worth thinking about, for sure.

Not criticising anything here; rather trying to understand your choices.

PJH

You're points are valid, and I appreciate the questions, as they do make me think about why I'm choosing certain things. In the end analysis, I am wanting the fastest and most featureful strictly upwardly compatible to the 4P machine I can actually get finished. Z380's features are superb, but compatibility needs to be tested. Last year at this time I had convinced myself that the eZ80F91's lack of strict compatibility wasn't an issue, but I was just plain wrong, because backwards compatibility does matter, unless you're just wanting to build it for the sake of building it.

And the ability to say that your TRS-80 is a full 16/32 bit system has a definite coolness factor.

Thank you for the thoughtful feedback!

 

[fritzeflink]

Hi lowen...

I'm with you.

 

[lowen]

Hi, Fritz! Good to see you around!

 

[clh333]

Z380, CPLD, bus extension / expansion. (my 2c)

 

[lowen]

Care to elaborate any on those choices?

 

[pjhacnau]

Care to elaborate any on those choices?

Well while clh333 is still to reply I'll throw in my thoughts as I voted for that line too.

First, because you didn't give the option separately, I'm treating "CPLD" as "CPLD/FPGA" - whatever meets your requirements better.

For me, something like an ARM as a secondary processor seems just . . . wrong. Given a CPLD and even an FPGA is a logical extension of the GAL/PAL logic that was current in the M4 days, it seems more appropriate. And it feels (to me) like CPLD is to PAL about where the Z380 is to the Z80. You've said your primary aim is a "fast 4P". A Z380 + CPLD would allow you to do that and include (say) HiRes and Orch90 in the one package, along with floppy and hard drive emulation and networking (either via serial or direct - say TRS-IO derived). I think that would more than meet your original goal. However, especialy if you use the 380, I would be looking at some expansion bus to allow for easy use of the 32 bit address space. If you went FPGA you could easily stick a PCI bus in there. But that comes back to time, resources, and what you want; something more minimal would still allow a lot.

Anyway, that covers my thoughts on the hardware side.

PJH

 

[lowen]

Well while clh333 is still to reply I'll throw in my thoughts as I voted for that line too.
....

For me, something like an ARM as a secondary processor seems just . . . wrong. Given a CPLD and even an FPGA is a logical extension of the GAL/PAL logic that was current in the M4 days, it seems more appropriate. And it feels (to me) like CPLD is to PAL about where the Z380 is to the Z80. You've said your primary aim is a "fast 4P". A Z380 + CPLD would allow you to do that and include (say) HiRes and Orch90 in the one package, along with floppy and hard drive emulation and networking (either via serial or direct - say TRS-IO derived). I think that would more than meet your original goal. However, especialy if you use the 380, I would be looking at some expansion bus to allow for easy use of the 32 bit address space. If you went FPGA you could easily stick a PCI bus in there. But that comes back to time, resources, and what you want; something more minimal would still allow a lot.

Thanks for the thoughts! You're very right when you say using an ARM just feels wrong; and yet TRS-IO uses an ESP32.... Storage emulation especially with files on a FAT filesystem would be quite difficult without some sort of processor to access, and with a goal of 100% 4P upwards compatibility exact WD1010 emulation for the HDC and exact FD1793/WD1773 emulation for the FDC will be required.

The FDC is actually the more difficult of the two due to the end of data INTRQ being tied to NMI and the timing of that, and the WAIT generation, although I might have some leeway there.

It may be that I could use a softcore processor in an FPGA to do it; I need to see which fully open softcores are capable enough to handle it. The Coco3FPGA project shows one way it could be done.

I'm still mulling it over, and weighing which option is something I think I can actually get done; feature creep is the enemy, and I'm doing this as a hobby, not a full-time job. Using a CPLD or FPGA (yes, I tend to group them together, too) plus an MCU of some kind means that I can build a somewhat generic board, start off with a simple monitor program and serial port, and do things in a stepwise manner.

For expansion, I'm mulling over some options: the extended RC2014 bus; or, the extended 16-bit ECB of the retrobrewcomputers.org site; or, 16-bit ISA; or, and this is quite ambitious, PCI.

Again, thanks for the comments!

 

[clh333]

I was following the sage advice: "It is better to keep your mouth shut and be thought a fool than to open it and remove all doubt." But since I have been called out by name I will offer what meager support I can for my opinion.

I begin with the assumption that backward compatibility with existing TRS-80 hardware and software is a prime design objective. The eZ80 has built-in capabilities that conflict with the TRS ROM addresses, so the choice seems to be between the Z280 and the Z380. The Z380 lacks some of the I/O traps and memory protection features of the Z280 but the 32-bit path and 4 Gb address space outweigh the deficiencies, in my opinion. You can do a lot more with 4 Gb than with 16 Mb.

The choice between an ARM, FPGA and CPLD is more difficult, and maybe depends on the designer's preference and experience (of which I have neither). But to quote Wikipedia: . "...non-volatile configuration memory. Unlike many FPGAs, an external configuration ROM isn't required, and the CPLD can function immediately on system start-up." ...and... "The most noticeable difference between a large CPLD and a small FPGA is the presence of on-chip non-volatile memory in the CPLD, which allows CPLDs to be used for "boot loader" functions, before handing over control to other devices not having their own permanent program storage." In techopedia: "CPLDs are leaders in the market of programmable logic devices, having multiple benefits like advanced programming, low cost, being non-volatile and easy to use."

Each of the TRS computers, from the Pocket PC to the Model 100 to the Model I, III and 4 exposed some form of bus expansion. A number of clever people designed peripherals which accessed that bus: the M3SE, FreHD, Orchestra-80, to name only a few. It seems unwise, in my view, to develop a new machine, purportedly backward-compatible, without including this useful feature. As it is I am currently reading TRS-80 Interfacing, Book 1, Jonathan A. Titus, Sams 1979 and although I do not have a Model I, I look forward to putting the trusty Model III to new uses. Rule the world, and all that.

You asked.

-CH-

 

[lowen]

I was following the sage advice: "It is better to keep your mouth shut and be thought a fool than to open it and remove all doubt." But since I have been called out by name I will offer what meager support I can for my opinion.

Indeed!

so the choice seems to be between the Z280 and the Z380. The Z380 lacks some of the I/O traps and memory protection features of the Z280 but the 32-bit path and 4 Gb address space outweigh the deficiencies, in my opinion.

As a bonus the Z380 is still an active component and can be ordered new. Z280 hasn't been new in 23 years.

The choice between an ARM, FPGA and CPLD is more difficult, and maybe depends on the designer's preference and experience (of which I have neither). But to quote Wikipedia: . "...non-volatile configuration memory. Unlike many FPGAs, an external configuration ROM isn't required, and the CPLD can function immediately on system start-up." ...

The typically non-volatile nature of CPLDs has a flipside: most of the CPLDs on the market have no startup delay required, they're ready to go and do their job as soon as power is applied. FPGAs need time to load their configurations, and the system design has to deal with that. An MCU has to boot up, and can take even more time to get started. And yes this choice IS more difficult, thus why I've asked here, since I certainly don't have all the answers, or maybe even not all the questions!

Each of the TRS computers, from the Pocket PC to the Model 100 to the Model I, III and 4 exposed some form of bus expansion.

I'm oddly enough looking to two expansion ports for sure: 72-pin SIMM for memory, and the standard TRS-80 4P I/O port. An RC2014 enhanced header wouldn't be hard or expensive to add.

You asked.

-CH-

I sure did, and thank you for answering! I spent both money and time chasing the eZ80 rabbit (pun intended), and would prefer to have a better idea up front this time around. For prototyping, I already have Altera DE1 and DE2 boards and STM32 Nucleo boards, so add in a Z380 protoboard and a prototype could come together pretty quickly. DE1 and DE2 boards have an Altera Cyclone II FPGA, some static and dynamic RAM, some Flash, and ports, including PS/2 keyboard and VGA, and an SD card socket, along with switches, LEDs, and displays that can be used for debugging.

 

[pjhacnau]

Indeed!


I sure did, and thank you for answering! I spent both money and time chasing the eZ80 rabbit (pun intended), and would prefer to have a better idea up front this time around. For prototyping, I already have Altera DE1 and DE2 boards and STM32 Nucleo boards, so add in a Z380 protoboard and a prototype could come together pretty quickly. DE1 and DE2 boards have an Altera Cyclone II FPGA, some static and dynamic RAM, some Flash, and ports, including PS/2 keyboard and VGA, and an SD card socket, along with switches, LEDs, and displays that can be used for debugging.

I snared a (relatively) cheap DE1 last year to run CoCoFPGA - happy to try some cross testing if you go that way and it will help. So long as you understand that my FPGA experience is mostly "bring up dev environment, build someone elese's code and write to FPGA".

PJH

 

[lowen]

I snared a (relatively) cheap DE1 last year to run CoCoFPGA - happy to try some cross testing if you go that way and it will help. So long as you understand that my FPGA experience is mostly "bring up dev environment, build someone elese's code and write to FPGA".

PJH

I will certainly keep that in mind, and I appreciate your offer!

 

[whartung]

Curiosity, not specifically in topic, but, maybe.

Can the Z380 work with "virutal Z80s"? Like, more than one? Specifically, say you had a native 32 bit Z380 system, would it be possible to host multiple CP/M instances within the memory space so as to be able to run "native" Z80 CP/M programs? The higher end x86 processors somewhat have this ability (though I don't know how it's manifest). Just wondering if the Z380 had anything similar, or is it more like the 65816, which is pretty much in "either or" mode.

 

[pjhacnau]

Thanks for the thoughts! You're very right when you say using an ARM just feels wrong; and yet TRS-IO uses an ESP32....

Excuse me while I indulge is some massive hand-wavy simplistic statements

I think there are 2 reasons that the TRS-IO uses an ESP32:

1) Anything lower-powered doesn't actually save that much money
2) It handles the whole networking stack with minimal code on the TRS80 itself.

With a fast Z380 and extra memory it should be relatively straightforward to do a driver to run in the main processor. LSDOS already allows for more than 3 swappable banks; you could allocate some "extra" banks for tx/rx buffers. Which raises the question - I'm assuming you'll support bank switching; how do you plan to do it and how much memory will you provide - I'd be happy with something like 512K which I think is the max LSDOS handles.

PJH

PS: Yes I just glossed over a big amount of effort by . . . "someone" to write said driver and make it work.

 

[lowen]

These two posts have inter-related topics, so I'll reply to both once....

Curiosity, not specifically in topic, but, maybe.

Can the Z380 work with "virutal Z80s"? Like, more than one? ... Just wondering if the Z380 had anything similar, or is it more like the 65816, which is pretty much in "either or" mode.

This is actually right on topic, because this is a capability I would be interested in myself. Unfortunately, Z380 is an 'either-or' processor, although that can be on an instruction-by-instruction basis for certain aspects. The Z380 has four modes selected by two bits: the first bit is 'Native/Extended' and the second bit is 'Word/LongWord' and together these give four modes: Native/Word, Native/LongWord, Extended/Word, Extended/LongWord. Native mode is Z80/Z180 compatible, where only the lower 16 bits of addresses for executing code and vectoring interrupts are used (PC and SP specifically will have their top 16 bits forced to all zeroes). Extended mode allows code to be executed anywhere in the 32-bit address space; the ramifications of a 32-bit Program Counter and 32-bit Interrupt vector capability are far-ranging, much like ADL mode on eZ80. A single instruction switches from Native to Extended, but a RESET is required to switch back. The reason for this is explained better in the Z380 User Manual than I can summarize here.

Word mode causes data operations that operate on 'words' to be 16-bits, compatible with Z80/Z180. LongWord changes this behavior to operate on 32 bits.

These subjects are dealt with in the Z380 User Manual first on page 5 (PDF page numbering), and then in Chapter 3 on pages 23 through 25.

In an a nutshell, no virtual Z80 mode like the V86 mode introduced by the Intel i386. There were early rumors and docs that eZ80180 was going to do a V80 mode and have a fully-functional MMU, but none of the currently-available eZ80's (eZ80F91, F92, F93, and L92 as well as eZ80190) have those capabilities.

---

...
2) It handles the whole networking stack with minimal code on the TRS80 itself.

It's also handling the WD1010 emulation. That is a significantly complex thing. As far as networking stack goes, any of a number of chips used on boards that typically get used by Arduino shields, such as the line of WizNET chips, can do the TCP/IP offload. The WD1010 emulation is another story.

With a fast Z380 and extra memory it should be relatively straightforward to do a driver to run in the main processor.

There are some TCP/IP stacks that will build on eZ80; it shouldn't be hard to get those to run on Z380. The hard part is getting an LS-DOS to run in the Extended mode. I'm planning on starting simpler than that, with the Z380 in Native/Word mode and work my way up from there, step by step. If I can make the individual steps small enough, I can eventually get up the ladder and get hardware built and out.

LSDOS already allows for more than 3 swappable banks; you could allocate some "extra" banks for tx/rx buffers. Which raises the question - I'm assuming you'll support bank switching; how do you plan to do it and how much memory will you provide - I'd be happy with something like 512K which I think is the max LSDOS handles.

LS-DOS allows banks 0-7 in stock trim. Since the upper 32K of the lower 64K is bank 0, you have the second 64K as banks 1 and 2, the third 64K as banks 3 and 4, the fourth 64K as banks 5 and 6, and then the lower 32K of the fifth 64K as bank 7. This is 288K.

Yes, I plan to implement Model 4P-compatible bank-switching (a simple MMU, in reality), with a port to select which 64K is mapped to the second 64K in a 128K 4P memory map. This is compatible with a lot of software already. I plan to also have a bit better MMU capability, but since the Z380 does not have an MMU of any kind (short of the really oddball chip select registers) it could be anything. I'm going to start simple: 4P-compatible plus a port to select which 64K to map.

PS: Yes I just glossed over a big amount of effort by . . . "someone" to write said driver and make it work.

While I don't have a TCP/IP driver, I DO have an @BANK driver that I wrote back in the late 80's/early 90's for the the 80Micro 320K mod; with minor modifications it can work with any memory expansion that uses a similar banking technique. My driver expands the supported memory capability to 1MB+32K using a 32-bit BAR and BUR (see page 7-10 (PDF page 85) of the Programmer's Guide to TRSDOS/LS-DOS 6 for details on @BANK and the BAR/BUR); BAR and BUR could in theory be expanded up to 256 bits, but that would be the LS-DOS limit due to the bank number needing to fit in one byte (LBANK$). 256 banks yields a machine with 8MB+32K.

Writing a good TCP/IP stack, on the other hand, is hard work. Better to use already well-tested code; otherwise it'll never get done.