System architecture for a Z380 TRS-80 compatible.

[pjhacnau]

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.

So to add (yet another) 2c+GST - start playing! I know what I 'd like, and I also know that I'll never get round to doing it. And I can't force anyone else to do it. So: make a final call, start working on it. I'm happy to come along for the ride as best I can.

[Added] Just one last question: I think you were talking about the enhanced RC2014 bus - correct?

PJH

[lowen]

So to add (yet another) 2c+GST - start playing! I know what I 'd like, and I also know that I'll never get round to doing it. And I can't force anyone else to do it. So: make a final call, start working on it. I'm happy to come along for the ride as best I can.

Yeah, I think I have a good path forward with some interest by more people than just me who can do the work.

[Added] Just one last question: I think you were talking about the enhanced RC2014 bus - correct?

Yes. I have personally already ordered a couple of different backplanes from Steve Cousins. These are full 80-pin buses, and are very reasonably priced.

I'm hopeful that the modularity will make it quicker to get real hardware built.

[lowen]

Yeah, I think I have a good path forward with some interest by more people than just me who can do the work.

I know, replying to myself is bad form... but I forgot to mention, thanks to both my coffee not having kicked in AND having to type on my phone that I want to thank EVERYONE who has participated in the discussion; I've ended up deciding to go a completely different direction than I thought I would, at least for the first phase of this.

[whartung]

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.)

I'm sorry, I can't seem to correlate what RC2014 card you linked to mentions the RPi in this case.

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.

The hang up, to me, is USB. Get USB "tone" and the rest of the world awaits you. Serial, Keyboards, block storage, networking, printers. Just...everything. "Universal", even.

I think USB is complicated enough that you can't really do it with out a μC. I don't know for sure. If you didn't use one, then I bet a large chunk of your system would be dedicated to driving the protocol. It's a combination of the complexity of the protocol, the breadth of the protocol, and just the raw speed of the protocol. Quite the burden for an 8-Bit or slow 16-Bit environment.

There's the CH376 chip, which is a μC that you can interface with a parallel port. It's a USB Host and has built in support for FAT32.

FTDI has parallel USB chips, but they don't document them without an NDA, which isn't useful for this community.

The CH376 IS a μC. It has a core, RAM, ROM. It's just pre-programmed and dedicated to USB and FAT32. So, it's a μC presented as a black box.

At the black box level, I can't honestly say it's much different from a dedicated SCSI chip.

Ostensibly the difference between a Z80 driving one of these, and a μC driving a Z80 is "who's in control". I don't know much about DMA. Is it common for DMA on small systems to halt (wait) the main CPU in its struggle over the bus? But even with DMA, a SCSI chip isn't "in control" over the system, right? The CPU is still sitting on the throne, even if it's ceding power occasionally to the other components.

[Eudimorphodon]

I'm sorry, I can't seem to correlate what RC2014 card you linked to mentions the RPi in this case.

I was referring to this:

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/

And like I said, from reading the creator's description at least, this card basically run the whole show; there's a Z80 attached to RAM hanging off the Raspberry Pi, but the Pi controls the CPU clock and is constantly halting it to "sneak in" and read/fill memory locations so the Z80 thinks it's talking to hardware when really it isn't. I mean, technically it's a neat achievement, but it also feels a lot like spending $80 to graft a bunch of things to a $5 computer that could do a better job just emulating the Z80 instead of wasting all that time nursemaid-ing an external chip. (It's basically doing everything else already.) If that's your bag, go nuts, but I don't think it quite feel right to me. There's not a "system" here at all without the Raspberry Pi plugged in, it's not a peripheral in any meaningful sense of the word.

The hang up, to me, is USB. Get USB "tone" and the rest of the world awaits you. Serial, Keyboards, block storage, networking, printers. Just...everything. "Universal", even.

I have no issue with stuffing a microcontroller in to handle USB or ethernet or whatever, and I'm even agnostic about the microcontroller being something as over-the-top powerful as a Raspberry Pi. But...

Ostensibly the difference between a Z80 driving one of these, and a μC driving a Z80 is "who's in control". I don't know much about DMA. Is it common for DMA on small systems to halt (wait) the main CPU in its struggle over the bus? But even with DMA, a SCSI chip isn't "in control" over the system, right? The CPU is still sitting on the throne, even if it's ceding power occasionally to the other components.

Like I said, I think it's sort of hard not to argue in the specific case of that card above that the Raspberry Pi completely owns the circus, there's nothing without it. That's not really a "black box" anymore.

