RetroBrew Computers Forum
Discussion forum for the RetroBrew Computers community.

Home » RBC Forums » General Discussion » TinyZZ, a Z280 SBC (Exploring Z280)
Re: TinyZZ, a Z280 SBC [message #4341 is a reply to message #4340] Fri, 16 February 2018 10:31 Go to previous messageGo to next message
wsm is currently offline  wsm
Messages: 223
Registered: February 2017
Location: AB, Canada
Senior Member
Different systems with different CPU and baud rates are obviously going to react differently to interrupt versus polled I/O. Part of my reason for developing interrupt driven queued I/O was a plan to upgrade to an eZ80 which is very roughly like a Z80 at 200MHz. The concept is to also use or develop a multi-tasking operating system.

Interrupt driven queued output allows the application to create new data in parallel with I/O operations and feed it to the queue until the queue limit is reached. This is most effective when multi-tasking with slower devices and I do have some development I plan to do with a device that has a maximum rate of only 9600 baud. Interrupt driven queued input allows for an immediate call to the scheduler / dispatcher if data is not available while also allowing the system to continue to receive data when another task is in control of the CPU.

I can't comment on Fuzix or the system beneath it. What I can say is that I run my console at 115,200 baud and a CP/M-2 LIST command of a very large file pushes the data out at the full baud rate while also doing other things like reading the file and processing clock interrupts. One of the benchmark tests I plan to do is to try using 1K-XMODEM with two buffers which will allow simultaneous disk I/O and serial I/O. The comparisons between polled serial I/O, interrupt driven and DMA based should give some interesting data, especially with USB and also in regards to idle time.

As to DMA controllers and their limitations ... I agree that many implementations just turn into bus hogs that really don't do much to improve performance, especially for single user systems. That's why I developed my own version that uses fly-by and a 16-bit data bus. It should be able to transfer data 28 times faster than the 33MHz Z180's internal DMA ... essentially UDMA 6 rate of 133MB/sec. The limitation can then become the I/O device rather than the bus.

Plasmo ... sorry to hijack your thread but there's been some interesting discussion for those less familiar with overall architecture.
Re: TinyZZ, a Z280 SBC [message #4342 is a reply to message #4341] Fri, 16 February 2018 11:19 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 866
Registered: March 2017
Location: New Mexico, USA
Senior Member
wsm wrote on Fri, 16 February 2018 11:31

Plasmo ... sorry to hijack your thread but there's been some interesting discussion for those less familiar with overall architecture.

Not at all. I enjoyed the conversation very much. The discussions about poll/interrupt/DMA are eerily familiar to what were talked about 20+ years ago. The conclusion was different then because in a hard real time world, the prescribed tasks must be completed every time tick without fail. We can't have an alternate bus master like DMA hogging the bus and we don't have much spare throughput for it to hog. Words like load-levelling alternate bus masters were bandy about rather freely.

I'm pleased with the participation of heavy hitters who worked with Z280 before and can look ahead. It help me imaging the road ahead while still feeling the ground immediately below. The TinyZZ is to help me exploring Z280 the first time around, but the core design is cheap and sparce in term of pc board real estate. There are plenty of room for 16meg SIMM and Ethernet and multiprocessor interface/connector even in the 10cm * 10cm format.

Please carry on. Like lowen said "I'm loving it"!
Re: TinyZZ, a Z280 SBC [message #4343 is a reply to message #4342] Fri, 16 February 2018 12:13 Go to previous messageGo to next message
lowen is currently offline  lowen
Messages: 226
Registered: August 2016
Location: Western NC USA
Senior Member
While I'm going to do my own run eventually, I found results from Stefan Nitschke, who ran dhrystone 1.0 on the CPU280 under the Unix-like UZI280. Here are his numbers:
Benchmarks testing the HiTech Compiler using Dhrystone 1.0 (12.5 MHz) :

	z80 Version			:  847
	z80 Version + z280 Lib		: 1041	(22%)
	z80 Vers + Optim + z280 lib 	: 1219	(44%)  


For comparison, see the table at http://tech-insider.org/unix/research/1986/0219.html

In a nutshell: The CPU280, with Z280 instructions and 'optimizations' scores in the same general neighborhood as a Sun 2/120, a PDP-11/70, a PC/AT 80286/6MHz PC-DOS 3 system, and many other systems that you'd initially think were far 'better' systems. The CPU280 outscores several runs from VAX-11/750 systems, several PDP 11 systems (11/44, 11/73), and any PC/XT-class systems.

So if you think of the Z280 at 12.5MHz as being the rough equivalent in terms of basic processor speed of the 11/83 or a 10-MHz 68K you'd be in the right ballpark.

I would like to see the 50MHz eZ80 benchmarked, personally. I think everyone would be surprized. The TI-84CE graphing calculator uses a 48MHz eZ80; wonder if there's a C compiler for the beast?

I know that dhrystone is the epitome of the fun to be had with artificial benchmarks, but I am still pleasantly surprized at how well the Z280 holds up against bigger iron, like the 11/70.


--
Bughlt: Sckmud
Shut her down Scotty, she's sucking mud again!

[Updated on: Fri, 16 February 2018 12:14]

Report message to a moderator

Re: TinyZZ, a Z280 SBC [message #4346 is a reply to message #4343] Sat, 17 February 2018 05:54 Go to previous messageGo to next message
etchedpixels is currently offline  etchedpixels
Messages: 333
Registered: October 2015
Senior Member
There's a whole Zilog toolchain and other supporting stuff. Start with: https://github.com/CE-Programming/toolchain. Nothing open however except in Z80 mode. There were several eZ80 projects but they all seem to have died due to the lack of open information on tools, programmers etc.

There are FPGA alternatives - the T80 core used in Will's socz80 is clock equivalent to the real silicon but will run at 100MHz+ with fast enough RAM or a cache. There's also the Nexgen core which is a modern design executing Z80 instructions and does a lot more at a lower clock rate.

And then of course there's the rabbit ...

[Updated on: Sat, 17 February 2018 05:55]

Report message to a moderator

Re: TinyZZ, a Z280 SBC [message #4347 is a reply to message #4346] Sat, 17 February 2018 06:37 Go to previous messageGo to next message
lowen is currently offline  lowen
Messages: 226
Registered: August 2016
Location: Western NC USA
Senior Member
Thanks for the pointer to the CE C SDK.

Even though I asked about C, the spasm-ng assembler can do eZ80 code. Also, the Y80e core is available that is supposed to be more efficient than the T80 or a-z80; see https://github.com/freecores/y80e

But this is a bit off topic for this thread.

For the Z280, there are, as far as I know, the following toolchains:

  1. John Coffman has done some work on the assembler for sdcc, but I don't know where that work stands
  2. Anders Ostlund has done some work on an assembler for sdcc.
  3. The UZI280 libraries for HiTech C coupled with the freeware version, on either the CPU280's CP/M 3 or within UZI280.
  4. The PRE280 preassembler distributed with the CPU280 code. Source for this is lost, even by its author. Also usable under CP/M 3 (or the zxcc CP/M emulation subsystem from Windows or Linux).
  5. Hector Peraza's Z280 assembler.

I feel like I'm forgetting some, and I apologize if I have.

If a Z280 generator and libs could be written for either the z88dk tool chain or the sdcc toolchain, it would be good.

For other compilers, if it can run on a PDP11 it should be able to run on Z280, if you want native development. I would defer to Alan's expertise on which modern cross compiler chain would be more desirable.

For CP/M the BDS C compiler is completely open, and maybe this could be ported and used for Z280 code generation.


--
Bughlt: Sckmud
Shut her down Scotty, she's sucking mud again!

[Updated on: Sat, 17 February 2018 06:46]

Report message to a moderator

Re: TinyZZ, a Z280 SBC [message #4348 is a reply to message #4347] Sat, 17 February 2018 07:41 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 866
Registered: March 2017
Location: New Mexico, USA
Senior Member
I'm a Windows user so I use Zilog Developer Studio, ZDS, to write Z80 assembly code for Z280. The tool supports eZ80 with simulator although I have not tried it. It also have hooks for C compiler, but I have not tried it, either. ZDS is free download from Zilog. There is ZDS II as well.

I tried Hector Peraza's Z280 assembler, ZSM4b5, in CP/M 2.2 environment. It assembled the test codes and generated listing and .rel files. That's as far as I got.
Re: TinyZZ, a Z280 SBC [message #4356 is a reply to message #4348] Sun, 18 February 2018 12:59 Go to previous messageGo to next message
etchedpixels is currently offline  etchedpixels
Messages: 333
Registered: October 2015
Senior Member
For cross compilers I think it comes down to SDCC. Even z88dk has moved to SDCC as it's core.
Re: TinyZZ, a Z280 SBC [message #4357 is a reply to message #4356] Sun, 18 February 2018 16:48 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 866
Registered: March 2017
Location: New Mexico, USA
Senior Member
Since there are some interests in having 16 meg of memory, I modified my CPLD equations and inserted a 16 meg SIMM module in the socket. It appears to work. All I know of the Z280 MMU is from what I read in the Preliminary Technical Manual, July 1987. I programmed the MMU based on these rather brief description. I did some double checks to make sure it is actually read/write the 16 meg of memory, but I'm not really confident of my understanding. My memory diagnostic takes 3 minutes to do 16 meg. Is there a Z280 memory diagnostic out there to double check my hardware?
Re: TinyZZ, a Z280 SBC [message #4365 is a reply to message #4357] Tue, 20 February 2018 05:16 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 866
Registered: March 2017
Location: New Mexico, USA
Senior Member
Played with the 16 meg memory long enough that I'm pretty sure it is working correctly. Another way of checking the RAM is turning it into a RAM disk, so I set up a 8meg RAM disk and was able to read/write/verify files using PIP. All seems to work properly.

Question: I'm still in CP/M 2.2, is there a command to initialize directory like the 'INIT' command in CP/M-68K? Right now I have to externally fill the RAM disk directory area with 0xE5.
Re: TinyZZ, a Z280 SBC [message #4366 is a reply to message #4365] Tue, 20 February 2018 06:44 Go to previous messageGo to next message
wsm is currently offline  wsm
Messages: 223
Registered: February 2017
Location: AB, Canada
Senior Member
Quote:
I'm still in CP/M 2.2, is there a command to initialize directory like the 'INIT' command in CP/M-68K?

Rather than developing a FORMAT command etc., I've found it just as easy to simply do an "ERA d:*.*" during my testing of RAMdisks. That changes the first letter of all the directory name fields to 0E5h.
Re: TinyZZ, a Z280 SBC [message #4368 is a reply to message #4366] Tue, 20 February 2018 10:51 Go to previous messageGo to next message
rhkoolstar is currently offline  rhkoolstar
Messages: 276
Registered: October 2015
Senior Member
ERA d:*.* only erases the DIR and R/W files in the current user area.
Better write a small program to fill the directory with $E5

'Real' formatting is off course not needed.
Re: TinyZZ, a Z280 SBC [message #4378 is a reply to message #4368] Thu, 22 February 2018 01:40 Go to previous messageGo to next message
rhkoolstar is currently offline  rhkoolstar
Messages: 276
Registered: October 2015
Senior Member
This is the tool I am using (in Z80 code)
It is probably way more involved than what you need.

It assumes 32 k memory pages, 0x0000-0x7FFF
and 128 directory entries

Maybe you can adapt it to your configuration
  • Attachment: rdinit.asm
    (Size: 1.66KB, Downloaded 305 times)
Re: TinyZZ, a Z280 SBC [message #4379 is a reply to message #4378] Thu, 22 February 2018 06:32 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 866
Registered: March 2017
Location: New Mexico, USA
Senior Member
Distraction, distraction and another distraction. This is why this is a hobby: distraction is far more interesting than the goal (which is CPM3 upgrade, I have to remind myself every morning)

#1: Martin Eberhard has released Xmodem 2.7 on comp.os.cpm several months ago. I finally was able to try it on TinyZ280. I can receive file from PC just fine, but at 57600 serial baud rate I think my PC is choking on the incoming serial stream. My terminal software is Tera Term. Even so, I'm happy to have it. This is a critical capability I needed so I can edit/assemble/test on my PC and then download the file to TinyZ280 to run.

#2: Another Martin on comp.os.cpm found an old copy of vi from a book by W. Miller A Software Tools Sampler. He and Udo Munk corroborated and came up with a working vi! I downloaded and ran it on TinyZ280 and it works. The cursor controls are the old 'HJKL' keys. Someone probably will fix that later on. Very cool, I might even entertain writing small program in the native CP/M environment.

#3: Received 10 Z280 from UTSource this week. With that I have enough parts and test software to do margin tests of the design. I tested 13 16-meg SIMM DRAM modules with the 10pcs Z280 over voltage range from 4.8V to 5.3V running RAM diagnostics and CP/M PIP with verify. All 10 Z280 passed, but 3 out of the 13 SIMM modules failed at high voltage. That were curious because parts run faster at higher voltage, but faster parts swinging over greater voltage range also generate more ground noises and ground bounce is always a concern with 2-layer pc board. I added a couple more ground wires to the board and all three DRAM modules passed the tests.

This reminds me of the curious problem with CPU280 where faster PAL part caused problem that was fixed with a slower part. Perhaps Z280 is more susceptible to ground noise. I examined the board layout of the CPU280. It is 2-layer board, but the board was beautifully designed with robust grid-like ground network. I did noticed there is only one 10uF capacitor. DRAM is a real noise maker, so I'd suggest if anyone experienced memory problem with CPU280 to add a couple more 10uF capacitors close to the DRAM array.

------------

rhkoolstar, thanks for the program, I'll modify it for my RAM disk which has 512 directory entries and I used Z280's MMU which has 4K size page. Right now my hardware boots to a monitor where I can erase the RAM disk directory before boot to CP/M. Eventually I'll boot straight to CP/M, so rdinit is a good utility to have.
Re: TinyZZ, a Z280 SBC [message #4380 is a reply to message #4379] Thu, 22 February 2018 07:21 Go to previous messageGo to next message
etchedpixels is currently offline  etchedpixels
Messages: 333
Registered: October 2015
Senior Member
On #2:do you know what licence the editor in the book is under. I was under the impression it was (C) Prentice Hall and had no particular permissions to re-use/redistribute outside of the book ?

There are a couple of other good small vi editors. Manx distributed one in source form with the Manx compiler kits which is a beauty. Sadly I don't think anyone knows where to even start to see about getting the Manx stuff freed up or I'd have chased it up for Fuzix.


The other very minimal one is 'ae', written for the obfuscated C contest which is public domain but a bit hard to read

https://groups.google.com/forum/#!topic/comp.editors/SID2De1 37wY

A slightly extended (and non obfuscated version) that can pretend to be both vi or emacs-ish (or with a few trivial changes wordstar-ish) is at

https://groups.google.com/forum/#!topic/comp.editors/NMhsctX nQ6I

and is a lesson in minimalist elegance.

It does need a curses library but that wouldn't be hard to fix. On a lot of compilers it's best to change movemap(Wink to use memmove(Wink not loops then the compiler will end up directly or indirectly using LDIR/LDDR.

It's tiny in space usage, and the extremist could turn it into hand coded Z280 fairly easily I am sure Cool

Re: TinyZZ, a Z280 SBC [message #4381 is a reply to message #4379] Thu, 22 February 2018 07:55 Go to previous messageGo to next message
wsm is currently offline  wsm
Messages: 223
Registered: February 2017
Location: AB, Canada
Senior Member
Plasmo - Since you have a CPLD and possibly a spare macrocell, you might want to think about a different approach to RAMdisk formatting. In my CPLD I have an I/O accessible flip-flop that is reset at power-on and is set on the trailing edge of a read. The reset signal / pushbutton does not affect it. This flip-flop is read within the cold boot loader and if it's in the reset state the loader sets the entire RAMdisk directory (16K in your case) to E5's using DMA propagation. LDIR would also work. Thus the RAMdisk directory is formatted once and only once at power-on and it's contents remain useable across multiple resets.

Since I don't use USER areas on the RAMdisk, a simple ERA *.* can be used to essentially reformat it if it becomes corrupted during testing and I've never required a power-off/on to accomplish that.
Re: TinyZZ, a Z280 SBC [message #4382 is a reply to message #4380] Thu, 22 February 2018 08:35 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 866
Registered: March 2017
Location: New Mexico, USA
Senior Member
etchedpixels wrote on Thu, 22 February 2018 08:21
On #2:do you know what licence the editor in the book is under. I was under the impression it was (C) Prentice Hall and had no particular permissions to re-use/redistribute outside of the book ?

Udo's github license page says it is "This is free and unencumbered software released into the public domain."
https://github.com/udo-munk/s/blob/s-cpm/LICENSE

"obfuscated C contest"! Laughing , there is such a thing then, not some software guys just want to see us hardware guys squirm. Twisted Evil
Re: TinyZZ, a Z280 SBC [message #4383 is a reply to message #4381] Thu, 22 February 2018 08:37 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 866
Registered: March 2017
Location: New Mexico, USA
Senior Member
wsm wrote on Thu, 22 February 2018 08:55
Plasmo - Since you have a CPLD and possibly a spare macrocell, you might want to think about a different approach to RAMdisk formatting. In my CPLD I have an I/O accessible flip-flop that is reset at power-on and is set on the trailing edge of a read. The reset signal / pushbutton does not affect it. This flip-flop is read within the cold boot loader and if it's in the reset state the loader sets the entire RAMdisk directory (16K in your case) to E5's using DMA propagation. LDIR would also work. Thus the RAMdisk directory is formatted once and only once at power-on and it's contents remain useable across multiple resets.

Since I don't use USER areas on the RAMdisk, a simple ERA *.* can be used to essentially reformat it if it becomes corrupted during testing and I've never required a power-off/on to accomplish that.


wsm, thanks for the suggestion. I do have 25% spare logic but the voltage supervisor reset is wired to same input as the push button reset. I do have a separate NMI button, so that can perform the warm boot function where RAM disk directories are not wiped.
Re: TinyZZ, a Z280 SBC [message #4384 is a reply to message #4383] Thu, 22 February 2018 09:15 Go to previous messageGo to next message
wsm is currently offline  wsm
Messages: 223
Registered: February 2017
Location: AB, Canada
Senior Member
Plasmo - I haven't used the Max7000 chips but it would appear that the Assignment Editor allows you to assign a Power-up Level of Low to a register. Thus the required logic is only on the Set line of a S-R flip-flop for the read trailing edge and the flip-flop's Reset input can be held inactive.

I use this technique on Xilinx chips which have a similar feature. I was leery of using this at first since I always try to write logic that forces registers to a known predictable state during reset. However after testing this feature on a half dozen boards I've never had a problem and have gained confidence with it.
Re: TinyZZ, a Z280 SBC [message #4386 is a reply to message #4384] Thu, 22 February 2018 09:40 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 866
Registered: March 2017
Location: New Mexico, USA
Senior Member
Ah, I see what you meant. I've never used that feature although FPGA and some CPLD do need to know whether voltage level is OK before they load the equations from internal flash (CPLD) or external flash (FPGA). So perhaps the initial state of flip flops are trustworthy. I'll look into that for sure.
Re: TinyZZ, a Z280 SBC [message #4387 is a reply to message #4386] Thu, 22 February 2018 12:58 Go to previous messageGo to next message
etchedpixels is currently offline  etchedpixels
Messages: 333
Registered: October 2015
Senior Member
I shall have to ask Udo. It's a small world Cool Udo also wrote the Z80 emulator I use for most of the Fuzix development and testing, and later it turned out he worked on Coherent (a commercial Unix clone) much of which was later opened up and some commands from it are used in Fuzix, and also most of the Z80 assembler I use witin Fuzix for native assembly Cool

The obfuscated C contest is one of the great traditions. People squash amazing things into unreadable code including things like a basic interpreter, chess, and my favourite of all time - a PC emulator

https://ioccc.org/2013/cable3/hint.html

The other contest I love is the 10 lines of basic contest: http://gkanold.wixsite.com/homeputerium/basic-10liners-2017

Re: TinyZZ, a Z280 SBC [message #4405 is a reply to message #4387] Thu, 01 March 2018 22:02 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 866
Registered: March 2017
Location: New Mexico, USA
Senior Member
I've successfully ported the non-banked version of CPM3 to TinyZ280. In the process I also removed all "workaround" for Z280 "bugs", specifically the extra codes to fix "OUTJMP" bug are all removed and all is working well. The only bug I know of is that refresh register can not be turned off with a value of 0x0. I'm using the refresh register for the DRAM so it is not turned off anyway. I exercise the MMU to do RAMdisk and memory diagnostic and the MMU is performing as expected. I used the DMA to do UART bootstrapping, but I have not used it for memory-to-memory transfer.

I'm beginning to question Z280's reputation for being buggy. Certainly I've encountered problems during the hardware & software developments, but they are all bugs on my part, not the Z280. Z280 is more susceptible to ground noise when interfacing to DRAM, but a couple extra ground wires took care of that. One thing that may be different about my board is that it has zero wait state access to all devices such as memory and compact flash. I believe OUTJMP problem showed up when I/O access has wait states inserted.

Does anyone has specific sample codes that'll cause Z280 to behave abnormally? I like to try them on my setup.
Re: TinyZZ, a Z280 SBC [message #4406 is a reply to message #4405] Fri, 02 March 2018 08:43 Go to previous messageGo to next message
lowen is currently offline  lowen
Messages: 226
Registered: August 2016
Location: Western NC USA
Senior Member
Quote:
I'm beginning to question Z280's reputation for being buggy.


I'm beginning to wonder myself. I have relied on and deferred to Tilmann Reh's experiences along with information from several users of the Z280, but that information is almost all pre-92, and I've seen datecodes now as late as 97. So I guess it's possible that some bugs actually were fixed, but since the bugs weren't documented neither were the fixes. I've not disassembled the Specialix firmware for their SI/XIO ISA card from the Linux kernel drivers; that might be interesting to see if any of the workarounds were used.

I know I'm questioning the quantity manufactured, or the wisdom that the Z280 never really was commercially successful. I mean, there are ten years' worth of production (according to datecodes) out there, and UTSource is claiming 30,000+ stock on chips. And every order I've placed has been filled, quickly, so they apparently have stock of some size to do that.

The CPU280 does some pretty significant wait state generation for I/O, but that's primarily because of the ECB interfacing.

I'm loving where you're taking this beast, Plasmo!


--
Bughlt: Sckmud
Shut her down Scotty, she's sucking mud again!
Re: TinyZZ, a Z280 SBC [message #4407 is a reply to message #4406] Fri, 02 March 2018 10:24 Go to previous messageGo to next message
tor is currently offline  tor
Messages: 25
Registered: April 2016
Location: Norway/Japan
Junior Member
This is getting more and more interesting. What I heard about the Z280 in the past was about a somewhat buggy processor that wasn't around anymore. Now it seems to be alive and well (not problematically buggy), and with 30000 chips in stock? I'm definitely taking notice. Memory management and CP/M (3).. this sounds very interesting.
Re: TinyZZ, a Z280 SBC [message #4410 is a reply to message #4406] Sun, 04 March 2018 08:09 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 866
Registered: March 2017
Location: New Mexico, USA
Senior Member
lowen wrote on Fri, 02 March 2018 09:43
Quote:
I'm beginning to question Z280's reputation for being buggy.


I'm beginning to wonder myself. I have relied on and deferred to Tilmann Reh's experiences along with information from several users of the Z280, but that information is almost all pre-92, and I've seen datecodes now as late as 97. So I guess it's possible that some bugs actually were fixed, but since the bugs weren't documented neither were the fixes. I've not disassembled the Specialix firmware for their SI/XIO ISA card from the Linux kernel drivers; that might be interesting to see if any of the workarounds were used.


The 15pcs of Z280 I have are from 1992 to 1997 so that's consistent with what you have. The earlier Z280 may have bugs, but Zilog had a number of years to correct that and it is hard to imagine they'll leave the more significant bugs as they were during all 10 years of production.

I re-read Tilmann Reh's description of Z280 bugs (section 10 of CPU280 Software Manual):
* OUTJMP bug is associated with I/O-write with wait state. This applies to both CPU access as well as DMA access. I can confirm that without wait state in I/O-write, the CPU access is not subject to the OUTJMP bug. I have not tried I/O write with DMA so far.
* DIVUW gives wrong results.
* DMA may not release the bus after I/O write for up to 20uS. There is a software fix named "Stefan Nitschke Chaos" for that.
* CPU may have invalid carry flag when instruction is sandwiched between two EX AF,AF' instructions. That error is also influenced by whether cache is enabled or not.

I'm ready to turn on DMA for CF and RAM disk data transfer so I will soon find out whether OUTJMP bug applies to DMA transfer of zero-wait I/O and whether DMA hangs on to the bus for up to 20uS. Any one know what is "Stefan Nitschke Chaos"? I imagine that code is implemented in UZI280?
I can understand the race of flag register updating its condition while it is been swapped out. Running with cache enabled will aggrevate that race condition even more. So turning off cache is a simple & quick test when encountering strange results.

I have not look into CPU280's BIOS nor UZI280. I imagine the specific bug fixes were documented in the codes. It may be interesting to remove these bug fixes and see if CPU280 with later date code Z280 still work or not. It is also interesting to port UZI280 and CPU280's BIOS to TinyZ280 with or without the bug fixes and see what happened.
Re: TinyZZ, a Z280 SBC [message #4414 is a reply to message #4410] Tue, 06 March 2018 13:29 Go to previous messageGo to next message
etchedpixels is currently offline  etchedpixels
Messages: 333
Registered: October 2015
Senior Member
I have the official G step errata list (1987)

It lists only two known bugs but I'm not clear if those are just 'new' ones or all the others got fixed and also Tilman claims Zilog didn't even acknowledge some of those he found.

1. A cache corruption bug in Z80 mode

2. Burst mode does not work in X2 and X4 bus clock

H step was released late 1987 early 1988 some time

It would be interesting to know if DIVUW works correctly on your CPU.
Re: TinyZZ, a Z280 SBC [message #4422 is a reply to message #4414] Tue, 06 March 2018 19:13 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 866
Registered: March 2017
Location: New Mexico, USA
Senior Member
This was what Tilmann Reh said about DIVUW bug:

The DIVUW gives wrong results in certain cases. Such a case is the MSB (bit15) of the divisor being set.

So I tried divide 0x20000000 by 0x8888 and get 0x3c00 quotient and 0x2000 remainder. Try 0x20000000 divide by 0x4888 get 0x70F1 quotient and 0x37F8 remainder. These are the correct answers according to my calculator. I tried three different addressing modes:
divuw[dehl],(addr), divuw[dehl],bc, and divuw[dehl],ix, all give the same answers.

Fritz had got Tilmann's board and has picture of it here: https://www.retrobrewcomputers.org/forum/index.php?t=msg& ;th=93&goto=4162&#msg_4162
The date code of Tilmann's Z280 is 8735. The date code of my Z280 that I just did the divuw tests is 9332. So perhaps the divuw bug is fixed since mid 1987.

I remember someone had said somewhere that 'step J' has the bugs fixed. I don't know how to identify the step. The parts I have all have a 2-letter designation on the same line as the date code, but all 15 Z280 have different 2-letter designations.
Re: TinyZZ, a Z280 SBC [message #4425 is a reply to message #4422] Wed, 07 March 2018 04:23 Go to previous messageGo to next message
etchedpixels is currently offline  etchedpixels
Messages: 333
Registered: October 2015
Senior Member
If you know a given divuw fails on Tillman's board then to an extent you do know how to identify the stepping Cool I've not seen any way to tell Z280 steps apart that is documented, nor any documented register that exposes it. The Z80 is similar - you can pull tricks to tell NMOS from CMOS but that is about it.

If you think the Z280 is buggy you should really read the 80286 errata, older versions of that were dire, after that the original 386 couldn't multiply, the pentium couldn't divide Cool

[Updated on: Wed, 07 March 2018 04:26]

Report message to a moderator

Re: TinyZZ, a Z280 SBC [message #4426 is a reply to message #4425] Wed, 07 March 2018 06:18 Go to previous messageGo to next message
lowen is currently offline  lowen
Messages: 226
Registered: August 2016
Location: Western NC USA
Senior Member
What I had thought about doing was writing a small routine that was the equivalent of DIVUW but using only Z80 instructions and then iteratively comparing the results of that routine with the results of DIVUW and see if there was a pattern. Work has me way too busy right now to be able to concentrate on it, though.

I'd love to see the equivalent of ZEXDOC and ZEXALL for Z280, but it will be a while before I will have time to try my hand at writing it.


--
Bughlt: Sckmud
Shut her down Scotty, she's sucking mud again!
Re: TinyZZ, a Z280 SBC [message #4427 is a reply to message #4426] Wed, 07 March 2018 08:05 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 866
Registered: March 2017
Location: New Mexico, USA
Senior Member
For the 680x0 family Motorola would designate the parts with 'XC' prefix before going full production and there usually is a cryptic line of text indicating the mask level and production facility. I guess date code on Z280 is all we have to go on.

Anyone who has a pre-1988 Z280, I'll trade you with a post-1992 Z280.

Never heard of ZEXDOC & ZEXALL until now. It is amazing how much Z80 knowledge are out there.
Re: TinyZZ, a Z280 SBC [message #4428 is a reply to message #4427] Wed, 07 March 2018 08:13 Go to previous messageGo to next message
lowen is currently offline  lowen
Messages: 226
Registered: August 2016
Location: Western NC USA
Senior Member
One of the best sources of information on Z80 is Rodnay Zaks' book. Rodnay has given permission for a PDF to be posted online, and you can grab it from the links at the end of this page. For that matter, the whole 'www.z80.info' site is a gold mine, but it needs more Z280, Z380, and eZ80 information. (Z380 and eZ80 are current production, but since both are only available in surface-mount packages, they haven't been as popular with hobbyists)

--
Bughlt: Sckmud
Shut her down Scotty, she's sucking mud again!

[Updated on: Wed, 07 March 2018 08:14]

Report message to a moderator

Re: TinyZZ, a Z280 SBC [message #4429 is a reply to message #4428] Wed, 07 March 2018 12:08 Go to previous messageGo to next message
etchedpixels is currently offline  etchedpixels
Messages: 333
Registered: October 2015
Senior Member
The other problem with them was that Zilog made it near enough impossible to use anything but their own proprietary cable and tools for programming the eZ80. Nowdays its documented and there are tools (eg https://hackaday.io/project/9483-ez80-open-source-programmerWink

There was an ez80 sbc project years ago (ez80sbc) - see https://web.archive.org/web/20100604065529/http://www.ez80sb c.com:80/


Re: TinyZZ, a Z280 SBC [message #4446 is a reply to message #4422] Thu, 15 March 2018 22:47 Go to previous messageGo to next message
fritzeflink is currently offline  fritzeflink
Messages: 80
Registered: January 2017
Location: germany
Member
plasmo wrote on Wed, 07 March 2018 04:13
This was what Tilmann Reh said about DIVUW bug:

The DIVUW gives wrong results in certain cases. Such a case is the MSB (bit15) of the divisor being set.

So I tried divide 0x20000000 by 0x8888 and get 0x3c00 quotient and 0x2000 remainder. Try 0x20000000 divide by 0x4888 get 0x70F1 quotient and 0x37F8 remainder. These are the correct answers according to my calculator. I tried three different addressing modes:
divuw[dehl],(addr), divuw[dehl],bc, and divuw[dehl],ix, all give the same answers.

Fritz had got Tilmann's board and has picture of it here: https://www.retrobrewcomputers.org/forum/index.php?t=msg& ;amp ;amp ;th=93&goto=4162&#msg_4162
The date code of Tilmann's Z280 is 8735. The date code of my Z280 that I just did the divuw tests is 9332. So perhaps the divuw bug is fixed since mid 1987.
.


The buggy old Z280 is mine. Very interesting info from you reading just as I can't sleep.
The CPU280 with the old Z280 stop after the ram test. I hope I got help next month from a 'developer' as I'm only a mechanic. Smile





/*-----
fritz
-----*/

[Updated on: Thu, 15 March 2018 22:48]

Report message to a moderator

Re: TinyZZ, a Z280 SBC [message #4447 is a reply to message #4209] Fri, 16 March 2018 02:40 Go to previous messageGo to next message
hperaza is currently offline  hperaza
Messages: 68
Registered: March 2017
Member
plasmo wrote on Tue, 30 January 2018 06:57
I'm leaning toward porting CP/M because it may test the board more thoroughly and also let me try Hector Peraza (hperaza) Z280 assembler ( https://www.retrobrewcomputers.org/forum/index.php?t=msg& ;amp ;amp ;th=93&goto=3700&#msg_3700). Right now I'm hand assembling the few Z280 extended instructions I needed.

You can use the Z280 assembler on Unix/Linux with a tool like John Elliott's ZXCC. There is a Windows port available somewhere as well.

The advantage of ZXCC over other CP/M emulators like e.g. z80pack is that with ZXCC you can run any CP/M utility directly from the command line (or from a Makefile), and access files on the host filesystem without having to put everything first in a virtual disk. ZXCC is used, for example, to cross-build CP/M 3 for the CPU280; that's the tool I used as well to develop and test the assembler.

BTW, I love your TinyZ280 board; I just added it to my TODO list Cool . The CPLD is a clever addition that makes it more versatile while keeping the component count down.
Re: TinyZZ, a Z280 SBC [message #4448 is a reply to message #4410] Fri, 16 March 2018 03:12 Go to previous messageGo to next message
hperaza is currently offline  hperaza
Messages: 68
Registered: March 2017
Member
[quote title=plasmo wrote on Sun, 04 March 2018 08:09]lowen wrote on Fri, 02 March 2018 09:43
I'm ready to turn on DMA for CF and RAM disk data transfer so I will soon find out whether OUTJMP bug applies to DMA transfer of zero-wait I/O and whether DMA hangs on to the bus for up to 20uS. Any one know what is "Stefan Nitschke Chaos"?

It's a section of code inside the DskIO routine, diskio.280 file. Basically, the DMA bug causes the data transfer from the FDC controller to fail with a DMA underrun error. When that happens, the code "fixes" the bug by writing four null words to four consecutive I/O addresses starting at FFxxE8. The mystery being that those addresses do not correspond to anything (documented, at least), that the fix has to be applied only when the bug is triggered, and that it needs to be applied only once (at least according to the code logic). So a second FDC DMA underrun error is supposed to be a floppy or FDC fault. The fix is never applied for hard disk (GIDE) DMA transfers, since IDE data transfers are not time-critical and there is no easy way to tell if the DMA bug happened in that case.
Re: TinyZZ, a Z280 SBC [message #4449 is a reply to message #4448] Fri, 16 March 2018 05:59 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 866
Registered: March 2017
Location: New Mexico, USA
Senior Member
FFxxE8 is the refresh controller (section 9.3 of Preliminary technical manual). I don't know what the next three I/O address after FFxxE8 are. Writing zero to FFxxE8 will disable the refresh controller but that will cause my board to crash, but I have not find out why exactly. To turn off the refresh controller, I would clear bit 7 (enable bit), but write non-zero values to remaining 7 bits. Since I do use the refresh counter for the DRAM, it is enabled and programmed to 16uS refresh.

I begin to understand why the unexpected 20uS delay: The refresh counter keeps track of how many refresh cycles it missed when Z280 bus mastership is relinquished to alternate bus masters (such as DMA). When Z280 regained the bus mastership, the refresh counter will take over immediately and make up for the refresh cycles it missed. This could be quite a number of cycles so Z280 appears to stalled during that period. At reset the refresh counter defaults to a refresh every 32 CPU clocks (about 2.6uS) so if DMA takes away 200uS from CPU bus mastership, the refresh counter will take 20uS to make up for the missing refresh cycles. Turning off the refresh counter will stop it from taking over the Z280 bus, but only until next reset.

CPU280 have DRAM as well, so it must have a different way of refreshing the memory and not relying on the internal refresh counter.

[Updated on: Fri, 16 March 2018 06:04]

Report message to a moderator

Re: TinyZZ, a Z280 SBC [message #4450 is a reply to message #4447] Fri, 16 March 2018 06:22 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 866
Registered: March 2017
Location: New Mexico, USA
Senior Member
hperaza wrote on Fri, 16 March 2018 03:40
plasmo wrote on Tue, 30 January 2018 06:57
I'm leaning toward porting CP/M because it may test the board more thoroughly and also let me try Hector Peraza (hperaza) Z280 assembler ( https://www.retrobrewcomputers.org/forum/index.php?t=msg& ;amp ;amp ;amp ;th=93&goto=3700&#msg_3700). Right now I'm hand assembling the few Z280 extended instructions I needed.

You can use the Z280 assembler on Unix/Linux with a tool like John Elliott's ZXCC. There is a Windows port available somewhere as well.

The advantage of ZXCC over other CP/M emulators like e.g. z80pack is that with ZXCC you can run any CP/M utility directly from the command line (or from a Makefile), and access files on the host filesystem without having to put everything first in a virtual disk. ZXCC is used, for example, to cross-build CP/M 3 for the CPU280; that's the tool I used as well to develop and test the assembler.

BTW, I love your TinyZ280 board; I just added it to my TODO list Cool . The CPLD is a clever addition that makes it more versatile while keeping the component count down.


Thank you for the pointer to ZXCC. The wonderful thing about the Z80 community is there are so many resources for every development environment and the bad thing about the Z80 community is there are so many resources for every development environment. Cool Without someone points the way, a newbie like me can get bogged down trying every different tools.

CPLD is the heart of the design. I've learned my lesson from Tiny68K where CPLD is completely used up without any spare pins and logic. Booting from CF is a simpler design that gives me a dozen spare pins and 25% spare logic thus more room to play! Laughing
Re: TinyZZ, a Z280 SBC [message #4451 is a reply to message #4158] Fri, 16 March 2018 16:59 Go to previous messageGo to next message
Andrew B is currently offline  Andrew B
Messages: 467
Registered: October 2015
Location: Near Redmond, WA
Senior Member
Administrator
The windows port of zxcc is part of Wayne's RomWBW repository:

https://github.com/wwarthen/RomWBW/tree/master/Tools/zx

A very useful tool indeed.
Re: TinyZZ, a Z280 SBC [message #4452 is a reply to message #4449] Sat, 17 March 2018 05:53 Go to previous messageGo to next message
hperaza is currently offline  hperaza
Messages: 68
Registered: March 2017
Member
plasmo wrote on Fri, 16 March 2018 05:59
FFxxE8 is the refresh controller (section 9.3 of Preliminary technical manual). I don't know what the next three I/O address after FFxxE8 are. Writing zero to FFxxE8 will disable the refresh controller but that will cause my board to crash, but I have not find out why exactly. To turn off the refresh controller, I would clear bit 7 (enable bit), but write non-zero values to remaining 7 bits. Since I do use the refresh counter for the DRAM, it is enabled and programmed to 16uS refresh.

Indeed, just consulted the manual and is there. I was quoting the source code comments, and it looks like either the register was not documented at the time, or Stefan Nitschke did not have access to the full documentation. Interestingly, there is an entry for the register in the z280equ.mac file.

Your explanation of the DMA delay makes full sense, and the 'bug' starts looking now more like a design 'feature' than a real bug. And since the workaround was found "by accident", the additional writes to the FFxxE9..EB addresses are very likely superfluous.
Re: TinyZZ, a Z280 SBC [message #4453 is a reply to message #4428] Sat, 17 March 2018 06:31 Go to previous messageGo to next message
fritzeflink is currently offline  fritzeflink
Messages: 80
Registered: January 2017
Location: germany
Member
lowen wrote on Wed, 07 March 2018 17:13
One of the best sources of information on Z80 is Rodnay Zaks' book. Rodnay has given permission for a PDF to be posted online, and you can grab it from the links at the end of this page. For that matter, the whole 'www.z80.info' site is a gold mine, but it needs more Z280, Z380, and eZ80 information. (Z380 and eZ80 are current production, but since both are only available in surface-mount packages, they haven't been as popular with hobbyists)


For german people you can get Zaks_Programmierung_des_Z80.pdf at

http://oldcomputers.dyndns.org/public/pub/manuals/ and scroll down for download.


/*-----
fritz
-----*/
Re: TinyZZ, a Z280 SBC [message #4454 is a reply to message #4410] Sat, 17 March 2018 07:00 Go to previous messageGo to previous message
hperaza is currently offline  hperaza
Messages: 68
Registered: March 2017
Member
plasmo wrote on Sun, 04 March 2018 08:09
* CPU may have invalid carry flag when instruction is sandwiched between two EX AF,AF' instructions. That error is also influenced by whether cache is enabled or not.

You can find the original bug report here.

My CPU (date code 9528) has the bug, and I can reproduce it consistently with any variations of the same sequence, e.g.:
scf
ex  af,af'
xor a
ex  af,af'
It is not that the carry bit disappears, but that the second ex af,af' instruction copies the flags register instead of swapping it (the accumulators are swapped as expected). For example, after the following sequence:
xor a      ;clear sign and carry
ex  af,af'
or  0FFh   ;set sign flag
ex  af,af'
both F and F' are identical: Carry and Zero bits clear, Sign and Even parity bits set. The pattern seems to be: one single arithmetic or logical instruction that uses the ALU sandwiched between two ex af,af' instructions. Thus, if the instruction is a load operation, or a rotate, nop, scf, etc. the bug will not be triggered. Neither it will if the "sandwich" consists of two or more instructions. Those are my observations so far.

How can it depend on the specific memory location (for me it happens when the starting address of the sequence is e.g. 100h, 1000h, 2000h, 8000h, etc. but not if it is e.g. 9E75h), or if cache is enabled/disabled is unclear to me. An easy fix is to add at least a nop after the arithmetic instruction, easy to do when developing new software, but difficult to fix for existing applications.

[Updated on: Sat, 17 March 2018 07:04]

Report message to a moderator

Previous Topic: PIC TV clock
Next Topic: ECB 4MEM question


Current Time: Fri Mar 29 04:02:37 PDT 2024

Total time taken to generate the page: 0.01001 seconds