Amideb: An Amiga Emulator System

[giantclam]

Originally Posted by pixie

Edit: Here's a playlist I created on youtube regarding the "issue"

Thanks for using easy2get Amiga software, and for the YT clips..."a picture says 1000 words"...as the saying goes 8)

From that set, I picked on the Andromeda.DOS demo disk ...as it was running really woeful ~ remember, it's always important to state that you're using AmiDeb at the time.

I've never played with a ryzen cpu, let alone a 8core...and as I don't have one here, I can only offer hypothesis ~ ultimately it'll be up to you to test same on your hardware, and report back.

....I think what you're seeing there, is the process thread jumping across cpu cores...at a guess. In theory, just 1 ryzen7 core is enough to do the AmiDeb thing going by the tests results I've got here... in say speak, I'm talking about 'cpu affinity' / 'cpu pinning'.... I checked the AmiDeb install set, and it's got all we need to test case this...

*Configure the A500 fs-uae config to load Andromeda.DOS.dms demo disk ; start the emulation by selecting 1 in the AmiDeb menu

*Use ctl-alt-F1 to switch back to the AmiDeb menu, which leaves the emulation running -- select 'u' for the utilities menu, then '6' to start command shell

*first you have to know the process id of fs-uae ...ie; sudo pidof fs-uae ...this will return the process number

*now you need to use the 'taskset' command, to bind that process to a single cpu core ... you can actually check first to see how the process is spread if you like ...ie; sudo taskset -cp <process number>

*lock the fs-uae process to a single core...ie; sudo taskset -p 0x1 <process number> ... you can check again if you like ...ie; sudo taskset -cp <process number>

*now you can hit ctl-alt-F2 to switch back to the emulator window running the demo, to see if this helped at all

This is what that looks like on the 4 core Phenom ...fs-uae was running on all 4 cores (0-3), and it's back to 1 core (core 0)





If this helps any....ummm...likely the AmiDeb menu needs another utility feature, to launch the fs-uae with cpu_affinity already set...ie; the command would look like ... taskset -c 0x1 fs-uae ...(start fs-uae on a single core)

There's a couple of other places to think about...ie; fs-uae starts with a priority of 20, so every other process running from 19 down to -20 can interrupt fs-uae...(this is largely in the kernel scheduler)...normally, especially with low powered systems, it can help to (re)nice the process to increase it's priority....but as said, you're at the other end of the stick...you've got too much processing power 8)

[pixie]

Originally Posted by giantclam

Was that using AmiDeb?

No, that is through WinUAE. But on FS-UAE isn't much different wether on windows or Linux. I haven't installed Daneb yet, my Linux skills aren't yet up to it

[giantclam]

Originally Posted by pixie

No, that is through WinUAE. But on FS-UAE isn't much different wether on windows or Linux. I haven't installed Daneb yet, my Linux skills aren't yet up to it

Ah-ha...you can muck about with the same thing in windows --> https://winbuzzer.com/2020/07/03/how-to-set-cpu-affinity-in-windows-10-with-task-manager-or-system-properties-xcxwbt/

The above commands hold true for linux distros (not just AmiDeb =)

[vk3heg]

Originally Posted by giantclam

You can always install and try a real-time kernel build if you want in AmiDeb...(I think, not tired but in theory it's simple as)..ie; sudo apt install linux-image-5.10.0-21-rt-amd64

I did that on one of my test installs this evening... Didn't see much change in the way the system performed. I3-3240, 8Gb ram, Nvidia GF110...

[giantclam]

Originally Posted by vk3heg

I did that on one of my test installs this evening... Didn't see much change in the way the system performed. I3-3240, 8Gb ram, Nvidia GF110...

Makes sense ~ using a RT kernel is only half the job ; you're still limited by the compile opts of X and everything else .... was that using nvidia 390.xx drivers?

[giantclam]

Originally Posted by OldAmigan

@Giantclam


I have a variety of older hardware but in the main I was thinking of a 1.46GHz Advent laptop with a Celeron M processor and 2Gb RAM and/or an old Dell Inspiron Mini10 with an Intel Atom Z530 CPU @ 1.6GHz with 2Gb Ram. Unfortunately with GMA500 graphics.

The Advent runs Sparky Linux at the moment, which is Debian based, and runs it well, so will hopefully run OK with AmiDeb.

Apols, missed this ...afaik AmiDeb image is not (yet) tuned for (U)EFI style bios type ...but even if it were, I very much doubt either of those machines can pull it off =)

