On Tue, Dec 13, 2016 at 5:51 PM, Ethan Dicks <ethan.dicks at gmail.com> wrote: I'm now thinking this is the RNG which is supposed to return a number something I know the app depends on. The real question becomes how to run this in emulation. -ethan

On Wed, Dec 14, 2016 at 2:08 AM, Alexis Kotlowy <thrashbarg at kaput.homeunix.org> wrote: I have not. Thanks for the suggestion. I don't know which emulators might implement the refresh register. That's what it will take - I'm 100% UNIX/Linux (well... plus VAX and PDP-11 and Amiga and PET...) Excellent. I expect it should work. 1979. Emulators weren't a factor then. I don't think so. It's just generating a percentage which it's using for probability. Tony Duell pointed that out too. I suspect that this code works for machines that existed at the time, with 16K DRAMs, and might or might not have worked on later machines. A quick scan of InfoWorld links and such and I can't find any S-100 cards with 4164s older than about 1983. I don't think there were many commercially available 64K DRAMs prior to 1982. -ethan

On Wed, 14 Dec 2016, Tony Duell wrote: It's been long since I did anything with the Z80, but offhand all flags are set as with ALU operations according to the value loaded into the accumulator (same with LD A,I, but not the reverse loads IIRC). These are the only Z80 LD instructions that set the flags. If help is still needed with interpreting this piece of code I can reach out for documentation and refresh old memory. BTW, as a side effect of incomplete instruction decoding and the lack of trapping on unimplemented operations the Z80 had a number of undocumented operations available, which however were reliable across different silicon manufactured and eventually got figured out and documented. Some software relied on correct execution of these operations and may require an accurate emulator implementation to run correctly. XZX is one emulator I know of that has claimed support for all these operations in its core processor support (I and R registers should also be correctly handled); otherwise emulating Sinclair ZX Spectrum class systems and running as an X11 client on various *nix systems. I haven't used it for years now though and have no idea whether it has been maintained beyond 1997 which is when the version I still have around has been released. Maciej

On Wed, Dec 14, 2016 at 4:26 PM, allison <ajp166 at verizon.net> wrote: 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). I know there were different types but not those details. Thanks. 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). So I'm learning. 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. I will look that up. 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

On 12/15/2016 02:12 AM, Ethan Dicks wrote: In the past the LD A,R was used to seed a random number generator, not the best but for tiny basics and the like is was enough. IT was used in one app I'd seen as a cycle counter as part of a debugger since it increments each M1 (instruction fetch) cycle. FYI later Z80 variants like 64180, Z180, Z280 that register was at least 8 bit incrementing. I've designed around them all. Allison