f



what of the eZ80?

Is anyone running an eZ80 system?

For a while the 50 MHz Zilog eZ80 looked like fun,
particularly their eZ80 Acclaim! eval boards.
I fear I missed buying the CP/M expansion board.
0
jeffj
7/5/2016 1:02:54 PM
comp.os.cpm 3422 articles. 0 followers. Post Follow

30 Replies
578 Views

Similar Articles

[PageSpeed] 8

I thought the eZ80 evaluation board was a little too sparse, though it would make a nice, simple CP/M system with its 8MB Nor Flash Rom functioning mostly as a Rom-Disk.

The eZ80 is much more capable though, so its really better to design a SBC specifically for a supercharged CP/M system.

For me that would be more retro than vintage. I'd rather had updated i/o particularly USB OTG even though you have to write device drivers for the eZ80.

 Jay_in_Dallas
--
0
9/13/2016 12:16:57 AM
There is a sight with CP/M 2.2 running that just needs an SD socket added.  The original site is down but here is an archive:

http://www.z80cpu.eu/mirrors/www.vegeneering.com/eZ80_CPM/index.html


Randy
0
randy482
9/13/2016 12:45:29 AM
On 07/05/2016 09:02 AM, Jeff Jonas wrote:
> Is anyone running an eZ80 system?
>
> For a while the 50 MHz Zilog eZ80 looked like fun,
> particularly their eZ80 Acclaim! eval boards.
> I fear I missed buying the CP/M expansion board.

Chris Brock ported MP/M to one of the Zilog evaluation boards.  He sent me the 
code several years ago but I have not been able to find time to work on this 
project.  His setup required an add-on static memory board, IIRC.




0
Steven
9/14/2016 11:57:05 AM
The ez80 has the worst MMU on the planet.

You can switch to 8 bit mode on any 64K boundary with no "common" memory.

But as I see it @50mhz how long would it take to copy 16K from one 64K block to another to emulate bank switching?  When a request to bank select happens just copy current "common" ram to next one.


Randy
0
randy482
9/14/2016 5:12:25 PM
On 09/14/2016 01:12 PM, randy482@hotmail.com wrote:
> The ez80 has the worst MMU on the planet.

> You can switch to 8 bit mode on any 64K boundary with no "common" memory.

> But as I see it @50mhz how long would it take to copy 16K from one 64K
> block to another to emulate bank switching?  When a request to bank select
> happens just copy current "common" ram to next one.

If you run in the right mode, you have 24-bit addressing.  Who needs bank 
switching in that situation?
0
Steven
9/14/2016 10:36:59 PM
On Wednesday, September 14, 2016 at 5:37:04 PM UTC-5, Steven Hirsch wrote:
> On 09/14/2016 01:12 PM, randy wrote:
> > The ez80 has the worst MMU on the planet.
> 
> > You can switch to 8 bit mode on any 64K boundary with no "common" memory.
> 
> > But as I see it @50mhz how long would it take to copy 16K from one 64K
> > block to another to emulate bank switching?  When a request to bank select
> > happens just copy current "common" ram to next one.
> 
> If you run in the right mode, you have 24-bit addressing.  Who needs bank 
> switching in that situation?

Yes you get 24 bit addressing but cant run z80 code, so no CP/M or MP/M


Randy
0
randy482
9/14/2016 11:15:39 PM
On Wednesday, September 14, 2016 at 4:15:40 PM UTC-7, rand...@hotmail.com wrote:
> 
> Yes you get 24 bit addressing but cant run z80 code, so no CP/M or MP/M

Well, CP/M-68K does 32 bits and is written in C; surely an enthused person
could make a 24-bit version?

