Jump to content
Nop90

Is 10 FPS a too low framerate for a LYNX tile based game?

Recommended Posts

A few years ago I had discussions with AtariAge people and we kind of agreed on a few more fields in the header. This is what cc65 tries to maintain today.
; ------------------------------------------------------------------------
; EXE header
        .segment "EXEHDR"
        .byte   'L','Y','N','X'                         ; magic
        .word   __BLOCKSIZE__                           ; bank 0 page size
        .word   0                                       ; bank 1 page size
        .word   1                                       ; version number
        .asciiz "Cart name                      "       ; 32 bytes cart name
        .asciiz "Manufacturer   "                       ; 16 bytes manufacturer
        .byte   0                                       ; rotation 1=left
                                                        ; rotation 2=right
        .byte   0                                       ; aud bits 1=in use for addressing
        .byte   0                                       ; eeprom
                                                        ; 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-5] - reserved - keep it to 0 for further usage
                                                        ; eeprom [6] - 0 - real eeprom, 1 - eeprom as a file in /saves/flappy.hi on SD cart
                                                        ; eeprom [7] - 0 - 16 bit mode, 1 - 8 bit mode
        .byte   0,0,0                                   ; spare

As you can see we even have an option for putting the eeprom in the /saves folder on a SD cart. I actually even have some dedicated binaries intended for the SD cart that could use this feature. But the SD firmware must support this and not turn off the controller after programming if the eeprom bit 6 is on.

Share this post


Link to post
Share on other sites

I also tried to run my homebrew games with handy v0.95 but no success with eeprom.

 

The sound is also horrible compared to Mednafen.

Share this post


Link to post
Share on other sites

update the emulator?

update to what?

 

Handy 0.95 should be the ltest.

 

Tried libretro (handy core) that creates an eeprom files on game start, but it's almost always empty. A cuople of times it had the correct values but it's cleaned on exiting the game.

 

I this situation I don't know if I'm doing something wrong, so I'm going to write a simple test code that I can share.

Share this post


Link to post
Share on other sites

Update:

 

analyzed the retroarch lynx core and it dumps the eeprom content on file only when the game is restarted or closed, but I think there is a bug in the closing code because there the eeprom is also cleared (probably to clear the state of the emulator), but this seems to happen before saving the eeprom content to file (so the saved content result always in a bunch of 0).

 

Since on starting/restarting a rom the emulator loads the eeprom file on memory, the cleaning part should be moved before the load eproom call to fix the problem.

 

Knowing this I tricked the emulator. Made a correct file save of the eeprom resetting the rom, changed the file name and closed the emulator. Than restored the filename and restarted the emulator and the gam: this way everything worked fine.

 

Now I know my code works as expected.

  • Like 2

Share this post


Link to post
Share on other sites

 

Finally found the updated repository https://github.com/bspruck/handy-fork

 

Compiled the sources with VS2017 and with this build the eeprom works fine.

 

Just a note, to compile the sources in VS2017, after retargeting the VS2015 project, had to add #include <windows.h> in eeprom.h for the definition of the min() macro.

 

if no one else does it, when I have time I'll open an issue in the retroarch repository for the eeprom bug in their build.

 

Other than this, game is finished, karri is testing it on real Lynx and I'm waiting for final graphics and musics. Than I'll start to share some preview images and maybe a video.

Share this post


Link to post
Share on other sites

 

A few years ago I had discussions with AtariAge people and we kind of agreed on a few more fields in the header. This is what cc65 tries to maintain today.
; ------------------------------------------------------------------------
; EXE header
        .segment "EXEHDR"
        .byte   'L','Y','N','X'                         ; magic
        .word   __BLOCKSIZE__                           ; bank 0 page size
        .word   0                                       ; bank 1 page size
        .word   1                                       ; version number
        .asciiz "Cart name                      "       ; 32 bytes cart name
        .asciiz "Manufacturer   "                       ; 16 bytes manufacturer
        .byte   0                                       ; rotation 1=left
                                                        ; rotation 2=right
        .byte   0                                       ; aud bits 1=in use for addressing
        .byte   0                                       ; eeprom
                                                        ; 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-5] - reserved - keep it to 0 for further usage
                                                        ; eeprom [6] - 0 - real eeprom, 1 - eeprom as a file in /saves/flappy.hi on SD cart
                                                        ; eeprom [7] - 0 - 16 bit mode, 1 - 8 bit mode
        .byte   0,0,0                                   ; spare

As you can see we even have an option for putting the eeprom in the /saves folder on a SD cart. I actually even have some dedicated binaries intended for the SD cart that could use this feature. But the SD firmware must support this and not turn off the controller after programming if the eeprom bit 6 is on.

 

 

I'm back on this thread to ask more info on bit 6 of the eeprom field in the header.

 

