BeePi 1.1

[TheNameOfTheGame]

Any tips to set Jinnee as the AV server in XAAES.CNF file? I tried setting it in the CNF file to Jinnee's path but that's not working. When I start Jinnee XAAES throws an error saying it can't set the AV server.

[Faucon2001]

Just replace in xaaes.cnf
setenv AVSERVER "JINNEE "
setenv FONTSELECT "JINNEE "
shell = c:\jinnee\jinnee.app

Respect the 2 blank spaces at the end of "JINNEE ", the name must be 8 characters long.

[TheNameOfTheGame]

Just replace in xaaes.cnf
setenv AVSERVER "JINNEE "
setenv FONTSELECT "JINNEE "
shell = c:\jinnee\jinnee.app

Respect the 2 blank spaces at the end of "JINNEE ", the name must be 8 characters long.

Thanks, that worked. Now I have the problem with Jinnee not working well with XAAES's background image. I can't find where that is set so I can turn it off and let Jinnee manage the desktop background. Where would I look to change the default background?

[wongck]

I can't find where that is set so I can turn it off and let Jinnee manage the desktop background. Where would I look to change the default background?

It is is inside a folder named as the resolution of your screen under the XaAES folder (where xaaes.inf is located).
If your rez is 1024x768x16bits the folder will be 1024768.16, and inside is a large file XA_FORM.MFD.
Just rename that to XA_FORM.MFX or delete it (if you never using it again).
Reboot and the wall paper will be gone.

[TheNameOfTheGame]

I can't find where that is set so I can turn it off and let Jinnee manage the desktop background. Where would I look to change the default background?

It is is inside a folder named as the resolution of your screen under the XaAES folder (where xaaes.inf is located).
If your rez is 1024x768x16bits the folder will be 1024768.16, and inside is a large file XA_FORM.MFD.
Just rename that to XA_FORM.MFX or delete it (if you never using it again).
Reboot and the wall paper will be gone.

Thanks, that fixed my issues with Jinnee. I've never used XAAES much before. Is there a place to go to read about it? I did a quick search and didn't find much.

Anyone get the game landmine to work? For me it is saying it can't find LANDMINE.RSC even though the file is right there in the directory.

[wongck]

Thanks, that fixed my issues with Jinnee. I've never used XAAES much before. Is there a place to go to read about it? I did a quick search and didn't find much.

Anyone get the game landmine to work? For me it is saying it can't find LANDMINE.RSC even though the file is right there in the directory.

Glad removing the wallpaper worked for you.
I think information (not documentation) for XaAES are all over the place and in pieces; you have to watch out for what ppl write on the forums etc.

Never used that Landmine before, and I did not download Beepi yet but maybe you try to change language settings via the CPX ?
It could be looking for RSC based on language. IDK.

[christos]

Hi,
since I really like your work on the desktop (seriously, how do you make it this usable?) is there any chance you could extract the disk image so that those of us who want to use it on our windows/linux machines can? Unfortunately I don't have a PI to run it on.

[TheNameOfTheGame]

So how does the hatari emulation work? Do I just open an .ST file and the game will run automatically?

*edit* I see the problem. Opening an .st file works under teradesk but not under jinnee.

[TheNameOfTheGame]

I have Hatari loading working now under Jinnee. Just had to add file associations for *.st,*.stx,*.msa,*.dim for the program c:/mint/bin/HATASTAR.PRG. Sound and joystick work good. Nice to have this option for loading games.

[TheNameOfTheGame]

90% of my first boots freeze and I have to press CTRL-ALT-BACKSPACE to reboot and then everything is fine. Is this normal?

[Faucon2001]

Hi,
since I really like your work on the desktop (seriously, how do you make it this usable?) is there any chance you could extract the disk image so that those of us who want to use it on our windows/linux machines can? Unfortunately I don't have a PI to run it on.

There is EasyAramint (see my signature) which is done for that. It's not up to date compared to BeePi, but it works perfectly on windows /linux /Mac machines.
If you want to extract BeePi setup, all the disks images and config files are stored at the root under /h/.system.
Mount BeePi image, copy the directory /h to your HDD and modify the paths in the file "config" accordingly. You should be able to start it with : aranym-jit -c config
You won't have printing, Hatari integration and will have to setup the internet bridge manually (look at the file rc.local for internet bridge activation)

[Faucon2001]

90% of my first boots freeze and I have to press CTRL-ALT-BACKSPACE to reboot and then everything is fine. Is this normal?

