Home » RBC Forums » General Discussion » Z380 usage examples?
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Z380 usage examples? (O.T. eZ80) [message #8939 is a reply to message #8936] |
Mon, 02 August 2021 16:20   |
jayindallas
Messages: 110
Registered: June 2021
|
Senior Member |
|
|
I looked at the eZ80 in 2014 and found it interesting.
To find out what some designers thought of it, I scanned the ever-convenient archives of comp.os.cpm and read everything involving the eZ80 from its introduction around 2007 to then-current time, 2014.
So the interval of time characterized was roughly between 2007 to 2014.
Most of the work done with eZ80 for CP/M-80 versions during that interval, consisted of buying the Zilog evaluation board and installing CP/M on it.
To run a single instances of CP/M 3 (aka CP/M Plus) in banked mode, the solution (if I recall, described by Chris B. in comp.os.cpm in said interval) is to use full 64KB pages as each bank. With 16MB of address space, that gives you 256 banks of 64KB each assuming you have all possible ram. Let NN be the bank address composed of Adr23:Adr16, then when a bank is changed, you change the NN address, no requirement to be consecutive blocks of memory.
If Bank 1 was NN=21h then Adr23:Adr16=21h. Bank 2 could be NN=22h (consecutive blocks of memory) or NN=35h (non-consecutive blocks).
Common memory can use the one or both of the two internal static 8KB ram that can be mapped by registers into any 64KB page. Therefore you affect a common memory block simply by remapping the internal static ram(s) to the same Adr23:Adr16 address of the new bank selected.
In the example above, if both 8KB internal static ram were used (sacrificing one's use as ethernet resources) than Bank 1 would have common memory block set to 21.C000-21.FFFFh (16KB), and Bank 2 would have it changed to 22.C000-22.FFFFh. No DMA required, just remap the common block to the same 64KB page as the current Bank.
|
|
|
|
|
|
| Re: Z380 usage examples? (O.T. eZ80) [message #8944 is a reply to message #8940] |
Tue, 03 August 2021 19:46 |
jayindallas
Messages: 110
Registered: June 2021
|
Senior Member |
|
|
- - - - - - - - -
WSM wrote:
....My curiosity was more about possible "armchair quarterbacks" who may have critiqued the eZ80....
Jay replies:
I recall one said that, ''the eZ80 cannot execute Z80 instructions''.
I interpreted that as documentation 'quick-out'. Some may have expected the eZ80 to be a shiny new Z280++, and it wasn't. When they saw it wasn't what they wanted, they bailed from the documentation quickly, so didn't know about ADL mode, z80 mode or MIXED-Mode. That's human nature...
A few of us became the defenders of the eZ80 and enlightened those that stated something sufficiently wrong. But that didn't mean we defenders were completely happy about all of Zilog's eZ80 choices.
For example, I'd have rather had Zilog remove the Ethernet section, and supply more Chip-Select pins. If I want an ethernet LAN on a design, I'd rather have more that a 10Mbps + sometimes 100Mbps LAN. I understand that Zilog engineers had to include the LAN support so that the eZ80 could claim some market niche to validate its design effort...
LAN [ check ]
GOOD LAN [no check]
Speaking of stating something wrong, I too, when writing about a strategic use of an illegal opcode interrupt, wrongly stated it took a single byte opcode, when it actually takes two bytes to create an opcode error. Doesn't invalidate the use as described, just a damn error.
- - - - - - - - -
WSM wrote:
....Right now one of the biggest headaches is sourcing the various components used in these designs....
Jay replies:
I realize that's most due to worldwide economic semi-suspension under pandemic, but at least before the pandemic, I bought 250 or 300 eZ80s because I didn't trust Zilog's sequential owners to keep it manufacturing. I have my toy-box no matter what any "Zilog-Owner-Of-The-Week" does.
Now I just have to find them; moved recently. When I find the MSP-430s or the old Philips 8051s, I'll be real close to the eZ80s. :S
UPDATE: 2022/06/28:
I found my stock of MSP-430s and my Philips 8051s (I used Temic 8051s in the product [better code security] and had left over Philips that had a code-security issue).
I still haven't found my eZ80s but at least I figured out why... I bought the eZ80 stock independently on my personal credit card so... that means I had to keep them separated from all my Corp-C inventory. So as far as I know at the moment, it could be in any storage bin I have instead of just my Corp-C bins. Well I'm going to be moving in the Fall/Winter so I'll have room to unpack everything and finally find those little trouble-maker eZ80s.
I'm considering using some of my overstock MSP-430s in a project to do an in-circuit emulator of a Z80 CPU by a 40-pin DIP with a MSP-430 chatting with the Raspberry Pi, and the MSP-430 doing the TTL emulation of the Z80 in a vintage system. As I'm considering throwing a 808x emulator in that too, the MSP-430 should do that more efficiently. I don't think my overstock of Philips 8051s are fast enough or well suited for the task. I'll find a use for them some day, or just dump them on eBay.
- - - - - - - - -
WSM wrote:
....Rather than use a Zilog MODG board, I chose to design my own PCBs....
Jay replies:
I didn't like the MODG board for other reasons. The eZ80 was capable of supporting 16MB of Static Ram at 50Mhz... so THAT is what I wanted to play with. Its like finding out you won a gift Porsche and you show up to pick it up and its just a small car for your key ring. And the salesman says "...But while you're here, take a look at this fine automobile!"
[Updated on: Wed, 29 June 2022 01:58] Report message to a moderator |
|
|
|
|
|
| Re: Z380 usage examples? (O.T. undocumented opcodes?) [message #8963 is a reply to message #8959] |
Thu, 05 August 2021 16:38 |
jayindallas
Messages: 110
Registered: June 2021
|
Senior Member |
|
|
- - - - - - - - -
etchedpixels wrote:
"...They stole several valid instructions and repurposed them. Stupid but valid instructions nevertheless..."
Jay replies:
Depends upon whether "Stupid but valid..." means something in the set of "UNDOCUMENTED Instructions".
Undocumented instructions occur at least in two ways:
1). Someone wants an instruction added but later its decided that documenting it would just confuse everyone and make assembler and disassembler coding unnecessarily complex. It might be an intended set of opcodes but it failed on testing and the smart decision was to pretend its not there and then you don't have to do new silicon to remove the mistake or fix it, even.
This is likely quite rare.
The more common reason for undocumented opcodes is:
2). When writing the what I'll call the 'opcode activation logic' they don't use additional transistors and circuit paths to make functions enable solely to one opcode. They use as few as necessary to get the silicon circuit done as 'gently' as possible and don't worry about the opcode-holes where someone could find an active instruction that does weird things or may retrigger the same operation as another opcode. As 'they,' the designers, can document the OFFICIAL opcodes, anything they don't document is effectively not a certified instruction with the product.
Its like a recent example I used in chip selection of a 2KB static ram in a 8KB mapped space. By using an 8K select instead of a 2KB select, they save two address lines being routed to the opcode activating logic. Sure you can access that 2KB from four different blocks of addresses, but it serves you no purpose, so 'they' document what they OFFICIALLY intend and leave the rest 'possible' and undocumented.
Its fair to say that all undocumented opcodes may still not be fully described because a valid operation may only follow with a specific opcode that moves a unknown register content or value that otherwise in eventually overwritten. I have a few I want to try someday involving the phantom 'W' register and its true nature and around some duality in the A and F registers.
That doesn't mean undocumented opcodes was a secret opcode for people to find like in a video game... its just super-grouping selects for microcoded operations. You can try every possibility and document what each does and call them undocumented opcodes, but that doesn't mean there was any reason for those to exist, its just the result of not excluding operations completely by using unnecessary logic additions.
I too like some of the undocumented opcodes and would like to use them... though I differ with syntax that past attempts have proposed.
Undocumented opcodes are still fun to examine. And their existence is thanks to holes in the opcode mapping, and may infer structures in the microcoded operations that can be really interesting to figure out.
So if any subsequent #80 or eZ80 comes along and finds a better use for the undocumented regions, BRAVO.
An intentional, DOCumented opcode generally will be much more valuable than an unintended unDOCumented opcode.
Maybe that should be called DOC's Law. 
[Updated on: Thu, 05 August 2021 17:33] Report message to a moderator |
|
|
|
|
|
| Re: Z380 usage examples? (O.T. undocumented opcodes?) [message #8965 is a reply to message #8964] |
Fri, 06 August 2021 09:31 |
jayindallas
Messages: 110
Registered: June 2021
|
Senior Member |
|
|
- - - - - - - - -
WSM wrote:
....I have a simple philosophy about undocumented opcodes....
....they don't exist and I NEVER use them or waste time exploring them....
Jay replies:
That's all very sensible and a good guiding principle.
- - - - - - - - -
WSM wrote:
....Subsequent device enhancements...incorporate a TRAP...
....for invalid instructions which I fully endorse.
Jay replies:
Exactly.
And somewhere on comp.os.cpm I wrote about a strategic use of an illegal opcode interrupt, with one previously mentioned 'damn error' and it REQUIRES that ability in the eZ80 to do its cleverness.
So the eZ80 TRAP is an example of DOC's Law.
So why is unDOC vs DOC a thing?
-------------------------------
The reason some think unDOCs are important is because some game-software companies, back in the day, didn't adhere to that philosophy and used unDOC.opcodes. Thus with gamers or those that use it as a rationale, unDOC.opcode compatibility makes some game software run incorrectly or lockup and so that makes it important.
It follows that if a Z80 runs an unDOC game fine and a eZ80 doesn't... then the eZ80 is a not compatible.
When is unDOCs thought to be more important?
-------------------------------------------
Its more of an issue when writing a Z80 emulator. unDOC.ers want the emulation to run these example gamer-software. If it doesn't pass their gauntlet of peril, they may give an emulator low marks compared to those that support them.
Its a tangled world of satisfying these criteria because you then have to check every Z80 silicon-change release to verify that they all behave the same way, otherwise open up a huge database on the behavior.to.emulate for any Z80 silicon-change that affected unDOCs. Then an accurate run of unDOCed code, with the wrong Z80 release issue, can now be an emulation failure if the software runs without crashing. Round and round we go...
And what about a HM64180 running Z80 code with unDOCs? Chaos feeds itself. If only Chaos could feed a turbine.
A genius named Federico Faggin once designed something, and is never quoted about the subject of unDOCs. That alone confirms his genius.
Puzzles underneath the unDOcs and 'x' flag results
--------------------------------------------------
However, if you like Z80s and puzzles, unDOCs can be interesting, couple that with the unDOC Z80 flag behaviors that Zilog simply marked officially as a 'x' don't care. Some in the emulator community also wants 'x'-don't-care-flag-results to be cared for. :S
I think there is some validating software that supposedly tests them all.
To me, I hear or read this and realize that the mentioned behaviour is not random, therefore its is suggestive of an underlying structure in the way the Z80 silicon was done. That can be an interesting puzzle for those that are bored with cryptanalysis and want to apply methods to new targets.
Chaos is sometimes fun to whittle at.
[Updated on: Fri, 06 August 2021 11:48] Report message to a moderator |
|
|
|
| Re: Z380 usage examples? (O.T. undocumented opcodes?) [message #8973 is a reply to message #8963] |
Sat, 07 August 2021 04:49 |
etchedpixels
Messages: 333
Registered: October 2015
|
Senior Member |
|
|
No they stole *documented* instructions. Take a look at what the .SIS .SIL .LIS .LIL prefixes are.
40
49
52
5B
All valid instructions in Z80 (LD B,B LD C,C LD D,D LD E,E)
Hence the classic way to detect an eZ80 of
xor a
ld e,e
ld hl,#0
inc a
jr z, is_ez80
You can make a Z180 Z80 illegal compatible, but not an eZ80. The Z180 has an illegal trap with vectors via 0, with two flags so you can catch it and actually fix them up. Because it's address 0 you can even load a CP/M 3 resident to do the fixing for you. The Z280 simply made all the Z80 illegals legal except for the one small range of bizarre ones that became TST.
As to undocumented instructions the reality back in the day was often that you had no choice but to use them, and a whole load of other techniques more modern programmers don't even know about. It makes a huge difference on some processors. On Z80 there were tight spots where using IXH/IXY type instructions got you a major and necessary speed up to get your game running as fast as required. On 8085 the code density improvement of compiling using the instructions that Intel decided not to document is enormous as is the performance win.
It's a luxury on a modern system, even a retro box with an 8MHz CPU, no wait states, no video contention and 512K of RAM, but it wasn't in the day.
One of the other great ones you don't see nowdays was the memory and clock saving trick of doing
__var: LD HL,#n
var .equ __var + 1
to save the data space of the variable by patching it into one of the instruction uses of it, and save a bunch of clocks in the hottest code path using
the variable.
Z80 illegals btw are totally consistent across all vendors and clones. In fact there are *more* differences in the legal instruction bugs between them than the illegals. On the genuine or licensed products the only illegals differences are that CMOS parts output 0xFF and NMOS 0x00 without of the undocumented OUT instructions, and the behaviour of certain undocumented flag bits which with very carefully constructed code can tell Zilog and NEC/SGS parts.
On the other hand - LD A,R and LD A,I have differing flag behaviours on the Z80 and some of the clones like the T80 FPGA core, the Soviet ones don't preserve the C flag on OUTI, the Z180 DAA is different, the Z180 RLD and RRD set the flags differently to the Z80....
And on the Z280 you might as well treat all instructions as illegals because they work, except when they don't.
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Z380 usage examples? (O.T. undocumented opcodes?) [message #10173 is a reply to message #8973] |
Thu, 08 December 2022 07:58 |
 |
lowen
Messages: 226
Registered: August 2016
Location: Western NC USA
|
Senior Member |
|
|
etchedpixels wrote on Sat, 07 August 2021 07:49...
And on the Z280 you might as well treat all instructions as illegals because they work, except when they don't.
Gotta love this quote....
A bit of a necropost, but finally after several IRL issues including two bouts with COVID, I'm finally getting back to some of this stuff. Just ordered one of WSM's Min-eZ for my Christmas to myself. I already have several Zilog boards, but a cased and running system to verify stuff on was very desirable. Thanks WSM!
Z380 is currently a dead end; it's no longer available and listed as obsolete at both Mouser and Digikey. Zilog still lists as an active part, but no distributors seem to have any. I have four of them in-hand, but as stated earlier they are quite a bit more expensive than any eZ80 and they also require much more in the way of support chips. Z380's major advantage in terms of being a 'super Z80' is that the Z80 I/O space isn't completely used up by onchip peripherals. With Z280 the internal peripherals are in a different I/O page; on Z180 you can at least move the I/O range used by internal peripherals. On eZ80 it's a different story, making it much more difficult to use an eZ80 as an upgrade 'super Z80.'
Z380 was in my opinion the best choice for a 'super Z80' upgrade for existing systems; Z280 is a close second, even with its flaws.
In practice, only HD64180/Z180 got used as a 'super Z80' and then only with caveats (undocumented instructions being one of them).
Z280 is easy to develop for these days with ZSM4, updated HiTech C, hperaza, mtdev79, and agn453 all having repos of softwre, plasmo's boards as well as z280emu which acts as a bugfixed Z280; real Z280's have real problems, but perhaps an emulated (ARM or other core) with a Z280 pinout could be done, using z280emu as the 'core' or maybe z280emu could be translated to Verilog or other HDL and put on an FPGA. Z280 is theoretically the best target, with system and user mode, a flexible MMU, etc. A reworked Z280 using the tricks of the Y80 core but adding the Z280 instructions would be IMO very cool. It's a lot of work, though.
Z380 has no MMU. There is no open assembler for Z380 that I know of, and only an old Zilog ZDS.
Effectively, the eZ80 doesn't have an MMU, either; the page size is 64K using MBASE, unless you resort to some address bus trickery (use A16-A23 as input to an MMU that also translates below A16 based on the contents of A16-A23). There IS an open assembler, spasm-ng. Thanks to the TI-84 PCE there are a LOT of eZ80 systems out there that are actual systems and not embedded. And Zilog's ZDS is available for the eZ80.
I was going to pursue a Z380 'super Z80' system, but when Mouser and Digikey dropped the chip the gig was up as far as I'm concerned, although a prototype would be a cool thing to play with.
--
Bughlt: Sckmud
Shut her down Scotty, she's sucking mud again!
|
|
|
|
| Re: Z380 usage examples? (O.T. undocumented opcodes?) [message #10174 is a reply to message #10173] |
Thu, 08 December 2022 16:06 |
plasmo
Messages: 916
Registered: March 2017
Location: New Mexico, USA
|
Senior Member |
|
|
lowen wrote on Thu, 08 December 2022 08:58
real Z280's have real problems, ...
lowen,
Do you have a list of Z280 problems? I like to verify them and see if I can come up with deterministic tests and workaround. One bug I know about and have worked around is that system clock and UART clock MUST be synchronous so the solution is to generate UART clock by dividing down system clock. I also recall there were confusion about Bus Timing and Initialization register because the bit values are different at two different sections of the document. Another question is about the instruction cache, but I could not get a definitive description of the cache problem. There were questions about earlier mask of Z280 having certain problems but I was not able to acquire these earlier datecode devices to test for them. The Z280 that I purchased from UTSource are all later date-code and presumably production devices.
Another successful developer of Z280 is Wayne Warthen who has a version of RomWBW with Z280 successfully using its cache, DMA, MMU, and mode 3 interrupt. My feeling is Z280 have gotten lots of bad press during its long, problematic roll out but now it is obsolete, the retired production Z280 parts are actually trouble-free.
Welcome back!
Bill
|
|
|
|
|
|
|
|
|
|
| Re: Z380 usage examples? (O.T. undocumented opcodes?) [message #10178 is a reply to message #10177] |
Fri, 09 December 2022 09:22 |
|
lowen
Messages: 226
Registered: August 2016
Location: Western NC USA
|
Senior Member |
|
|
lintweaker wrote on Fri, 09 December 2022 06:03As an update from the original topic starter. I have had not much luck using the Z380 as a direct/full Z80 replacement, but I have not given up yet. The lack of a Z80 compatble /m1 signal is one issue.
The dynamic RAM support on Z380 is quite a bit different, too, if I remember correctly; Z80 is built for RAS-only CPU-counted refresh, but Z380 supports CAS-before-RAS refresh where the RAM itself maintains the counter. And then there is the 'separate I/O signal' bus transaction that is quite different. I have a basic design, but haven't had opportunity to do any construction, except soldering two of my Z380's to protoboards right before I got sick the first time around with COVID.
Quote:I have been using AS/ASL (https://github.com/flamewing/asl-releases as an assembler which fully supports the Z380 (among many other CPUs).
AH! Thanks for that pointer!
Quote:I am working on a dual CPU design with 2 Z80's where you can boot from 1 and switch to another using some IO port writes. Once that is working I'll update the design, replacing one of the Z80's with a Z180, Z280 or Z380. The idea is to boot the system with a known working Z80 and then switch to the alternate CPU for more speed/features.
This is the basic architecture of the MSX Turbo-R, with a Z80 and an R800. There was a Z380 add-on board for MSX available at one point, but I'm not sure how much of the design is open. See https://web.archive.org/web/20010501063925/http:// www.geocities.com/CollegePark/Classroom/9927/padial/page10.h tm
wsm wrote on Fri, 09 December 2022 00:48Lamar: And thank you for your purchase of a Min-eZ which was shipped today. Enjoy your Christmas present!
Looking forward to it!
Quote:Besides the I/O range issue, one aspect of upgrading an eZ80 for a 'super Z80' that hasn't been mentioned, is the bus speed. While the eZ80 supports up to 7 I/O wait states, the basic I/O read signals are only valid for 11.5 ns and write for 9 ns. These basic cycles are much too fast for a lot of peripherals without adding wait states. In addition to being relatively slow, retro peripherals often require long setup and/or hold times which require additional circuitry.
50MHz is very fast relative to exiting vintage systems, that is for sure. eZ80 was designed for easy interfacing to static RAM, and it does that very well.
The TRS-80 TRSDOS/LS-DOS 6 operating system has several 'bus settle' delays due to some of the hardware design characteristics of the TRS-80 Model 4 system.
Quote:...The more I thought about it and how others might add their unique I/O devices, the more I've been leaning towards only supporting I2C and SPI as external interfaces for user expansion.
I think you are on the right track. If someone wants a 'fully expandable eZ80' there is the Z20X that fits that particular bill..... https://hackaday.com/2020/02/23/a-z80-computer-at-the-next-level/
--
Bughlt: Sckmud
Shut her down Scotty, she's sucking mud again!
|
|
|
|
| Re: Z380 usage examples? (O.T. undocumented opcodes?) [message #10179 is a reply to message #10178] |
Fri, 09 December 2022 10:03 |
wsm
Messages: 232
Registered: February 2017
Location: AB, Canada
|
Senior Member |
|
|
Quote:The TRS-80 TRSDOS/LS-DOS 6 operating system has several 'bus settle' delays due to some of the hardware design characteristics of the TRS-80 Model 4 system.
I forgot to mention on this forum that TRS-OS has been ported to my Min-eZ and eZ-Tiny systems which allows TRSDOS/LS-DOS 6 programs to operate on them albeit MUCH faster.
|
|
|
|
Current Time: Wed Mar 19 02:13:02 PDT 2025
Total time taken to generate the page: 0.00676 seconds
|
RetroBrew Computers Forum
Members
Search
Help
Login
Home
