On Wed, Dec 14, 2016 at 4:26 PM, allison <[email protected]> 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
