Closed chrisblown closed 11 months ago
chrisblown
commented
1 year ago I've tested the same setup on my Mac x86 build of Amiberry 5.6.1 and the CD32 works fine. So not sure what specifically is different on Debian / RPi3B (other than lack of grunt)
chrisblown
commented
1 year ago Seems to be related to mis-configuration.
chrisblown
commented
1 year ago I've reopened this since I'm having issues loading ISO/CUEs on and off. I thought it was a config issue but the very same configuration that was previously working earlier today is now doing the same thing
I've checked the amiberry log and during the times the system doesn't boot it logs
CD32: device unit 0 lost
CD32: device unit 0 lost
CD32: device unit 0 lost
CD32: device unit 0 lost
It seems totally random, when its working I can swap disk consistently with no problems, when it doesn't work no amount of ejecting or selecting new disks does anything.
I'm going to try another SD card to see if that has any impact.
giantclambake
commented
1 year ago That error is being emitted by akiko.cpp ~ debug build of amiberry might disclose more in the logfile.
chrisblown
commented
1 year ago I'm currently using a binary, I'll see if I can build a source version & get debug enabled.
I noticed this report in WinUAE https://github.com/tonioni/WinUAE/issues/132 that @midwan reported ages ago Maybe not related, but the "small delay" part got me thinking this might be machine dependant (esp. considering the RPi3 isn't the speediest)
giantclambake
commented
1 year ago Unfortunately I only have a RPi3A+ so I'm unsure if testing on that will be comparable =)
chrisblown
commented
12 months ago I've spend some time testing this further. While my issue seems somewhat random, if I start the machine with a CD image mounted first time that seems to work. I hesitate to say 100%, but almost always.
Here is a log dump when it picks up the CD correctly (when its mounted at start)
CD: plain CD image mounted!
1: 0 00:02:00 DATA 4 0 4659200
- /mnt/dietpi_userdata/amiberry/iso/cd32/vital light.iso
2275 00:32:25
uae_start_thread "cdimage_unpack" function at 0x5585e9b200 arg (nil)
CD32: using drive IMG:/mnt/dietpi_userdata/amiberry/iso/cd32/vital light.iso (unit 0, media 1)
uae_start_thread "akiko" function at 0x5585e70500 arg (nil)
CD32: media changed = 1 Here is a log dump when nothing is mounted at start (and subsequently it seems to never see a CD change from here on)
uae_start_thread "cdimage_unpack" function at 0x556249b200 arg (nil)
CD32: using drive IMG:<EMPTY> (unit 0, media 0)
uae_start_thread "akiko" function at 0x5562470500 arg (nil)
CD32: media changed = 0
...
No disk in drive 0.then from here it logs - quite unhappy about things ;)
CD32: extended rom delay loop patched at 0x00e592d4
Card 0: skipping autoconfig (not autoconfig)
CPU cycleunit: 256 (0.500)
CD32: device unit 0 lost
hardreset, memory cleared
SDL2: CH=2, FREQ=44100 'bcm2835 Headphones, bcm2835 Headphones' buffer 2048/2048 (pull)
SNDRATE 312.0*227.0*50.080410=3546894.958099
SERIAL: period=372, baud=9600, hsyncs=14, bits=8, PC=f8018a
Error: Invalid argument.
Card 2: Z2 0x00200000 2048K RAM Fast memory
mapped_malloc(): 0x00e90000 - 0x00ea0000 (0x20e90000 - 0x20ea0000) -> Filesystem autoconfig (*)
Card 3: Z2 0x00e90000 64K ROM Filesystem autoconfig
Memory map after autoconfig:
00000000 2048K/1 = 2048K ID* C32 Chip memory
00200000 2048K/1 = 2048K ID* F32 Fast memory
00400000 6656K/0 = 6656K -- F32 <none>
00A80000 512K/1 = 512K ID* F32 Kickstart ROM (1E62D4A5)
=CD32 KS ROM v3.1 rev 40.60 (512k)
00B00000 512K/1 = 512K ID* F32 Extended Kickstart ROM (D67BDF13)
00B80000 64K/0 = 64K -- F32 Akiko
00B90000 64K/0 = 64K -- F32 Custom chipset
00BA0000 256K/0 = 256K -- F32 <none>
00BE0000 128K/0 = 128K -- CIA CIA
00C00000 1024K/0 = 1024K -- F32 Custom chipset
00D00000 768K/0 = 768K -- C16 <none>
00DC0000 64K/0 = 64K -- C16 Battery backed up clock (MSM6242B)
00DD0000 128K/0 = 128K -- C16 Gayle (high)
00DF0000 64K/0 = 64K -- C16 Custom chipset
00E00000 512K/1 = 512K ID* F16 Extended Kickstart ROM (D67BDF13)
00E80000 64K/0 = 64K -- F32 Autoconfig Z2
00E90000 64K/1 = 64K --* F32 Filesystem autoconfig
00EA0000 384K/0 = 384K -- F32 <none>
00F00000 64K/1 = 64K --* F32 UAE Boot ROM
00F10000 448K/0 = 448K -- F32 <none>
00F80000 512K/1 = 512K ID* F16 Kickstart ROM (1E62D4A5)
=CD32 KS ROM v3.1 rev 40.60 (512k)
01000000 4064M/0 = 4064M -- F32 <none>
FF000000 64K/0 = 64K -- F32 Autoconfig Z3
FF010000 16320K/0 = 16320K -- F32 <none>
CD32: device unit 0 lost
filesystem: diagentry 00202fb0 configdev 00000c48
SNDRATE 313.0*227.0*49.920410=3546895.062012
PAL mode V=49.9204Hz H=15625.0879Hz (227x312+1) IDX=10 (PAL) D=0 RTG=0/0
CD32: device unit 0 lost
CD32: device unit 0 lost
SNDRATE 312.5*227.0*50.000282=3546895.024776
PAL mode lace V=50.0003Hz H=15625.0879Hz (227x312+1) IDX=10 (PAL) D=0 RTG=0/0
CD32: device unit 0 lost
AUD1: forced idle state PER=4096 PC=00fbc2a8
AUD0: forced idle state PER=4096 PC=00fbc2a8
CD32: device unit 0 lost
CD32: device unit 0 lost
CD32: device unit 0 lost
Stored port 0/1 d=0: added 200 0 System mouse MOUSE0
Autoconfig board list:
Card 01: 'UAE Boot ROM' no autoconfig 00f00000 - 00f0ffff.
Card 02: 'Z2 Fast RAM'
e6.51.00.00.07.db.00.00.00.01.00.00.00.00.00.00
MID 2011 (07db) PID 81 (51) SER 00000001
Z2 0x00200000 0x00200000 2048K RAM 0
Card 03: 'UAE FS ROM'
d1.52.40.00.07.db.00.00.00.03.20.00.00.00.00.00
MID 2011 (07db) PID 82 (52) SER 00000003
Z2 0x00e90000 0x00e90000 64K ROM 0
END
Autoconfig board list:
Card 01: 'UAE Boot ROM' no autoconfig 00f00000 - 00f0ffff.
Card 02: 'Z2 Fast RAM'
e6.51.00.00.07.db.00.00.00.01.00.00.00.00.00.00
MID 2011 (07db) PID 81 (51) SER 00000001
Z2 0x00200000 0x00200000 2048K RAM 0
Card 03: 'UAE FS ROM'
d1.52.40.00.07.db.00.00.00.03.20.00.00.00.00.00
MID 2011 (07db) PID 82 (52) SER 00000003
Z2 0x00e90000 0x00e90000 64K ROM 0
END
Stored port 0/1 d=0: added 200 0 System mouse MOUSE0
Autoconfig board list:
Card 01: 'UAE Boot ROM' no autoconfig 00f00000 - 00f0ffff.
Card 02: 'Z2 Fast RAM'
e6.51.00.00.07.db.00.00.00.01.00.00.00.00.00.00
MID 2011 (07db) PID 81 (51) SER 00000001
Z2 0x00200000 0x00200000 2048K RAM 0
Card 03: 'UAE FS ROM'
d1.52.40.00.07.db.00.00.00.03.20.00.00.00.00.00
MID 2011 (07db) PID 82 (52) SER 00000003
Z2 0x00e90000 0x00e90000 64K ROM 0
END
KS ver = 40 (0x28)
Stored port 0/1 d=0: added 200 0 System mouse MOUSE0
Stored port 0/1 d=0: added 200 0 System mouse MOUSE0
Stored port 0/1 d=0: added 200 0 System mouse MOUSE0
SETSYSTIME
SETSYSTIME
CD32: device unit 0 lost
CD32: device unit 0 lost
CD32: device unit 0 lost
CD32: device unit 0 lost
CD32: device unit 0 lost
CD32: device unit 0 lost
CD32: device unit 0 lost
CD32: device unit 0 lost
SNDRATE 313.0*227.0*49.920410=3546895.062012
PAL mode V=49.9204Hz H=15625.0879Hz (227x312+1) IDX=10 (PAL) D=0 RTG=0/0
CD32: device unit 0 lost"Here is a log dump when it picks up the CD correctly (when its mounted at start)"
Can I ask what exactly you mean by this, specifically what exactly is being 'mounted' here?...ie; is the effective path of
/mnt/dietpi_userdata/amiberry/iso/cd32/vital light.iso actually a USB drive mount-point? I'm not familiar with diet-pi, but as an example, in my testing, I copy the {bin,cue,iso} files into my $homedir (or somewhere like ~/amiberry/isocd/ ) ~ I'm not suggesting one has to do that, I'm merely detailing my procedures =)
"Press F12, then eject, then select image, choose another ISO/CUE Press Resume, back to CD32 screen no activity.."
The Resume button should not be used like this ..at least, not in my experience with amiberry on x86-64 ~ the resume button is for when you change some param of the emulator machine context and wish to continue ; you can't change the runtime media of the running context and continue/resume... ie; just as one doesn't want to loadup a demodisk.adf, pause somewhere during that presentation, swap out disk image with sysinfo.adf and press resume... madness ensues =)
The Reset button does what Ctrl-LAmige/RAmiga does ; reset the current machine context ...I'm not sure if I'd consider this a bug, however if you F12 out of a running CD32 machine context, change the cue/iso source, and then press Reset, you see the CD32 keylocker prompting you for the unlock code. Somewhere in a dream one night, I construed this to be a close proximity to anti-piracy measures to combat hot-swapping of CD media...
The Restart button emulates the act of a real Amiga owner having to switch off the power-brick for at least 5seconds, in the case when keyboard input could not effect a Reset ...there were numerous demo/music/scene floppies back in the day, that deliberately forced a cold-reboot...even though it's warm =) If I'm running amiberry configured to do CD32 emulation, and I want to change CD source, I always use the Restart button....which infact restarts amiberry itself, but it does so retaining the same machine settings ~ you're free to change cd/disk/hd media and press Start... works every time....
....although I did stumble upon the quirk of the previous CD image being loaded, in spite of the fact the image textbox was displaying something different ~ ejecting the current CD image you wanted and reloading it seemed to work.... (I'll see if I can recreate that on this machine later).
I tested all this out on both rpi4B4G and rpi3A+ ....so we'll go with the latter for fair comparison. This rpi3A+ is actually destined for a pistorm setup on a rev.6A A500 mainboard, thus all sorts of curiosity for me here =) Running with the bullseye 64bit RaspOS image on both boards...on the rpi3 you really don't want the overhead of X/Wlalaland so just boot and autologin to CLI...
....if you want point&click in console, 'sudo apt install gpm' .... start amiberry from cmdline (from within the amiberry dir)
...as mentioned, I have the following archive contents/files in my ~/amiberry/isocd/ directory;
Quickstart -> Amiga model CD32 -> Select image (~/amiberry/isocd/Vital Light (1994)(Millennium)[!].iso) -> Start
//emulation runs as it should, in fact I'm surprised at how well amiberry/rpi3 manages so well doing this...
F12 -> Restart -> Eject -> Select image (~/amiberry/isocd/Cannon Fodder.cue) -> Start
//emulation runs as it should, I'm surprised again...flat 50FPS during battle action...so much fun =)
F12 -> Restart -> Eject -> Select image (~/amiberry/isocd/Vital Light (1994)(Millennium)[!].iso) -> Start
It all seemed to work 'as expected', even on the lowly rpi3A+ ~ does the above example work for you?
chrisblown
commented
11 months ago Thanks for the reply, yes I am quite impressed how well the old Pi3 does too :)
Dietpi puts things under /mnt/dietpi_userdata which is on the SD card in my case (but I guess they put it there so you can easily mount it elsewhere if you want). Either way I've tried ISO/CUE media from the local SD and USB with no changes.
What you are are saying about using Resume makes sense, although when using the CDTV, it forces a reset each time you eject and reinsert a new disk (on Amiberry and the real machine). So using Resume here "resets" the machine when the disc is ejected.
I have a real CD32 here which I can test, but if I'm not mistaken, the CD32 doesn't reset when you open the CD door? does it? I can't recall.. Anyway from a warm boot screen (no disk) you can open the door and put a disk in and it'll boot from the rainbow animation with the letters CD spinning off screen - OR you can put a disk in with the machine powered off and turn it on (or reset as you say) and it kinda skips the rainbow part of boot screen and just flashes up the logo Amiga CD 32 and then the CD spins off and it boots.
Couple of things to note. I'm not using the Quickstart > Amiga model CD32 setup. I couldn't get this to work, I just get the purple 3.1 floppy disk boot screen? I had to create my own configuration and manually add both CD32 roms (rom and ext).
Technically when I press F12, and insert a disk and then Resume it should just be the same as opening the door and putting a disk in and closing it. When my setup is behaving, e.g not reporting CD32: device unit 0 lost this works most of the time (without requiring a reset) resume works and the rainbow animation continues and after a few seconds the CD letters spin and way it boots.
When you say F12 -> Restart -> Eject -> Select image (~/amiberry/isocd/Vital Light (1994)(Millennium)[!].iso) -> Start
You mean "Reset" here not "Restart"?
OK I'm going to try your suggestion and always hit "Reset" after F12 and see if that makes any difference. I feel like this issue is more to do with Amiberry initialising the CD drive emulation since akiko.cpp it is actually reporting CD32: device unit 0 lost...
I'm keen to understand in your setup. 1. Do you even see the CD32 boot screen when you use Quickstart > Amiga Model CD32 ? and 2. Do you see any mention of CD32: device unit 0 lost in your amiberry.log file ever?
Thanks!
giantclambake
commented
11 months ago When you say F12 -> Restart -> Eject -> Select image (~/amiberry/isocd/Vital Light (1994)(Millennium)[!].iso) -> Start
You mean "Reset" here not "Restart"?.
No, I mean Restart --- about the only time I use the Reset button, is when I'm mucking about with a specific title (whatever that might be) ...basically when I want to reset the emulation with the same media inserted, or, I've watched one demo.adf, come to the end, and wish to watch another demo.adf (F12->change floppy image->Reset) .... with no emulator changes.
...if in the case it's CD32 emulation, Reset (for me at least, I'll retest) changes machine behavior. If I use Reset during CD32 emulation (and then after changing media), I will be presented with the Amiga CD32 amin that leads to the keylock screen. If I use Restart, I get the Amiga CD32 anim that leads directly to loading the selected title.
- Do you see any mention of CD32: device unit 0 lost in your amiberry.log file ever?
I don't believe I enabled logging because "it was working as I expected", but I want to retest this and will do that (the reason I want to retest is because the build on my amd64 box was behaving differently).
I should also point out, if a CD32 title is available as a whdload archive, I will use that in preference (but I realize this isn't always the case and image cue/iso files are the only resort).
More later once I recheck/test this lot....
chrisblown
commented
11 months ago Whaaa .. Restart, completely restarts Amiberry doesn't it. I have default.uae setup with Show GUI unticked so for me hitting Restart will boot up the default.uae config (which for me is a HD booted A4000)
I've actually never seen the keylock screen on Amiberry - unless I press a button from the CD32 boot screen.
I'm going to have to do some further testing myself, since I never really used "Restart", I swear that its just the same hitting Quit and then starting Amiberry again. :)
giantclambake
commented
11 months ago M'kay, well that was fun...
- Do you see any mention of CD32: device unit 0 lost in your amiberry.log file ever?
No...not a once (see logfiles) ~ I retested all of the above with logging enabled --
amiberry.log -- this is when it behaves badly : as it turns out, to recreate it, press the Reset widget =)
amiberry.2.log -- is pretty much what gets logged when things are all happy, using the Restart widget as per my example.
- Do you even see the CD32 boot screen when you use Quickstart > Amiga Model CD32 ?
Everytime...well, nearly...Cannon Fodder tends to bypass the splashscreen (I think?) ... if I use the Reset widget, invariably I'll see the colorful lockscreen anim ; if I use the Restart widget, I see the dull reddish Amiga CD32 banner before loading game.
For poop and laughter, I performed one of my classic benchmark test runs ..with Sysinfo on standard A500 config, it got 0.75 mips ...@ 25MHz 2.72 mips...Fastest possible scored 3.00 mips, but the emulator locked up getting the bargraph drawn =)
It just failed the Sounds of Gnome music disk test
68K 500chip/500fast 7MHz .... nope, not even close.... " " " 14MHz .... nope, barely discernible improvement... " " " 25MHz ..... no cigar...going for gold next... 020 " " Fastest Possible ..... so, so close...just the tempo is a tad slow, like listening to a 45rpm record at 44.85rpm
....I wonder what happens if I turn JIT on?....(blammo!, crash..), m'kay, question answered =) So it's not just in 32bit land I see this (same segfault), but at least now I have a logfile of it happening...
Inbetween each step above, I'm using the Reset widget, especially changing cpu/chipset types. I should've thought to toggle the NTSC switch just incase the 60Hz timebase could grab the figurative 0.15rpm it needs, without messing anything else up ... hmmm, I should go back and check that later =)
However, I've now learnt not to use the Reset widget when in CD32 mode when it comes to changing media(image). This is akin to me knowing not to use Fullscreen mode (x86-64, X) because it opens a portal to the 9th dimension (and it's worse than that with nvidia drivers)....it's not exactly the same, but as aligned with that joke of a person going to the doctor and saying "it hurts when I poke my eye", and the doctor replies "well then, stop poking your eye" ...
Wrt your lost CD scenario ... I somehow imagine this is system layer stuff somewhere, and aught to do with amiberry itself, if only because I cannot recreate the Lost CD echo from akiko.cpp no matter how ridiculously overloaded I got the rpi3A+ ...ie; doing a single media change as described using Restart button was a 5-10min ordeal on the X desktop (but to it's credit, it did it without crashing =)...and I'm talking not even being able to ssh in to killall -9 amiberry kind of overloading ; tough little board.. lol..
I'm keen to understand in your setup.
I'd suggest grabbing another 32Gb or bigger sdcard, and trying the raspOS 64bit bullseye arm64 image, and reviewing the situation ~ if it works there, that forms a clue/pointer.... ie; answering the question, is it OS related or not?
chrisblown
commented
11 months ago haha, very entertaining..
I'd suggest grabbing another 32Gb or bigger sdcard, and trying the raspOS 64bit bullseye arm64 image, and reviewing the situation ~ if it works there, that forms a clue/pointer.... ie; answering the question, is it OS related or not?
Ok, sounds like a plan..
giantclambake
commented
11 months ago Ok, sounds like a plan..
It just levels the playing field, to the point the only difference is the rpi3 model difference (and perhaps display).
I should've thought to toggle the NTSC switch just incase the 60Hz timebase could grab the figurative 0.15rpm it needs, without >messing anything else up...
It didn't help and screwed everything else up...ended up down near 42.13rpm, letterboxed with top/bottom cutoff...ugly...
Maybe if I changed kernel bootparams to bring up console in 1024x768 (on one of my 4:3/5:4 LCD displays), I'd gain a little bit more with the smaller framebuffer... point is, there's room for improvement me thinks.
Whaaa .. Restart, completely restarts Amiberry doesn't it.
You would think ... amiberry's far too .. enigmatic.. to be rationalized by mere thought alone... I tested your supposition ;
Start amiberry -> Start in Quickstart mode is default -> Quickstart panel, select sysinfo.adf for DF0 -> Start ....
...allow sysinfo to load -> F12 -> Restart ---> you end up restarting amiberry, and you're back at the Quickstart page, previous media unloaded
Change Amiga model to CD32 (note floppy widget becomes inactive, CD widget auto enabled) - load Cannon Fodder.cue from aforementioned archive -> Start
...blackscreen boot, 'Accessing ..blabla' and get to intro music --> F12 -> Restart
...and you're back at the Quickstart page, CD32 model still selected, with the CD image area inactive, and the floppy drive active... ??.... go figure, where's my 'phone... click .... https://imgur.com/0De0UJP.png
This is why I was so pickle footed describing how I interpret the the three R widgets ~ Restart is conditional on Amiga model selected ...at least when model=CD32 has been selected. Following the same procedure hereabove on this amd64 rig, I end up back where I expect to be....ie; https://imgur.com/0MgvUBb.png
So..I dunno ,,,I'll have to see if I can recreate it on the rpi4B4G and see if that divines whether it's a grunt thing, or something to do with the rpi3 amiberry build... BUT... the phone pic above, woeful that it is, ensures us something rather weird is going on =)
More later when I see what the rpi4 does following the same stanza...
I have default.uae setup with Show GUI unticked so for me hitting Restart will boot up the default.uae config (which for me is a >HD booted A4000)
Handling of default.uae is a bit of an artform - realistically I think the equivalent best performance I can get with rpi3A+ is A1200/020/fastest possible ....although I'm pretty sure if JIT worked you could get further, maybe pass Sound of Gnome test.
giantclambake
commented
11 months ago Okay ... this https://imgur.com/0De0UJP.png would seem to be a rpi3(A+) thing ~ I couldn't recreate it on the rpi4, nor on the amd/intel x86-64 machines here.
It's a bug for sure, but you have to ask yourself just how many ppl out there, are using the rpi3 with amiberry? The interesting thing is, the CD image textbox is greyed out, but on the Hard drives/CD tab, I can load an image. It's almost like it hasn't let go of the handle to the currently loaded image...which tallies with how it behaves displaying one image name in the textbox, but always starting the last/previous image instead...(as a consequence of using the Reset widget).
Anyhoo, from the amiberry wiki ;
Restart: This button will stop emulation (if running), reload Amiberry and reset the configuration. This has a similar effect as if >you Quit and Start Amiberry again. It can be useful if you want to change a setting that cannot be changed on-the-fly, for >example, and you don't want to quit and start the emulator again to do that.
Note, 'similar' effect to quit & start. settings that 'cannot be changed on the fly'...and the last bit is intimating that when you quit&start amiberry, the default.uae is read in... not for example the amiga model you've currently selected. So 'reset the configuration' is understated as it were.... =)
//breaking news...
Got amiberry/rpi3A+ to 8.0 mips at cli on a 1280x1024 @ 60 Hz 4:3 display ~ this pushed Sound of Gnome tempo/timing to where it should be, but it was dropping some notes with occasional light crackles ...maybe 4 out of 10 now with this test 8^)
midwan
commented
11 months ago CD32 doesn't boot iso or cue cd-rom images
To Reproduce
- Quickstart CD32, click Set configuration
- Make sure CD drive is ticked
- Select image then choose a CD32 cue or iso file
- Click start
- Purple Kickstart 3.1 screen appears
Or
- Add CD32.rom and CD32ext.rom to ROM area
- Make sure CD Drive is ticked in Hard Drives/CD area.
- Select Image then choose a CD32 cue or iso
- Click start
- CD32 boot animation appears + intro sound ..
- Press F12, then eject, then select image, choose another ISO/CUE
- Press Resume, back to CD32 screen no activity..
Expected behaviour CD image is detected and boots..
- OS: Debian / Dietpi 8.22 (Pi3 Model B)
- Version [5.6.1]
Other info CDTV QUickstart boots CDTV titles ok.
Did you try just selecting CD32 from Quickstart, without clicking on Set Configuration ? It shouldn't be needed if you've just started the emulator anyway, it's meant to be used when you've been making config changes, and you want it to reset them to the options of the Quickstart selection.
BTW I can boot CD32 images just fine here (Pi400 running 5.6.1 on Manjaro)
chrisblown
commented
11 months ago My plan is to try another OS as @giantclambake suggested and I'll report back..
There is definitely some differences between Quickstart and a saved Configuration with the CD32.
If you Quickstart > CD32 and go to Hard Drives/CD you will see CD drive/image ticked.
If you Quickstart > CD32, Save this Configuration, Restart and Load this Configuration you will see CD drive/image unticked.
I'm not sure if this is actually an issue, just noting this inconsistency.
chrisblown
commented
11 months ago Righto, I've just done some testing on my x86 Mac version of Amiberry (5.6.1) and I have been able to reproduce the issue.
First some setup
Quickstart
Configuration
Now, if you recall I mentioned above that if I saved a Configuration with a CD ISO/CUE set, OR selected an image before starting the machine up then it all works. This is because when a path to the ISO/CUE is saved then CD drive/image is ticked.
Configuration - Working
This is reproducible for me and I've done it several times to confirm, interested if anyone else can confirm following the steps above. The problem seems to be that the ticked state of CD drive/image CANNOT be saved without a file also being selected.
chrisblown
commented
11 months ago Digging a little deeper, when you include an ISO/CUE and save the Configuration, here is the diff between the files. The presence of a value for cdimage0= also sets scsi=true. I'm not sure if scsi=true is directly related to CD drive/image being ticked...
-cdimage0=
+cdimage0=/Users/chris/Desktop/Cannon Fodder - CD32/Cannon Fodder.cue
...
-scsi=false
+scsi=trueThe example configuration created above if you add
cdimage0=anything
scsi=true | false The config loads and works fine
midwan
commented
11 months ago @chrisblown If my understanding of the problem was correct, I think I fixed it with the commit above. Could you please test and confirm?
chrisblown
commented
11 months ago @chrisblown If my understanding of the problem was correct, I think I fixed it with the commit above. Could you please test and confirm?
Thx, tested and confirmed (on x86 Mac). This fixes the ticked state of CD drive/image being saved correctly to a Configuration. I'll try on the Pi when I get a chance since I'm using a binary atm.
giantclambake
commented
11 months ago @chrisblown If my understanding of the problem was correct, I think I fixed it with the commit above. Could you please test and confirm?
Thx, tested and confirmed (on x86 Mac). This fixes the ticked state of CD drive/image being saved correctly to a Configuration. I'll try on the Pi when I get a chance since I'm using a binary atm.
I just went to test this ~ but it seems the git master tree is broken atm -- I saw this in x86-64 a few days ago ; I'm getting the same thing with rpi3/4 targets....
Thread 1 "amiberry" received signal SIGSEGV, Segmentation fault.
__memcpy_generic () at ../sysdeps/aarch64/multiarch/../memcpy.S:111
111 ../sysdeps/aarch64/multiarch/../memcpy.S: No such file or directory.I did a git bisect between current and v5.6.1 ....I'm thinking the first round discloses the error ;
g++: warning: ‘-mcpu=’ is deprecated; use ‘-mtune=’ or ‘-march=’ instead
cc1plus: error: bad value ‘cortex-a72+crc+simd+fp’ for ‘-mtune=’ switch
cc1plus: note: valid arguments to ‘-mtune=’ switch are: nocona core2 nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell core-avx2 broadwell skylake skylake-avx512 cannonlake icelake-client rocketlake icelake-server cascadelake tigerlake cooperlake sapphirerapids alderlake bonnell atom silvermont slm goldmont goldmont-plus tremont knl knm intel x86-64 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 znver2 znver3 btver1 btver2 generic nativeBisecting it to bad commit;
8214d58c0ddcd783c9f3782d4f8c3dc51fbd1e10 is the first bad commit commit 8214d58c0ddcd783c9f3782d4f8c3dc51fbd1e10 Author: Dimitris Panokostas midwan@gmail.com Date: Wed Jun 21 21:14:28 2023 +0200
enhancement: added flatpak package files
- Picked from the preview branchflatpak/128x128.png | Bin 0 -> 19851 bytes flatpak/256x256.png | Bin 0 -> 42525 bytes flatpak/32x32.png | Bin 0 -> 6588 bytes flatpak/48x48.png | Bin 0 -> 8545 bytes flatpak/64x64.png | Bin 0 -> 10593 bytes flatpak/com.blitterstudio.amiberry.desktop | 11 +++ flatpak/com.blitterstudio.amiberry.metainfo.xml | 35 +++++++ flatpak/com.blitterstudio.amiberry.yml | 120 ++++++++++++++++++++++++ 8 files changed, 166 insertions(+) create mode 100644 flatpak/128x128.png create mode 100644 flatpak/256x256.png create mode 100644 flatpak/32x32.png create mode 100644 flatpak/48x48.png create mode 100644 flatpak/64x64.png create mode 100644 flatpak/com.blitterstudio.amiberry.desktop create mode 100644 flatpak/com.blitterstudio.amiberry.metainfo.xml create mode 100644 flatpak/com.blitterstudio.amiberry.yml
TIA
solskogen
commented
11 months ago You're using wrong PLATFORM when compiling.
giantclambake
commented
11 months ago I wish =) Long boring vid ... start to finish... https://www.youtube.com/watch?v=8RqLi3V4yIo
This is PLATFORM=x86-64 ...I get the same with PLATFORM=rpi4-64-sdl2 (all on debian bookworm)
On my $LFS builds it's slightly different, but, lets just figure on bookworm atm 8)
solskogen
commented
11 months ago This error is because you're using the wrong PLATFORM on wrong platform. The commit above have no code change what-so-ever. I've only checked on my Pi400 running Bookworm, where amiberry compiles fine and works when I start it up.
g++: warning: ‘-mcpu=’ is deprecated; use ‘-mtune=’ or ‘-march=’ instead
cc1plus: error: bad value ‘cortex-a72+crc+simd+fp’ for ‘-mtune=’ switch
cc1plus: note: valid arguments to ‘-mtune=’ switch are: nocona core2 nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell core-avx2 broadwell skylake skylake-avx512 cannonlake icelake-client rocketlake icelake-server cascadelake tigerlake cooperlake sapphirerapids alderlake bonnell atom silvermont slm goldmont goldmont-plus tremont knl knm intel x86-64 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 znver2 znver3 btver1 btver2 generic nativePerhaps I should've included this to denote previous video;
gcb@gallah:~/amiberry$ cat /etc/debian_version
12.2
gcb@gallah:~/amiberry$ uname -a
Linux gallah 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29) x86_64 GNU/LinuxI'll retest on the rpi4 ...hang in there =)
giantclambake
commented
11 months ago //sorry it takes so long, internet here is like 150kbps upload ~ AU's fixed-wireless NBN is woeful =^/
pi@raspberrypi:~ $ cat /etc/debian_version 12.2
pi@raspberrypi:~ $ uname -a
Linux raspberrypi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/LinuxPLATFORM-rpi4-64-sdl2 https://www.youtube.com/watch?v=9ojYwEVXQg4
solskogen
commented
11 months ago Doing it by video is very inefficient. Just post the error instead. But as you see, you don't get any of the g++ warnings now. It seems to me that you're not running Raspberry Pi OS, or that you've changed it somewhat.
solskogen@raspberrypi:~/amiberry $ uname -a Linux raspberrypi 6.1.0-rpi4-rpi-v8 #1 SMP PREEMPT Debian 1:6.1.54-1+rpt2 (2023-10-05) aarch64 GNU/Linux
giantclambake
commented
11 months ago It seems to me that you're not running Raspberry Pi OS, or that you've changed it somewhat.
Stock Raspberry Pi OS, no changes ...on the x86-64 box, stock Debian bookworm... no changes, fresh git clone, right target PLATFORM....same error. It maybe inefficient, but, video works for me =)
Not that I'm terribly worried ~ git trees break from time to time --- pretty sure with this issue though, I can just meld in midwan's commit here ...no biggy =)
solskogen
commented
11 months ago On the Pi it cannot be a stock install, look at my uname - your kernel is from April. And a completely other kernel. It cannot be a stock install from the latest image (from October).
On x86_64 I also get the segfault.
solskogen
commented
11 months ago I found the commit that borked x86_64: 0873ccf820cdebdb9fa0fafd3882578e9c635d7f
giantclambake
commented
11 months ago ...ummm... 2023-10-10-raspios-bookworm-arm64-full.img ... plus whatever updates to current.
Thanks for finding the culprit ~ on the $LFS builds, compiling amiberry normally hits the segfault, attaching gdb results in no segfault, likewise a debug build of amiberry doesn't hit it either...really elusive behavior.
solskogen
commented
11 months ago Have you been running rpi-update?
giantclambake
commented
11 months ago Ahh! No... that'll be the difference no doubt, I just do regular system updates =)
solskogen
commented
11 months ago Then why do you have a kernel from April then?
giantclambake
commented
11 months ago Best guess? ..the rpi4 is housed in a SunFounder/Pironman v2 enclosure ~ the features of the unit are controlled by the pironman software which is installed as a service (https://github.com/sunfounder/pironman). Considering that's the only non-standard software installed, I'll have to suspect it's install script did it to satisfy some dep.
Thanks for pointing this out ... I'll dig a little further, but I do know it's not something I intentionally installed, that's for sure.
midwan
commented
11 months ago The discussion is unrelated to the bug reported, so please move it to Discussions instead :) Closing this one, as the bug was fixed.
CD32 doesn't boot iso or cue cd-rom images
To Reproduce
Or
Expected behaviour CD image is detected and boots..
Other info CDTV QUickstart boots CDTV titles ok.