[giantclam]

//other notes...

*if you do install nvidia drivers (and it seems worth doing if you have the hardware), it will smash the console fbdev resolution. It seems fbdev is largely unset, so kernel takes the EDID info from the monitor, and sets fbdev to display native resolution. The nvidia drivers don't honor any established compliance here, so when you reboot after installing the nvidia drivers, the fbdev is under the nvidia driver control...and it will arbitrarily set some fbdev resolution (I think it's 800x600)...and the menu text will be 4 times bigger..and look like crap =)

*the menu text is justified top/left and I dunno about everyone else, but IMO font size is too small...(that's one of the enigmas of having the nvidia server smash the fbdev --- one side of your brain breathes a sigh of relief in that finally the text size is more like it should be, but the other side of the brain is saying it looks like crap =)...really, right...in a perfect world, you'd wrap the menu in ncursorlib & display center/middle justified with known menu boundaries...this is how the deb installer does it, so the ncurses menu appear consistent across different monitors...just saying... =)

*this notion exists anyway, but I sorta tripped over it above, considering just how one could go about getting taskset to work with the menu ~ the existing notion is that there may be some users, who...once they've finished setting up the Amiga guest the way they want it, they'd prefer the AmiDeb box to boot straight to Workbench, no menu. That's not all that hard to implement...but as the menu is calling startx[command] directly, and considering other thing one might want to do, I would wonder if .xinitrc style of X $display handling makes more sense (tempered with the fact nobody has demonstrated the need to employ taskset ..yet.. anyway)

...just musing in my head about configurata ..dreams of RAMB0: etc etc....if you had your Amiga guest all set up, and the AmiDeb system was configured to boot straight into emulation...you could in theory intercept short_press on PC powerswitch, to be a suspend-to-ram call...given the tiny OS footprint, that'd take but a moment ~ when you start the machine again, it'd save some bootup time...dunno how much, but I might have a look at it (extra packages needed =)

l8r

[vk3heg]

Originally Posted by pixie

@vk3heg
I do not have a dvd player, could you tell which steps to follow so that I could burn the iso to a usb pen?

On windows I recommend "Win32DiskImager", and on linux it's as simple as

sudo dd if=amideb-i386-firmware-usb.iso of=/dev/sdc bs=1M status=progress

Note: /dev/sdc is the actual usb memory stick, and not the partition.

[vk3heg]

Originally Posted by giantclam

Makes sense ~ using a RT kernel is only half the job ; you're still limited by the compile opts of X and everything else .... was that using nvidia 390.xx drivers?

The test was done with and without current nvidia drivers.

[giantclam]

Originally Posted by vk3heg

The test was done with and without current nvidia drivers.

Hmm..ok, then it's as per my previous speculation ; we're at the limit of the code execution speed of the binaries (both fs-uae and linked libs)...


...which fs-uae build is being employed here?

[vk3heg]

Originally Posted by giantclam

Apols, missed this ...afaik AmiDeb image is not (yet) tuned for (U)EFI style bios type ...but even if it were, I very much doubt either of those machines can pull it off =)

UEFI 64Bit beta version.

https://amiga.vk3heg.net/?page_id=239

[giantclam]

Originally Posted by vk3heg

UEFI 64Bit beta version.

https://amiga.vk3heg.net/?page_id=239

Typo on that page ---> Stabdard ISO file

[giantclam]

Originally Posted by vk3heg

UEFI 64Bit beta version.

* amideb-x64-firmware-usb.iso -- this just failed on a laptop here with UEFI bios...


...looking at it....


gcb@gallah:~/amideb$ isohybrid -u -v amideb-x64-firmware-usb.iso
catalogue offset: 1056
ve[0]: 1, cs: 1
ve[1]: 0, cs: 1
ve[2]: 0, cs: 1
ve[3]: 0, cs: 1
ve[4]: 0, cs: 1
ve[5]: 0, cs: 1
ve[6]: 0, cs: 1
ve[7]: 0, cs: 1
ve[8]: 0, cs: 1
ve[9]: 0, cs: 1
ve[10]: 0, cs: 1
ve[11]: 0, cs: 1
ve[12]: 0, cs: 1
ve[13]: 0, cs: 1
ve[14]: 21930, cs: 21931
ve[15]: 43605, cs: 65536
de_boot: 136
de_media: 0
de_seg: 0
de_sys: 0
de_mbz1: 0
de_count: 4
de_lba: 1057
de_mbz2: 0
isohybrid: amideb-x64-firmware-usb.iso: unable to find efi image




