Jump to content

Photo

Further emulator development

emulator handy xhandy sdl mednafen emu source

45 replies to this topic

#26 karri OFFLINE  

karri

    River Patroller

  • 2,365 posts
  • Location:Espoo, Finland

Posted Sun Jan 10, 2016 10:10 PM

Thank you. I had no memory of the outcome of this.

 

Currently I have no plans to use AUDIN for bank switching. I am using it for eeproms and controlling LED strips.

 

But it is nice to know that there is a way to extend memory if needed.

 

Currently there is no AUDIN bank switch support in cc65. Adding it as an extra top address pin is not trivial as we need to place the bootloader also in the middle of the ROM when AUDIN is high at startup. Because of this complexity I never tried to implement it.


Edited by karri, Sun Jan 10, 2016 10:55 PM.


#27 obschan OFFLINE  

obschan

    Chopper Commander

  • 168 posts
  • Location:Hong-Kong

Posted Tue Jan 12, 2016 6:43 PM

Thanks sage for your pull requests.



#28 Shannon OFFLINE  

Shannon

    Born To Be Insane

  • 7,792 posts
  • Pac-man Fever
  • Location:Arcade

Posted Wed Jan 13, 2016 1:49 AM

Nice to see some work being done to improve the lynx emulation.  I remember seeing the source code available for the following two fixes.  So I'm not sure what you are referring to.

 

Everon detection bug fix.  Fixes some display issues with Joust, Pong1k demo and the Wuerfel demo

Hardware bug emulation of SCB data ending exactly at last bit of shiftregister corrected.

 

These might have been in SDL Lynx.  Also Handy, Mednafen and Retroarch have always had sources available.

 

Is there an example of a game that uses stereo sound where the difference can be distinguished?

 


Edited by Shannon, Wed Jan 13, 2016 1:58 AM.


#29 sage OFFLINE  

sage

    Dragonstomper

  • Topic Starter
  • 913 posts
  • Location:Germany

Posted Wed Jan 13, 2016 10:44 AM

Nice to see some work being done to improve the lynx emulation.  I remember seeing the source code available for the following two fixes.  So I'm not sure what you are referring to.

 

Everon detection bug fix.  Fixes some display issues with Joust, Pong1k demo and the Wuerfel demo

Hardware bug emulation of SCB data ending exactly at last bit of shiftregister corrected.

 

Everon has nothing to do with the sprite unpacking.

 


These might have been in SDL Lynx.  Also Handy, Mednafen and Retroarch have always had sources available.

I dont get your point.

 


Is there an example of a game that uses stereo sound where the difference can be distinguished?

Sure there are examples. Any game that uses stereo fo "hearing" the direction. Battlewheels, Xenophobe. For music. Klax

For attenustion I am not sure, but I guess all homebrews which use mod player with attenuation. Maybe Klax.



#30 sage OFFLINE  

sage

    Dragonstomper

  • Topic Starter
  • 913 posts
  • Location:Germany

Posted Wed Jan 13, 2016 10:56 AM

and for the 8 bit downsampling: anything which has noiises with value 3 or less will result in no output in 8 bit mono.

no game as example, but you can try yourself with a small piece of code.



#31 Shannon OFFLINE  

Shannon

    Born To Be Insane

  • 7,792 posts
  • Pac-man Fever
  • Location:Arcade

Posted Wed Jan 13, 2016 4:06 PM

Weird.. I just remember when implementing the "everon" fix the Joust issues went away.. maybe it was sprite unpacking but the point is that whatever "mostly closed" source I got the the fix from worked.

 

I guess I misunderstood what you meant by "mostly closed" source.  Nothing ever prevented me from getting those fixes.

 

Thanks for the game examples..  I suspected Klax would be one.. that game has such great sound

 

I looked at your submissions to Mednafen (which he added by the way) and see what you mean.  The changes apparently seem to have made their way into Retroarch as well.



#32 sage OFFLINE  

sage

    Dragonstomper

  • Topic Starter
  • 913 posts
  • Location:Germany

Posted Thu Jan 14, 2016 8:42 AM

You are talking about my changes to menafen which took around 2? years to get included in the released version?



#33 Shannon OFFLINE  

Shannon

    Born To Be Insane

  • 7,792 posts
  • Pac-man Fever
  • Location:Arcade

Posted Thu Jan 14, 2016 8:56 AM

Yes I would be referring to those changes.  I hope I didn't confuse you too much.   :P