To make the SD cart save data on a file the bit 6 need to be set. but what if it's cleared. Maybe does the SD cart have an internal eeprom?

 

Is this bit ignored on emulators suporting eeprom saves?

Share this post


Link to post
Share on other sites

I have been testing the SD cart a little. What works seems to be to create files with 128 bytes in them and save them in /saves/flappy.sav

 

In your own code you need to include LynxSD.c and LynxSD.h

 

After that you can read the "eeprom" like:

if (LynxSD_OpenFile("/saves/flappy.sav") == FR_OK) {
    LynxSD_ReadFile((void *)eeprom_buffer, 128);
    LynxSD_Close();
}

And save the eeprom like:

if (LynxSD_OpenFile("/saves/flappy.sav") == FR_OK) {
    LynxSD_WriteFile((void *)eeprom_buffer, 128);
    LynxSD_Close();
}

All the eeprom's I have seen out in the wild are these 128 byte chips. So the code above should be inserted in the proper hobby builds to create SD aware games.

 

The bit needs to be correctly set to $40. Otherwise the code will hang. Same thing happens if the bit is falsely set to $40 but the game is coded for 93c46. The code will hang on the SD card.

 

Emulators need to catch up on this if you want it to work.

Edited by karri

Share this post


Link to post
Share on other sites

Thanks karri for your support.

 

If I understand what you're saying the sav file needs to be created when copying the rom in the SD. It's not atomatically created by the SD firmware detecting the bit set in the rom header. Right?

 

Is the lynxSD code safe for cart releases (or for rom played on emulators) ?

Share this post


Link to post
Share on other sites

I am still studying this. The best thing might be to add timeouts to the LynxSD code so that in case it does not work the software does not hang.

Share this post


Link to post
Share on other sites

Yes, the timeout should be placed in the while loop here

 

 

 
static u8 ReadByte()
{
    while (!(*IODAT & AUXMASK)); // wait for data in read FIFO
    return *CART0; // read byte
}
 

 

and another nice feature coud be to allow to go back to cart menu from homebrews (could be used the so long ignored Pause+Opt1+op2 combo :) ). Since the bit 6 of the eeprom field leave the cart MCU active, it should be possible to load back the second stage of the new menu, like the first stage does.

  • Like 1

Share this post


Link to post
Share on other sites

 

Yes, the timeout should be placed in the while loop here

 
static u8 ReadByte()
{
    while (!(*IODAT & AUXMASK)); // wait for data in read FIFO
    return *CART0; // read byte
}
 

and another nice feature coud be to allow to go back to cart menu from homebrews (could be used the so long ignored Pause+Opt1+op2 combo :) ). Since the bit 6 of the eeprom field leave the cart MCU active, it should be possible to load back the second stage of the new menu, like the first stage does.

 

 

 

I see you looked at the new menu code already, cool! It was a gamble on whether the second stage would work at all, glad it did. I agree that going back to the loader is a nice feature, it would have to be made in a way that works both on the Lynx SD and in emulators i.e. check if Lynx SD exists. I've talked to SainT about this and he said there's no real provision for detecting the SD cart. What could be done is trying to read the menu.bin file with a timeout in place. FYI here's a demo for Lynx SD I/O I put together - https://github.com/ikromin/atarilynx/tree/master/demo/lynxsd_io

Share this post


Link to post
Share on other sites

Made a quick and dirty POC of a homebrew that can return to SD cart menu.

 

It doesn't hangs on emulator, but is untested on the SD.

 

Code and lnx file in the zip attached. Please let me know if it works.

 

Note: SD timeout is implemented with a stupid counter in the loop in WriteByte() and Readbyte(). Probably the IO_TIMEOUT needs to be adjusted and the loop delayed with some dummy instructions.

SDTest.zip

  • Like 1

Share this post


Link to post
Share on other sites

I'll check this out when back home this weekend, unless Karri or someone else beats me to it.

Share this post


Link to post
Share on other sites

With the latest firmware made today I do get the screen saying press Opt1+Pause+Opt2 to return to the menu. Pressing these hangs the Lynx.

Share this post


Link to post
Share on other sites

at least the check file function with the timeout works fine on both sd cart and emulators.

 

The menu loading was taken fron Igor code without modifications. Probably it needs some tunings.

Share this post


Link to post
Share on other sites

The only big thing missing was closing the file after checking if it exists.

 

Please try the attached version.

 

If it doesn't work I'll have to wait for my SD cart for debugging.

SDTest.zip

Share this post


Link to post
Share on other sites

I've tried to load the LNX file and it gives me a corrupted screen...but I may be running a previous version of the firmware

Edited by necrocia

Share this post


Link to post
Share on other sites

Made sure I had the final release firmware and tried again and it still gives me a corrupted screen whenever I try to load the LNX file

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