cctech Digest, Vol 30, Issue 15
tim at tim-mann.org
Thu Jan 5 19:15:32 CST 2017
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
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
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
> 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
> > 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
> > (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
> > 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
> 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