On 4/24/2024 11:34 PM, Edward Rawde wrote:
> "Don Y" <blockedofcourse@foo.invalid> wrote in message
> news:v0cm9k$2qh0i$1@dont-email.me...
>> On 4/24/2024 7:03 PM, Edward Rawde wrote:
>>>> so in something like and FPGA in is with range of internal ram and
>>>> memory
>>>> speed is not really an issue
>>>
>>> Yes. That's where I'd put a Z80 in the unlikely event that I wanted to
>>> use
>>> one these days.
>>> Along with RAM, ROM, and anything else it needs.
>>
>> You'd be better served to use something like a 6502 core as
>> the bus is cleaner and the core can run considerably faster.
>
> One reason I liked the 6809 was that it had 16 bit registers like the first
> CPU I ever used.
> https://en.wikipedia.org/wiki/National_Semiconductor_SC/MP

My first processor was a Nova 1200. My first *embedded* processor
was the i4004.

The 4004 was about 2000 transistors; the Z80 closer to 8000. (The
6502 splits the difference at about 4000). Your attitude/expectations
as to what you can do with a given platform vary directly with the
capabilities that platform makes available.

E.g., the i4004 product required "factory initialization constants"
in order to be operated. Moving to the i8085 allowed us to replace
the in-house DEC mainframe's functionality with runtime code *in*
the product. In practical terms not much of a performance improvement
but a big psychological advantage (no need to rely on a service provided
by the factory to *use* the equipment! What a novel concept -- and one
that is quickly becoming obsolete! :< )

The '09 (particularly the '09E) was pretty fast and easy to interface
with. The software folks were always begging for a 2MHz '09 system
doing video games (but, memory costs increase considerably in those days!)

When vendors would pitch hardware to us, they would always cite
"benchmarks". All of which were synthetic workloads. They'd be
upset when we would normalize their results for "constant
recurring dollars" -- if I have to specify more expensive components
to get that increase in performance, then my product cost increases
and I have to determine what the impact on sales might be!

[It's amazing how good you can get at normalizing performance
specs when you do it pretty regularly -- new processors were
continuously being released, "back then". Sadly, there is
comparatively little variety, nowadays.]

In article <v09p38$1uqd3$2@dont-email.me>,
Don Y <blockedofcourse@foo.invalid> wrote:
>On 4/23/2024 5:08 PM, Edward Rawde wrote:
>> It must be trivial to get a VHDL/Verilog model and make your own by now.
>
>The problem with all the early/simple/trivial processors is getting
>the rest of the system to run as fast as the core can. E.g., running
>a core at ~200MHz and expecting the same bus timing means < 5ns memory.
>
>(for a Z80, that would be ~10ns as the bus timing is inherently slower)
>
>The better option is to embed the core *in* a design to give you
>the advantages of a programmable sequencer (instead of "junk logic")
>
>> The 6809 was my preference but took a few more years.

Motorola was much better in this respect. Peripherals are accessed
by handshake. So you could put a longer delay iff the peripherals
are slow.

I remember spending 2000 guilders in around 1980 for 16 K ram
for my Z80.
Just to discover that code in this ram couldn't run, because the
Z80 was too slow. Only useable for data.

I managed to factor numbers of up till hundreds of digits,
using 1K of ram and 1K of videoram (that contained the digits)
before this extension. No restrictions on the size of the
factors! (Patience required.).

Groetjes Albert

>
>
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

Am 27.04.24 um 12:39 schrieb albert@spenarnc.xs4all.nl:

> Motorola was much better in this respect. Peripherals are accessed
> by handshake. So you could put a longer delay iff the peripherals
> are slow.
>
> I remember spending 2000 guilders in around 1980 for 16 K ram
> for my Z80.
> Just to discover that code in this ram couldn't run, because the
> Z80 was too slow. Only useable for data.

The other way around. The RAM cycle time was too slow for the
Z80 because of the DRAM refresh cycle after the instruction fetch.
And there was a /wait input on pin 24 if your bus logic was
unable to keep up with the Z80. Looks like handshake for me.

My first 64K*1 DRAMs did cost DM 64,00 each - which was quite a
sensation (NEC or Hitachi). And of course, my system got
the the first usable 8" DSDD floppy drives and ran CP/M.
I'm pretty sure that the instructions were in DRAM.
There was no ROM after booting at all.

I did the CP/M port with a friend. It later turned out that
the Altos computer was near identical, just patching the
I/O addresses would have been enough.
Later I even got a 1MB RAM floppy, powered by 8086.
(really to do a paid CP/M-86 port :-)

regards, Gerhard

On a sunny day (Sat, 27 Apr 2024 13:57:05 +0200) it happened Gerhard Hoffmann
<dk4xp@arcor.de> wrote in <v0ip6h$1tn2$1@solani.org>:

>Am 27.04.24 um 12:39 schrieb albert@spenarnc.xs4all.nl:
>
>> Motorola was much better in this respect. Peripherals are accessed
>> by handshake. So you could put a longer delay iff the peripherals
>> are slow.
>>
>> I remember spending 2000 guilders in around 1980 for 16 K ram
>> for my Z80.
>> Just to discover that code in this ram couldn't run, because the
>> Z80 was too slow. Only useable for data.
>
>The other way around. The RAM cycle time was too slow for the
>Z80 because of the DRAM refresh cycle after the instruction fetch.
>And there was a /wait input on pin 24 if your bus logic was
>unable to keep up with the Z80. Looks like handshake for me.
>
>My first 64K*1 DRAMs did cost DM 64,00 each - which was quite a
>sensation (NEC or Hitachi). And of course, my system got
>the the first usable 8" DSDD floppy drives and ran CP/M.
>I'm pretty sure that the instructions were in DRAM.
>There was no ROM after booting at all.
>
>I did the CP/M port with a friend. It later turned out that
>the Altos computer was near identical, just patching the
>I/O addresses would have been enough.
>Later I even got a 1MB RAM floppy, powered by 8086.
>(really to do a paid CP/M-86 port :-)
>
>regards, Gerhard

I used 5 1/4 inch floppies in Kaypro2 format
added a 256 kB RAM disk addressed by the Z80 I/O instuctions.
Added a 'copy floppy to ramdisk' command, and could run from there.
No seek and no r/w times times.
https://panteltje.nl/panteltje/z80/system14/diagrams/index.html
scroll down to
Ramdisk card:
diagram part 1
diagram part 2
component layout
timing waveforms
Wrote my own CP/M clone.

On 4/27/2024 3:39 AM, albert@spenarnc.xs4all.nl wrote:
> In article <v09p38$1uqd3$2@dont-email.me>,
> Don Y <blockedofcourse@foo.invalid> wrote:
>> On 4/23/2024 5:08 PM, Edward Rawde wrote:
>>> It must be trivial to get a VHDL/Verilog model and make your own by now.
>>
>> The problem with all the early/simple/trivial processors is getting
>> the rest of the system to run as fast as the core can. E.g., running
>> a core at ~200MHz and expecting the same bus timing means < 5ns memory.
>>
>> (for a Z80, that would be ~10ns as the bus timing is inherently slower)
>>
>> The better option is to embed the core *in* a design to give you
>> the advantages of a programmable sequencer (instead of "junk logic")
>>
>>> The 6809 was my preference but took a few more years.
>
> Motorola was much better in this respect. Peripherals are accessed
> by handshake. So you could put a longer delay iff the peripherals
> are slow.

The Z80 allowed the bus cycle to be indefinitely extended by
the assertion of WAIT. As a bus cycle had many clock edges,
you could support devices that were "slightly slower" than
the nominal bus timing without having to allow "twice" as
much time for the access.

The WAIT feature was present on many MCUs of that era (I recall
NOT present on the 8x300)

The M68K was the first mainstream device to use "asynchronous"
memory requiring an explicit acknowledgement (DTACK) for each
bus transaction (by contrast, one could *wire* WAIT permanently
inactive if you had sufficiently fast enough memory; OTOH, DTACK
*had* to be stroked regardless of memory speed -- or even the
PRESENCE of memory in an address region!)

Implementing dual-ported memory was considerably easier on MCUs
with fixed bus timings (6502/2A03, 68xx, etc.) as you KNEW when the
MCU would NOT be accessing memory. For procesors with variable
bus cycles (68K, Z80, etc.), you had to resort to introducing wait
states (in case the MCU wanted access to the memory while the
arbiter was giving access to the other "bus master") or playing
games with the clock stretching.

[*Single* writes could be cached in external logic and defered until
the arbiter returned access to the MCU to eliminate stalling the bus
in those cases; no such mechanism available for reads, though]

The 16032 had the cleverest pinout, supporting external coprocessors
(including the PMMU) without requiring superfluous bondout options.

> I remember spending 2000 guilders in around 1980 for 16 K ram
> for my Z80.
> Just to discover that code in this ram couldn't run, because the
> Z80 was too slow. Only useable for data.

Huh? An opcode fetch takes the same amount of time as a data fetch. The
opcode fetch also has a bit of extra time in the cycle (4 clocks vs 3)
to squeeze in a DRAM refresh (damn near everyone recognized this ability
when designing memory controllers; stalling the MCUs accesses just
to steal a bus cycle would be a significant hit on bandwidth).

The abundance of clock edges in the cycle made designing a DRAM controller
out of discrete logic pretty trivial. And, the processor's internal
"refresh register" eliminated the need for an external counter to
perform that function.

I have a Z80 system with 512KB of DRAM (huge for that era). It
allows for 8 simultaneous MP/M users or a single CP/M user with
a relatively large RAM disk (blazing fast compared to the 8"
floppies of the day -- especially for software development where
multipass tools were common)

> I managed to factor numbers of up till hundreds of digits,
> using 1K of ram and 1K of videoram (that contained the digits)
> before this extension. No restrictions on the size of the
> factors! (Patience required.).