Again, different strokes for different folks. For me the line lies somewhere around "Does the microcontroller have to actively quarterback every aspect of the CPU's operation, or could you pull it out and reasonably substitute something else? (without *massively* redesigning the system)" ballpark.

[whartung]

I was referring to this:

Ah, thanks.

And like I said, from reading the creator's description at least, this card basically run the whole show; there's a Z80 attached to RAM hanging off the Raspberry Pi, but the Pi controls the CPU clock and is constantly halting it to "sneak in" and read/fill memory locations so the Z80 thinks it's talking to hardware when really it isn't.

Absolutely. I agree completely in this case. The Pi is running the show. If it's in control of the clock, what more needs to be said? I mean, "BusRaider" kind of says it all.

[lowen]

Ok, so, an update.

I have ordered a Steve Cousins BP80 backplane kit. I figure I'll need some control signals to communicate between modules for the memory mapping and such, and I already know I'll need NMI for the FDC, so I need more than the regular 39-pin RC2014 standard bus can provide.

I've ordered ten of Plasmo's protorc_rev3 boards from JLCPCB; $21 shipped for ten. Can't beat that. The protorc3 was chosen for its large size and a full 80 pins on the bus side (getting the 80 pins will require some modifications, mostly cutting all 40 traces connecting the two sets of 40, but that's ok.

I've bought a VGARC from plasmo to serve as the base for the video and maybe the keyboard.

The initial system will have three boards:

1. Z80380 with glue logic in CPLD plus some SRAM on a board. Might have a serial port, might not, might have some other ports, might not. Probably will need ROM.
2. VGARC for video and if I can get it to fit keyboard control. Push comes to shove I can use a small MCU and push the keyboard matrix into one side of that nice 8K dual-port RAM in the right addresses; or I can adapt to use a Newkey/80.. I will need to modify the CPLD contents to use the TRS-80 video modes and memory mappings.
3. A replica of the 4P gate-array's floppy controller circuitry. I have a small quantity of the relatively easy to use WD1773 floppy controller chip that the gate-array 4 and 4P used, just have to duplicate the functionality of the floppy gate-array chip (4.4.0). This will be the most complicated board, but for a 100% 4P compatibility without a high-powered MCU an actual FDC is required. Can connect to a Goteck or HxC, of course, don't have to use real floppy drives.

This is lacking some of what the stock out-of-box 4P can provide, notably the parallel printer, sound, and RS-232 (4P has a dumb UART, a TR1865 in particular). But it's a start.

[Eudimorphodon]

I was mulling over the idea of using dual-port memory for a TRS-80 keyboard matrix converter instead of one of those analog matrix switches, but it seems like a potential drawback is if you want to absolutely strictly emulate the keyboard behavior you’ll have to update a whole 256 byte block with all the possible AND combinations for each keypress. I don’t know how much software actually abuses the “I can read any combination of rows at once” behavior, though.

[lowen]

I was mulling over the idea of using dual-port memory for a TRS-80 keyboard matrix converter instead of one of those analog matrix switches, but it seems like a potential drawback is if you want to absolutely strictly emulate the keyboard behavior you’ll have to update a whole 256 byte block with all the possible AND combinations for each keypress. I don’t know how much software actually abuses the “I can read any combination of rows at once” behavior, though.

I'm looking at some options. I'll have to look through my notes to see if I have ever come across a program that accesses the keyboard in that manner. I like the 'array of 74HC595' style units, such as the TEK one on hackaday. But I might just punt and use my Newkey/80 for the task.

[Eudimorphodon]

I'm looking at some options. I'll have to look through my notes to see if I have ever come across a program that accesses the keyboard in that manner.

I have vague memories of reading once that it was standard with TRS-80 key scans to read the "255" row (which is activating all the row lines at once) to see if "any key" is pressed down and then only scan the individual lines if you get a value indicating there's a key held down somewhere, but the gross thing about how it's set up is an evil software developer could have written software that only scans, say, two rows simultaneously...

But realistically I have no idea how true that is.

I like the 'array of 74HC595' style units, such as the TEK one on hackaday. But I might just punt and use my Newkey/80 for the task.

"Just in case" I need them sometime soon I ordered some MT8809's from AliExpress that just arrived the other day; if they actually *work* they're going to be cheaper than eight '595s, but there may be a big "if" there.... I need to get off my rear and wire one up to an arduino or whatever to smoke test it.