New emulator "Felix" - help needed

[laoo]

Hello there!

What do you think about the idea to try to create a new Lynx emulator? Because let’s face it. Handy, to put it mildly, has few shortcomings. It’s old, hardly maintainable and it isn’t precise enough to meet today’s standards. Practically every console nowadays has a decent emulator except Lynx (even such niches like Neo Geo Pocket, Wonderswan etc).

Some time ago during pandemic lockdown I decided to toy with the idea. Partly as a C++ exercise and to find how hard it is. General premise was to make a foundation for an emulator that will (unlike Handy) emulate our handheld in cycle exact manner. I was writing it for around half a year now with long breaks (actually May-July 2010 and May-August 2021) and have something that isn’t production ready, but I’ve decided that it’s stable enough to be shown to you.

I’m not good with naming things so it stuck with an abbreviation of “Felis lynx” so here it is: Felix.

It still needs much fiddling and tuning but the effect so far is in my opinion quite satisfactory: screen DMA is processed per byte so it is possible to change palette in the middle of the line, sprite blitting can be interrupted, etc. It happily emulates everything what we wrote (our games and demos work great. Actually it’s the answer to how we manage to generate good quality video of “Unlit” as obviously Handy can’t emulate GameDrive), some things work better than in Handy, but there are still many ROMs that do not work properly or even at all. I know about some glitches in many productions (e.g. @42bs' demo0006.o fails miserably and I don't know how to debug it), also many games written in cc65 crashes or does strange things. But frankly I don’t have the necessary resources to investigate it all and pin the bugs down in a reasonable time-frame (I have my real life, work, and such). Hence this call for help.

If some of you will be willing to take some time to run some ROMs and notice in systematic way what, when and where is wrong it would be appreciated. If programmers would run their own ROMs and maybe investigate what fails it would be great. Generally every feedback counts.

It will change, but for time being:

• Emulator core is written in standard/portable C++20 (hm, actually this won’t change).
• I’m a Windows programmer and currently only implementation is as an ordinary Windows application that uses the core emulation library.
• I’m a lazy Windows programmer and am using DirectX 11 for video processing, so the emulator needs a Windows machine that was decent about 10 year ago.
• There is no UI. You just run the emulator with a cartridge image as a program argument or drag&drop image file to the emulator's window.

Currently there is no debugger, but there are some tracing facilities. Felix embeds Lua interpreter and besides LNX/LYX/O images it accepts LUA script with definitions of the form:

 

lnx = "full/path/to/image/file";

Log{ path = "full/path/to/trace/file.log" };

 

There are few more, but it’s too internal to write about it at this point.

The project is located on github

Latest release

Before someone asks: I obviously drew inspiration from source code of Handy and @LX.NET’s emulator written in C#. Maybe I even copied a few lines, don’t remember exactly. Nevertheless the code has an MIT license. It compiles under Microsoft Visual Studio Community 2019. Externally it needs only boost (currently 1.77) and uses some other github projects namely imgui, libwav, lua and sol2.

Not sure what to write more at the moment, so please try the emulator and give me some feedback!

Edited November 5, 2021 by laoo

[42bs]

Just checked some of my old and upcoming 249byte demos. And most of them do not work at all.

For example NOISE does not work.

But ROTZ works tough w/o sound.

[42bs]

Hmm, could it be, that you do load and decrypt .lnx file w/o the ROM?

It seems screen base (FD94/5) is at $0000.

 

Also, writing the low byte of most SUZY registers clears the high byte.

Edited October 25, 2021 by 42bs

[laoo]

3 minutes ago, 42bs said:

Hmm, could it be, that you do load and decrypt .lnx file w/o the ROM?

It seems screen base (FD94/5) is at $0000.

Yes. I do not use original ROM.

But I could easily initialize hardware withe the same values as the ROM does.

Edited October 25, 2021 by laoo

[42bs]

Just now, laoo said:

Yes. I do not use original ROM.

But I could easily initialize hardware withe the same values as the ROM does.

This would not work, as the zero page contains different values depending on the decrypted contents.

So it would be easier to run the original ROM.

 

 

[laoo]

6 minutes ago, 42bs said:

Also, writing the low byte of most SUZY registers clears the high byte.

I was implementing it. There might be bugs though.

[laoo]

1 minute ago, 42bs said:

This would not work, as the zero page contains different values depending on the decrypted contents.

So it would be easier to run the original ROM.

You're right. If your code depend on the content of the RAM after decryption it needs to be run on original ROM. I don't embed it obviously. Few months ago there was ability to run emulator with two files - ROM image and cartridge image but I disabled it recently because I haven't thought about your scenario. I'll reenable it then

[42bs]

Math Timing
Multiplies with out sign or accumulate take 44 ticks to complete.
Multiplies with sign and accumulate take 54 ticks to complete.

I think the "and" is not an exclusive and (like &&) but rather an "or". oid SuzyMath::mul( uint64_t tick ) { mFinishTick = tick + ( ( mSignMath && mAccumulate ) ? 54 : 44 ); mOp = Op::MULTIPLY; } So it should be mSignMath || mAccumulate IMHO.

