info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
what of the eZ80?
1,179 views
Skip to first unread message
Jeff Jonas
Jul 5, 2016, 9:02:55 AM7/5/16
to
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.
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.
Jay_in_Dallas
Sep 12, 2016, 8:16:59 PM9/12/16
to
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
--
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
--
rand...@hotmail.com
Sep 12, 2016, 8:45:30 PM9/12/16
to
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
http://www.z80cpu.eu/mirrors/www.vegeneering.com/eZ80_CPM/index.html
Randy
Steven Hirsch
Sep 14, 2016, 7:57:10 AM9/14/16
to
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.
rand...@hotmail.com
Sep 14, 2016, 1:12:27 PM9/14/16
to
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
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
Steven Hirsch
Sep 14, 2016, 6:37:04 PM9/14/16
to
switching in that situation?
rand...@hotmail.com
Sep 14, 2016, 7:15:40 PM9/14/16
to
On Wednesday, September 14, 2016 at 5:37:04 PM UTC-5, Steven Hirsch wrote:
Yes you get 24 bit addressing but cant run z80 code, so no CP/M or MP/M
Randy
Randy
roger...@gmail.com
Sep 14, 2016, 8:41:09 PM9/14/16
to
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
>
> Yes you get 24 bit addressing but cant run z80 code, so no CP/M or MP/M
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...@gmail.com
rand...@hotmail.com
Sep 14, 2016, 9:00:09 PM9/14/16
to
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
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
Jay_in_Dallas
Sep 14, 2016, 11:21:05 PM9/14/16
to
randy482 wrote:
> ...But as I see it @50mhz how long would
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
--
> ...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
--
Floppy Software
Sep 15, 2016, 2:28:13 AM9/15/16
to
IMHO it sould be CP/M-Z8K the right path to follow in this case.
Udo Munk
Sep 15, 2016, 4:18:00 AM9/15/16
to
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
> 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.
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.
Steven Hirsch
Sep 15, 2016, 7:59:54 AM9/15/16
to
both worlds. That's what Chris Brock's port does. It runs vanilla Z80
programs as user tasks and switches modes at system level.
Bruce Mardle
Sep 16, 2016, 12:26:14 PM9/16/16
to
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 than useful.
> IMHO it sould be CP/M-Z8K the right path to follow in this case.
I made a Z8001/Z8010 computer in the early '80s. I picked a Z8000 partly because 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 specify 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!)
Chris B
Oct 18, 2016, 9:03:42 PM10/18/16
to
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 remain static at all times to work as a common memory bank. This is configurable at system generation time on 4K boundries.
The eZ80 has 16K of internal CPU RAM that can be configured to be ever-present at the top of the 16 bit 64K addressable range when in Z80-compatible mode. 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 Bank 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 this up and it works great.
I used to make a living writing and maintaining CP/M BIOSes in the 1980s.
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 remain static at all times to work as a common memory bank. This is configurable at system generation time on 4K boundries.
The eZ80 has 16K of internal CPU RAM that can be configured to be ever-present at the top of the 16 bit 64K addressable range when in Z80-compatible mode. 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 Bank 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 this up and it works great.
I used to make a living writing and maintaining CP/M BIOSes in the 1980s.
Jay_in_Dallas
Oct 22, 2016, 1:28:32 AM10/22/16
to
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
> ...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
Jay_in_Dallas
Oct 22, 2016, 1:38:45 AM10/22/16
to
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?)...
> ...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?)...
Jay_in_Dallas
Oct 24, 2016, 5:40:57 PM10/24/16
to
Steven wrote:
> ...Chris Brock ported MP/M to one of the Zilog
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
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
> ...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...
> years ago but I have not been able to find time
> to work on this project. His setup required an
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...
> Chris Brock's port does. It runs vanilla Z80 programs
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
Jay_in_Dallas
Oct 24, 2016, 5:52:03 PM10/24/16
to
JDallas wrote:
> ...just run as a normal eZ80 until it fetched an instruction that kicks
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
> ...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...
> 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
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
Steven Hirsch
Oct 25, 2016, 7:44:42 AM10/25/16
to
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
> 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.
8MB of flash memory. Time to take another look at Chris's code.
Jay_in_Dallas
Oct 25, 2016, 11:16:07 AM10/25/16
to
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
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
Jay_in_Dallas
Dec 13, 2016, 10:34:19 AM12/13/16
to
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
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
Udo Munk
Dec 13, 2016, 2:00:22 PM12/13/16
to
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?
> eZ80 Linux-Lite?
>
> Has anyone looked into implementing a light version of Linux on a
> Ram-Rich eZ80?
Fuzix
rescu...@gmail.com
Mar 9, 2022, 1:57:07 PM3/9/22
to
I'm replying on a message from you that was written on Sept 2016, but I'm just trying if I can get in contact with you about eZ80 SBC (CP/M) systems.
Are you still reading this group?
Cheers
Robbert, the dutch guy living in Istanbul
Randy McLaughlin
Mar 9, 2022, 2:37:47 PM3/9/22
to
I am still here but I never even built the system.
Somewhere I have a couple F91's but never got around to do that much with them.
Howard Harte was going to use them on the failed Imsai Two project. Howard got CP/M 3 running but he designed a motherboard to do it, his site showing it is now down:
https://comp.os.cpm.narkive.com/MFHlP2Xh/ez80-based-single-board-computer-runs-cp-m-3-0
Randy
Somewhere I have a couple F91's but never got around to do that much with them.
Howard Harte was going to use them on the failed Imsai Two project. Howard got CP/M 3 running but he designed a motherboard to do it, his site showing it is now down:
https://comp.os.cpm.narkive.com/MFHlP2Xh/ez80-based-single-board-computer-runs-cp-m-3-0
Randy
Bill McMullen
Mar 9, 2022, 4:16:21 PM3/9/22
to
I've got a few too many things on my plate to get involved with the EZ80SBC project. However, I have built a few eZ80 projects with CP/M 2.2 (a 50 MHz eZ80F91 and an 18.432 MHz eZ80F92/3) that are available on Tindie at https://www.tindie.com/stores/circlem/
One of the biggest issues with a 50 MHz eZ80 is availablility of parts: the 50 MHz eZ80L92 is available but requires external RAM (no common area) and Flash while the eZ80F91AZA has had it's delivery dates constantly pushed back. My order scheduled for June last year is now scheduled for December of this year while an order from a different supplier is now scheduled for May, about a year late.
Randy McLaughlin
Mar 9, 2022, 10:42:24 PM3/9/22
to
If you really want a fast CP/M system a better way to go is FPGA I would recommend the multicomp designs.
The EZ80 is great but past.
Randy
The EZ80 is great but past.
Randy
Bill McMullen
Mar 10, 2022, 1:14:07 PM3/10/22
to
On Wednesday, 9 March 2022 at 20:42:24 UTC-7, Randy McLaughlin wrote:
> If you really want a fast CP/M system a better way to go is FPGA I would recommend the multicomp designs.
>
> The EZ80 is great but past.
The eZ80 from 2001 may be "past" in some people's opinion, but this thread is also about CP/M (1974) which predates the eZ80 by about 27 years. Forty-six years after the Z80 introduction it's still an orderable part from Zilog distributors. Many hobbyists prefer real Zilog hardware as do companies with legacy products who have no desire to go through the arduous process of FPGA development and quality control validation plus long-term availability issues.
> If you really want a fast CP/M system a better way to go is FPGA I would recommend the multicomp designs.
>
> The EZ80 is great but past.
The eZ80 is pipelined and has reduced the T states for most of the Z80 instructions (i.e. 1 vs 4 T states for LD R,R'). My eZ80 benchmarking may be somewhat limited but my various tests put a 50 MHz eZ80 as the equivalent of a Z80 at about 170-195 MHz.
What is the Z80 equivalent frequency of your FPGA implementations? The S100 Z80 FPGA SBC appears to be a 50 MHz Z80 (possibly about 1/4 the speed of an eZ80) and uses an FPGA board that's fifteen times the cost.
Agustin Gimenez
Apr 22, 2022, 2:14:18 PM4/22/22
to
I just stumbled upon this post when I was seeking for some eZ80 info and may be you will be interested in something I'm creating. Is a SBC using an eZ80190F, with 512Kb of FLASH, 2Mb of 10ns RAM for zero wait states, 2 bus expansions, 6 device ports (a multiplexed SPI port up to 25Mhz with extra signals for INT, RDY and RST) and a debug serial port.
https://twitter.com/gusmanb/status/1517286665974394880
I've been working on this for two years on my spare time and I'm nearly finished with the base system, I already have a bootloader, the device kernel, a library for STM32 CPU's to create devices and so on, I will publish it as open source very soon on my Github so if you're interested follow me: https://github.com/gusmanb
Also I'm preparing a VGA card using a raspberry pico and storage/IO devices using STM32 boards.
Cheers!
0 new messages