Jump to content
sage

Further emulator development

Recommended Posts

Getting a bit annoyed by the bad situation with lynx emulators I started to patch and back port things to the handy original code.

Bad situation in the sense that it is nearly impossible to get bug-fixes or additional features into (mostly closed source) emulator code.

Nevertheless, all emulator code is derived from the original handy code, but in some emulators a lot of code changes have been applied.

But the original code is abandoned. And this is what I would like to change!

Now I have the hope that, IF we have a central place for the base code, we can advertise it and patches from there find their way to the respective emulators.

 

The following things are planned or already done:

* Full stereo 16 bit support (10 bit significant)

* Attenuation support (Lynx 2)

* Using second strobe as read on second bank (messed up completely in emulation)

* Use of AUDIN to switch banks (like in Alpine Games)

* lnx format extension to support AUDIN banking

* Using AUDIN + second strobe for read/write to EEPROM (save game)

* TWI EEPROMs (BLL save features)

* Everon bug-fix

* Split code base into "core" and "gui", remove windows dependencies from core

* Compile an up-to-date windows handy version

 

Repository will most likely be placed at github.

Comments and suggestions?

 

  • Like 5

Share this post


Link to post
Share on other sites

Sounds great. Could the repository be bitbucket/atarilynx? It is a group repository already.

Share this post


Link to post
Share on other sites

as its proposed to be public, it actually doesnt matter if I use github or bitbucket.

 

IMO it should not be a all in one repo. I would prefer to have emulation, tools and compilers seperated to make it easier to pick what you want.

 

BUt, what are your arguments?

Share this post


Link to post
Share on other sites

Everything you've listed is an improvement, especially the separation of the windows-specific portions of the emulator and proper stereo support.

However, just to be clear - will you be performing AUDIN and strobe emulation as discussed here?

 

The only missing improvement I can think of is a more stable framerate in Windows, especially when using DirectX. I have not looked at what Handy is exactly doing here since I started using an NTSC adapter to log video, but it constantly drops frames even on performant computers. Mednafen does not seem to have these issues.

Share this post


Link to post
Share on other sites

Everything you've listed is an improvement, especially the separation of the windows-specific portions of the emulator and proper stereo support.

Yes. Actually the in-code dependence is not so big, as the code with only a few patches is used in SDL handy.

 

However, just to be clear - will you be performing AUDIN and strobe emulation as discussed here?

 

 

 

More or less ;-)

First I fixed the bugs in the source code (second bank could never be working with that code) and added a way to use 4 banks with two strobes and AUDIN as additional (kind of) address pin.

 

The only missing improvement I can think of is a more stable framerate in Windows, especially when using DirectX. I have not looked at what Handy is exactly doing here since I started using an NTSC adapter to log video, but it constantly drops frames even on performant computers. Mednafen does not seem to have these issues.

 

 

 

Problem: Seems the directx/draw/sound stuff handy was compiled against has been dropped alltogether. at least I cannot get it compiled with VS 2015.

 

Which means at the moment I only can test the code changes with sdl-handy. but here banking and stereo (and 16 bit stereo that is) are working fine.

Share this post


Link to post
Share on other sites

Just to mention that in mednafen the code has been modified to a larger extend, thus a few bugs have been fixed "by accident" there. But it makes it now harder to port back any change.

 

I know that there was some guy who release a "handy 0.96/7" with some fixes, but I could not find the source code. But it seems that it could at least be compiled with _some_ version of VC then.

Share this post


Link to post
Share on other sites

We can have a separate repository for emulation. Currently there is already compilers in lynx/tools and other stuff like KiCad files, Raspberry Pi programmer sources in lynx/contrib.

 

So we go with github

 

I also have Atari Lynx emulator sources for at least PSP and probably Android somewhere.

Edited by karri

Share this post


Link to post
Share on other sites

I know that there was some guy who release a "handy 0.96/7" with some fixes, but I could not find the source code. But it seems that it could at least be compiled with _some_ version of VC then.

 

The available source for Handy will compile with Visual Studio 6. No idea what other versions it will cooperate with.

 

Share this post


Link to post
Share on other sites

I would like to propose libretro for the further improvements.

It is actively developed, it runs on most of the platforms with an unique emulator engine base, and the maintainers are quite keen on getting help.

The improvements will be available to all retroarch users, not only our limited subset.

And if you want to use your own ui, you can directly use the lib and not use their ui retroarch.

Edited by obschan

Share this post


Link to post
Share on other sites

I would like to propose libretro for the further improvements.

It is actively developed, it runs on most of the platforms with an unique emulator engine base, and the maintainers are quite keen on getting help.

The improvements will be available to all retroarch users, not only our limited subset.

And if you want to use your own ui, you can directly use the lib and not use their ui retroarch.

 

So, they are limiuted to ONLY retroarch users... thats exactly what I want to avaoid after my experiecnes with mednafen.

Thus your arguments are just contrary. Or I do not understand them.

  • Like 1

Share this post


Link to post
Share on other sites

How about creating a clean separation of the emulation core from the applications (Handy, Mednafen, etc.). Ideally there would be a standard interface that is provided or adopted from the core. One or more applications can be maintained together with the core to prove/test its functionality. We could look over compatibility and provide upgrades for others to adopt into their codebases.

 

BTW, I can help out with getting Handy to compile again against Visual C++ 2015 (or Visual Studio 2015). I will have a look. From memory I remember that you need to install the DirectX 9 SDK for the required libraries.

 

GadgetUK was the one who did some changes in the sound area, to get Gates of Zendocon sound during the spider section. It also has much cleaner sound. I have those sources and can check with him if it is okay for us to look at that and merge into the codebase if we want to.

 

