Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Any CP/M-Like Work Done for the eZ80?
1,392 views
Skip to first unread message
Paul Bartlett
Nov 14, 2012, 12:27:18 PM11/14/12
to
Just a curiosity question (well, two questions), as I am no longer
doing anything with Z80/8080 or CP/M. However, my first computer was a
Kaypro IV running CP/M 2.2. It is still boxed up in a closet, although
I don't know if any of the 5 1/4" system diskettes are still bootable.
As we all know, Zilog came out with the eZ80 CPU, a Z80 workalike (but
much faster and more efficient) with an Address and Data Long mode
capable of linearly addressing 16MB of memory rather than the Z80's
64KB. (I can remember when some room-filling IBM mainframes had only
16MB of memory.) Has anyone ever tried to port or adapt any flavor of
CP/M to the eZ80 while making use of the large memory address space?
Does anyone know if a manufacturer has ever made a more or less general
purpose computer (or advanced programmable calculator) based on the
eZ80? Thanks.
--
Paul Bartlett
doing anything with Z80/8080 or CP/M. However, my first computer was a
Kaypro IV running CP/M 2.2. It is still boxed up in a closet, although
I don't know if any of the 5 1/4" system diskettes are still bootable.
As we all know, Zilog came out with the eZ80 CPU, a Z80 workalike (but
much faster and more efficient) with an Address and Data Long mode
capable of linearly addressing 16MB of memory rather than the Z80's
64KB. (I can remember when some room-filling IBM mainframes had only
16MB of memory.) Has anyone ever tried to port or adapt any flavor of
CP/M to the eZ80 while making use of the large memory address space?
Does anyone know if a manufacturer has ever made a more or less general
purpose computer (or advanced programmable calculator) based on the
eZ80? Thanks.
--
Paul Bartlett
rzh_...@yahoo.com
Nov 14, 2012, 1:52:49 PM11/14/12
to
On Wednesday, November 14, 2012 9:27:20 AM UTC-8, Paul Bartlett wrote:
....<snip> .....
Your question(s) are best addressed to Howard Harte. As far as I know, he has done quite a bit of work with the eZ80. I know he was extremely interested in the eZ80 development kit offered by Zilog. He convinced me to get one. It has been a long while since I fired mine up, but I think that the big disadvantage of that kit (that I discovered) was that a person who wanted to do any serious CP/M type work with it would have to acquire (or build) a daughter board for it. It has little capability for general purpose I/O, as I remember. My memory is really foggy about the hardware .... sorry. Do a search with "eZ80" and Howard's name in it, and see what comes up.
Roger
....<snip> .....
> As we all know, Zilog came out with the eZ80 CPU, a Z80 workalike (but
>
> much faster and more efficient) with an Address and Data Long mode
>
> capable of linearly addressing 16MB of memory rather than the Z80's
>
> 64KB. (I can remember when some room-filling IBM mainframes had only
>
> 16MB of memory.) Has anyone ever tried to port or adapt any flavor of
>
> CP/M to the eZ80 while making use of the large memory address space?
>
> Does anyone know if a manufacturer has ever made a more or less general
>
> purpose computer (or advanced programmable calculator) based on the
>
> eZ80? Thanks.
Hi Paul,
>
> much faster and more efficient) with an Address and Data Long mode
>
> capable of linearly addressing 16MB of memory rather than the Z80's
>
> 64KB. (I can remember when some room-filling IBM mainframes had only
>
> 16MB of memory.) Has anyone ever tried to port or adapt any flavor of
>
> CP/M to the eZ80 while making use of the large memory address space?
>
> Does anyone know if a manufacturer has ever made a more or less general
>
> purpose computer (or advanced programmable calculator) based on the
>
> eZ80? Thanks.
Your question(s) are best addressed to Howard Harte. As far as I know, he has done quite a bit of work with the eZ80. I know he was extremely interested in the eZ80 development kit offered by Zilog. He convinced me to get one. It has been a long while since I fired mine up, but I think that the big disadvantage of that kit (that I discovered) was that a person who wanted to do any serious CP/M type work with it would have to acquire (or build) a daughter board for it. It has little capability for general purpose I/O, as I remember. My memory is really foggy about the hardware .... sorry. Do a search with "eZ80" and Howard's name in it, and see what comes up.
Roger
David Griffith
Nov 14, 2012, 10:32:33 PM11/14/12
to
seem to be after. Google tells me that the page for this is
http://www.ez80sbc.com/ but nothing is answering. Google will still
show you useful stuff like pictures, software, and schematics.
--
David Griffith
davidmy...@acm.org <--- Put my last name where it belongs
Torfinn Ingolfsen
Nov 15, 2012, 3:24:18 AM11/15/12
to
On 11/15/2012 04:32, David Griffith wrote:
>
> Someone created what's called the EZ80SBC, which is precisely what you
> seem to be after. Google tells me that the page for this is
> http://www.ez80sbc.com/ but nothing is answering. Google will still
> show you useful stuff like pictures, software, and schematics.
Another is the EZ80P: http://www.retroleum.co.uk/ez80p/
>
> Someone created what's called the EZ80SBC, which is precisely what you
> seem to be after. Google tells me that the page for this is
> http://www.ez80sbc.com/ but nothing is answering. Google will still
> show you useful stuff like pictures, software, and schematics.
Don't know if anybody has a working CP/M for it.
And another: MIC80: http://www.shaels.net/index.php/mic80
--
Torfinn Ingolfsen,
Norway
William
Feb 2, 2014, 12:26:11 PM2/2/14
to
I took a look at Peter Schorn's well written Atltair SIMH code and it looks fairly easy to emulate for the extra instructions of the EZ80. These extra instructions include much better loading of 16 bit words. I imagine Zilog's EZ80 C compiler would make extensive use of them.
Anyway if someone were seriously interested I could probably find the spare time to make the necessary modifications.
Anyway if someone were seriously interested I could probably find the spare time to make the necessary modifications.
Chris B
Feb 2, 2014, 8:14:07 PM2/2/14
to
On Wednesday, November 14, 2012 9:27:20 AM UTC-8, Paul Bartlett wrote:
The eZ80 is very fast, and mind-boggling fast when its added capabilities are utilized. Its native Z80 instructions run at a minimum of 110 Mhz Z80 equivalent clock rate, with most instructions running around a 200Mhz equivalent. The commonly used 16 bit ADD instruction clocks in at 660 Mhz equivalent. One of my first impressions of the eZ80 a long time ago was that there was not all that much in the way of new instructions. But the opposite is the case, as most of the new instructions are new modes of the LD instruction which make for a great performance impact. For instance, one of the most common MP/M internal subroutines is a routine that inserts a new process descriptor into a linked list by priority. The DRI version takes 218 T states to execute. My recoded eZ80 version does the exact same thing consuming just 38 T states. So when code is recoded for the eZ80, it is a fair estimate that it is the equivalent of a Z80 running at 1Ghz.
Chris
Mr. Emmanuel Roche, France
Feb 3, 2014, 3:32:37 AM2/3/14
to
"William" wrote:
> Anyway if someone were seriously interested I could probably find the spare time to make the necessary modifications.
William, after April 2014, you will be able to waste your time with the EZ80.
> Anyway if someone were seriously interested I could probably find the spare time to make the necessary modifications.
Meanwhile, there is more interesting stuff to do, for an experienced PL/M user like you, like recreating the source code of the CP/M 1.3 programs.
(We have the binaries, and the source code of the CP/M Plus (or 3.1...) programs.)
By the way, since there will be talks about the PL/M Compiler, maybe a study of its generated code would be interesting?
Too bad that Intel lost its "Insite Software Library".
Yours Sincerely,
Mr. Emmanuel Roche, France
Jon Saxton
Feb 3, 2014, 4:24:39 AM2/3/14
to
On 2014-02-03 11:14, Chris B wrote:
>
> I've been working on an MP/M for the eZ80 F91 for a couple of years now.
> It is up and running enough to run as a 6 user system ...
>
> I've been working on an MP/M for the eZ80 F91 for a couple of years now.
Interesting. I was under the impression that MP/M relied on banked
memory similar to CP/M Plus. It is also my impression from reading the
eZ80 documentation that there is no common memory available in Z80 mode,
i.e. the address spaces are completely disjoint.
Am I correct? Or is there some memory management trick that I have
overlooked?
--
Former sysop of Tesseract RCPM+ which operated
in the 1980s from Dural, NSW, Australia.
http://triton.vg/TesseractRCPM+Catalog.html
William
Feb 3, 2014, 9:50:26 AM2/3/14
to
> Meanwhile, there is more interesting stuff to do, for an experienced PL/M user like you, like recreating the source code of the CP/M 1.3 programs.
> Too bad that Intel lost its "Insite Software Library".
Mr. Emmanuel Roche, France
Feb 3, 2014, 12:11:52 PM2/3/14
to
Argh!
Upon re-reading me, I notice that I wrote:
> Meanwhile, there is more interesting stuff to do, for an experienced PL/M user like you, like recreating the source code of the CP/M 1.3 programs.
I was meaning, of course: "experienced PL/M programmer"...
My apologies!
Upon re-reading me, I notice that I wrote:
> Meanwhile, there is more interesting stuff to do, for an experienced PL/M user like you, like recreating the source code of the CP/M 1.3 programs.
My apologies!
Chris B
Feb 3, 2014, 12:15:06 PM2/3/14
to
No trickery is involved; the eZ80 directly supports mapping a common memory section within any 64K bank.
In ADL mode, the eZ80 memory is one 16mb unit. When in Z80 mode, that same 16mb RAM consists of 256 banks of 64kb banks. The eZ80 supports programmably overlaying its on-chip 16K ram to overlay the top 8K or 16K of any 64k bank. So I'm using 8K of internal CPU RAM as the "Common Bank".
Mechanically, to switch to a new bank takes two operations: setting a new value to MBASE (2 T states) and setting the same value to the RAM overlay address register (4 T states). On the Z180, to switch banks requires either a table look-up or calculation before setting a memory register. On the eZ80, neither is required; the MP/M bank value *IS* the same value to program the registers, so bank switching is simpler and faster than with a Z180.
I've re-coded a lot of the OS to execute in ADL mode which simplifies things a lot. For instance, Function 152 "Parse Filename" used to read a mutual exclusion queue, copy the string to parse from the User Bank to the Common Bank and then to the System Bank to be processed, after which two more copy operations and a queue write.
I rewrote the code to be re-entrant so that no queue reading is needed and the user string to parse is directly processed in the user bank from where the ADL code is, so all copy operations are eliminated. The eZ80 has so much power to make things so much faster ...
E.g., LDIR, in either Z80 or ADL mode, consumes 5 T states per cycle vs. 21 for the Z80.
Chris
Wolfram
Feb 3, 2014, 1:08:48 PM2/3/14
to
Chris B hat am 03.02.2014 18:15 geschrieben:
Hi Chris,
that's very interesting for me, because I've got an eZ80P
http://www.retroleum.co.uk/20110530/ez80p/ made by Phil.
Would You think it's able to run a kind of CP/M or MP/M?
Wolfram
that's very interesting for me, because I've got an eZ80P
http://www.retroleum.co.uk/20110530/ez80p/ made by Phil.
Would You think it's able to run a kind of CP/M or MP/M?
Wolfram
Paul Bartlett
Feb 3, 2014, 1:11:13 PM2/3/14
to
On Mon, 3 Feb 2014, Mr. Emmanuel Roche, France wrote:
> "William" wrote:
>
>> Anyway if someone were seriously interested I could probably find
>> the spare time to make the necessary modifications.
>
> William, after April 2014, you will be able to waste your time with the EZ80.
>
> [remainder trimmed]
> "William" wrote:
>
>> Anyway if someone were seriously interested I could probably find
>> the spare time to make the necessary modifications.
>
> William, after April 2014, you will be able to waste your time with the EZ80.
>
I am not William, but what is happening after April 2014?
--
Paul Bartlett
Mr. Emmanuel Roche, France
Feb 3, 2014, 2:14:59 PM2/3/14
to
Hello, Paul!
> I am not William, but what is happening after April 2014?
CP/M will be 40 years old!
Please, re-read the ""Legacy of Gary Kildall" event April 25" thread.
(Maybe I should retire, then? At least, I already have white hair... Hahaha!)
> I am not William, but what is happening after April 2014?
Please, re-read the ""Legacy of Gary Kildall" event April 25" thread.
(Maybe I should retire, then? At least, I already have white hair... Hahaha!)
Chris B
Feb 3, 2014, 2:25:08 PM2/3/14
to
A quick check of the eZ80 L92 documentation indicates the L92 eZ80, unlike the F91 eZ80 doesn't have any on-chip RAM , so the RAM control registers at I/O locations B4 and B5 that i use for bank-switching don't exist. ... so that means that the way my MP/M is working now, it can't be made to work on an L92 eZ80-based system which is what the EZ80P uses.
However ... I plan on evolving my MP/M code to where the OS is 100% ADL which will eliminate any need at all for a Common Bank. Each User process will have an entire 64kb to use. When I achieve that, my MP/M-based OS will run just fine on an L92 eZ80. In fact, the EZ80P has a good head start in other ways since it already contains flash ROM for mass-storage. Without studying the EZ80P h/w too much, I think it is safe to presume a third user console could be implemented using the video controller and attached keyboard.
Chris Brock
Paul Bartlett
Feb 3, 2014, 3:41:20 PM2/3/14
to
On Mon, 3 Feb 2014, Mr. Emmanuel Roche, France wrote:
> Hello, Paul!
>
>> I am not William, but what is happening after April 2014?
>
> CP/M will be 40 years old!
>
> Please, re-read the ""Legacy of Gary Kildall" event April 25" thread.
>
> (Maybe I should retire, then? At least, I already have white hair... Hahaha!)
FORTRAN (the programming language) is almost sixty years old (I myself
>
>> I am not William, but what is happening after April 2014?
>
> CP/M will be 40 years old!
>
> Please, re-read the ""Legacy of Gary Kildall" event April 25" thread.
>
> (Maybe I should retire, then? At least, I already have white hair... Hahaha!)
first programmed in it in 1968), but so far as I know, it is still
going strong, even though it has had updates and improvements over many
years. Yes, there can be and are uses for complex operating systems,
but there can be and are uses for simplicity in life. Why are the Z80
and eZ80 still manufactured compared to some of the almost
mind-bogglingly complex chips today? You do not need a sledgehammer to
crush an ant. In some situations, a relatively simple OS like CP/M or
its variants may be more satisfactory than something like MS Windows
with its millions(?) of lines of C code. I myself still sometimes use
MS QuickBasic or QBasic for simple programming tasks that I only need
to do once or a few times.
--
Paul Bartlett
Steven Hirsch
Feb 3, 2014, 6:33:59 PM2/3/14
to
On 02/03/2014 12:15 PM, Chris B wrote:
> I've re-coded a lot of the OS to execute in ADL mode which simplifies
> things a lot. For instance, Function 152 "Parse Filename" used to read a
> mutual exclusion queue, copy the string to parse from the User Bank to the
> Common Bank and then to the System Bank to be processed, after which two
> more copy operations and a queue write.
Sounds cool, but if I understand correctly most applications will fail due to
> I've re-coded a lot of the OS to execute in ADL mode which simplifies
> things a lot. For instance, Function 152 "Parse Filename" used to read a
> mutual exclusion queue, copy the string to parse from the User Bank to the
> Common Bank and then to the System Bank to be processed, after which two
> more copy operations and a queue write.
fundamental incompatibility in the instruction set. Is that not the case?
Chris B
Feb 3, 2014, 7:01:12 PM2/3/14
to
At h/w reset, the eZ80 begins and operates 100% Z80 instruction set compatible. Even the bugs are compatible. E.g., the DAA instruction bug. It was supposed to, and was documented to work after an 8-bit INC register instruction. It doesn't in a Z80, it doesn't in the eZ80 either. The work around is to use the INC immediate instruction with a value of 01. I haven't yet used a great number of applications yet, but the ones I have all execute correctly. The team at Zilog that designed the eZ80 years ago knew what they were doing.
BTW, how do you like SLR180+ ?
Chris Brock
BTW, how do you like SLR180+ ?
Chris Brock
Chris B
Feb 3, 2014, 7:15:57 PM2/3/14
to
Slight correction to my prior post: where I wrote INC immediate, I should have written ADD immediate meaning the instruction ADD 01.
Chris Brock
Chris Brock
Steven Hirsch
Feb 3, 2014, 9:56:21 PM2/3/14
to
incompatibilities. I'm guessing that your MP/M port switches into extended
mode for system calls, correct?
Where can I get an eZ80 machine? :-) The only one I've seen is on a web site
that hasn't been updated in years and it was very costly.
> BTW, how do you like SLR180+ ?
opportunity to make use of it.
Steve
Jon Saxton
Feb 4, 2014, 12:03:33 AM2/4/14
to
precisely the "memory management trick" which I did not notice. I am
now encouraged to build a CP/M Plus for it.
By "it" I mean the "Zilog eZ80AcclaimPlus Wireless Zdots SBC Development
Kit" that I bought a couple of years ago and which is still in its
original box. It was one of the last five available as a clearance item
from Mouser in the USA (where I was living at the time).
Chris B
Feb 4, 2014, 12:46:05 AM2/4/14
to
On Monday, February 3, 2014 6:56:21 PM UTC-8, Steven Hirsch wrote:
> On 02/03/2014 07:01 PM, Chris B wrote:
>
> > At h/w reset, the eZ80 begins and operates 100% Z80 instruction set
>
> > compatible. Even the bugs are compatible. E.g., the DAA instruction bug.
>
> > It was supposed to, and was documented to work after an 8-bit INC register
>
> > instruction. It doesn't in a Z80, it doesn't in the eZ80 either. The work
>
> > around is to use the INC immediate instruction with a value of 01. I
>
> > haven't yet used a great number of applications yet, but the ones I have
>
> > all execute correctly. The team at Zilog that designed the eZ80 years ago
>
> > knew what they were doing.
>
>
>
> That's great! For some reason I had the impression there were a few major
>
> incompatibilities. I'm guessing that your MP/M port switches into extended
> mode for system calls, correct?
Actually, the eZ80 supports a cool way of switching to extended (ADL) mode. Anywhere in Z80-mode code you can put a "long" CALL instruction in place:
> On 02/03/2014 07:01 PM, Chris B wrote:
>
> > At h/w reset, the eZ80 begins and operates 100% Z80 instruction set
>
> > compatible. Even the bugs are compatible. E.g., the DAA instruction bug.
>
> > It was supposed to, and was documented to work after an 8-bit INC register
>
> > instruction. It doesn't in a Z80, it doesn't in the eZ80 either. The work
>
> > around is to use the INC immediate instruction with a value of 01. I
>
> > haven't yet used a great number of applications yet, but the ones I have
>
> > all execute correctly. The team at Zilog that designed the eZ80 years ago
>
> > knew what they were doing.
>
>
>
> That's great! For some reason I had the impression there were a few major
>
> incompatibilities. I'm guessing that your MP/M port switches into extended
> mode for system calls, correct?
CALL.IL ADL_System_Entry_Point
This instruction switches the CPU to ADL mode and makes a 24-bit address jump to where the ADL-mode subroutine is. At the end of the subroutine is a RET.L instruction which returns CPU execution back to the first instruction after that CALL.IL instruction, and at the time switching the CPU back from ADL mode to Z80-mode.
> Where can I get an eZ80 machine? :-) The only one I've seen is on a web site
> that hasn't been updated in years and it was very costly.
However, Zilog has two eZ80 F91 development kits. Neither kit includes a good solution for mass storage. I designed and built a Compact Flash interface, but I'll soon be switching to using a Paralax SD Memory interface kit which will easily use the eZ80's SPI feature. I think I paid $15 for it and someone else has posted an eZ80 SPI CP/M driver for it. it connects using a four wire interface.
The smaller dev kit has 128K of RAM, which would seem to be enough for a CP/M Plus system, but I kind of doubt it. 64K for a User Bank and 64K for the System Bank doesn't leave much for mass storage deblocking buffers (even flash memory needs blocking/deblocking because writes are slow and are sensitive to wear leveling issues).
The larger kit that I have comes with 1mb of RAM and I think the newest kit doubles that. It would need a Paralax kit for a storage solution. So my mass storage is implemented as A through P at 65 megabytes for each drive for a total of 1gb. The main advantage of the Zilog kits are the development system. I can make a s/w change, and download it in seconds. The breakpoint and single-step through the source code greatly speed up debugging.
Eventually, I'd like to make an eZ80 PCB to share with fellow enthusiasts ...
Chris Brock
Chris B
Feb 4, 2014, 12:55:16 AM2/4/14
to
When you get started, let me know. I can help you figure out how to get the development kit going and send you some of my code to show how to initialize the h/w and bank-switch ..
Where in the USA did you live and when?
Chris Brock
Jon Saxton
Feb 4, 2014, 4:12:56 AM2/4/14
to
On 2014-02-04 15:55, Chris B wrote:
> On Monday, February 3, 2014 9:03:33 PM UTC-8, Jon Saxton wrote:
>>
>>>> Interesting. I was under the impression that MP/M relied on banked
>>>> memory similar to CP/M Plus. It is also my impression from reading the
>>>> eZ80 documentation that there is no common memory available in Z80 mode,
>>>> i.e. the address spaces are completely disjoint.
>>
>>>> Am I correct? Or is there some memory management trick that I have
>>>> overlooked?
>>>
> On Monday, February 3, 2014 9:03:33 PM UTC-8, Jon Saxton wrote:
>>
>>>> Interesting. I was under the impression that MP/M relied on banked
>>>> memory similar to CP/M Plus. It is also my impression from reading the
>>>> eZ80 documentation that there is no common memory available in Z80 mode,
>>>> i.e. the address spaces are completely disjoint.
>>
>>>> Am I correct? Or is there some memory management trick that I have
>>>> overlooked?
>>>
>>> Hi Jon,
>>>
>>> No trickery is involved; the eZ80 directly supports mapping a common memory section within any 64K bank.
>>> In ADL mode, the eZ80 memory is one 16mb unit. When in Z80 mode, that same 16mb RAM consists of 256 banks of 64kb banks. The eZ80 supports programmably overlaying its on-chip 16K ram to overlay the top 8K or 16K of any 64k bank. So I'm using 8K of internal CPU RAM as the "Common Bank".
>>>
>>> Mechanically, to switch to a new bank takes two operations: setting a new value to MBASE (2 T states) and setting the same value to the RAM overlay address register (4 T states). On the Z180, to switch banks requires either a table look-up or calculation before setting a memory register. On the eZ80, neither is required; the MP/M bank value *IS* the same value to program the registers, so bank switching is simpler and faster than with a Z180.
>>> I've re-coded a lot of the OS to execute in ADL mode which simplifies things a lot. For instance, Function 152 "Parse Filename" used to read a mutual exclusion queue, copy the string to parse from the User Bank to the Common Bank and then to the System Bank to be processed, after which two more copy operations and a queue write.
>>>
>>> I rewrote the code to be re-entrant so that no queue reading is needed and the user string to parse is directly processed in the user bank from where the ADL code is, so all copy operations are eliminated. The eZ80 has so much power to make things so much faster ...
>>> E.g., LDIR, in either Z80 or ADL mode, consumes 5 T states per cycle vs. 21 for the Z80.
>>>
>>> Chris
>>
>> Overlaying the top 8/16 kB of a 64 kB bank with on-chip memory is
>> precisely the "memory management trick" which I did not notice. I am
>> now encouraged to build a CP/M Plus for it.
>>
>> By "it" I mean the "Zilog eZ80AcclaimPlus Wireless Zdots SBC Development
>> Kit" that I bought a couple of years ago and which is still in its
>> original box. It was one of the last five available as a clearance item
>> from Mouser in the USA (where I was living at the time).
>
>>>
>>> No trickery is involved; the eZ80 directly supports mapping a common memory section within any 64K bank.
>>> In ADL mode, the eZ80 memory is one 16mb unit. When in Z80 mode, that same 16mb RAM consists of 256 banks of 64kb banks. The eZ80 supports programmably overlaying its on-chip 16K ram to overlay the top 8K or 16K of any 64k bank. So I'm using 8K of internal CPU RAM as the "Common Bank".
>>>
>>> Mechanically, to switch to a new bank takes two operations: setting a new value to MBASE (2 T states) and setting the same value to the RAM overlay address register (4 T states). On the Z180, to switch banks requires either a table look-up or calculation before setting a memory register. On the eZ80, neither is required; the MP/M bank value *IS* the same value to program the registers, so bank switching is simpler and faster than with a Z180.
>>> I've re-coded a lot of the OS to execute in ADL mode which simplifies things a lot. For instance, Function 152 "Parse Filename" used to read a mutual exclusion queue, copy the string to parse from the User Bank to the Common Bank and then to the System Bank to be processed, after which two more copy operations and a queue write.
>>>
>>> I rewrote the code to be re-entrant so that no queue reading is needed and the user string to parse is directly processed in the user bank from where the ADL code is, so all copy operations are eliminated. The eZ80 has so much power to make things so much faster ...
>>> E.g., LDIR, in either Z80 or ADL mode, consumes 5 T states per cycle vs. 21 for the Z80.
>>>
>>> Chris
>>
>> Overlaying the top 8/16 kB of a 64 kB bank with on-chip memory is
>> precisely the "memory management trick" which I did not notice. I am
>> now encouraged to build a CP/M Plus for it.
>>
>> By "it" I mean the "Zilog eZ80AcclaimPlus Wireless Zdots SBC Development
>> Kit" that I bought a couple of years ago and which is still in its
>> original box. It was one of the last five available as a clearance item
>> from Mouser in the USA (where I was living at the time).
>
> Great to hear you're going to awaken your sleeping giant!
>
> When you get started, let me know. I can help you figure out how to get the development kit going and send you some of my code to show how to initialize the h/w and bank-switch ..
>
> Where in the USA did you live and when?
>
> Chris Brock
Thanks for the offer. I shall definitely avail myself of your
>
> When you get started, let me know. I can help you figure out how to get the development kit going and send you some of my code to show how to initialize the h/w and bank-switch ..
>
> Where in the USA did you live and when?
>
> Chris Brock
expertise. I have a few other projects underway at the moment so it
probably won't be until the middle of the year.
I lived for more than 20 years in the USA, mostly in New York but I did
spend a year and a half on the west coast working for a large
Seattle-based retailer. (Wish I could have stayed there.) Returned to
Australia in 2012 to enjoy my retirement. Of course now I am busier than
I ever was while working for a living.
Wolfram
Feb 4, 2014, 12:14:25 PM2/4/14
to
Chris B hat am 04.02.2014 06:46 geschrieben:
> Eventually, I'd like to make an eZ80 PCB to share with fellow enthusiasts ...
>
> Chris Brock
>
Yes please, do so!
Wolfram
> Eventually, I'd like to make an eZ80 PCB to share with fellow enthusiasts ...
>
> Chris Brock
>
Wolfram
Steven Hirsch
Feb 5, 2014, 9:02:55 AM2/5/14
to
On 02/04/2014 12:46 AM, Chris B wrote:
> However, Zilog has two eZ80 F91 development kits. Neither kit includes a
> good solution for mass storage. I designed and built a Compact Flash
> interface, but I'll soon be switching to using a Paralax SD Memory
> interface kit which will easily use the eZ80's SPI feature. I think I paid
> $15 for it and someone else has posted an eZ80 SPI CP/M driver for it. it
> connects using a four wire interface.
>
> The smaller dev kit has 128K of RAM, which would seem to be enough for a
> CP/M Plus system, but I kind of doubt it. 64K for a User Bank and 64K for
> the System Bank doesn't leave much for mass storage deblocking buffers
> (even flash memory needs blocking/deblocking because writes are slow and
> are sensitive to wear leveling issues).
>
> The larger kit that I have comes with 1mb of RAM and I think the newest kit
> doubles that. It would need a Paralax kit for a storage solution. So my
> mass storage is implemented as A through P at 65 megabytes for each drive
> for a total of 1gb. The main advantage of the Zilog kits are the
> development system. I can make a s/w change, and download it in seconds.
> The breakpoint and single-step through the source code greatly speed up
> debugging.
I did some digging today and am wondering if this is what you mean by "larger
> However, Zilog has two eZ80 F91 development kits. Neither kit includes a
> good solution for mass storage. I designed and built a Compact Flash
> interface, but I'll soon be switching to using a Paralax SD Memory
> interface kit which will easily use the eZ80's SPI feature. I think I paid
> $15 for it and someone else has posted an eZ80 SPI CP/M driver for it. it
> connects using a four wire interface.
>
> The smaller dev kit has 128K of RAM, which would seem to be enough for a
> CP/M Plus system, but I kind of doubt it. 64K for a User Bank and 64K for
> the System Bank doesn't leave much for mass storage deblocking buffers
> (even flash memory needs blocking/deblocking because writes are slow and
> are sensitive to wear leveling issues).
>
> The larger kit that I have comes with 1mb of RAM and I think the newest kit
> doubles that. It would need a Paralax kit for a storage solution. So my
> mass storage is implemented as A through P at 65 megabytes for each drive
> for a total of 1gb. The main advantage of the Zilog kits are the
> development system. I can make a s/w change, and download it in seconds.
> The breakpoint and single-step through the source code greatly speed up
> debugging.
kit":
http://www.zilog.com/index.php?option=com_product&task=dev_tool_detail&DevToolKit=eZ80F910300KITG
?
If so, do have any leads on where I can buy single units? DigiKey has it as
non-stock (call us and hang on to your hat...). Mouser has a price, but will
sell only in increments of (3) units.
I wonder if it's worth asking the Zilog rep. Occasionally they do return
e-mail from hobbyists.
Steve
p.s. - Where would the sources for the SPI driver be posted?
Chris B
Feb 5, 2014, 12:47:33 PM2/5/14
to
You did find the one I was referring to, which is the successor to the kit I have that has apparently been discontinued. There is good news here. I don't know why both DigiKey and Mouser have a minimum qty of 3. That is a price that makes sense only for an education institution purchase, perhaps 5% of potential sales. I saw Tom Orniston of Zilog at their booth at a trade show earlier this year and grumbled about not being able to buy a replacement CPU module for my development kit. He said he'd contact the distributors to fix that and he did. But this isn't the good news I was talking about ...
For what we'd be using the kits for, this is a better option for around half the price, that's in stock with only a qty 1 purchase:
http://www.futureelectronics.com/en/technologies/development-tools/microcontroller-microprocessor/8-bit-eval-board/Pages/2027395-ZGATE000100ZCOG.aspx?IM=0
http://www.digikey.com/catalog/en/partgroup/zgate-evaluation-board-zgate000100zcog/34379?mpart=ZGATE000100ZCOG&vendor=269&WT.z_ref_page_type=PS&WT.z_ref_page_sub_type=PD&WT.z_ref_page_id=PD&WT.z_ref_page_event=DC_Link_Table
http://www.mouser.com/ProductDetail/ZiLOG/ZGATE000100ZCOG/?qs=sGAEpiMZZMuqBwn8WqcFUoYrdCCfhZ3YW6n%2f39Ip3Tw%3d
According to Zilog's website, this kit includes 512K of RAM which is plenty. The downside, is that there's no way to expand beyond 512K. My kit has 1Mb, but I'm only using 512K. There is one DB9 for a serail port, the other serial port is available through the expansion connector. Ditto for the SPI interface.
It's important to get the "ZGATE" version instead of the $99 kit, which only has 128K.
Here is the link to the page with the SPI drivers and a wiring diagram that can be used for the Parallax kit:
http://z80cpu.eu/mirrors/www.vegeneering.com/eZ80_CPM/index.html
And, here is how to get to the Paralax kit:
go to parallax.com and search for 32313
Chris Brock
beat...@gmail.com
Mar 11, 2014, 4:48:08 PM3/11/14
to
External memory decoding can also facilitate banking within
multiple 64K segments. Consider 8 MB of RAM, each 1MB mapped
into a single 64K space, via standard Z180-compatible MMU decoding.
Or, 8MB of RAM, with each 512k maps up to 16 users, each user
having 64k physical address, extended with e.g. MMU180.
(See http://opencores.org/project,mmu180 -- this can be
used in multiplicity within the memory decoding logic.)
This way, each instance can utilize a Z180-compatible banked BIOS,
and the applications can also take advantage of the banked memory.
--
Douglas Beattie
http://www.linkedin.com/in/beattidp
multiple 64K segments. Consider 8 MB of RAM, each 1MB mapped
into a single 64K space, via standard Z180-compatible MMU decoding.
Or, 8MB of RAM, with each 512k maps up to 16 users, each user
having 64k physical address, extended with e.g. MMU180.
(See http://opencores.org/project,mmu180 -- this can be
used in multiplicity within the memory decoding logic.)
This way, each instance can utilize a Z180-compatible banked BIOS,
and the applications can also take advantage of the banked memory.
--
Douglas Beattie
http://www.linkedin.com/in/beattidp
Chris B
May 22, 2014, 2:11:27 AM5/22/14
to
Hi Douglas,
I see what your'e saying, but I can't yet see any situation where using an external Z180 compatible MMU would be advantageous. The Z180 is, I suppose slightly more memory efficient in that it doesn't block access to main memory that is overlapped by the eZ80's internal 8K or 16K CPU RAM that would be used for Common memory. But this just doesn't matter since 512Kx8 SRAM cost $7 and the eZ80 can address 16MB vs the Z180's 512K or 1MB. The way the Z180 switches banks is slower; the eZ80 can do it in 1 instruction taking 2 T states. And its easy to use bank numbers directly instead of MMU codes. The Z180 requires a table lookup to translate a bank # to MMU load value. And an external MMU would undoubtedly add several T states to all RAM accesses which would significantly reduce eZ80 performance.
Also, what applications are there that could take advantage of banked memory? I've never heard of any apps that directly manipulate Z180 banked memory. Doing so would be cumbersome; the eZ80 is 100% Z80 and Z180 instruction compatible, yet greatly expands the instruction set to provide any app with direct linear access to 16MB of RAM without having to "manage" banks.
The eZ80 can support 256 64K user banks. It would be a shame to have each user app going to all the trouble of flipping in banks to the 64K range of the original Z80 or Z180 when the existing instruction set as well as new instructions are ready now to to work in the 16MB "bank".
Chris Brock
I see what your'e saying, but I can't yet see any situation where using an external Z180 compatible MMU would be advantageous. The Z180 is, I suppose slightly more memory efficient in that it doesn't block access to main memory that is overlapped by the eZ80's internal 8K or 16K CPU RAM that would be used for Common memory. But this just doesn't matter since 512Kx8 SRAM cost $7 and the eZ80 can address 16MB vs the Z180's 512K or 1MB. The way the Z180 switches banks is slower; the eZ80 can do it in 1 instruction taking 2 T states. And its easy to use bank numbers directly instead of MMU codes. The Z180 requires a table lookup to translate a bank # to MMU load value. And an external MMU would undoubtedly add several T states to all RAM accesses which would significantly reduce eZ80 performance.
Also, what applications are there that could take advantage of banked memory? I've never heard of any apps that directly manipulate Z180 banked memory. Doing so would be cumbersome; the eZ80 is 100% Z80 and Z180 instruction compatible, yet greatly expands the instruction set to provide any app with direct linear access to 16MB of RAM without having to "manage" banks.
The eZ80 can support 256 64K user banks. It would be a shame to have each user app going to all the trouble of flipping in banks to the 64K range of the original Z80 or Z180 when the existing instruction set as well as new instructions are ready now to to work in the 16MB "bank".
Chris Brock
Jay_in_Dallas
May 26, 2014, 12:50:35 AM5/26/14
to
Steve wrote:
> If so, do have any leads on where I can buy
> single units? DigiKey has it as non-stock.
> If so, do have any leads on where I can buy
> Mouser has a price, but will sell only in
> increments of (3) units.
I just checked Mouser's eZ80F91 1K+ pricing.
> increments of (3) units.
The listing included the EZ80F910300KITG which had
changed the minimum order to 1 unit.
------------------------
Mouser Part#:692-EZ80F910300KITG
Manufacturers Part#:EZ80F910300KITG
Availability:Non-Stocked
Pricing (USD):$249.95
Min.:1
Mult:1
------------------------
-Jay in Dallas
Jay_in_Dallas
May 26, 2014, 1:32:39 AM5/26/14
to
Douglas Beattie wrote:
> External memory decoding can also facilitate
> banking within multiple 64K segments.
That is the solution I chose too. It allows efficient multi-user time-slicing.
> External memory decoding can also facilitate
> banking within multiple 64K segments.
The Common-Bank only works for single-user. But using the full 16K SRam, you're giving up an ethernet feature.
-Jay in Dallas
Jay_in_Dallas
May 27, 2014, 11:37:23 AM5/27/14
to
Chris wrote:
> The eZ80 can support 256 64K user banks. It would be
> a shame to have each user app going to all the trouble
> of flipping in banks to the 64K range of the original
> Z80 or Z180 when the existing instruction set as well
> as new instructions are ready now to to work in the
> 16MB "bank".
In Z80 and Z180 applications the MMU or the banked addressing effectively put up protective walls between multiple user pages. The eZ80's doesn't provide those walls.
> The eZ80 can support 256 64K user banks. It would be
> a shame to have each user app going to all the trouble
> of flipping in banks to the 64K range of the original
> Z80 or Z180 when the existing instruction set as well
> as new instructions are ready now to to work in the
> 16MB "bank".
A quick example of the problem:
Among several users working in various pages, one user's program bug creates a runaway that overwrites all memory. Everyone user's workspace gets instantly wiped without any warning.
That tends to make them mad.
The hardware trick I devised to implement protective walls between users on the eZ80 is to have the kernel latch A16-A23 on the external address bus to lock in his 64KB page during his running time-slice. If his program creates a runaway through the 16MB address range, the wall maps it all within his 64KB page; no one else is injured. The latch is released when the kernel is invoked by a method specific to the user-kernel implementation.
If you want a user's banked memory in neighboring linear address space or instead to give them a bigger page in ADL-mode, you could simply latch A18-A23 to give each user a 256KB page running in ADL-Mode. You get the advantage of ADL-mode with the ability to put up protective walls between user pages.
The use of protective walls can be implemented various ways. You might consider a combinations of these:
1). The kernel always puts walls around every user.
2). The kernel puts walls around low level users and allows superusers to run without walls.
3). The kernel only puts up a wall when the user requests it for testing a program.
4). Only superusers can request the kernal to remove his wall.
-Jay in Dallas
Jay_in_Dallas
May 30, 2014, 11:07:25 AM5/30/14
to
Re: eZ80 in Multiple User Systems - Using TRAP to maximize TPA space:
At first glance the TRAP mechanism looks like a useful tool to maintain links to CP/M modules relocated from the user page into the kernel’s domain.
TRAP 101:
(1) A TRAP occurs when the eZ80 detects an illegal instruction (opcode). It pushes the opcode address onto the active stack and jumps to either the user page, UU.0000h in Z80 mode or to 00.0000h in ADL mode where the kernel can be located to take control. Note that running in “mixed memory mode” allows interrupts to also be redirected to 00.xxxxh page so it a good reserved place for the kernel.
(2) You can strategically force a TRAP condition by placing a single byte, illegal instruction in memory for program flow to hit. This could be useful to place compact vectors to BIOS relocated outside of the user page and inside the kernel’s domain.
To use TRAPs to relocate OS code outside of the user page and there by increase the TPA, you could use extend the BIOS example here:
The block at UU.0000h-00FFh would replace BIOS vectors with addresses to distinct single byte TRAPs in high memory; each a single byte address apart. For X BIOS functions, you’d need X bytes, each with the same illegal instruction in that memory location. Don't use the same address as the address is later used to identify the intended BIOS function.
The TRAP is just being used as a compact mechanism to thread the process into the kernel’s domain. The side-effect is that the TPA can grow as the BIOS and other OS code is relocated into the kernel’s domain.
What happens when a BIOS function is called by the user?
The vector in low memory provides a unique address in high memory for that BIOS function. Execution proceeds to the illegal instruction at that address. A TRAP condition is created and that address is pushed onto the stack. The kernel can recover this address to determine what BIOS function was called. After the push, execution continues inside the user page at UU.0000h.
Of course you don’t want to cold boot on every BIOS function. It now has dual function and the kernel has to make the determination.
User address UU.0000h requires instructions to pass control to the kernel (outside the user page) in ADL mode. Several methods apply, including forcing a software interrupt (in Mixed Memory Mode interrupt processing goes to 00.xxxxh when configured appropriately).
Now the cold boot vector has dual use from the kernel’s perspective. It looks at the stack to see if it has the TRAP constructs. If not, it processes an intended cold boot.
If it’s processing a TRAP situation then the address of the TRAP is recovered from the stack and used as an index (BIOS addresses in the user space are a byte apart so subtract to make them zero-relative) to identify the relocated BIOS function in the kernel’s domain. After the BIOS function is complete, the kernel has to repair the stack for the awkward hand-off and return appropriately to the user page as if nothing unusual ever happened.
If you can relocate your BIOS outside of the user page to thereby increase the TPA, you can continue the progression to increase the TPA. It might be advantageous to paint some of the high memory with TRAPs so that a user program directly calling BDOS could be detected and either processed or signaled with an error message.
The LOADER program could read the CP/M version and take over to load its Flash ROM UU.0000h-0100h page and BIOS TRAP construct for various CP/M versions that might be run in different user spaces. Naturally the kernel would control the time-slicing for the users.
-Jay in Dallas
At first glance the TRAP mechanism looks like a useful tool to maintain links to CP/M modules relocated from the user page into the kernel’s domain.
TRAP 101:
(1) A TRAP occurs when the eZ80 detects an illegal instruction (opcode). It pushes the opcode address onto the active stack and jumps to either the user page, UU.0000h in Z80 mode or to 00.0000h in ADL mode where the kernel can be located to take control. Note that running in “mixed memory mode” allows interrupts to also be redirected to 00.xxxxh page so it a good reserved place for the kernel.
(2) You can strategically force a TRAP condition by placing a single byte, illegal instruction in memory for program flow to hit. This could be useful to place compact vectors to BIOS relocated outside of the user page and inside the kernel’s domain.
To use TRAPs to relocate OS code outside of the user page and there by increase the TPA, you could use extend the BIOS example here:
The block at UU.0000h-00FFh would replace BIOS vectors with addresses to distinct single byte TRAPs in high memory; each a single byte address apart. For X BIOS functions, you’d need X bytes, each with the same illegal instruction in that memory location. Don't use the same address as the address is later used to identify the intended BIOS function.
The TRAP is just being used as a compact mechanism to thread the process into the kernel’s domain. The side-effect is that the TPA can grow as the BIOS and other OS code is relocated into the kernel’s domain.
What happens when a BIOS function is called by the user?
The vector in low memory provides a unique address in high memory for that BIOS function. Execution proceeds to the illegal instruction at that address. A TRAP condition is created and that address is pushed onto the stack. The kernel can recover this address to determine what BIOS function was called. After the push, execution continues inside the user page at UU.0000h.
Of course you don’t want to cold boot on every BIOS function. It now has dual function and the kernel has to make the determination.
User address UU.0000h requires instructions to pass control to the kernel (outside the user page) in ADL mode. Several methods apply, including forcing a software interrupt (in Mixed Memory Mode interrupt processing goes to 00.xxxxh when configured appropriately).
Now the cold boot vector has dual use from the kernel’s perspective. It looks at the stack to see if it has the TRAP constructs. If not, it processes an intended cold boot.
If it’s processing a TRAP situation then the address of the TRAP is recovered from the stack and used as an index (BIOS addresses in the user space are a byte apart so subtract to make them zero-relative) to identify the relocated BIOS function in the kernel’s domain. After the BIOS function is complete, the kernel has to repair the stack for the awkward hand-off and return appropriately to the user page as if nothing unusual ever happened.
If you can relocate your BIOS outside of the user page to thereby increase the TPA, you can continue the progression to increase the TPA. It might be advantageous to paint some of the high memory with TRAPs so that a user program directly calling BDOS could be detected and either processed or signaled with an error message.
The LOADER program could read the CP/M version and take over to load its Flash ROM UU.0000h-0100h page and BIOS TRAP construct for various CP/M versions that might be run in different user spaces. Naturally the kernel would control the time-slicing for the users.
-Jay in Dallas
Jay_in_Dallas
May 30, 2014, 11:20:25 AM5/30/14
to
Addendum:
It is true that you can merely force a TRAP at the BIOS links at UU.0000h-00FFh or link directly the kernel in ADL mode from there.
-Jay in Dallas
It is true that you can merely force a TRAP at the BIOS links at UU.0000h-00FFh or link directly the kernel in ADL mode from there.
-Jay in Dallas
rescu...@gmail.com
Mar 9, 2022, 2:30:09 PM3/9/22
to
On Thursday, November 15, 2012 at 5:32:33 AM UTC+2, David Griffith wrote:
> Paul Bartlett <bart...@panix.com> wrote:
> > Just a curiosity question (well, two questions), as I am no longer
> > doing anything with Z80/8080 or CP/M. However, my first computer was a
> > Kaypro IV running CP/M 2.2. It is still boxed up in a closet, although
> > I don't know if any of the 5 1/4" system diskettes are still bootable.
>
> > As we all know, Zilog came out with the eZ80 CPU, a Z80 workalike (but
> > much faster and more efficient) with an Address and Data Long mode
> > capable of linearly addressing 16MB of memory rather than the Z80's
> > 64KB. (I can remember when some room-filling IBM mainframes had only
> > 16MB of memory.) Has anyone ever tried to port or adapt any flavor of
> > CP/M to the eZ80 while making use of the large memory address space?
> > Does anyone know if a manufacturer has ever made a more or less general
> > purpose computer (or advanced programmable calculator) based on the
> > eZ80? Thanks.
> Someone created what's called the EZ80SBC, which is precisely what you
> seem to be after. Google tells me that the page for this is
> http://www.ez80sbc.com/ but nothing is answering. Google will still
> show you useful stuff like pictures, software, and schematics.
>
> --
> David Griffith
> davidmy...@acm.org <--- Put my last name where it belongs
Hi David.
Hoping you are still subscribed to this group, so you can read my message (and maybe reply on it..)
Recently, I posted this message (below) in the 'Z80-MBC2' Facebook group:
=====================================
Hi there.
I'm actually a relic from the CP/M days (I'm from 1956) and had several SBC's and also CP/M machines, check it out here:(https://tinyurl.com/yckv7tun)
Clockspeed of my fastest machine (Kaypro 4) was only 2.5 Mhz.
The Z80-MBC2 runs at 8 Mhz, which is quite impressive.
Then I asked myself: what is the fastest Z80 available??
I have seen 12 Mhz Z80's, but then I checked the internet, and I came across a project (July 2007 !!!) of a DIY Z80 based SBC that ran a whopping 50 (!!!) Mhz clockspeed.
It's an industrial type of Z80: the eZ80.
Around 2007 or so, some guy (Howard Harte) in Arizona started developing a SBC computer using this lightning fast 50 Mhz eZ80 CPU, and named it: the ez80SBC system.
There was a website ([http://www.ez80sbc.com but that domain is gone, and so the site disappeared. Luckily we have a great internet 'history book' called 'The WayBack Machine' and thanks to that, we can still see the the ez80SBC project website via this URL:
https://web.archive.org/web/20100604065529/http://www.ez80sbc.com/
I wonder if we can find some people in our group that would be interesting in building such a lightning 50 Mhz Z80 based system like this.
Anyone interested??
Waiting for your comments.....
Rgds
Robbert, the dutch guy living in Istanbul...
=====================================
Would be great if you could comment on this.
Rgds
Robbert / TA2IX (aka PA3BK)
> Paul Bartlett <bart...@panix.com> wrote:
> > Just a curiosity question (well, two questions), as I am no longer
> > doing anything with Z80/8080 or CP/M. However, my first computer was a
> > Kaypro IV running CP/M 2.2. It is still boxed up in a closet, although
> > I don't know if any of the 5 1/4" system diskettes are still bootable.
>
> > As we all know, Zilog came out with the eZ80 CPU, a Z80 workalike (but
> > much faster and more efficient) with an Address and Data Long mode
> > capable of linearly addressing 16MB of memory rather than the Z80's
> > 64KB. (I can remember when some room-filling IBM mainframes had only
> > 16MB of memory.) Has anyone ever tried to port or adapt any flavor of
> > CP/M to the eZ80 while making use of the large memory address space?
> > Does anyone know if a manufacturer has ever made a more or less general
> > purpose computer (or advanced programmable calculator) based on the
> > eZ80? Thanks.
> Someone created what's called the EZ80SBC, which is precisely what you
> seem to be after. Google tells me that the page for this is
> http://www.ez80sbc.com/ but nothing is answering. Google will still
> show you useful stuff like pictures, software, and schematics.
>
> --
> David Griffith
> davidmy...@acm.org <--- Put my last name where it belongs
Hi David.
Hoping you are still subscribed to this group, so you can read my message (and maybe reply on it..)
Recently, I posted this message (below) in the 'Z80-MBC2' Facebook group:
=====================================
Hi there.
I'm actually a relic from the CP/M days (I'm from 1956) and had several SBC's and also CP/M machines, check it out here:(https://tinyurl.com/yckv7tun)
Clockspeed of my fastest machine (Kaypro 4) was only 2.5 Mhz.
The Z80-MBC2 runs at 8 Mhz, which is quite impressive.
Then I asked myself: what is the fastest Z80 available??
I have seen 12 Mhz Z80's, but then I checked the internet, and I came across a project (July 2007 !!!) of a DIY Z80 based SBC that ran a whopping 50 (!!!) Mhz clockspeed.
It's an industrial type of Z80: the eZ80.
Around 2007 or so, some guy (Howard Harte) in Arizona started developing a SBC computer using this lightning fast 50 Mhz eZ80 CPU, and named it: the ez80SBC system.
There was a website ([http://www.ez80sbc.com but that domain is gone, and so the site disappeared. Luckily we have a great internet 'history book' called 'The WayBack Machine' and thanks to that, we can still see the the ez80SBC project website via this URL:
https://web.archive.org/web/20100604065529/http://www.ez80sbc.com/
I wonder if we can find some people in our group that would be interesting in building such a lightning 50 Mhz Z80 based system like this.
Anyone interested??
Waiting for your comments.....
Rgds
Robbert, the dutch guy living in Istanbul...
=====================================
Would be great if you could comment on this.
Rgds
Robbert / TA2IX (aka PA3BK)
Chris B
Mar 12, 2022, 7:03:19 PM3/12/22
to
Chris
0 new messages