System architecture for a Z380 TRS-80 compatible.

[Eudimorphodon]

So, what about an RC2014 RTL8019 card? See https://github.com/Manawyrm/RC2014-Ethernet and https://github.com/Manawyrm/RC2014-Ethernet-Firmware ?

That's pretty much what I was talking about on the nose; Realtek is still churning out "full" 8019s and they also sell a similar chip which has the same core but it has some of the ISA-specific bus glue ripped out. (The 8019 includes full plug-and-play ISA bus decoding, including address decoding for an onboard EEPROM, etc. The smaller chip is just the raw 8-bit bus and interrupt lines but is otherwise so similar you can use the same drivers; Eeguru put one on a Tandy Plus Bus card recently and it worked with a generic NE2000 driver.)

[lowen]

Incredibly stupid idea: if you're confident/eager to get TRS/LS-DOS 6+ running on an eZ80 and the switch to the z380 is entirely forced on you because of the impossibility of achieving backwards compatibility with I/III software on the eZ... and we're already talking about a multi-CPU design anyway, how about using an eZ80 paired with fast Z80 (they come up to 20mhz, right?) and Model I/III software (and maybe anything 4-centric that genuinely won't work on the eZ80 because it tickles the hardware in ways that can't be patched) runs on the "classic" CPU? Maybe even chuck a 4k dual-ported RAM "mailbox" between the two CPUs (maybe have it double for video memory?) and map peripherals like the floppy controller to the classic Z80 (at the Model III/4 compatible addresses) so it could optionally act as an I/O offload processor for the eZ80? A 20mhz Model III is more than anyone needs.

Not at all stupid, and essentially similar to the Model 16/6000 design with the Z80 doing I/O and Model II software, but the 68K being available for Xenix.

I WANT to do an eZ80F91 LS-DOS machine; I also want the machine to be more than my own personal prototype and get use elsewhere. It becomes a pragmatic decision; 'build it and they will come' or 'build what is already wanted.' While I'm downsizing my eZ80 stock, and am keeping at least one or two modules to play with, but I am steadfastly refusing to put to much on my own plate for 2021; got burned last year by COVID (in more than one way) and am not going to repeat the experience.

Just because it's possible does not mean it's feasible; in 2020 I got caught up in what was possible which turned into something that wasn't feasible given the circumstances, and I'm not doing that again.