Also, at the risk of being repetitive, there is also the cross-platform compatible .NET code in C# that I wrote. Apart from a yet unfound bug that causes STUN Runner to crash I believe there is a slightly better implementation of the emulation. It takes much of Handy's ideas, but has a more object-oriented approach. Also, it already has support for EEPROM for 93CX6 and ComLynx works from a single emulator app (up to 6 stable). I would love to hear ideas how we can use and improve that code (or choose it as our basis of further development perhaps :$ ).

 

I have looked at the repo you made, sage. Will start from there.

  • Like 2

Share this post


Link to post
Share on other sites

So, they are limiuted to ONLY retroarch users... thats exactly what I want to avaoid after my experiecnes with mednafen.

Thus your arguments are just contrary. Or I do not understand them.

How about creating a clean separation of the emulation core from the applications (Handy, Mednafen, etc.). Ideally there would be a standard interface that is provided or adopted from the core. One or more applications can be maintained together with the core to prove/test its functionality. We could look over compatibility and provide upgrades for others to adopt into their codebases.

 

This is what libtetro is. Retroarch is the separated ui. Libretro is an emulator engine library.

https://github.com/libretro/libretro-handy

Share this post


Link to post
Share on other sites

How about creating a clean separation of the emulation core from the applications (Handy, Mednafen, etc.). Ideally there would be a standard interface that is provided or adopted from the core. One or more applications can be maintained together with the core to prove/test its functionality. We could look over compatibility and provide upgrades for others to adopt into their codebases.

 

BTW, I can help out with getting Handy to compile again against Visual C++ 2015 (or Visual Studio 2015). I will have a look. From memory I remember that you need to install the DirectX 9 SDK for the required libraries.

 

GadgetUK was the one who did some changes in the sound area, to get Gates of Zendocon sound during the spider section. It also has much cleaner sound. I have those sources and can check with him if it is okay for us to look at that and merge into the codebase if we want to.

 

Also, at the risk of being repetitive, there is also the cross-platform compatible .NET code in C# that I wrote. Apart from a yet unfound bug that causes STUN Runner to crash I believe there is a slightly better implementation of the emulation. It takes much of Handy's ideas, but has a more object-oriented approach. Also, it already has support for EEPROM for 93CX6 and ComLynx works from a single emulator app (up to 6 stable). I would love to hear ideas how we can use and improve that code (or choose it as our basis of further development perhaps :$ ).

 

I have looked at the repo you made, sage. Will start from there.

No problems here! I think I left that version of the code a bit messy with bits commented out etc. And I am not sure the sound buffer sizing is still correct, I just fluffed it really to get it sounding better without really sitting down to think through whether the solution was accurate or not. The math side of the emulation in Handy isn't 100% there's still a bug there, perhaps regards timing on how long certain suzi operations take. Warbirds is a good example - the background rotates further / less than it should, and I suspect its a problem with timing related to suzi. EDIT: Also note, I added in 2 or 3 of the fixes that LX NET discovered as well - graphical bug fixes and the like.

Edited by GadgetUK

Share this post


Link to post
Share on other sites

codebase looks o.k., very close to original code.

the interface is a bit more abstracted.

i will have a closer look at it later.

Share this post


Link to post
Share on other sites
GadgetUK was the one who did some changes in the sound area, to get Gates of Zendocon sound during the spider section. It also has much cleaner sound. I have those sources and can check with him if it is okay for us to look at that and merge into the codebase if we want to.

My impression from the fixes on the sound system are mixed. Mostly a fix at one place breaks another game.

Also, at the risk of being repetitive, there is also the cross-platform compatible .NET code in C# that I wrote.

Yes, but i havent seen any update for a long time :-(

 

 

Apart from a yet unfound bug that causes STUN Runner to crash I believe there is a slightly better implementation of the emulation. It takes much of Handy's ideas, but has a more object-oriented approach. Also, it already has support for EEPROM for 93CX6 and ComLynx works from a single emulator app (up to 6 stable). I would love to hear ideas how we can use and improve that code (or choose it as our basis of further development perhaps :$ ).

I have looked at the repo you made, sage. Will start from there.

o.k.

Share this post


Link to post
Share on other sites

patches for libretro were straitforward... but the compile howto lacks important information.

I hate that.

Share this post


Link to post
Share on other sites

o.k. retroarch now has 16 bit stereo (well 2*10 bit ;-)

 

lets see the reaction on the pull request...

Share this post


Link to post
Share on other sites

o.k. retroarch now has 16 bit stereo (well 2*10 bit ;-)

 

lets see the reaction on the pull request...

I guess quick, because the fix has been merged. By obschan if I am not mistaken. Let's see if I can get it all to compile.

Edited by LX.NET

Share this post


Link to post
Share on other sites

compile did work immediately, but it was not so clear how to set a working configuration...

Share this post


Link to post
Share on other sites

pull request for audin switchable ROMS.

 

My main problem was testing here. You have to use lynxboot.img in the correct place, the internal "replacement" for the decryption will NOT work. Took me a while to find that out.

Share this post


Link to post
Share on other sites

Did you make some changes for lnx headers in order to tell the emulator that AUDIN is used for addressing the roms?

Share this post


Link to post
Share on other sites

yes. one bit of the 40 spare bits.

 

-> we discussed that two(?!?) years ago here somehow.

Share this post


Link to post
Share on other sites

yes. one bit of the 40 spare bits.

 

-> we discussed that two(?!?) years ago here somehow.

I was obviously at sleep during the discussion.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...