) 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
 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