quick-and-dirty port of my Zymosis Z80 emulation engine to D. code was built from scratch and not using huge tables to generate huge sources (it's just one module with source size ~64KB).

it properly emulates all known Z80 quirks (including MEMPTR register) and passes all 1335 tests from FUSE.

sorry, it uses GDC @attribute("forceinline") feature, so you need latest GDC to build it. it's not strictly necessary though (speed optimizations? who needs that speed optimizations with current CPUs?!) and can be hacked away with this piece of code:

version(GNU) {
  import gcc.attribute;
} else {
  private struct Attribute(A...) { A args; }
  auto attribute(A...) (A args) if (A.length > 0 && is(A[0] == string)) { return Attribute!A(args); }
}

i'm pretty sure that this is the first Z80 emulator written in D. %-)

ah, nearly forgot to give repo URL: http://repo.or.cz/w/zymosis.d.git

ketmar:

> sorry, it uses GDC @attribute("forceinline") feature, so you need latest GDC to build it. it's not strictly necessary though (speed optimizations?

Have you performed a benchmark with and without that attribute?


> http://repo.or.cz/w/zymosis.d.git

In this kind of code computed gotos could help performance.


> struct { ubyte c, b; };

Struct definitions in D don't end with the semicolon.


> @property final void iff1 (int v) nothrow { riff1 = (v != 0); } /** set interrupt flip-flop 1 */

I suggest to omit the space between the function name and its arguments. And if you want you can also add an "in":

... iff1(in int v) nothrow ...


> { rregR = ((rregR&0x7f)+1)|(rregR&0x80); }

Better to add spaces around those operators. And perhaps it's better to use enum values instead of magic constants.


>   final void exec () {
>     ubyte opcode;
>     bool gotDD, trueCC;
>     int disp;
>     ubyte tmpB, tmpC, rsrc, rdst;
>     ushort tmpW = 0; /* shut up the compiler; it's wrong but stubborn */
>     /* main loop */
>     while (rtstates < rnext_event_tstate) {
>       if (rCallPager) pager();
>       if (rCheckBPs && checkBP()) return;
>       rprevpc = rorgpc;
>       rorgpc = rpc;
>       /* read opcode -- OCR(4) */
>       opcode = fetchOpcode();
>       rprev_was_EIDDR = 0;
>       disp = gotDD = false;
>       rdd = &rhl;
>       if (rhalted) { --rpc; continue; }
>       /* check for I[XY] prefix */
>       if (opcode == 0xdd || opcode == 0xfd) {

I suggest to add an empty line before the line of comment.
And I suggest to use 4 spaces as indent unit.


> static __gshared ubyte parity_tbl[256];

Better to use the D syntax:

static __gshared ubyte[256] parity_tbl;

Bye,
bearophile

On 20 April 2014 21:16, ketmar via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

>
> i'm pretty sure that this is the first Z80 emulator written in D. %-)
>

I suspect mine might have been the first Z80 emulator written in D, but even then, probably not :)

https://github.com/TurkeyMan/superemu

On 21 April 2014 00:49, Manu <turkeyman@gmail.com> wrote:

> On 20 April 2014 21:16, ketmar via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:
>
>>
>> i'm pretty sure that this is the first Z80 emulator written in D. %-)
>>
>
> I suspect mine might have been the first Z80 emulator written in D, but even then, probably not :)
>
> https://github.com/TurkeyMan/superemu
>

Funny you make a point of forceinline, I have forceinline placeholders all
over my emulators too ;)
It'll come... one day.

On Sunday, 20 April 2014 at 13:08:02 UTC, bearophile wrote:
>> sorry, it uses GDC @attribute("forceinline") feature, so you
> Have you performed a benchmark with and without that attribute?
not on this code yet. will check it someday,

>> http://repo.or.cz/w/zymosis.d.git
> In this kind of code computed gotos could help performance.
i don't think so: it's not a 'table-driven executor', it does proper instruction decoding by various opcode bitfields like Z80 do. this is "by design". so i can't just make a huge table for computed goto.

>> struct { ubyte c, b; };
> Struct definitions in D don't end with the semicolon.
ah. tnx, this is a C code leftovers. maybe compiler should emit warnings on superfluous semicolons?

> I suggest to omit the space between the function name and its arguments.
sorry, but i will not change my coding style. i may use original author's style when sending patches, but i'm used to my own for my projects.

> And if you want you can also add an "in":
tnx, will do.

> And perhaps it's better to use enum values instead of magic constants.
this is hardware magic by itself. %-) i don't think that constants like 'BIT7MASK' and 'BITS0TO6MASK' will look prettier here.