[Fadest]

Thanks,

 

Will give it a try on my current projects.

Does it handle EEprom saves ?

[laoo]

24 minutes ago, 42bs said:

Math Timing
Multiplies with out sign or accumulate take 44 ticks to complete.
Multiplies with sign and accumulate take 54 ticks to complete.

I think the "and" is not an exclusive and (like &&) but rather an "or". oid SuzyMath::mul( uint64_t tick ) { mFinishTick = tick + ( ( mSignMath && mAccumulate ) ? 54 : 44 ); mOp = Op::MULTIPLY; } So it should be mSignMath || mAccumulate IMHO.

Hm... It seems you're right. The wording is slightly unfortunate.

 

BTW. I've checked and I haven't disabled the usage of original ROM. Just run the emulator with two files eg. Felix.exe lynxboot.img image.lnx and it should run with supplied ROM.

 

11 minutes ago, Fadest said:

Thanks,

 

Will give it a try on my current projects.

Does it handle EEprom saves ?

I haven't gotten around it yet, but it should definitely be on the TODO list. You can add an issue request to not forget about it.

Edited October 25, 2021 by laoo

[laoo]

@42bs Here's the quick patch for math timing... I was hoping that demo0006 will magically start to work, but sadly that's not it

 

 

 

 

Edited October 28, 2021 by laoo
Removed obsolete executable.

[42bs]

8 minutes ago, laoo said:

BTW. I've checked and I haven't disabled the usage of original ROM. Just run the emulator with two files eg. Felix.exe lynxboot.img image.o and it should run with supplied ROM.

Now most 249 intros work. One that uses heavily math (but no sprites) doesn't.

I will clone the project and check if I can compile and run.

[42bs]

6 minutes ago, laoo said:

@42bs Here's the quick patch for math timing... I was hoping that demo0006 will magically start to work, but sadly that's not it

 

 

Felix_0.4.1(3G01a2ccc).exe 920.5 kB · 1 download

Tried it with above mentioned demo and still does not work.

 

new_bll/demos/apfel_2a.o does also not work. Display is completely corrupted (XOR sprite does not work!).

Edited October 25, 2021 by 42bs

[laoo]

@42bs I'm pretty sure the demo0006 does not work due to bugs in suzy math and not triangle drawing, because st-nicc works w/o problems.

 

So apfel_2a.o uses XOR sprites. I haven't tested it really and it seems that it does not work

[42bs]

2 minutes ago, laoo said:

@42bs I'm pretty sure the demo0006 does not work due to bugs in suzy math and not triangle drawing, because st-nicc works w/o problems.

Think so. The demos which do not work correctly use mainly Suzy math.

[+karri]

What a nice idea to have an updated emulator.

 

[42bs]

Ok, a quick debug session did not reveal what is going wrong.

I guess I will have to make some test cases which use all the dirty tricks ?

[laoo]

11 minutes ago, 42bs said:

Ok, a quick debug session did not reveal what is going wrong.

I already spent few hours debugging demo0006, but it's logic is too complicated. Maybe something trivially reproducible (deterministically rotating triangle or something) could help.

 

11 minutes ago, 42bs said:

I guess I will have to make some test cases which use all the dirty tricks ? 

The more dirty tricks, the better ?

Edited October 25, 2021 by laoo

[42bs]

new_bll/demos/drawtest.o

You can skip through the parts with a button. Last is a rotating square. Means at max 4 triangles.

[Fadest]

First tests :

Ynxa & Raid on TriCity seems to freeze on the screen where EEProm is checked. Need to make more tests, but I guess either I have a bad header (as I usually don't care about EEprom on emulators, and don't need header on real card...), either it is the read/write function which freez.

 

With Space Lock from Yastuna 2, I have very strange behaviour for my sprite : sometimes they move in the wrong direction avec make silly things, they redisplay at the righ tposiiton. I guess this is due to the mirror flag or my sprite descriptor.

 

Example :

First level, I moved the red ship to the left (to the direction of the center of the playfield)

Second level, I first moved it to the right, then to the left.

Left & right use the same sprite, mirrored, not dure I am doing really touchy things apart this (this was kind of my first Lynx program)

 

[Fadest]

OK, I don't know why I can't post the animated GIF here, I will send it to you on Discord

 

[+karri]

I just tried some of my games. They work well up to the point when they try to write on the eeprom. The sound seems to work very well and the speed is great.

 

PS. the controls are X, Y and cursor keys. No idea what to press for Opt1, Pause, Opt2

[Fadest]

On my french keyboard, it is 1 (Opt 1), 2 (Pause) and 3 (Opt 2) keys with or without Capslock (so &, é and " works also :D)

[laoo]

Indeed the keys are 1, 2 and 3. I thought that Handy is using these keys.

 

@42bs I've found a bug in multiplication thanks to @Fadest's sample code. I'm not sure it's the only bug, but probably not. I'll try to fix it today.

[Songbird]

This looks very cool!

 

For me to use it, I would want a debugger with breakpoints, memory read/write, and step functions at a minimum. Handy is far from perfect, but at least I can step through assembly and see what's going on when something doesn't work properly.