@Maijestro

Quote:
Certainly not "solved"; more like, "alleviated".

Quote:
No no no, it's actually very easy to use! I got it working in Rave without much hassle. Any developer can contact me if they'd like to give ExtMem a try.

Whether an application can benefit from ExtMem is another question. Basically, it's good for storing any data that doesn't need to be accessed at a given time, or very frequently. Like undo data, for example. Or game assets not used in the current level.

@Djk83

Create and restore a backup of AmigaOS4 is easy.

I simply created a drawer on another disk different then SYS: and copied all the SYS: contents here.

As I applied Update3 and I found some issues, I rebooted with OS4 install CD, run directory opus, deleted all files and drawers in SYS: and copied there the backup.

I have a Sam460.
Up until recently it booted fine with a RX560.
Shortly after installing 4.1FE update3, the machine stopped booting into Workbench.
It still worked with a HD5450.

I've now reverted back to an earlier backup, 4.1FE update2.
Still doesn't boot to Workbench.
The boot appears to fail right after loading Kickstart.
No splash screen, the monitor loses signal and the boot appears to stop dead.

Any ideas?

Cheers

Hi Djk83,

I didn't have any problems updating with AmiUpdate, except that Candi stopped working.

Is it surprising that Candi works for you with update 3?

I replaced the Workbench.library file with the old one, and so far everything is working perfectly.

@smf

Quote:

As @smf mentioned in the quoted fragment, grey screen occurring between the U-Boot and AmigaOS splash screen indicates a problem with Kickstart. Obviously, grey screen is not very informative, and connecting through a serial cable may be a bit of a hassle for somebody who didn't do it before. Being a Sam owner, I have little experience with X5000, but still I have a small observation that I somehow hope could be helpful.

When supporting my colleague in restoring his X5000 back to life after Update 3, accidentally I've made a typo in the Kicklayout file in the bootable pendrive I've created. This resulted in a strange behaviour and also a grey screen - even after we've reinstalled AmigaOS from scratch. Of course the problem here was that because of that typo, one of the files from the Kickstart wouldn't load and at the same time it tried to load the mistyped file that did not exist at all.

How did I learn about it? I have entered the boot menu, selected Boot from Hard Disk option, and then triggered boot procedure by typing "boota" in the command line. This way I could see some useful information during Kickstart loading, in particular the message about the missing file. Much more helpful than simply a grey screen. Now I wish I knew that before we decided to format the SYS partition.

My point is, maybe someone who still hasn't resolved this issue, could try this approach and see if it brings anything to the table.

@daveyw

Looks like Update 3 can mess up with USB.

Feel free to look at my post in the other thread (which also is a follow up on this post). I described issue with USB after applying Update 3 on X5000 and how it was resolved.

Yesterday, together with my colleague, we took another attempt at solving the issue with his X5000/20 after failed Update 3 installation.

tl;dr
We have decided to reinstall AmigaOS from scratch, and eventually succeeded in installing Update 3 from the downloaded archive, but first we had to solve a problem with USB by doing "usb reset" in the U-Boot. For the detailed description, please continue reading.


1. Bootable USB preparation
Using my Sam460, we've created a bootable USB stick (this was the easy part, thanks to this tutorial with a great, screenshot illustrated guide attached).

2. USB problem
We've inserted newly created bootstick and launched X5000. Any hopes that we've had, faded away right after AmigaOS splash screen. Workbench greeted us with a grey screen with only a top bar with a Boing Ball visible, and some Grim Reaper errors popping up one over another. The errors were mentoning hid.usbfd and a keyboard. We've unplugged both mouse and keyboard right after launching a boot procedure, which left us with only single Grim Reaper error related to CANDI (I still don't understand why it was there despite booting from freshly created USB, but this makes me think that the original corrupted OS installation from internal SSD was still involved in the process).

Initially, I thought that I have made a mistake when preparing the bootable pendrive. We've carefully created another one, but still no luck.

We've also tried with replacing the ehci.usbhcd driver from Update 2 (despite it was X5000/20). Obviously, that didn't help as well.

We've ended up performing "usb reset" in the U-Boot. Only after that we've experienced a proper AmigaOS installation screen after booting from the pendrive.

3. AmigaOS fresh installation
At this point we were already short on time and decided not to spent another (possbily frustratingly fruitless) hours trying to repair existing installation.
Instead, we've just quick formatted the system partition and proceeded with fresh installation in the following order:
* AmigaOS 4.1 FE
* Update 2
* Enhancer Software 2.2
* Update 3

4. Final thoughts
I don't the know the precise details of the AmigaOS 4.1FE setup on which we originally failed to install Update 3, but certainly we had Update2 and ES 2.2 installed, and CANDI up and running during the Update 3 installation. Knowing that the CANDI doesn't play well with Update 3, on second attempt we haven't turned it on.