>> static __gshared ubyte parity_tbl[256];
> Better to use the D syntax:
> static __gshared ubyte[256] parity_tbl;
ah, C leftovers again, changed, tnx.

thanks for all your comments and suggestions. i'm still D newbie, so they are valuable input.

On Sunday, 20 April 2014 at 15:17:56 UTC, Manu via Digitalmars-d-announce wrote:
>> https://github.com/TurkeyMan/superemu
wow, my google-fu is bad than. %-) doing 'git clone' right now.
btw, what is the license for your code?

> Funny you make a point of forceinline, I have forceinline placeholders all
> over my emulators too ;)
i think that almost any emulator writer just can't resist the urge to 'help' compiler this way. %-)

On 21 April 2014 04:03, ketmar via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

> On Sunday, 20 April 2014 at 15:17:56 UTC, Manu via Digitalmars-d-announce wrote:
>
>> https://github.com/TurkeyMan/superemu
>>>
>> wow, my google-fu is bad than. %-) doing 'git clone' right now.
> btw, what is the license for your code?


I don't really care. Refer to it as much as you like.
I have larger plans for this project, but I've been distracted with other
apparently more important things. I've been meaning to get back to it.
It's a bit out of date now. I need to update it.

It might be fun to collaborate if you're interested...?


 Funny you make a point of forceinline, I have forceinline placeholders all
>> over my emulators too ;)
>>
> i think that almost any emulator writer just can't resist the urge to 'help' compiler this way. %-)


Indeed.

>> btw, what is the license for your code?
> I don't really care. Refer to it as much as you like.
so maybe you will add license to sources? WTFPL, for example, which basically means "public domain". the thing is that sources without license are proprietary, and nobody except the author can do anything with that.

> I have larger plans for this project, but I've been distracted with other
> apparently more important things.
same thing here. %-)

> It might be fun to collaborate if you're interested...?
i'm actually know only one vintage computer: ZX Spectrum. and sadly i have not much time now. but this surely will be fun, so i hope that i will be able at least help a little here and there. %-)

p.s. zymosis was written a long time ago in C, when i realized that there is NO Z80 emulator which is:
1. accurate.
2. does not need alot of tables to generate 400kb of shitty source code.
3. written by me. %-)

zymosis.d was just a quick port from C which i did in two or three evenings. one of the goals wal to see how easy it will be to port such a messy code, 'cause i'm planning to use D in my future projects and eventually port all my homebrew C libraries to D.

and when zymosis.d compiled first time it immediately passes almost all tests. very impressive. then i decided to announce the thing here — just in case if anybody will need such thing. there is no much sense to let it rotting on my hdd.

On 22 April 2014 00:45, ketmar via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>>> btw, what is the license for your code?
>>
>> I don't really care. Refer to it as much as you like.
>
> so maybe you will add license to sources? WTFPL, for example, which basically means "public domain". the thing is that sources without license are proprietary, and nobody except the author can do anything with that.

Yeah I know, I just never expected anyone else to take interest. I'm often torn between gpl and bsd/zlib.

If something's open source with no commercial intent, is there good reason not to use gpl? How hard is it to change later?


>> It might be fun to collaborate if you're interested...?
>
> i'm actually know only one vintage computer: ZX Spectrum. and sadly i have not much time now. but this surely will be fun, so i hope that i will be able at least help a little here and there. %-)

I've written a spectrum emulator. Good fun.
It could play games from cassette tape attached to the audio-in port ;)


> p.s. zymosis was written a long time ago in C, when i realized that there is
> NO Z80 emulator which is:
> 1. accurate.
> 2. does not need alot of tables to generate 400kb of shitty source code.
> 3. written by me. %-)

Yeah, I understand point 3. It's a good exercise to write an emulator, so a lot of people reinvent that wheel for the experience alone :)

On Tue, Apr 22, 2014 at 11:17:32 +1000, Manu via Digitalmars-d-announce wrote:
> Yeah I know, I just never expected anyone else to take interest. I'm often torn between gpl and bsd/zlib.

FYI, if you're using the free services on GitHub, it *must* be FOSS. I think the GitHub terms of service permit forking for public repositories regardless of the license[1].

> If something's open source with no commercial intent, is there good reason not to use gpl?

http://choosealicense.com/

> How hard is it to change later?

If you're the only author, you can change at will. If you accept contributions, you'll need everyone to agree (or rip their code out). You could go with a contributor agreement, but I'd advise against it. Personally, I refuse to contribute to projects which require handing copyright of my pathces over.

--Ben

[1]https://help.github.com/articles/github-terms-of-service §F.1