(fundamentally CP/M-68K is a 16-bit operating system surrounded by 32-bit
glue; shouldn't be hard to make 24-bit glue)
-- 
roger ivie
roger.ivie@gmail.com
0
roger
9/15/2016 12:41:07 AM
Yes I've tried to convince myself to do it.  Then I would have an ez80 version that won't have anything to run.  To run z80 code on the ez80 you need to be in z80 mode (16 bit addressing when the top 8 bits are preset).

It is possible to modify CP/M 68K for ez80 then have it open .com files in a 64K z80 space but you are talking about a year or more of development time for a system only a small handful of people could possibly use.


Randy
0
randy482
9/15/2016 1:00:08 AM
randy482 wrote:
> ...But as I see it @50mhz how long would
> it take to copy 16K from one 64K block to
> another to emulate bank switching?...

Yes. When the OS is requested to switch user pages, just copy the common block forward every time it switches. A block copy operating in 50Mhz, 16MB mode is hard to beat. Doing anything else has diminishing return for the effort or cost.


> ...Yes you get 24 bit addressing but can't
> run z80 code, so no CP/M or MP/M...

If you design an eZ80 single board computer, you'll need to write a kernel to run its modern resources.

That kernel can easily manage multiple users in their own 64KB blocks, by time-slicing their access to the processor. An eZ80 timer determines how long the user's environment runs and when that timer interrupts and invokes the kernel, it cuts in and freezes that user-space environment until it runs again, and loads the next assigned user-space and runs it until the next timer interval expires.

***So even if the kernel runs in 16MB mode, it can support several users (or background tasks) running Z80 code with CP/M or MP/M in various 64KB blocks.

That's Legacy Z80++.

Note that the kernel would be intercepting all the BIOS calls from the active user-space and doing the single board computer resource work as necessary for that eZ80 board. No direct user-space access to devices, ports etc would occur. That's necessary if you have several users vying for resources. The BIOS bridge to the kernel would buffer incoming and outgoing information until it can be delivered.

There would be no need to write a BIOS, the kernel just intercepts all access to either the space it would have occupied or just the jump entry points itself. It does that by overwriting the BIOS after it is loaded. Its replaced with something that invokes a high level vectored interrupt to the kernel which can then recover the source address and z80 registers to identify the intercepted BIOS access and settings, and call its own kernel routines instead.

Interestingly, the kernel might have to make CP/M 2.2 think a USB memory stick is just another floppy disk. As long as your legacy OS doesn't know any better, its happy. But the kernel has to know what OS is running, so it can identify virtualized BDOS diskette traversals, into its real meaning and present a version of the eZ80 resources in a way the OS expects a diskette/floppy drive to respond.

Traversing to a floppy the directory track? As long as the kernel knows the OS version running, it can make its system resources look like a floppy drive but with instantaneous seek times. The kernel keeps track of the virtual floppy's track, head, selections and creates sector images the OS expects, but there are no real-world delays.

Ultimately, the better solution is to simply create a new OS that can *look* like any legacy OS you want to run in Z80 mode.

Jay_in_Dallas
--
0
9/15/2016 3:21:08 AM
IMHO it sould be CP/M-Z8K the right path to follow in this case.
0
Floppy
9/15/2016 6:28:12 AM
On Thursday, September 15, 2016 at 10:21:05 AM UTC+7, Jay_in_Dallas wrote:

> Yes. When the OS is requested to switch user pages, just copy the common block forward
> every time it switches. A block copy operating in 50Mhz, 16MB mode is hard to beat. Doing
> anything else has diminishing return for the effort or cost.

CP/M 3 as well as MP/M often switch to the bank that is the active one already. So always
check the bank it wants to switch to, and only copy if it's a different one.

In the 80th I implemented MP/M on a Z80 system with multiple 64K banks but without MMU.
Copy between the banks was done with a Z80 DMA, this worked, but way to slow, unusable for
anything but playing with it.
0
Udo
9/15/2016 8:17:59 AM
On 09/14/2016 07:15 PM, randy482@hotmail.com wrote:
> On Wednesday, September 14, 2016 at 5:37:04 PM UTC-5, Steven Hirsch wrote:

>> If you run in the right mode, you have 24-bit addressing.  Who needs bank
>> switching in that situation?

> Yes you get 24 bit addressing but cant run z80 code, so no CP/M or MP/M

If you isolate use of 24-bit addressing to the BIOS you can have the best of 
both worlds.  That's what Chris Brock's port does.  It runs vanilla Z80 
programs as user tasks and switches modes at system level.


0
Steven
9/15/2016 11:59:48 AM
On Thursday, 15 September 2016 07:28:13 UTC+1, Floppy Software  wrote:
> IMHO it sould be CP/M-Z8K the right path to follow in this case.

I think similarities between the Z80 and the Z8000s are more misleading tha=
n useful.
I made a Z8001/Z8010 computer in the early '80s. I picked a Z8000 partly be=
cause the assembly language is vaguely similar to the Z80 I already knew...=
 but there aren't many Z80 instructions that'll assemble on a Z8000. I was =
forever typing "DJNZ label"... forgetting that on the Z8k you have to speci=
fy a register (and DJNZ is 16-bit. DJNZB is 8-bit).

I tried compiling the CP/M-Z8K assembler under Cygwin recently. No luck. It=
 makes some odd assumptions about the C runtime system.

(I wrote a Z8001 assembler in Turbo Pascal on an Amstrad PCW to go with my =
computer. I must try to resurrect the computer/assembler one day!)
0
Bruce
9/16/2016 4:26:13 PM
Steven is correct. Allow my to clarify ...

Reading through the eZ80 F91 documentation, you won't find the word "MMU". =
But neither MP/M nor CP/M Plus require an MMU. What they do require is that=
 the higher addresses of  memory within the CPU's 16 bit addressing range r=
emain static at all times to work as a common memory bank. This is configur=
able at system generation time on 4K boundries.=20

The eZ80 has 16K of internal CPU RAM that can be configured to be ever-pres=
ent at the top of the 16 bit 64K addressable range when in Z80-compatible m=
ode. You can configure the eZ80 to use either 16K or 8K of its internal RAM=
 to be the common memory. So for CP/M Plus or MP/M, this means the User Ban=
k size would be 48K or 56K. Bank-switching is insanely quick. All it takes =
is writing one byte to an internal register, just 2 T states or 40 ns.

This comes not just from reading the documentation; I have actually coded t=
his up and it works great.

I used to make a living writing and maintaining CP/M BIOSes in the 1980s.
0
Chris
10/19/2016 1:03:40 AM
Chris wrote:
> ...The eZ80 has 16K of internal CPU RAM...

But you have to decide if you want to sacrifice the Ethernet 10/100Mbps capability that uses 8KB for that SRam. Even though the 100Mbps speed is maybe stretching its abilities, Ethernet is a nice bridge.

It seems likely that the address block location of E000h and C000h in a 64KB page, had this very intention as a means of supporting some retro common memory block with the SRam. It takes the sting out of not having a MMU, but I find the CSx# lines to be very handy, but obviously only at 64KB block granularity.

Last year I pondered the pros and cons of using the internal ram as common memory and various 8-bit and even 32-bit DMA transfers, and decided that since CP/M 3:Plus and MP/M were not that important to me personally, I'd just choose to do a block copy instruction when the bank number changes. Various hardware enhancements just really don't pay off for common memory function. If you run as fast as possible (50Mhz) there is no time to decode during an access to static ram and you really have to use CSx# to do that.

And while 16KB is probably a big common memory block, I think when I checked the specifications, 32KB was the maximum size for common block and the maximum number of banks for a user was sixteen 64KB blocks (or was it thirty two?) at 4KB granularity. Anyway, the only way to support every retro possible configuration is to copy the common memory block when the bank is actually changed. At least until Zilog puts a little more fast internal ram in the processor.

Personally, I'd rather use an external Ethernet chip and have the eZ80F91+ toss the Ethernet I/O lines and instead provide more CSx# lines and more internal common memory. External USB chips make the system design a lot more efficient, but I think Ethernet and USB should be *not* internal eZ80 features; its better to be able to choose superior chips from the larger chip marketplace.

I'm using 2MB ISSI Static rams in my design (instead of Cypress that Zilog's board uses) and with only CS{0,1,2,3}# available, you can only address 8MB of the 16MB directly as 50Mhz static ram. You can expand static beyond that with banking but you only have about 1.5ns to 3ns of propagation delay to inject into r/w access cycles. Or wait until 4MB static rams become available. Until then, I'm banking each CSx# 2MB block of memory.