Just did a cross-check (same machine, same USB stick) with debian-11.6.0-amd64-netinst.iso ...machine boots from that fine ; isohybrid prolly has it right --- it couldn't find the the efi image, neither could BIOS =)

[giantclam]

Did some testing this afternoon ~ x86 is quicker than X86_64 on 64bit cpu. Came across this a number of years back mucking around with android emulation ; you could get around 10% performance boost by going to x86. Typically speaking, X86_64 is quicker but when you're running emulators, that's often not the case. You can view this objectively or subjectively ...latter first;

*https://download.d0.se/pub/SysInfo.adf

With base A500 fs-uae config as is, internal rom emulation, best score I can get with x86_64 is -610-

Exact same test conditions, but with AmiDeb i386 ...best score of -615- ...it's only a tiny amount, but any gain is a gain for good.

The objective view....this is difficult to visualize...if sysinfo is correct, the human eye will not see 1% performance increase with the naked eye, so higher time resolution is required. To think about that, is to realize the emulator is refreshing display at 50Hz (PAL... NTSC 60Hz), so if you've got a capture device capable of 100Hz (or 120Hz for NTSC), you've doubled time res. In the Andromeda.DOS demo, there's a text scroll top left of demo...



If you capture that while running the demo on both i386 & x64 AmiDeb, align the start point and comparatively step-frame through both recordings side-by-side, you will see it....just...it's only a bee's dick, but it's there.

So I'm dropping back to AmiDeb-i386 for the now.... don't take this as advice ; other cpu setups may differ =)

[giantclam]

Originally Posted by vk3heg

The test was done with and without current nvidia drivers.

Went back to looking at this last night, as it should've gained -something- ... turns out debian dkms won't build a nvidia-rt-driver ....but it looks like it can be done...


...but I'll have to sit down with it, prolly on a bullseye install in vm to figure it out...

[giantclam]

"At the end of the installation of AmiDeb you have a real Debian Linux system, with the benefit of being able to update and customise the system."

// consider this observation, -not- criticism //
// TLDR applies, but if you're interested...

It's not a 'real' Debian Linux system ~ reason: no manpages =)

Why would there be any reason to update, and further, what effectively would ever be updated, on a reduced install set.... *that affected/improved the the emulation*...? I will find out ~ I'm prepared to leave AmiDeb installed on the rig I've got for the rest of this year, and I'll throw an 'apt update && apt list --upgradable ' every month, just to see what (if any) packages get updated, making note if such upgrades would affect and/or improve the fs-uae emulation. Possibly just fs-uae itself?...I dunno, but I'm prepared to sit on it for a year to find out ~ at this stage, my gut feeling is 'nothing' would need updating that's of any consequence, that serves AmiDeb's end goal.

This is why I initially questioned 'target audience' ~ might we be able to examine that pool? Here's how I see it, and I'm taking clues here from posts in this thread;

*unaligned audience ~ user has spare x86(or x86_64) machine sitting around, that they want to turn into a booting Amiga emulator. If it came to customizing the AmiDeb installation, you're gunna want to be reasonably proficient with debian linux...

*windows audience ~ similar to above, in that the user would like to boot their windows box into AmiDeb for a high performance Amiga installation, and once they're finished, be able to boot back into windows. Now...I haven't tried a parallel install (I will later), to ascertain whether or not the grub install will an a boot entry point for the windows installation, but it's ostensibly a moot point, because AmiDeb does a 'quiet' grub boot, and you're not presented with the boot selector, to be able to choose windows when the machine boots. This won't be a problem, if you use a separate hdrive ~ you can use BIOS boot disk selector to choose what installation you boot....but anything less than that is going to present itself as problematic...ie; installing AmiDeb to another partition on the same disk.

*apple audience ~ (I bet nobody expected this entry =)...last iMac I toyed with was back in 2010 or so ; it's similar to the windows case above, but one has to do it all from the EFI bios. Back in the day, I used the 'rEFIt' bootloader, so as to be able to boot into either OSX, windows, or Debian....but, it's doable ...(at least it was back then 8) You'll still have the boofle wrt having a disk partition to install to (and opening up an iMac to fit a 2nd drive isn't gunna happen easy =)...likely the easiest way is by external hdrive....

