Reicast-emulator: Dreamcast bios parameters are not saved

[legluondunet]

Hello,

when I launch Reicast, the Dreamcast bios asks me to set the date and time.
I can also set the language in the bios settings.
But this settings are not stored at the next Reicast launch.
Is there a way to store the bios settings? The Dreamcast date and time could be synchronize with the computer ones and the language precised by Reicast?

Regards.

LGDN.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[sergiobenrocha2]

Happening to me too, wondering if I'm a noob or it's reicast fault.

[Holzhaus]

I can reproduce this too.

[mac1202]

I got the same problem, could someone tell us if it's the normal behavior (feature not yet supported) or if something is wrong with our setup.

[7oxicshadow]

This issue only happens on Linux I believe.

I have fixed it in one of my PR's.

The reason for this bug is that (currently) the linux client does not exit cleanly and just halts execution. This means that it does not call the routines to save the NVRAM which results in no date and time being saved.

The PR is called "Allow Linux build to close cleanly" PR#917

[mac1202]

Ok thanks for yout explanation.

[Veyrdite]

Link: https://github.com/reicast/reicast-emulator/pull/917

[goigle]

What's the status on this?

[7oxicshadow]

@goigle if you build your own you could use my branch if you want a temporary fix. It contains all of my fixes for this problem and should be upto date with the current reicast master.

https://github.com/7oxicshadow/reicast-emulator

[legluondunet]

@7oxicshadow : thank you, but there is a problem to integrate your fix to the master branch? not enough tested? not enough stable?

[AbandonedCart]

@legluondunet Blame Github and the new collaboration structure. It is now a tedious process to merge anything. I found the PR, but still need to test it against other platforms.

[skmp]

(Turned reviews off today, dhould be eady to merge things again)

On Sun, 4 Jun 2017 at 19:42, TwistedUmbrella [e-mail]
wrote:

@legluondunet https://github.com/legluondunet Blame Github and the new
collaboration structure. It is now a tedious process to merge anything.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/reicast/reicast-emulator/issues/863#issuecomment-306055076,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAYAMnN9d6ivHebkw4m0QTZbvLKuvmA8ks5sAuxugaJpZM4GhtXH
.

>

~skmp

[AbandonedCart]

@skmp lol, thanks. It should be able to accept outside reviews for someone with write access to merge. That seems to be the major flaw. Not every tester has write access.

[sl1pkn07]

i get this in https://github.com/7oxicshadow/reicast-emulator

/tmp/makepkg/reicast-emulator-git/src/reicast-emulator/core/linux-dist/main.cpp: In function 'int main(int, wchar**)':
/tmp/makepkg/reicast-emulator-git/src/reicast-emulator/core/linux-dist/main.cpp:509:20: error: 'evdev_controllers' was not declared in this scope
                 if(evdev_controllers[port].fd >= 0)
                    ^~~~~~~~~~~~~~~~~

[7oxicshadow]

@sl1pkn07 I have enabled the issue tracker on my branch so that you can create a bug there. You need to check your makefile has USE_EVDEV set to 1. It is located in the shell/linux folder.

[sl1pkn07]

that's is. now build ok and works!

thanks!

PS: cmake shell need add this option into options. i'm working on it

[7oxicshadow]

Glad you got it working. Setting the Dreamcast clock gets annoying pretty quickly....

I am guessing if you are using cmake to generate the makefile it would explain why it was set to 0.

For new users attempting to build it should just be as simple as cloning my branch, change directory to the shell/linux folder and then type make.

Assuming you have the correct dependencies the file should compile and the binary will be located in the same folder.

[metekamil]

