Z-80 code question about a loop that depends on the contents of the refresh register

[Ethan Dicks]

On Wed, Dec 14, 2016 at 4:26 PM, allison <ajp166 at verizon.net> wrote:
>>> On 14/12/2016 09:19, Ethan Dicks wrote:
>>>>
>>>> So far, this loop hangs on all three emulators I've tried - simh's
>>>> altairz80, simcpm010 for AmigaDOS, and EMUZ80 for Raspberry Pi.  I'm
>>>>   guessing none of these environments emulate specific behavior of the
>>>>   Refresh register?

> The first year of appearance for 64K DRAMS was mid to late 1980 (expensive
> and scarce)  and mostly sampling to the big vendors.  For regular users late 81
> when the price started down.

Right.  I was a user of 8-bit micros in that exact era.  My first
hands-on experience as a user was the memory inside the Commodore 64.
My first engineering experience was in 1984 on a product designed in
1983 (COMBOARD-II with 128K of 4164 chips and a 74S409 refresh
controller).

> There were three flavors, 8bit refresh, 7bit refresh, and
> internal refresh came in a bit later by maybe mid 1982.

I know there were different types but not those details.  Thanks.

> The Z80 could do 8bit refresh with hardware or software or the self refresh
> (internal).

I'm also a little fuzzy on this aspect of things because I was never a
Z-80 user back in the day.

Software Results considered a Z-80 COMBOARD very early on, but
abandonded that approach because it would have likely required 2 hex
Unibus modules and so opted to hold out a few months and go with a
68000 and SRAM design on a single hex card (my old boss still has an
XC68000 with S/N 424 engraved on the lid).

> Nominally the R register is a counter that increments from any value to 7bit
> overflow.

So I'm learning.

> I believe most emulators actually do that.

The first three emulators I tried (simcpm010, altairz80, and EMUZ80)
on three different platforms (AmigaDOS, Linux, and ARM) do not.  I now
have a couple of names of DOS/Windows emulators that should.  I will
have to run them under Wine since I'm not a Windows user.

It's funny because I would have tried this on simcpm010 25 years ago
(it was on the Amiga disk I just extracted all these files from) and
it would have failed then just as it fails today, and then, I had *no*
idea why.  I've learned a lot since then because it only took me a few
hours of digging to uncover why.

> Check MyZ80 Simon Crans work (32bit
> dos/ pre-7-winders only or in a 32bit sim/VM).

I will look that up.

> Either that or lookup and assemble Grant Searle's low chip count Z80 system.

The worry is not running on real hardware.   Once I get some time to
clean up my XOR or dig out a Kaypro, I will run it on real hardware.
I want to find/fix an emulator for modern machines so that other
people can just grab and go.  Also, this is not _just_ a Z-80 program,
it's a CP/M program, with CP/M BDOS calls to open/close/read/write
files and read-from/write-to the console (F_OPEN, F_CLOSE, F_READ,
F_WRITE, C_READSTR, C_WRITE).

Right now, I'm leaning towards fixing altairz80 first since that runs
on "everything".  I may also work with the author of EMUZ80 so it
works on bare-metal Raspberry Pi (EMUZ80 is a Pascal app that runs in
the Lazarus bare-metal framework, so you need Windows to rebuild the
app).   I don't mind putting known-working Windows-based emulators on
a list of "verified environments", but I'm not going to push this to
the public without a Mac and a Linux answer.  Telling the world that
they have to build a real Z-80 CP/M machine to play a game isn't going
to hit a large audience.

Thanks,

-ethan