Well, that's a recurring bug that Beepi is suffering since the first version.It has decreased a bit (before it was 100%), but I can't find a fix, this issue happening only on RPi. On a X86, the same setup works flawlessly. It seems to be something related to RPi linux distribution as it never happens when you start the emulation from the shell.
If a Linux Guru can help that would be great as I have no solution for this annoying bug.

[TheNameOfTheGame]

90% of my first boots freeze and I have to press CTRL-ALT-BACKSPACE to reboot and then everything is fine. Is this normal?

Well, that's a recurring bug that Beepi is suffering since the first version.It has decreased a bit (before it was 100%), but I can't find a fix, this issue happening only on RPi. On a X86, the same setup works flawlessly. It seems to be something related to RPi linux distribution as it never happens when you start the emulation from the shell.
If a Linux Guru can help that would be great as I have no solution for this annoying bug.

Ah, well it is a bit annoying but BeePi boots so fast, it's not too much of a problem to reboot. Hopefully a fix can be found. I wonder what made the freezing reduce from 100% of the time to less of the time with the new release?

[Count]

This is just an idea to possibly get rid of the "hang on boot" issue. I haven't tried it yet and it will increase the startup time, of course.

What if Aranym would be started from rc.local only to be shut down immediately to let BeePi continue and start Aranym again using the desired configuration?

Aranym could be started running EmuTOS and a floppy disk (or very small hard disk) image with a single application in the AUTO folder which uses NatFeat to shutdown the emulator immediately. The idea behind this is that this first start lasts so short that the freeze will not occur.

From my experience it takes a lot of seconds to get to the point of freezing. When booting TOS 4.04 with 14 MB RAM, it occurs at the end of the memory test just before the last part of the second bar disappears.

Philippe, I sent you a link to some archive files regarding BeePi 1.0 (via email) in late Septemer 2019. You can find a SHUTDOWN.PRG in aratools.zip.

[TheNameOfTheGame]

This is just an idea to possibly get rid of the "hang on boot" issue. I haven't tried it yet and it will increase the startup time, of course.

What if Aranym would be started from rc.local only to be shut down immediately to let BeePi continue and start Aranym again using the desired configuration?

Aranym could be started running EmuTOS and a floppy disk (or very small hard disk) image with a single application in the AUTO folder which uses NatFeat to shutdown the emulator immediately. The idea behind this is that this first start lasts so short that the freeze will not occur.

From my experience it takes a lot of seconds to get to the point of freezing. When booting TOS 4.04 with 14 MB RAM, it occurs at the end of the memory test just before the last part of the second bar disappears.

Philippe, I sent you a link to some archive files regarding BeePi 1.0 (via email) in late Septemer 2019. You can find a SHUTDOWN.PRG in aratools.zip.

That's what I was thinking also. Have it automatically reboot once so that the freeze goes away. Hopefully your idea works as I have no clue how to get that implemented.

[MegaSTEarian]

I am about to deploy BeePi to my Pi 4 and having deployed EasyArramint -which does not freeze- I have to ask: What is different between BeePi and EasyAramint on the guest OS side? Why do we think that this freeze is cause by BeePi and not a Pi boot process? Maybe something is being initialised with a delay?

[Playmobil]

I have to ask: What is different between BeePi and EasyAramint on the guest OS side?

May be Philippe can answer better than me, because my english is not very good, but BeePi1.1 and EasyAramint are same... Just some softwares are upgraded in Beepi1.1... I'm still using EasyAramint since years, updated softwares by myself... It's a very good base for emulating ours Atari's...

[TheNameOfTheGame]

I have to ask: What is different between BeePi and EasyAramint on the guest OS side?

May be Philippe can answer better than me, because my english is not very good, but BeePi1.1 and EasyAramint are same... Just some softwares are upgraded in Beepi1.1... I'm still using EasyAramint since years, updated softwares by myself... It's a very good base for emulating ours Atari's...

That's weird since EasyAramint doesn't seem to freeze. So these 'upgraded softwares' may be the culprit causing the freezes.

[MegaSTEarian]

I have to ask: What is different between BeePi and EasyAramint on the guest OS side?

May be Philippe can answer better than me, because my english is not very good, but BeePi1.1 and EasyAramint are same... Just some softwares are upgraded in Beepi1.1... I'm still using EasyAramint since years, updated softwares by myself... It's a very good base for emulating ours Atari's...

Yes, I know they’re the same so the only difference is the host. EasyAramint is using Windows/OSX platforms as hosts while BeePi is using Pi.

[MegaSTEarian]

I have to ask: What is different between BeePi and EasyAramint on the guest OS side?

