Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.sinclair > #4134 > unrolled thread

How does a Spectrum emulator work?

Back to article view | Back to comp.sys.sinclair

Contents

  How does a Spectrum emulator work? bit-naughty@hotmail.com - 2016-04-02 09:40 -0700
    Re: How does a Spectrum emulator work? Guesser <alistair@zxnet.co.uk> - 2016-04-02 18:14 +0100
      Re: How does a Spectrum emulator work? jbkoelman.sp@gmail.com - 2016-04-02 12:43 -0700
        Re: How does a Spectrum emulator work? "Brian Gaff" <briang1@blueyonder.co.uk> - 2016-04-02 21:22 +0100
          Re: How does a Spectrum emulator work? jbkoelman.sp@gmail.com - 2016-04-02 13:49 -0700
          Re: How does a Spectrum emulator work? Leiradella <aleiradella@gmail.com> - 2016-04-02 14:01 -0700
    Re: How does a Spectrum emulator work? "Brian Gaff" <briang1@blueyonder.co.uk> - 2016-04-02 21:17 +0100
    Re: How does a Spectrum emulator work? Leiradella <aleiradella@gmail.com> - 2016-04-02 13:56 -0700
    Re: How does a Spectrum emulator work? Andre Majorel <cheney@halliburton.com> - 2016-04-06 11:56 +0000
      Re: How does a Spectrum emulator work? Tyrell <on4ssc@gmail.com> - 2017-01-28 15:59 +0100
        Re: How does a Spectrum emulator work? AndyW <Andy@nojunqmail.com> - 2017-01-30 07:33 +0000

#4134 — How does a Spectrum emulator work?

.... I remember having a small discussion with Gasman about this right here (and btw, Gasman, I'm still looking to get in touch with you, if you're reading this, please post here!), but I got to thinking about it, and..... how is it done? 

