Z80 emulator for Intel Mac?

Z80 emulator for Intel Mac?

Post by Martin Whi » Tue, 07 Nov 2006 11:02:16


Hi people,

Just come across this newsgroup while looking for some info so I hope this
is the right place for the subject!

I've been doing some work on an emulator project over the last few days and
am basically just wandering if I'm starting with the right kind of tool for
the job.

The stuff I'm working on is originally for windows and it uses "Raze" as
it's Z80 core so to start off with, as I use a Mac (Intel iMac) I grabbed
the code for Raze and compiled it up into a MachO library. It seems to be
working just fine - I wrote a few Z80 instructions to continually inc. a
memory address, then I peek at that address periodically and it IS changing
as I would expect.

I was wandering though since Raze seems to be very old whether there may be
something better or whether it's a case of Raze being a good "oldie" :o)

Being completely new to this (I normally spend my time with the real
hardware as opposed to emulating it) it seems a little strange for starters
to be doing things like, start emulation, execute n cycles, then stop to
allow us to do stuff, then loop. I'm perhaps wandering whether this just
comes down to age but surely these days PC (and iMac's!) are powerful enough
that you could just kick off the Z80 emulation in it's own thread, running
realtime and let it run forever (well, until you hit the virtual power
switch) and then just interact with it via memory, I/O, int's etc. as the
real hardware would have to do?

OR, like I say, being an emulation noob am I missing something very obvious
- LOL!

Cheers,
Martin.
 
 
 

Z80 emulator for Intel Mac?

Post by Dunn » Wed, 08 Nov 2006 07:48:48


Martin White < XXXX@XXXXX.COM > typed:


Nope, you could do it that way. However, most emulators will emulate n
cycles and then perform "housekeeping" such as updating screens and
gathering user input. A lot of hardware such as the Sinclair machines had a
50hz interrupt and a ULA interfering with the z80, so it makes sense for us
that emulate such hardware to run one frame's worth of opcodes before
updating the display. As the z80s we emulate run at 3.5mhz, you only emulate
so much before you have to stop for speed-throttling reasons.

If you want to set up a thread, as you say, there's nothing to stop you.
Emulating a plain z80 on it's own with no extra hardware attached is a task
even the old 286s could handle with ease. These days, accurate z80 emulation
(including the hidden Memptr register and undocumented opcodes) along with
memory contention and accurate sub-scanline display updates is a task that
only machines of more than about 300mhz can handle - and when you add in
Windows' rather poor attempts at multitasking, you're pushing close to 1ghz
before you've got smooth emulation.

It all depends on what you want to emulate, really.

D.

 
 
 

Z80 emulator for Intel Mac?

Post by Martin Whi » Wed, 08 Nov 2006 08:20:59

Okay, I guess that makes sense then to do the updating / pausing during
vblanking.

I'm working on an emulation project that is looking at emulating one of
these: http://www.yqcomputer.com/

According to the source I picked up the machine's cpu is running at 3.25Mhz
although I've not looked at the schematics yet to confirm this one way or
another.

Not much there to the actual base unit. A neon display unit, keyboard, tape
drive, RS232, probe and scope trigger output, however the pods are going to
be an altogether different matter. It's more or less all done aside from the
pod(s).

The idea is to be able to interface it to either virtual hardware or
physical hardware as and when things progress.

Any comment on a suggested Z80 core for portability between Unix / Windows /
Intel Mac?

Thanks,
Martin.


On 6/11/06 22:48, in article kZO3h.15602$ XXXX@XXXXX.COM ,
 
 
 

Z80 emulator for Intel Mac?

Post by Dunn » Thu, 09 Nov 2006 07:01:02


Martin White < XXXX@XXXXX.COM > typed:


I couldn't recommend any - for our projects, none were accurate enough.
There's recently been a lot of developments regarding undocumented behaviour
(and indeed, behaviour that was thought properly documented!) which is not
incorporated into any of the open-source z80 cores. As such, we rolled our
own.

D.