Further emulator development

[+karri]

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 January 11, 2016 by karri

[obschan]

Thanks sage for your pull requests.

[Shannon]

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 January 13, 2016 by Shannon

[sage]

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.

[sage]

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.

[Shannon]

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.

[sage]

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

[Shannon]

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

Edited January 14, 2016 by Shannon

[sage]

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

[sage]

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?

[+karri]

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 February 10, 2016 by karri

[sage]

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?

[sage]

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

[+karri]

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 February 11, 2016 by karri

[sage]

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 February 16, 2016 by sage

[sage]

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.

[LX.NET]

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

[LX.NET]

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.

[sage]

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

[Turbo Laser Lynx]

Thanks for this sage, very nice.

[sage]

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 May 14, 2018 by sage

[mikewilkinson]

Does anyone know why this want run for me? all I get is a blank screen and a sound as if the emulator is turning off and on. In fact I couldn't get any version of the development running. Please help. TYVM  

 

FYI: I can run Handy just fine.