5 Jan
2017
5 Jan
'17
4:15 p.m.
For what it's worth, xtrs (http://tim-mann.org/xtrs.html) emulates LD A,R
by putting an 8-bit random number in A. Of course that's cheesy and wrong
-- especially bit 7 being random instead of retaining a 0 from reset or the
last value written to it -- but at least it works OK with Ethan's
subroutine. The subroutine may loop a few times due to the value randomly
being negative or zero until it escapes the first time the value is
randomly positive.
xtrs sets the sign and zero flags according to the value, and does
something complicated with the other flags that I don't remember the reason
for -- but it might be correct; i think I got it from some reference on the
web last time I hacked on that instruction.
The pointer that someone posted to
http://www.worldofspectrum.org/faq/reference/z80reference.htm#RRegister may
inspire me to fix the emulation, though it looks like a bit of work to get
it exactly right...
On Thu, Dec 15, 2016 at 10:00 AM, <cctech-request at classiccmp.org> wrote:
Message: 10
Date: Wed, 14 Dec 2016 17:34:29 -0500
From: Ethan Dicks <ethan.dicks at gmail.com>
To: "General Discussion: On-Topic Posts" <cctech at classiccmp.org>
Subject: Re: Z-80 code question about a loop that depends on the
contents of the refresh register
Message-ID:
<CAALmimm07Bf=fjp70jzMKiV0m94aWxzggjeZuJg=ji
LeLXT+gw at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
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