JDallas
0
10/22/2016 5:28:26 AM
JDallas wrote:
> ...32KB was the maximum size for common block and the
> maximumnumber of banks for a user was sixteen 64KB 
> blocks (or was it thirty two?) at 4KB granularity...

Correction:
...32KB was the maximum size for common block at 4KB granularity and the maximum number of banks for a user was sixteen 64KB blocks (or was it thirty two?)...
0
10/22/2016 5:38:40 AM
Steven wrote:
> ...Chris Brock ported MP/M to one of the Zilog
> evaluation boards.  He sent me the code several
> years ago but I have not been able to find time
> to work on this project.  His setup required an
> add-on static memory board, IIRC...

Zilog updated the evaluation board in 2014 or 2015 and it includes a Cypress 1MB static ram capable of running 50Mhz (its a 100Mhz ram but the eZ80 access times are 50Mhz). It also includes a nice 8MB nor-flash Rom perfect for use a Rom-Drive.

As your message may have referred to the prior eZ80 evaluation board (2007-ish?), you may no longer require a "add-on static memory board". Just make your 8MB Rom your Rom-Disk and your 1MB ram your CP/M 3:Plus operating ram.

The evaluation board is capable of doing 10Mbps Ethernet (100Mbps is a stretch) so that gives you a bridge to access files from a PC. However, loading that Ethernet FTP package may eat up the CP/M environment unless you write a version that loads a lot of the package under CP/M.