How do you actually *send* a stream of hex to your CPU? (I'm talking about the machine your emulator is running on,.. that is to say, in general, Mister Intel...) I mean, figuring out the Z80 code, and figuring out what it's Intel equivalent will be is obviously the *main* task of an emulator, and hard enough by itself, but... once you know what instructions you want to *send* to Mr. Intel, .... how do you do it?

I once heard or read somewhere of a trick where you put an instruction on the stack (like, the hex code), and then do, essentially, a POP EIP (I'm using 32-bit terminology), but then what do you do if that instruction is a JMP? What is the actual _essence_ of emulation....? :)

...And of course THEN there is the question of how the actual *conversion* is done....I'm emphatically NOT a C programmer, so please don't tell me to read FUSE code or something, to figure out how THAT's done.... :)

[toc] | [next] | [standalone]

#4135

On 02/04/2016 17:40, bit-naughty@hotmail.com wrote:
> ..... I remember having a small discussion with Gasman about this right here (and btw, Gasman, I'm still looking to get in touch with you, if you're reading this, please post here!), but I got to thinking about it, and..... how is it done?
>
> How do you actually *send* a stream of hex to your CPU? (I'm talking about the machine your emulator is running on,.. that is to say, in general, Mister Intel...) I mean, figuring out the Z80 code, and figuring out what it's Intel equivalent will be is obviously the *main* task of an emulator, and hard enough by itself, but... once you know what instructions you want to *send* to Mr. Intel, .... how do you do it?
>
In 2016 you don't. You write some code for each instruction and another 
bit of code reads from the memory that represents the spectrum's memory 
at the appropriate offset saved in some kind of variable representing 
the program counter. You read the bytes and call the relevant routine 
for that opcode. They update other variables for other registers and 
read or write bytes in the memory array. Then you do it all again for 
the next instruction etc. You also need some counters for things like 
interrupts, and some code to interpret the contents of the memory array 
and generate the display.

Then you compile all that code into a binary and let the operating 
system and standard libraries worry about making it run.

> I once heard or read somewhere of a trick where you put an instruction on the stack (like, the hex code), and then do, essentially, a POP EIP (I'm using 32-bit terminology), but then what do you do if that instruction is a JMP? What is the actual _essence_ of emulation....? :)
>
> ....And of course THEN there is the question of how the actual *conversion* is done....I'm emphatically NOT a C programmer, so please don't tell me to read FUSE code or something, to figure out how THAT's done.... :)
>
Was the source for the Z80 emulator ever released, or was it only made 
freeware? I seem to remember than translating Z80 to x86 instructions 
was one of the tricks it used to get acceptable emulation speed out of 
the processors of the time.

[toc] | [prev] | [next] | [standalone]

#4136

In the documentation of the Z80-emulator there was some explanation of the emulator.
Exact as described for each opcode a small routine was coded.
On a PC enough memory is available and the Z80-emulator needed 64K for the emulation since each opcode was emulated at address #nn00 where nn held the number of the opcode. Each opcode had therefore 256 bytes room for the routine.

Also the minimal requirements of the host computer were mentioned. For speed you needed at least 10x faster than emulated computer.
More memory (original and emulation must be loaded) and finally same or higher screenresolution to display the screen.

These rules apply quite well, although it didn't stop me from trying to code a ZX81 emulator for the ZX Spectrum and the Sam Coupe which both only have a bit faster CPU than the ZX81 and therefore do not comply to the speed rule.

On the SAM coupe we were able to not truly emulate original code, but just let it run and only built a screen during intrupt.
This made a full speed ZX81 possible.

For the ZX Spectrum there is a full emulator, but the emulator runs certain parts of the ROM in a ZX-Spectrum mode, using the moved addresses.
With this trick a lot of games run well on the ZX Spectrum too.

[toc] | [prev] | [next] | [standalone]

#4138

Yes but this only really worked because the z80 in the 81 machine was mostly 
taking time building the picture you saw. That was why it had fast and slow 
mode.
 As a matter of interest, did anyone manage to emulate the tape loader from 
the 81. it was flaky at the best of times on the original machine.
 Brian

-- 
 -----  -
This newsgroup posting comes to you directly from...
The Sofa of Brian Gaff...
briang1@blueyonder.co.uk
Blind user, so no pictures please!
<jbkoelman.sp@gmail.com> wrote in message 
news:a8eaf40e-89f6-41d6-916a-c68a358acf79@googlegroups.com...
> In the documentation of the Z80-emulator there was some explanation of the 
> emulator.
> Exact as described for each opcode a small routine was coded.
> On a PC enough memory is available and the Z80-emulator needed 64K for the 
> emulation since each opcode was emulated at address #nn00 where nn held 
> the number of the opcode. Each opcode had therefore 256 bytes room for the 
> routine.
>
> Also the minimal requirements of the host computer were mentioned. For 
> speed you needed at least 10x faster than emulated computer.
> More memory (original and emulation must be loaded) and finally same or 
> higher screenresolution to display the screen.
>
> These rules apply quite well, although it didn't stop me from trying to 
> code a ZX81 emulator for the ZX Spectrum and the Sam Coupe which both only 
> have a bit faster CPU than the ZX81 and therefore do not comply to the 
> speed rule.
>
> On the SAM coupe we were able to not truly emulate original code, but just 
> let it run and only built a screen during intrupt.
> This made a full speed ZX81 possible.
>
> For the ZX Spectrum there is a full emulator, but the emulator runs 
> certain parts of the ROM in a ZX-Spectrum mode, using the moved addresses.
> With this trick a lot of games run well on the ZX Spectrum too. 

[toc] | [prev] | [next] | [standalone]

#4139

Brian,

Even with 80% for screen update it is slower on the ZX Spectrum. 
Added the time needed to emulate each opcode an average emulationspeed is about 10%
Other tricks are needed to speed up the emulator.

[toc] | [prev] | [next] | [standalone]

#4141

>  As a matter of interest, did anyone manage to emulate the tape loader from 
> the 81. it was flaky at the best of times on the original machine.

The EightyOne emulator has a good tape loader emulation IMO. It can take .P and .TZX files and emulate the loading process with the horizontal bars, and sound.

EightyOne is for Windows only, but I've ported it to libretro so now it runs on all platforms where RetroArch can run, including tape emulation. You can find it here: https://github.com/libretro/81-libretro

[toc] | [prev] | [next] | [standalone]

#4137

Not sure what you are asking. Many moons ago there was a dos program that 
emulated the z80 chip on other chips. Once this core is done then you 
presumably need to emulate the hardware of the target machine assuming it 
uses a z80..
To me this was always the hard bit, especially inside windows which tended 
to stop direct calls to the pc hardware completely.
 Its been a long time since I looked at any code, but a lot of it was 
written in other languages, depending on the  machine and hardware. C is a 
common choice of course.
 Direct assembler has to run on the emulated chip of course.
 Brian

-- 
 -----  -
This newsgroup posting comes to you directly from...
The Sofa of Brian Gaff...
briang1@blueyonder.co.uk
Blind user, so no pictures please!
<bit-naughty@hotmail.com> wrote in message 
news:cb4d972b-4829-4377-b4f1-ce90924d0c7d@googlegroups.com...
.... I remember having a small discussion with Gasman about this right here 
(and btw, Gasman, I'm still looking to get in touch with you, if you're 
reading this, please post here!), but I got to thinking about it, and..... 
how is it done?

How do you actually *send* a stream of hex to your CPU? (I'm talking about 
the machine your emulator is running on,.. that is to say, in general, 
Mister Intel...) I mean, figuring out the Z80 code, and figuring out what 
it's Intel equivalent will be is obviously the *main* task of an emulator, 
and hard enough by itself, but... once you know what instructions you want 
to *send* to Mr. Intel, .... how do you do it?

I once heard or read somewhere of a trick where you put an instruction on 
the stack (like, the hex code), and then do, essentially, a POP EIP (I'm 
using 32-bit terminology), but then what do you do if that instruction is a 
JMP? What is the actual _essence_ of emulation....? :)

...And of course THEN there is the question of how the actual *conversion* 
is done....I'm emphatically NOT a C programmer, so please don't tell me to 
read FUSE code or something, to figure out how THAT's done.... :) 

[toc] | [prev] | [next] | [standalone]

#4140

> ...And of course THEN there is the question of how the actual *conversion* is done....I'm emphatically NOT a C programmer, so please don't tell me to read FUSE code or something, to figure out how THAT's done.... :)

I've written an article covering the (very) basics of a ZX81 emulator for #altdevblogaday. The site is down, but I have a backup here: http://htmlpreview.github.io/?https://raw.github.com/leiradel/altdevblogaday/blob/master/article6/article6.html

It has some C code, but it is an article so you may find it useful.

[toc] | [prev] | [next] | [standalone]

#4142

On 2016-04-02, bit-naughty@hotmail.com <bit-naughty@hotmail.com> wrote:

> How do you actually *send* a stream of hex to your CPU? (I'm
> talking about the machine your emulator is running on,.. that
> is to say, in general, Mister Intel...) I mean, figuring out
> the Z80 code, and figuring out what it's Intel equivalent will
> be is obviously the *main* task of an emulator, and hard
> enough by itself, but... once you know what instructions you
> want to *send* to Mr. Intel, .... how do you do it?

Usually, emulation is not done by translating from one machine
code to another. Most emulators are really interpreters that
happen to interpret machine code instead of BASIC.

That approach is slower (the interpreter is not as fast as
translated code could be) but has advantages. You don't have to
worry about self-modifying code and it's easy to add a debugger
to the emulator or make it run on a different host CPU (provided
you wrote it in a high-level language).

-- 
André Majorel http://www.teaser.fr/~amajorel/
J'ai des vrais problèmes, vous avez des faux problèmes.

[toc] | [prev] | [next] | [standalone]

#4320

On 6/04/2016 13:56, Andre Majorel wrote:
> On 2016-04-02, bit-naughty@hotmail.com <bit-naughty@hotmail.com> wrote:
>
>> How do you actually *send* a stream of hex to your CPU? (I'm
>> talking about the machine your emulator is running on,.. that
>> is to say, in general, Mister Intel...) I mean, figuring out
>> the Z80 code, and figuring out what it's Intel equivalent will
>> be is obviously the *main* task of an emulator, and hard
>> enough by itself, but... once you know what instructions you
>> want to *send* to Mr. Intel, .... how do you do it?
>
> Usually, emulation is not done by translating from one machine
> code to another. Most emulators are really interpreters that
> happen to interpret machine code instead of BASIC.
>
> That approach is slower (the interpreter is not as fast as
> translated code could be) but has advantages. You don't have to
> worry about self-modifying code and it's easy to add a debugger
> to the emulator or make it run on a different host CPU (provided
> you wrote it in a high-level language).
>

Hi !
The way an emulator is working is quite simple.
There's this big "switch" statement, peeking at a memory location, 
decoding which instruction it is, and setting flag as the real Z80 would 
do it. Then it increases the memory location (PC) depending on the Z80 
instruction length and decodes the next instruction.
Then it's a matter of converting the content of the spectrum screen 
location into the host computer screen buffer + playing the sound and 
reading joystick input.

I'm really missing speccy emulator development ... I learned a lot at 
that time, and it sure gave me some serious headache when it came to 
debug non working stuff (graphical artifacts, mostly due to some non 
working opcodes).

Anyone here still using Speccyal'K on the GP32 or DC Speccyal'K ? :)

Tyrell

[toc] | [prev] | [next] | [standalone]

#4321

On 28/01/2017 14:59, Tyrell wrote:
>
> Anyone here still using Speccyal'K on the GP32 or DC Speccyal'K ?

I still have it on my GP2X although I have not fired it up for ages, my 
phone does it all now and Marvin on my android is my main speccy emulator.
I still fire up the Bard's Tale on long train journeys.

Andy

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.sinclair

csiph-web