May be Philippe can answer better than me, because my english is not very good, but BeePi1.1 and EasyAramint are same... Just some softwares are upgraded in Beepi1.1... I'm still using EasyAramint since years, updated softwares by myself... It's a very good base for emulating ours Atari's...

That's weird since EasyAramint doesn't seem to freeze. So these 'upgraded softwares' may be the culprit causing the freezes.

This could be a good reason if the updates affect emulated Atari (during the) boot process.

[Faucon2001]

Thanks, your feedbacks are helpful to think out of the box.

I have investigated a bit more into this bug. These are my findings so far.
- This issue doesn't occur on X86 platform. I have BeeKey booting in 5s without hanging off after the boot. This issue is RPi related.
- The slight decrease of first boot freeze could be linked to the Host system update from Debian Stretch to Buster which has a slightly different boot sequence.
- When you start BeePi from the shell (not auto booting), there is no freeze.
- The Atari side of EasyAramint, Beepi and Beekey is the same ( at least on my setup at home), the only variable is the host system.
- This issue appears at the first boot, when the host system is starting all its services. The reboot done after the freeze of aranym doesn't reboot the host system, but only restart Aranym.
- Looking at systemd boot sequence, they are services which are started or completed after rc.local (which is used to start the emulation)
My hypothesis is that services necessary for Aranym are not fully started when aranym first starts. Restart of Aranym working 100% of the time is another clue for that hypothesis . I am going to dig into this direction.

-> Count : your solution is elegant though slow and complicated, but I keep the idea if I can't find another way around.

I am thinking at 2 solutions :
1- Start the emulation from the shell and not from rc.local, allowing aranym to start after all services available. It implies auto login as root and will slightly increase boot time. It has always concerned me to allow autologin as root, but the implementation is not complicated and it's worth testing.
2- Tweek rclocal.service to start last in the boot sequence after all services are available if the hypothesis is confirmed. I am not really versed into systemd boot sequence configuration but it should not be impossible to learn.

So back to the bench. The new lockdown in France may give me some extra time to work on it

[MegaSTEarian]

- This issue appears at the first boot, when the host system is starting all its services. The reboot done after the freeze of aranym doesn't reboot the host system, but only restart Aranym.
- Looking at systemd boot sequence, they are services which are started or completed after rc.local (which is used to start the emulation)
My hypothesis is that services necessary for Aranym are not fully started when aranym first starts. Restart of Aranym working 100% of the time is another clue for that hypothesis . I am going to dig into this direction.
.
.
.
.
2- Tweek rclocal.service to start last in the boot sequence after all services are available if the hypothesis is confirmed. I am not really versed into systemd boot sequence configuration but it should not be impossible to learn.

So back to the bench. The new lockdown in France may give me some extra time to work on it

That makes things a lot more clear. It is now obvious that rc.local has to start last. I guess either by giving it a delayed start conf or by setting it last in the boot configuration.

I think you will need to play a bit with system conf files and add as dependencies the required system services but looks like you nailed it already. Way to go!

Here's some basic info from Pi themselves: https://www.raspberrypi.org/documentati ... systemd.md


PS: you could probably use "After=network.online.target" which means that it will start not only when network service is available but fully connected and I believe that this would be ok for a more smooth startup.

[Count]

What I experienced today was that after hanging, the boot process of Aranym continues after a certain amount of time. I turned my BeePi on this morning, recognized it hanging and went over to do my regular work. After two hours I looked at it again and saw that it has continued booting into the desktop. That means, it is not really a freeze but rather a delay.

Maybe Aranym is waiting for anything which has not started at the time the boot process is interrupted.

After editing rc.local and inserting "sleep 5" right before startemu is called, the issue did not occur anymore. I started the machine about ten times since then and everything was fine.

[MegaSTEarian]

Sleep 5 is a workaround though. Might be better if you set it to start after all system services have started or?

[TheNameOfTheGame]

What I experienced today was that after hanging, the boot process of Aranym continues after a certain amount of time. I turned my BeePi on this morning, recognized it hanging and went over to do my regular work. After two hours I looked at it again and saw that it has continued booting into the desktop. That means, it is not really a freeze but rather a delay.

Maybe Aranym is waiting for anything which has not started at the time the boot process is interrupted.

After editing rc.local and inserting "sleep 5" right before startemu is called, the issue did not occur anymore. I started the machine about ten times since then and everything was fine.

Adding "sleep 5" before startemu seems to have fixed the freezing for me as well. For now, this is a good workaround. Thanks. I think this bug is getting close to being solved.