*debian audience ~ ummm...might ostensibly a waste of time (I intimated this earlier) ; you could use your existing debian install, and have a separate grub boot entry, to load into AmiDeb. I'm not sure of the specifics...umm...likely you'd have to create a fakeroot (put under /opt makes sense), and symlink everything you need from the existing debian install, into the fakeroot dir....and pivot_root off the grub entry....such'or'similar...so then when you boot the linux box, you get the grub menu with a 'amideb' item you select, and it'd boot just like a 'real' AmiDeb install does...(and just now thinking about it, this might be possible by changing runlevels from with the booted debian system, allow you to switch into amideb mode...so no need to futz with the bootloader at all)

*linux audience ~ YMMV 8) This could be anywhere from a linux user that typically uses another linux distro, having to come to grips with apt...to someone like me, who used to build linux systems (see: https://www.linuxfromscratch.org/lfs/)...and in that regard, debian would likely not have been my first choice for the base install set of AmiDeb. I know it might sound like an oxymoron, but debian is too mature/stable for this kind of thing, IMHO anyway. With stability comes policy...and don't get me wrong here, there is absolutely very little wrong with debian policy... BUT ...you don't need this for AmiDeb.

Again, do not misunderstand me here ~ debian is my distro of choice, just because of it's policies and stability ...for general computing needs ...but AmiDeb is not that - it's what I call a linux appliance, it has a specific computing task..just 1 ...run fs-uae as best as is possible, on x86 machines, that's it, stuum. For this kind of thing, leveraging & utilizing an existing linux distro, would have me consider ArchLinux before Debian...just due to the differences in distro policy....

...so how do differences in distro policy, possibly impact upon the end goal here...ie; run fs-uae on x86 linux as best as is possible? Well...both vk3heg & myself, have hit upon a prime example ; an RT kernel makes little difference with or without nvidia graphics drivers. As I looked into this, I soon realized we were running RT kernels, on non-RT nvidia drivers. Down the rabbit hole, I found out why I couldn't I compile nvidia-RT-drivers on Debian using DKMS ....

# The NVIDIA driver does not support real-time kernels.
# Can't easily set this via BUILD_EXCLUSIVE.
[[ "$kernelver" =~ "-rt-" ]] && build_exclude="yes"

That, is policy....and this is hypothetical at the now, but if RT nvidia drivers did make any improvement to how fs-uae run in AmiDeb, it's not so easy to test the case with debian, as there are no nvidia-RT drivers....not even in sid .... if this were Arch linux, I (and others) could easily test that -- https://aur.archlinux.org/packages/nvidia-rt ...different policy, largely governed by Arch users, not the Arch distro policies...


Wrt a linux appliance, distro policies suck ~ the best analogy, is thinking about modern modems, all pretty much based on linux. There's no packages or package-manager, updates come in a single firmware binary, and you define your own policy (at the build machine typically) ; it's just easier to deal with on custom hardware. AndroidOS did a very similar thing, defining their own policies and package-manager (apk), and the base OS is updated by firmware binary. For mine, AmiDeb attempts to leverage ix86 hardware, into being 'custom' hardware of a sorts ; all the machine can (or needs) to do, is run fs-uae as performantly as is possible.

In this regard, I think I can do better than Debian (or Arch for that matter), but that is conjecture ~ I have to know, for my own edification, whether or not that conjecture holds water. Thus....I'm going to toddle off, dump debian base, and build AmiDeb into a proper linux appliance. I'll keep notes as I go =) It's been nigh on 10 and a bit years since I mucked about with linux builds...but it's ok -- I still wake up in the middle of the night screaming "configure, make, make install"...it's like learning to ride a bicycle ~ once learnt, the skill tends to never leave you...building a linux system is the same 8)

I'll keep in contact with this thread, help out AmiDeb any way I can along the way...but debian policy is...umm...stifling...?...something like that...and I stress again I'm talking about the linux distro I use and have great respect for...but here, just to run fs-uae, it's overkill. Not sure howm long it'll take me..."a month of sundays" sounds about right...but I'll start tonight B)

[giantclam]

