Hi emulator developers / Z80 gurus! Would you please take a look at this?

Paragon (1172)

03-09-2014, 16:57

So one day I was doing I don't remember what, and then a weird idea came to my mind... well, read the whole story here:

https://bitbucket.org/konamiman/z80dotnet

It would be great if the fellow MSXers reading this, especially emulator developers and Z80-savvy people, take a look at this (proto-)project if only to point blatant design mistakes or just to make improvement suggestions. Anyone should be able to understand the code, even with no previous knowledge of C#.

And don't worry... Nextor is still my top priority. But I had to take this off my head. :)

By Grauw

Ascended (10577)

03-09-2014, 18:56

Looks nice. I’m thinking what it could be used for. Maybe write a simple BDOS implementation and run MSX-DOS utilities on the PC / Mac. Or baking results of Z80 algorithms, for use in build tools to improve runtime performance without having to reimplement (and keep in sync) the algorithm in another language.

As for feedback, the Memory getter returns an array of bytes, this seems like it would not interact well with memory mapping, or at least not efficiently. Better to have a pluggable interface for memory regions, with a simple 64K default / example implementation which then does provide peek/poke and block peek/poke methods. I also think it’s practice not to use C# getters for things that are computationally expensive.

By konamiman

Paragon (1172)

03-09-2014, 22:05

Hi Grauw, thanks for your feedback! Actually something similar to the BDOS emulator that you mention exists already. It's a program named CPM32.EXE that allows to execute CP/M code in Windows, I use it to compile Nextor with the M80 assembler. Indeed, it would be nice to have the same for MSX-DOS.

The byte array returned by the memory getter is not computed, it is just a reference to an actual plain byte array with 64K items. Memory access is performed by simply reading and writing from this array, but the value that is actually processed can be modified from within the memory access event.

The idea then is that when a mapped memory segment / ROM segment / slot page is switched, the appropriate 16K (or 8K, or whatever) area int the memory array is overwritten with the new contents (taking first a backup of the existing contents, if it's RAM). Yes, copying data around is not a very good practice, but we're talking about copying at most 64K bytes, which is not that much for a modern machine IMO (I could be wrong, of course).

Anyway your idea of explicitly providing code to manage certain memory areas is not at all a bad idea, areas with no code assigned could default to simply accessing the byte array.

By Grauw

Ascended (10577)

03-09-2014, 22:59

Something like:

interface Memory {
    public byte get(short address);
    public void set(short address, byte value);
    public byte[] getBlock(short start, short end);
    public void setBlock(short start, byte[] values);
}

class PlainMemory implements Memory {
    private byte[] = new byte[65536];
}

class Z80Processor {
    private IMemory memory = new PlainMemory();
    public void setMemory(IMemory memory) { … }
}

Then it’s easy to e.g. create a ROM memory implementation, or a slot selection implementation with 16 pluggable items, or a memory mapper implementation, etc.

By konamiman

Paragon (1172)

04-09-2014, 14:16

I like the idea! Besides, the C# indexer syntax allows to access single values as if the object was actually an array: byte x = z80.Memory[address] instead of byte x = z80.Memory.Get(address).

In fact I like it so much that I have "implemented" it in the lunch break. Go and check the last commit.

By anonymous

incognito ergo sum (116)

04-09-2014, 14:56

Dotnet? why???

What about people using a decent OS?

By konamiman

Paragon (1172)

04-09-2014, 15:22

Because:

Starting at version 7, Windows is a pretty decent OS. Really.
You are not constrained to Windows when using .NET. There's the Mono project, with which it should not be too hard to ensure compatibility for this particular project.
In the Real World (TM) I'm a C# programmer. So if I develop something non-MSX, it will be in C# (unless it's something very simple that can be done in standard C, such as the Nextor's ROM builder). I'm very sorry but I really don't have the time to learn more languages / OSes / IDEs / frameworks.
Similar projects exist already outside the .NET world. See for example here: http://sourceforge.net/projects/libz80

...and basically because the idea that popped in my mind was not like "What if I develop a Z80 simulator in python?" (which I don't doubt that for sure would be quite fun too). Sorry. :)

By anonymous

incognito ergo sum (116)

04-09-2014, 17:01

MONO does not work very well in some circumnstances and it still implies supporting a Microsoft technology (regardless the fact the it isn't open, free, etc.).

Anyway, the good point of this is that if you program it in C# it should be easy to port to Java (not my favourite language either, but at least it's a bit more standard, open, etc.).

By konamiman

Paragon (1172)

04-09-2014, 17:18

C# is 100% open and standard: http://www.ecma-international.org/publications/standards/Ecm... . Developed by Microsoft? Yes, but why should that be a problem?

In which circumstances does exactly Mono (which is by the way an open source project) not work very well, other than it does not support certain .NET technologies that are not needed for a CPU simulator (http://www.mono-project.com/docs/about-mono/compatibility)? Honest question, I know very little about this project.

And as for porting the project to Java, if someone does that (provided that I really finish the C# project some day, of course) I would be more than happy. The more options the better.

By anonymous

incognito ergo sum (116)

04-09-2014, 17:16

8-O

Didn't know that C# was standardized! Shocked.

About the Java port, it should be easy really. The big difference is the lack of struct-like data types in Java, although it can be easily transformed to regular classes.

Being able to execute Z80 code on modern platforms can be very useful (e.g. running PMEXT from the Windows command line).

By mars2000you

Enlighted (6216)

04-09-2014, 17:21

You don't need to run PMEXT from the Windows command line, you need only to use Bandizip :

http://www.bandisoft.com/bandizip/en/