I don't recall if the newer eZ80 evaluation board had a micro-SD socket or not. It would be more ideal to write the drivers so that the e-board would treat the micro-SD as a floppy disk.


Steven wrote: 
> ...If you isolate use of 24-bit addressing to the BIOS
> you can have the best of both worlds.  That's what
> Chris Brock's port does.  It runs vanilla Z80 programs
> as user tasks and switches modes at system level...

Technically, you can run the eZ80 in "mixed-mode" to allow any CP/M program to access resources in the 16MB address space, if and when it needs to do so. It would just run as a normal eZ80 until it fetched an instruction that kicks it into 24bit mode. If you're running a vintage CP/M 2.2 program on an eZ80 running in mixed-mode, the program will never exit 64KB mode. But you can write code that runs in a 64KB memory space under CP/M that can kick it into 24bit mode to do a bit of processing and then restore it to 64KB mode for normal vintage operation to continue.

You really can have the best of both worlds with the eZ80... you just have to spend the time to wrap your head around it and see what its capable of doing. As someone suggested, its a lot of work for something only a handful of people would use.

But then again, for Vintage/Retro hobbyists, that's a given before you start *any* project. The question is more generally framed, as in the early days of hobbyist computing, "Does this project have value to me?" ... and if it works, share it with others.

JDallas
0
10/24/2016 9:40:56 PM
JDallas wrote:
> ...just run as a normal eZ80 until it fetched an instruction that kicks
> it into 24bit mode. If you're running a vintage CP/M 2.2 program on
> an eZ80 running in mixed-mode, the program will never exit 64KB
> mode. But you can write code that runs in a 64KB memory space
> under CP/M that can kick it into 24bit mode to do a bit of processing
> and then restore it to 64KB mode for normal vintage operation to continue...

One could argue that mixed-mode, described lightly above, makes an MMU moot.

If you need something from another CP/M 3:Plus page or need to access common memory, just open 24bit mode, access directly what you need, then restore 64KB mode again.

Its as easy as standing up in an office cubical and looking across the room at a clock on the wall. There is no need to bring the clock into your cubicle. ;)

JDallas
0
10/24/2016 9:52:01 PM
On 10/24/2016 05:40 PM, Jay_in_Dallas wrote:
> Steven wrote:
>> ...Chris Brock ported MP/M to one of the Zilog evaluation boards.  He
>> sent me the code several years ago but I have not been able to find time
>> to work on this project.  His setup required an add-on static memory
>> board, IIRC...

> Zilog updated the evaluation board in 2014 or 2015 and it includes a
> Cypress 1MB static ram capable of running 50Mhz (its a 100Mhz ram but the
> eZ80 access times are 50Mhz). It also includes a nice 8MB nor-flash Rom
> perfect for use a Rom-Drive.
>
> As your message may have referred to the prior eZ80 evaluation board
> (2007-ish?), you may no longer require a "add-on static memory board". Just
> make your 8MB Rom your Rom-Disk and your 1MB ram your CP/M 3:Plus operating
> ram.

Yes, you are correct.  My board is an eZ80AcclaimPlus! with 1MB of SRAM and 
8MB of flash memory.  Time to take another look at Chris's code.