(That idea gets less viable if you share the same RAM between the two CPUs, I suppose, although it's probably theoretically possible if you build a sophisticated enough memory controller in your FPGA. Although I guess if you do that then you wouldn't need the separate dual-ported RAM part unless you still want separate ram for video, which might not be a bad idea considering the bandwidth drain it's otherwise going to impose.)

I would go with a design similar to the Model 16 where there is a small window (32K) of shared RAM between the Z80 and the 68K. But such a design is far more complicated than I realisticallyhave time to do. A small RC2014 Z380 with simple 4P hardware compatibility is within my time budget, cost budget, and skill level to actually get done. I'm tired of just talking about it; I want to play with the hardware already.

Out of curiosity: does this desire to not have the BASIC onboard stem from technical concerns or is it to avoid embedding proprietary/encumbered software into the system? It might theoretically be useful in the bootstrapping-it-all-up phase to be able to drop into BASIC and poke the hardware. Although... I guess in theory isn't there a rumor at least that the Model 4P ROM has some kind of secret serial boot/debugging capability built into it?

I prefer to not include potentially encumbered intellectual property; plus the 4P already carries the 'machine type' of Model 5....

The debugging and serial boot capabilities of the 4P are nice, and are documented in the Service Manual for the 4P.

---

That's pretty much what I was talking about on the nose; Realtek is still churning out "full" 8019s and they also sell a similar chip which has the same core but it has some of the ISA-specific bus glue ripped out. (The 8019 includes full plug-and-play ISA bus decoding, including address decoding for an onboard EEPROM, etc. The smaller chip is just the raw 8-bit bus and interrupt lines but is otherwise so similar you can use the same drivers; Eeguru put one on a Tandy Plus Bus card recently and it worked with a generic NE2000 driver.)

I had no idea it existed until today. I am a firm believer in software and hardware reuse; why should I poorly reinvent a wheel that someone else has working already and has released under an open source license compatible with what I'm planning to use?

As much as I like ECB, the RC2014 bus has mindshare, and seems to be a good and simple foundation to build on.

[Eudimorphodon]

I would go with a design similar to the Model 16 where there is a small window (32K) of shared RAM between the Z80 and the 68K. But such a design is far more complicated than I realisticallyhave time to do. A small RC2014 Z380 with simple 4P hardware compatibility is within my time budget, cost budget, and skill level to actually get done. I'm tired of just talking about it; I want to play with the hardware already.

Just googled up RC2014, and looking at the structure of the bus... When you say "z380 with simple hardware compatibility", do you mean a single card with the CPU and all the 4P-specific parts on it, or spreading it over an RC2014's bus backplane? Just spitballing again, would it make sense to break the "4P I/O" bits into one board and the CPU components into another so theoretically they could be mix-and-matched? I'm reminded of how back in the day people used to homebrew "TRS-80 cards" which had the Tandy specific video display/keyboard/ROM bits to plug into S-100 bus backplanes along with standard (or lightly modified) S100 Z80 CPU and memory cards. Basically what separates a "Model 4" from a generic CP/M-style machine is:

• The dual mode (64/80 column) memory-mapped video. (switchable addressing/paging for 3/4 modes)
• Memory mapped keyboard matrix.
• 14k ROM/write-protected RAM @0000h in Model III mode
• TRS-80 specific I/O addresses and peripherals. (Parallel port, I/O registers, cassette/sound, etc. Paged around between 3/4 mode)
• Disk/storage devices (putting this as a separate bullet point because it may be apropos to put these on a separate card from the "core" TRS-80 bits.)
• TRS-80 Model 4-compatible main memory paging. (This is awkward? Does RC2014 have something like the *PHANTOM line in S100 where one card can grab the bus and override another's address space, or would the TRS-80 I/O card at minimum need to host the base 64k of main memory and/or use one of the "user" lines on the extended bus to communicate with any other memory card?)

Basically I'm wondering if there's any explicit advantage to sticking this on the same card as the z380, or if it could be modular-ized. Tackling things in pieces might help get stuff out of your head and into hardware quicker. And it also would open the door to playing mix-and-match with various components so people that aren't interested in X or Y of the total spec could easily borrow Z to roll their own spin on it.

(For instance, at the lowest end a "TRS-80-IO-card" locked into the Model III memory map and paired with a Z80 CPU would scratch the "I just want to play Robot Attack on a real machine but my Model III is terminally cranky" segment of TRS-80 users. Also if you divorce things storage devices onto their own card then it opens up various possibilities for choosing between, say, cheap and cheerful floppy drive/controller emulation entirely on an STM32 verses a full-stack FPGA floppy controller emulation with pin headers and everything, etc.)

I mean, I guess obviously modular-izing would mean multiple PLDs instead of one big fat FPGA, but if smaller-scale CPLDs are on the table then maybe it could be a plus? No idea. I don't know how you were envisioning doing I/O with the z380, if it would explicitly rely on more-than-8-bit-wide access to anything other than RAM.

[lowen]

Just googled up RC2014, and looking at the structure of the bus... When you say "z380 with simple hardware compatibility", do you mean a single card with the CPU and all the 4P-specific parts on it, or spreading it over an RC2014's bus backplane? ...

I mean, I guess obviously modular-izing would mean multiple PLDs instead of one big fat FPGA, but if smaller-scale CPLDs are on the table then maybe it could be a plus? No idea. I don't know how you were envisioning doing I/O with the z380, if it would explicitly rely on more-than-8-bit-wide access to anything other than RAM.

You know, this might not be a bad idea at all. I honestly hadn't thought of doing it that way. Thanks for the insight, and the inspiration!

EDIT: I knew I had seen something similar to this idea, with TRS-80 compatible hardware on S100, at Dave's Old Computers: http://dunfield.classiccmp.org/t80s/index.htm

[dittman]

This RC2014 card lists TRS-80 compatible graphics as a feature and shows the system running Galaxy Invasion: https://www.tindie.com/products/robd...it-for-rc2014/

[whartung]

The whole microcontroller argument doesn't bother me. Not sure how one "black chip with silver legs" is any different from any other "black chip with silver legs" if you get what you want out of the other end.

Something I've discussed before, conceptually, is the idea of the "sufficiently smart I/O processor". Now, mind, I am not a hardware person. I'm software, I think in terms of boxes and lines and whiteboards.

In my mind, it's a Raspberry Pi Zero, but that's simply there as an example.

To me, the singular requirement for such a device is a parallel interface to the host CPU.

There are a lot of advanced I/O devices out there for μC, but today, the vast majority of them use some serial interface.

While you can bit bang something like SPI on a 4Mhz 8bit CPU, it just crushes what little I/O bandwidth you have.

This can be offset by some special hardware to drive SPI at "full speed", but at that point you still need a chip and a parallel interface (otherwise, what's the point).

Then we get to something like the Pi Zero. Which has all of the important modern interfaces, notably USB, but it also has video. You can get Ethernet/Wifi via USB.

So, why not have a parallel interface from the host CPU to the Pi Zero GPIO ports, a protocol over said lines, to a "kernel" that manages the underlying raw I/O to the "real world".

The Pi Zero is a $5 part. I appreciate it is, perhaps, "overkill" for this. I know the Pi has other issues, apparently it likes to pause on a whim, making it perhaps not so good at synchronous interfaces. But async, it would do fine. An 8-Bit CPU would barely notice any inherent pauses within processing pipeline. (As I understand it these pauses ware within the SoC itself, no, say, the Linux kernel.)

What you don't get is things like DMA or anything like that. The Pi doesn't have enough pins to support it, plus there's those potential pauses. You also can't do "memory mapped graphics" (because all people seem to care about with retro computing is video games). But there could easily be a very smart "graphics co-processor" subsystem built. "How many sprites do you need?"

But it sure beats the heck out of bit banging SPI, and it should easily be able to keep up with a 115K UART.

It is an imperfect solution, since it's a general purpose part, it has a software component, it has a "slow" start up time when it "boots". But I think it's a viable one. The other nice thing is that it's ideally CPU agnostic -- it only requires 2 8-Bit ports. I can't speak to the voltages (3.3 vs 5). But that seems manageable as well.

To me, it solves a lot of problems of general questions everyone has with modern "retro" machines. USB takes care of, well, almost everything. File systems, printers, networking, etc. Truly "universal". And the Pi is fast enough to handle TLS over the network. And it does it with one "chip" (actually a small daughter board).

[lowen]

This RC2014 card lists TRS-80 compatible graphics as a feature and shows the system running Galaxy Invasion: https://www.tindie.com/products/robd...it-for-rc2014/

Wow, that's quite the board there. It's all open, so ordering through tindie isn't required, boards can be fabbed other places, but it's pretty complex. But an option, for sure, as long as having not one but two 32-bit MCUs in the system doesn't bother you. (Doesn't bother me, actually, but I think I'll probably go ahead and do a simpler framebuffer direct-drive board, probably using a CPLD for the timing and RAMDAC).

[Eudimorphodon]

What you don't get is things like DMA or anything like that. The Pi doesn't have enough pins to support it, plus there's those potential pauses. You also can't do "memory mapped graphics" (because all people seem to care about with retro computing is video games). But there could easily be a very smart "graphics co-processor" subsystem built. "How many sprites do you need?"

The linked RC2014 card above uses a Raspberry Pi Zero, and essentially all it does is DMA. (It uses some external hardware glue to regularly pause the attached Z80 with the WAIT lines and block-copy bytes to and from RAM; that's how it handles things like TRS-80 keyboard emulation in addition to the memory-mapped video, it copies a bitmap of the keyboard matrix into RAM mapped where a TRS-80 has the real thing.)

Personally, despite my previous endorsement of microcontrollers for all manner of things, kind of start drawing a line around this point because, honestly, it kinda starts feeling like you might as well have just emulated the Z80 in the Pi and saved the hardware. It would probably actually be closer to cycle-accurate than the real Z80 hanging off there like a tumor and being wait-stated all the time.

(Although, again, I guess it depends what gives you joy. If programming the Pi to do this is the real project then have at it. So far as I know there's no set of stone tablets somewhere that were handed down from on-high dictating the "correct" way to enjoy "retrocomputing".)

[Eudimorphodon]

I think I'll probably go ahead and do a simpler framebuffer direct-drive board, probably using a CPLD for the timing and RAMDAC

If you want a laugh here's my lo-tech approach. The big black chip in the lower left is an AVR324 that's programmed to do address generation and sync. (IE, it would basically be possible to rip it out and plug in a CRTC instead. The AVR has the advantage of actually still being manufactured, it's "self-initializing", and it also handles some other sundry tasks like outputting the master clock it squeezes out of the cheap crystal and doing power-on reset generation for the system..) The rest of it is 2 GALs, 2 '245 buffers, 2 '573 latches, and a shift register. I'm actually pretty proud of my latest "invention", which is it has fully unified memory architecture, IE, it can do character/"tile" modes with the "character buffer" and the "character generator" residing in the same memory. A simple state machine in one of the GALs coordinates a sequence in which on one "tick" of the pixel clock the '245 buffers put the address from the "CRTC" onto the address bus and latch the resulting data byte into the upper '573, and on a following "tick" the character data is combined with a font/row selector byte latched in the lower '573, placed on the bus, and the resulting pixel data latched in the shift register for clocking out.

(The CPU is soon to be grafted onto this mess to the right of the yet-unwired RAM chip; the GAL under that is going to define the memory map. I won't need another set of buffers for the CPU because the WDC65C02 CPU I'm going to use has internal tri-states that I think I can just tie to its Phi clock, generated by that state machine GAL, so it stays quiet when its not its turn.)

And of course I'm sure this would *trivially* fit in a pretty small CPLD. I'm doing it this way because it's letting me task-switch with both simple PLD programming and assembly-language bit-banging on the AVR, it's all through-hole so I can learn on the breadboard, and, well, it's twisted and wrong and I kind of like that. (Cue the Frank Sinatra.)

videomess.jpg

[gp2000]

Although... I guess in theory isn't there a rumor at least that the Model 4P ROM has some kind of secret serial boot/debugging capability built into it?

Yes, a 4P can download a program from RS-232 if you hold the right shift key and BREAK after power-on or reset.

Here's a program to do the download (it includes source code):

http://48k.ca/boot4p.html

The download itself is just a slight bit more than transmitting a file in /CMD format to it.