Edited by Shannon, Thu Jan 14, 2016 8:57 AM.


#34 sage OFFLINE  

sage

    Dragonstomper

  • Topic Starter
  • 913 posts
  • Location:Germany

Posted Mon Jan 25, 2016 3:15 PM

updates to retroarch are much much faster ... pull request accepted, buildbot delivers new core the next day... wow.



#35 sage OFFLINE  

sage

    Dragonstomper

  • Topic Starter
  • 913 posts
  • Location:Germany

Posted Tue Feb 9, 2016 2:24 PM

I implemented eeprom save features for 93c series in 8 and 16 bit mode. now, the question is, how to extend the lnx header to allow to set this information.

any suggestions?



#36 karri OFFLINE  

karri

    River Patroller

  • 2,365 posts
  • Location:Espoo, Finland

Posted Wed Feb 10, 2016 6:20 AM

The eeprom's are not linked to any "banks" so I really don't have good suggestions.

 

All cc65 libraries support only the 16bit read/write modes. And there is no support for "blocks". All access is one word at a time.

 

Would it be bad to just indicate the type of eeprom by the way it is accessed?

 

Take 1 byte from the "spares"

 

0 - no eeprom

7 - 93c46 16 bit mode (used in MegaPak I at least)

9 - 93c66 16 bit mode

11 - 93c86 16 bit mode

16 - 64k forgot the name of the chip 16 bit mode

 

The number comes from the total size 2^7 = 128, 2^16 = 64k

 

Our current 64kbyte eeprom is using a slightly different set of pins. The chips selects are completely in software. But the Lynx lacks the driver for this.

 

But on the other hand so far no developers have been using the 64k chip either. I have mainly shipped 2k 93c86 blank boards and 128 byte 93c46. Perhaps the 64k is overkill.


Edited by karri, Wed Feb 10, 2016 6:23 AM.


#37 sage OFFLINE  

sage

    Dragonstomper

  • Topic Starter
  • 913 posts
  • Location:Germany

Posted Wed Feb 10, 2016 1:44 PM

if the 64k chip has a different protocoll, i would not support it. the ocde for 93c46 to 93c86 is identical... well lets say, parametrizeable.

But I would need an additional bit for 8 bit access mode, which is used by lynxopoly (IMO).

I would not waste bit for unused chips, but at least 56,66,76 will come for free if we support 46 and 86.

 

[2:0]

0 - no eeprom

1 - 93c46 16 bit mode (used in Ttris, SIMIS, Alpine Games, ..., MegaPak I at least)

2        56

3 - 93c66 16 bit mode

4        76

5 - 93c86 16 bit mode

[3-6]

reserved - keep it to 0 for further usage

[7]

0 - 16 bit mode

1 - 8 bit mode

 

for the 64k chip. if I look into the schemtics you postet, its a I2C, not microwire interface, thus completely different protocol, right?



#38 sage OFFLINE  

sage

    Dragonstomper

  • Topic Starter
  • 913 posts
  • Location:Germany

Posted Wed Feb 10, 2016 1:46 PM

PS: And I would not make the pins configurable, because up to now all boards use A7 and A1 .



#39 karri OFFLINE  

karri

    River Patroller

  • 2,365 posts
  • Location:Espoo, Finland

Posted Thu Feb 11, 2016 12:58 AM

if the 64k chip has a different protocoll, i would not support it. the ocde for 93c46 to 93c86 is identical... well lets say, parametrizeable.

But I would need an additional bit for 8 bit access mode, which is used by lynxopoly (IMO).

I would not waste bit for unused chips, but at least 56,66,76 will come for free if we support 46 and 86.

 

[2:0]

0 - no eeprom

1 - 93c46 16 bit mode (used in Ttris, SIMIS, Alpine Games, ..., MegaPak I at least)

2        56

3 - 93c66 16 bit mode

4        76

5 - 93c86 16 bit mode

[3-6]

reserved - keep it to 0 for further usage

[7]

0 - 16 bit mode

1 - 8 bit mode

 

for the 64k chip. if I look into the schemtics you postet, its a I2C, not microwire interface, thus completely different protocol, right?

 

Yes the protocol is completely different. I suggest we skip it for the present. The price of the chip is in the same range as the 512k flash and so far no drivers exist. It was just a suggestion on the forum.

 

I still like the idea of using bits 0:4 for describing the 2's power (size) of the chip. And use bit 7 for 16/8 bit. It still takes just one byte. It still leaves bits 5 and 6 free for extensions.


Edited by karri, Thu Feb 11, 2016 1:05 AM.


#40 sage OFFLINE  

sage

    Dragonstomper

  • Topic Starter
  • 913 posts
  • Location:Germany

Posted Tue Feb 16, 2016 2:24 PM

typedef struct
{
  UBYTE   magic[4];
  UWORD   page_size_bank0;
  UWORD   page_size_bank1;
  UWORD   version;
  UBYTE   cartname[32];
  UBYTE   manufname[16];
  UBYTE   rotation;
  UBYTE   aud_bits;
  UBYTE   eeprom;
  UBYTE   spare[3];
}LYNX_HEADER_NEW;

where

aud_bits [7:1] - undefined, keep zero for further extension

aud_bits [0] - 0 no audio banking , 1 audio banking (same size as bank0/bank1)

 

eeprom [2:0] -

0 - no eeprom

1 - 93c46 16 bit mode (used in Ttris, SIMIS, Alpine Games, ..., MegaPak I at least)

2        56

3 - 93c66 16 bit mode

4        76

5 - 93c86 16 bit mode

(remark: size in bits is 2^(value+9) -- (please recheck!)

eeprom [3-6] - reserved - keep it to 0 for further usage

eeprom [7] - 0 - 16 bit mode, 1 - 8 bit mode

 

Remark: UWORD is intel endianess as in original handy code. beware if code compiles on other platforms


Edited by sage, Tue Feb 16, 2016 2:29 PM.


#41 sage OFFLINE  

sage

    Dragonstomper

  • Topic Starter
  • 913 posts
  • Location:Germany

Posted Fri Feb 19, 2016 2:09 PM

It would be nice if someone can verify the EEPROM support. Code is ugly but working. Cleanup is still needed.

I tried my own test cart as well as Alpine Games. But main problem is, that carts which use EEPROM contain additional emulation detection code (SIMIS, Alpine Games, ...) thus its not so easy to verify.

 

EEPROM content will not be saved to "emulator savestates", thus until now its not so usefull yet.

 

I only patched sdl-handy yet.

https://github.com/b...andy-sdl-master

 

libretro will follow as soon as I get some feedback.



#42 LX.NET OFFLINE  

LX.NET

    Dragonstomper

  • 750 posts
  • Location:The Netherlands

Posted Sun Feb 21, 2016 5:26 AM

It would be nice if someone can verify the EEPROM support. Code is ugly but working. Cleanup is still needed.

libretro will follow as soon as I get some feedback.

I have scheduled some time today. Will get back as soon as I have results



#43 LX.NET OFFLINE  

LX.NET

    Dragonstomper

  • 750 posts
  • Location:The Netherlands

Posted Sun Feb 21, 2016 11:18 AM

Created a pull request for github.com/bspruck/handy-fork with fixes for Visual Studio 2015 build of Handy (including handybug.exe).

Now onto the SDL version and my own emulator.



#44 sage OFFLINE  

sage

    Dragonstomper

  • Topic Starter
  • 913 posts
  • Location:Germany

Posted Sat May 12, 2018 2:48 PM

I pushed read/write eeprom (to a file) support to repository. This means now the eeprom is preserved between restarts of the emulator.

sdl-handy iw roking nice with that, retroarch/libretro too.

I have not compiled handy on windows with up to date Visual Studio, thus no binary distribution at the moment.

dl -> github.com/bspruck/handy-fork

 

PS: official libretro is already updated, the fix should be in the next release and/or core update



#45 Turbo Laser Lynx OFFLINE  

Turbo Laser Lynx

    Moonsweeper

  • 402 posts
  • Location:Finland

Posted Mon May 14, 2018 4:16 AM

Thanks for this sage, very nice. :thumbsup:



#46 sage OFFLINE  

sage

    Dragonstomper

  • Topic Starter
  • 913 posts
  • Location:Germany

Posted Mon May 14, 2018 2:13 PM

beware, this saved eeprom states are not transferable between different endianess systems, aka PC and ARM. Well not quite, as for 8 bit access EEPROM it works, but not for 16bit.

 

seems I have to fix that ... it annoys me.


Edited by sage, Mon May 14, 2018 2:17 PM.






Also tagged with one or more of these keywords: emulator, handy, xhandy, sdl, mednafen, emu, source

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users