I remember now why that n68-s3 mobo was retired from use ~ it does weird things at cold/warm boot, like randomly deciding to reorder boot drive priority...(re)flashed latest bios, even rolled back bios, still does it...must be a bug in the MCP-61 chipset not honoring bios settings..strange...but usable -- if there's only 1 boot drive it has no choice =)

I was just checking out the AmiDeb website...

https://amiga.vk3heg.net/?epkb_post_...nvidia-drivers

*...if the machine has inet connectivity, and the cmd ' sudo apt install nvidia-driver firmware-misc-nonfree' is issued, apt/dkms will proceed under the auspices that the root user knows what they're doing. As such, dkms isn't going to walk the pci bus to determine whether or not you have the nv GPU hardware that the driver actually supports...and the apt target 'nvidia-driver' is going to install/provide nvidia-kernel-418.226.00 ...

[tested]....the nvidia-driver target blacklists nouveau driver before the nvidia modules are compiled, and as I noted previously if kernel-headers aren't installed, the dkms process will quietly 'fail' ... (not really, it's put on hold)...but everything else, all the nvidia blobbed libs and changes to X config are made regardless of an incomplete/unsuccessful dkms module build phase --- when you reboot the AmiDeb install, fs-uae will no longer work (there is a bold warning from systemd that load modules fails on bootup). This leaves a different after taste in the user's mouth, as they followed instructions they thought would work, which didn't, and broke it ; this brings about feelings of self doubt/failure ('did I do something wrong?'), and trying to recover from this situation is some horrorshow I didn't bother checking out =)

I haven't checked how far back chipset coverage goes wrt nvidia-kernel-418.226, but it's at least possible/probable for a user to know they have nvidia GPU, but not know nvidia-kernel-418.226 doesn't support it, and they will break their AmiDeb installation.

Ergo...info needs to be provided on the above URL to get users to check ( lspci ) if they have a compatible nv chipset that nvidia-kernel-418.226 supports ~ if they don't, they should check if the nvidia-legacy-390.xxx target supports their GPU and install that instead....and it gets worse....

...because there'll be users out there, who think nvidia drivers == go faster, and they'll try the above URL even if they don't have a (supported) nvidia GPU in the first place =) If this all happens, you need an uninstall script (using apt most likely), that purges all the nvidia-driver packages, unblacklists nouveau, and relinks all the libraries in cleanup fashion (this used to be in the stock nvidia driver tarball, but I've no idea where it went in debian packages) .... and if you don't provide that, and the quickest solution for the end user is to reinstall AmiDeb....it starts mimicking some other OS that I'm not at all fond of 8)

Again and I stress, this is meant to be 'constructive criticism' , not just me 'picking holes' in AmiDeb (which I consider to be cool =)

[pixie]

Originally Posted by giantclam

if sysinfo is correct, the human eye will not see 1% performance increase with the naked eye, so higher time resolution is required.

I assure you that if this 1% makes it out of sync punny human will notice, ita has to be all or nothing otherwise it won't look as it should

[giantclam]

Originally Posted by pixie

I assure you that if this 1% makes it out of sync punny human will notice, ita has to be all or nothing otherwise it won't look as it should

...there's probably more to squeeze out of the AmiDeb install, just by compiling a kernel for the task...ie; don't have mitigations compiled in/active for a start...


..in times past, you'd look to be getting away from journaling filesystems, just to avoid losing clocks when journal updates/writes happen...even syslogd or anything that would try access disk, you'd steer down the drain hole of /dev/null or recompile them with no logging options, just to keep them off the bus...there's lots of little tweaks one can do. =)


This is, compiling a linux kernel for oneself is at least user hostile, and maybe even daunting...but back in the day when linux distros first appeared, this was the first thing you did post install ~ compile and install a linux kernel to suit your specific machine, because the -install- kernel is built to work on as many machines as possible, and they tend to be slow kernels back then compiled -march=i386, and your machine was i586/i686 ...back then, it really was amazing how much quicker 'your' kernel build ran

[giantclam]

..there's probably more to squeeze out of the AmiDeb install, just by compiling a kernel for the task....

Just thinking about this (after getting to know the linux 5.19.2 tree), you could build a 'faster' debian bullseye kernel image, and package it as a custom.deb file, which users could install via menu with 'dpkg -i <custom-name>.deb' .... that'd probably be the most user friendly route to an AmiDeb specific faster kernel build....