Jump to content
IGNORED

Further emulator development


sage

Recommended Posts

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
Link to comment
Share on other sites

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
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 2 weeks later...
  • 2 weeks later...

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
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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
Link to comment
Share on other sites

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/bspruck/handy-fork/tree/master/handy-sdl-master

 

libretro will follow as soon as I get some feedback.

Link to comment
Share on other sites

  • 2 years later...

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

  • Like 3
Link to comment
Share on other sites

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
Link to comment
Share on other sites

  • 3 years later...

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...