0
Steven
10/25/2016 11:44:37 AM
Great!

Keep us posted on your project as it could be more relevant to anyone wanting a quick eZ80 platform for CP/M as that is the board being sold by Zilog today.

I looked at that board a year ago and the price was still bubbling around with a high minimum purchase quantity. Finally available in single quantity purchase at around $169 each as I recall. Granted that price is mostly the development software that comes with it, but after reading the eZ80 documentation, I thought it would be more interested to use more of its power.

I decided to design my own eZ80 board as that processor is the last available processor in normal production that is really compatible with that era and is capable of running all that code. I'm in no rush to fabricate my board, its more of a fun, learning process that evolves in circuit board design CAD (Pads). I found oddities in the eZ80 design that probably made it unpopular in its roll-out, and am searching for the solutions/work-arounds just as a personal challenge in my spare time.

Currently I'm evolving my static ram memory away from the main board and onto DIMM type cards. When the rams are on the main board, you have to do too many versions of the main pcb for various needs of ram. Moving static ram to DIMM type cards means one board can be used for all those memory configurations, just plug in what you need and let the OS adjust.

This evolved from having three types of memory cards:
(1) 4x2MB linearly mapped to CS0# through CS3#
(2) 4x2MB banked mapped to one CSx#; for example, CS0.0# through CS0.3#
(3) 4x2MB combo for CSx# and CSx+1# banked mapped as two rams each.

That evolved to reduce components off the memory card to using only (1) and (2) as useful mappings. The idea is that (1) would be used on minimal systems and (2) for pushing the memory to the Crazy-Z80 realm. I figured that having a special DIMM socket for (1) would suffice and four type (2) for high-end applications.

I added some circuit so that a system reset disables all the ram, so the eZ80 can boot up off its internal 256KB rom and 16KB of ram (or onboard nor-flash rom) to read the board IDs from the socket and configure the resources accordingly. I also added write protect controls so that 50Mhz ram could be used as zero wait state rom, without any code accidentally overwriting it.

Currently I'm looking at making ram cards (1) and (2) a "flippy" pcb so that how its plugged into the DIMM socket determines how its configured - to be either (1) Linear or (2) banked. This is an interesting pursuit as it only requires one memory card design and upgrading memory would never involve replacing and throwing away a ram card. If the component side is facing one way, its (1) Linear, and if its facing the other way (using the same card edge connector) then its (2) Banked. The card ID likewise changes.

If the "flippy" idea doesn't look clean in the pcb layout, I may punt it for linear ram on the main board and DIMM sockets for banking. As soon as I tidy up that part of the design, I'll work on locking in a USB controller chips for it.

I can't say I'll ever finish this design. It would be easier if I retired but I don't have time for that yet. But my dissatisfaction with the state of the current PC computer and its various operating systems, keeps me interested in making my own computer and OS somewhere near the mid-point, along a spectrum from the 1980s CP/M system to today's PC.

JDallas
0
10/25/2016 3:16:07 PM
eZ80 Linux-Lite?

Has anyone looked into implementing a light version of Linux on a Ram-Rich eZ80?

I've been reading about several operating systems and I guess my time using Unix has shaped a lot of my opinions as Linux seems to be about 80% of what I was thinking about doing as a kernel. My raw thinking on the matter is that CP/M versions would be like a shell what would run mostly externally of any user's 64KB workspace, making the TPA much larger. And various vintage computer's uniqueness in display, keyboard etc could be handled by the selection of the TERMINAL under a Linux core.

I realize that it just sounds a lot like taking a PC-based CP/M-Z80 emulator and running it on a Z80 instead of the '86 processors and maybe it *is* just that. But hobbyist project don't have to make a lot of sense... its just about whether someone wants to take the time to do something one finds interesting. :S

Thoughts?

JDallas
0
12/13/2016 3:34:20 PM
On Tuesday, December 13, 2016 at 4:34:19 PM UTC+1, Jay_in_Dallas wrote:

> eZ80 Linux-Lite?
> 
> Has anyone looked into implementing a light version of Linux on a
> Ram-Rich eZ80?
> Thoughts?

Fuzix
0
Udo
12/13/2016 7:00:20 PM
Reply: