jarikomppa / emu8051 Goto Github PK

Just by looking at the list of features (forgive me for not yet delving deep into implementation details or the software itself), I think it would be nice if it also supported attaching a serial terminal with an arbitrary serial baud rate (since a lot of external components will use this), and an LCD component would be nice as well.

I'm having trouble with backspace not working. When in the file loading and breakpoint popups pressing backspace does nothing. Pressing delete works as expected.
I haven't looked into why but getch() returns 263 when i press backspace. Perhaps some locale setting...

Anyways, I made it work by also checking for KEY_BACKSPACE. Will create a pull-request.

Ok, I know this one is taking it far,
but would it be a nice idea to have an API that would allow creating custom serial port or I/O port components? In my eyes this would make this software infinitely more extensible and useful than most simulators

I'm using emu8051 as part of another project and I require custom savestates.
However, I can't just save or load the entire struct from file because it contains pointers.

I have additional devices and ROM banks anyway, so I mostly care about the CPU register state.
Therefore these fields should be in a struct, or at least next to each other:

That way, one could easily copy them to a file (for now, I'll individually write each entry to a file - I guess the benefit is that it allows to handle endianess correctly).

The parameter parsing code tries to parse "/foo" as an option, instead of as a path.

This appears to be for a seamless appearance in windows environments. Since this isn't documented anywhere (and since I think window's option syntax is stupid), I'd like to remove this.

If I understand your code right, there is a bug with the timing of instructions. The functions implementing the opcodes seem to return the number of cycles the instruction takes less one.

nop() (single cycle instruction) returns 0
div_ab() returns (four-cycle instruction) returns 3

The result then goes into the mTickDelay member of the aCPU variable.
When the tick() function is called, it first does the following check:

So if mTickDelay is already 0, it will not be decremented. Farther down, the opcode function is called because mTickDelay is 0.
If mTickDelay is 1 when the function is called, mTickDelay is first decremented, and with it being 0 after decrement, the opcode function is called as well. Therefore it makes no difference, if mTickDelay is 0 or 1 when tick() is called.

Unless I am missing a major point here (apologies if I do, but at the moment, I don't have an environment setup for C program step debugging as I am focusing on other languages, so I am doing this in my head), this basically turns 2-cycle instructions into single cycle instructions and 4-cycle instructions into 3-cycle instructions. Wouldn't the opcode functions have to return the actual number of cycles the instruction takes instead of one less?