I want to emphasize, that prior to applying Update 3 for the first time (before all the things went off), we didn't have any problems with USB devices. Keyboard, mouse, pendrives... everything was working fine. This makes me think that the failed update messed with the USB on the U-Boot level, but I have no idea how that would even be possible.

This time we wanted to try installing Update 3 via AmiUpdate, but for some reason AmiUpdate didn't see the proper server and as such, we couldn't connect. Only after installing Update 3, AmiUpdate started working as expected, enabling future updates.

@Maijestro


Skethblock supports extmem.

* I restored a backup with the pre-update3 installation -> Internet connection is fine
* I applied update3 again -> Internet connection is KO

At least, the issue is reproducible at will.

@vagappc

Thanks for checking. The more input, the better.

@joerg
Probably the reason for lha on Amiga was that PKZip was copyrighted and maybe also patented while lha was free and achieved better compression than zip but could not replace zip on PC where that was already established but could become widepread on Amiga where zip wasn't yet present. For BBoot none of case insensitivity nor Amiga attributes are relavant as this archive primarily stores the sources that I wrote and compile on Linux so other format would actually lose attributes. Users only need the bboot binary from it and most users use it for QEMU on other platforms where extracting tar.xz is not a problem. So maybe those who use it on real Pegasos II can extract it on some other machine too which is a bit inconvenient but not a big barrier. I'm not sure it's even possible to download it from codeberg from AmigaOS given the browser situation.

Quote:
The flags are exactly the problem why PPC can't use hardfloat in QEMU. The PPC not only has cumulative flags like other archs but also per operation bits which need to be cleared and reset for each operation. Clearing the bit before each operation would be slower than using softfloat and not emulating these is not acceptable either (even optionally as checking for that option would also make it slower, I've tried that before). So the only way would be to detect if guest reads flags and recompute last FP op to provide per operation bits while we could skip updating these bits otherwise if guest does not access them. Most apps never read these so they could use hardfloat then. But somebody should look at implementeing this and submit it to QEMU.

@sailor
The BBoot README says:
Quote:
Primary advantage may be that it's faster and if PCI setup is enabled ("Apb" option) then also fixes interrupt controller setting which may avoid lost interrupts with multiple PCI cards. Also truncates 64 bit BARs of newer cards so AmigaOS can see them but that's not enough to use newer GPUs via a bridge because the bridge would also need to be handled which is only done by newer, still unreleased kernel.

@MazinKaesar

Update 3 installs AmiSSL 5.25 - I believe it is still the latest.

An installation log is not saved by the OS4 Installation Utility (unlike what you can choose to do with the Installer).

Edit: BTW, I would be very surprised if AmiSSL had anything to do with the network driver working or not.

Best regards,

Niels

It seems the issue is in AmiSSL version provided but I can't find any log to check.

@MazinKaesar

I just checked on my Sam460LE, I don't have the problem.

I set my PubTest partition (the one I used to test the various beta versions of Update 3 up to the release) back to its initial state, i.e. with Update 2 and the other later small updates. Then I installed the publically released Update 3 (fetched from my account at Hyperion's page) and let it reboot, and the network came up with no problems.

Best regards,

Niels

The network device in no more present in the list of the wizard, you can use the "folder" button to get the correct file and it is recognized and the connection is refreshed. But it does not work anyway.

Maybe it could be a bug of Update3 you can find only in SAM460CR/LE.

Can someone provide me with a location to video that I can test with Emotion that would prove that I have everything set up properly?

@AMIGASYSTEM

Quote:

As already mentioned, the 4GB problem could be solved with Exec Extended Memory, but there are hardly any applications that use it. Perhaps the developer documentation is simply too difficult to understand. Or perhaps people have already tried it and failed.

https://wiki.amigaos.net/wiki/Exec_Extended_Memory

This future would also be useful for the RAM disk....

Perhaps it is not yet mature enough to make it worthwhile to use the function.

With or without support, it will still take a very long time to create a fully stable port of Odyssey, as very few people are working on it.

Nevertheless, I'm keeping my fingers crossed that one day we will be able to use a browser that allows us to make better use of the Internet.

@afxgroup


what ever happened to this? I would assume this would be a perfect test case for it.

Thanks for taken the feedback onboard.

I do have quick question if you know anything about AHI setting and if QEMU setting confit with it.

I got audio out, I have it set as SB128: HiFi 16bit stereo++ and can hear the test beeps.

I installed both AmigaAmp and TuneNet, both complain about AHi.device not being update, so I downloaded and installed the latest version, but still come up with the same error.

I never had to play around with this on my X1000 it all just worked. cheers.

I having fun time resetting up my system on this QEMU, so far no Gurus, which I'm kinda amazed by so far, even on my X1000 i would of had one by now. Just this AHI issue.

Thanks again for the work on the app