I built this fork but no luck with the date/time. :(

[Flupper]

@7oxicshadow
Many thanks for fixing this, tested working 100% on Manjaro KDE x86_64.

[metekamil]

I'm running this on the Pi3, still had date time. Is there a specific bios release it should be using?

[sl1pkn07]

└───╼  sha256sum dc_flash.bin dc_boot.bin 
dd8b365521a9c08bb4c170da3592212580f7251f35a45d6083774d1c030bc3e3  dc_flash.bin
88d6a666495ad14ab5988d8cb730533cfc94ec2cfd53a7eeda14642ab0d4abf9  dc_boot.bin

from european dreamcast

[metekamil]

I verified the bios sum, its the same. Rebuilt with this fork. Still get the date/time (even after setting and exiting). Does anyone know which file the data/time is saved to?

[7oxicshadow]

@metekamil Did you have any other version of reicast installed before you built this branch? Can you confirm that you are definitely launching using ./reicast.elf and not just typing reicast into terminal?

[metekamil]

i'm using attract mode. I deleted the old version of the emulator and launched to make sure it didn't launch. I copied the reicast generated from sudo make install under /usr/local/bin to the correct location. Re launched the emulator and tested. I'm not using an elf file, but the filesize is the same as the reicast file that was built under /usr/local/bin. I deleted it and rebuilt to insure it was the latest build under /usr/local/bin. File size is 16393980. I did have to update the make file to work on the pi3 (it is running the pi2 make code).

[metekamil]

@7oxicshadow ^ and thanks!

[7oxicshadow]

@metekamil Out of curiosity, if you have the time, can you do clean build, but instead of doing a make install. can you just try running reicast.elf from inside the shell/linux folder?

[7oxicshadow]

@metekamil I just realised something, How are you exiting reicast? The bios is saved if you exit by pressing the escape key or by closing the window. I suspect that attract mode terminates it differently

[metekamil]

I ran the elf file from the terminal, from where the make script was executed. The emulator ran very slow (probably because it didn't find my config settings). It went straight to the dreamcast console with the 4 system options. It did NOT prompt me for date time! :) BUT...I couldn't control anything using my joysticks (this is on an arcade with an attached keyboard). I proceeded to copy the elf file to where I usually run the emulator. I ran the reicast joystick tool and ran the emulator with the usual parameters. It then prompted me for date/time. I went back to the original location and ran the elf file with not parameters same as usual, it then prompt me with the date/time. I'm trying to figure out what files the reicast-joystick updated/added. So I can clear those out. It seems that the joystick tool causes the date/time to prompt going forward....(I'm stubborn so I'll probably keep trying to figure this out) ..,

[metekamil]

Also the escape key does not do anything with the keyboard plugged in. That was another reason why I ran the joystick tool. To make sure it was setup correctly. I currently hit a button which instantly exits. The console for reicast (running from a macbook via ssh, does not show any messages when I exit. It just quits instantly. So chances are thats an issue also.

[metekamil]

The joystick has an option to setup exit, however it does have a keyboard config menu. I may try that and make sure to setup the escape key, just in case it specifically checks for the escape button in the code.

[7oxicshadow]

@metekamil Just to give you an idea. The following should be seen in the terminal on exiting correctly

start_shutdown called
rend_terminate called
ngen thread stopped
main loop ended
recSh4 Term
Sh4 Term
Saved /home/toxicshadow/.reicast/data/dc_nvmem.bin as nvmem

closing any open controllers
Destroy GL Context
Destroy X11 Window

The nvmem line is the most important :) Assuming your joystick program doesn't delete dc_nvram.bin it shouldnt ask for the date/time on subsequent runs.

[metekamil]

Thanks for that info! 👍 Yeah its definitely not doing that :) I'll figure out how this attract mode can cleanly exit, thanks again!

[metekamil]

....Will let you know....

[metekamil]

VREG = 03 ARMRST 00
ALSA: underrun occurred
ALSA: underrun occurred
DIV32S matched 1% @ 0x8C091086
DIV32S matched 100% @ 0x8C09108C
div32s 1/0/3
ALSA: underrun occurred
DIV32S matched 1% @ 0x8C0911E4
DIV32S matched 100% @ 0x8C0911EC
div32s 1/0/3
DIV32S matched 1% @ 0x8C09126E
DIV32S matched 1% @ 0x8C091278
VREG = 03 ARMRST 01
VREG = 03 ARMRST 01
VREG = 03 ARMRST 00
ALSA: underrun occurred
ALSA: underrun occurred
DIV32S matched 1% @ 0x8C0294A6
DIV32S matched 100% @ 0x8C0294AC
div32s 1/0/3

Yeah this is all I see before it quits...

[7oxicshadow]

I have been looking around and it seems that others have been having issues with the RTC not saving even though they are using my build so I have been doing some testing.

I have confirmed that my build works on Linux desktop x86_64 (standalone)
I have confirmed that my build works on Raspberry Pi 2 (standalone)
I have confirmed that my build does NOT work with RetroPie

This was all very confusing as there is no reason for it to not work if you are using a front end launcher. After much head scratching I started to dig around the RetroPie launch script. It appears that they are using the command line to configure the home directory and joypads which Reicast has support for using the -config command.

I have confirmed that if i remove the command line parameters from the RetroPie script, my code works as expected and the RTC problem is resolved....but the joypad no longer works :(

After spending the past couple of days digging around the Reicast code it appears that using the -config command line parameter forces reicast to use a "virtual" config and ignores the config file stored ~/.reicast folder.

There are 2 conditions that cause the RTC to fail:

• A valid dc_nvmem.bin file doesn't exist
• There is no "Dreamcast.RTC" entry in the emu.cfg file.

It appears that the creation of a virtual cfg causes condition 2 to fail. As of yet I have no solution to RetroPie. It would be better if the RetroPie team were to modify the emu.cfg directly rather that relying on the command line options as it would eliminate the issue all together.

If anyone is having problems with my build on any frontend I would recommend check the launch parameters that are being passed. I will keep digging around the source code but I don't think this will be easy to solve without breaking the concept of "virtual" configs.

[substring]

The behaviour is veeeery strange ... Despite i just can't find a step by step, there is 1 thing I am sure of : the RTC is not always saved to the dc_nvmem.bin despite showing the message on the output. I have a dc_nvmem.bin for which time is set "for good". If I remove it, let reicast create a new one, set time and leave, the RTC is saved in the emu.cfg, but the dc_nvmem.bin is "not saved" properly. If I restore the dc_nvmem.bin that works, time is set and no need to go in the BIOS.

I'm using Recalbox, which doesn't set standard paths for config/bios/etc ... files

[vico93]

@7oxicshadow Any chance for we see your fork built for libretro? I use reicast core and ran with this very same annoying bug.

[7oxicshadow]

@vpontin I have never looked at the libretro library. I assume that it is closely linked to the original source but their shutdown routines will probably be custom. Unfortunately I don't get much time to spend on this project nowadays so I can't make any promises.

Whilst no project is ever truly dead I think the team maintaining this project have since moved on. I think everyone is now looking into the redream project as it has been built from the ground up and is getting great results (last time I tried it). I think it has been designed to be very flexible with respect to libretro so I wouldn't be surprised if they had a core for that soon.

[vico93]

Sadly redream doesnt even work here. Soon i load any dreamcast content the emulator promptly crashes the whole retroarch

[Elenedeath]

i found a workaround fix, the save of this file "dc_nvmem.bin" is not implemented on reicast without this you cant save the date, time and language.

i put a "dc_nvmem.bin" create with "nulldc" emulator on the reicast data folder and never have the date settings and set language to french work.

you cant change settings after creating, need to return on nulldc for change settings

i try this on windows emulator and on my retropie and work great

for retropie go on a nulldc emulator on windows launch it without disk
set the settings like you want, exemple language to french
exit the emulator
go to data folder on nulldc emulator

copy "dc_nvmem.bin and paste it to "/opt/retropie/configs/dreamcast/data"

for the date i try to set the correct time but all time the emulator have one hour after the actual hour.

exemple: real time 16h40, nulldc set to 15h40, reicast show 17h40
i try to fake my computer for save file attribute at 15h40 but reicast set 17h40

i change the hour on the retropie at 15h40 and now reicast show 16h40
reicast check local time and add one hour due to my local time gmt+1, need a fix for check utc not local time or local time without adding time

[OmenBoy]

@Elenedeath this isn't working for me on Windows, I've tried many times but it still asks me for the time and date.

[crocket]

When I use reicast-libretro, time and date are saved as data/dc_nvmem.bin. I just had to replace dc_flash.bin with data/dc_nvmem.bin.

I suggest using reicast-libretro with RetroArch.

[OmenBoy]

@crocket I am using reicast-libretro but your method doesn't work for me, I still have to enter the clock settings every time.

[AbandonedCart]

@OmenBoy There were no obvious fixes in the source, but the bug doesn't seem to happen with everyone. One workaround was to manually set the time to exactly 1 minute before (or after, i would have to go dig it up) the real system time. For some reason, it just wouldn't sync the exact time.

[7oxicshadow]

@vpontin This issue should now be resolved in the latest libretro core. (The fix is committed, just need the buildbot to catch up)

Better late than never :)

[AbandonedCart]

Edit: Nevermind. That appears to have been a local typo.

[legluondunet]

I just tested the last Reicast git version, the issue is still present.

config:
Ubuntu 18.04
Nvidia

[AbandonedCart]

Interesting, this issue isn't present on Android
(but Android settings are shell-based, not cfg)

[7oxicshadow]

@legluondunet the issue on the main reicast branch is understood and there is a pull request that should fix it.

I think there is currently discussions about how the dynarec process is handled in general so it won't be be introduced for a while.

[AbandonedCart]

This has finally been resolved across platforms.

[prataczak]

I have the issue with the latest stable version of RetroArch for PC and the latest Reicast core.

[AbandonedCart]

@prataczak The best place to report them would be https://github.com/libretro/reicast-emulator/issues

[prataczak]

Will do, thanks.