Z-80 code question about a loop that depends on the contents of the refresh register
ethan.dicks at gmail.com
Wed Dec 14 16:34:29 CST 2016
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
> 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
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
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.
More information about the cctech