@kas1e

Quote:
You've seen the "Nemo revision 2.1 Motherboard Firmware re-flash guide", right? (Per this post you have a copy.) It has details on the rescue flash chip and how to use it to restore the main chip if it gets corrupted.

@derfs
The problem still persists. I reinstalled the system for A1 and updated to UP3.
If you select “Restart System” or “AOS4” from the menu, the system freezes.
If I type “reboot” in the shell, the problem does not occur. Apparently, a reboot from the shell is permanent and does not require closing tasks (I'm guessing).

Thanks to the efforts of Kasie and Balaton, a major achievement has been achieved, solving a problem we've been struggling with for 20 years.
Now, beyond possible further optimizations, we could join forces and go further. Perhaps by reworking the old ATI graphics card drivers and introducing new ones. The same goes for sound cards and other hardware that has never been fully supported.
..<obviously with open source code.

Here's a quick demo. IT MIGHT NOT MAKE SENSE WITHOUT A DESCRIPTION!
I pulled my x86_64 machine out of the closet because QEMU 11 RC1 has been released.
This is a technical/dev demo! It might not be very polished because of my mess
I’ll explain what’s going on:
My laptop (from my son- using “kvm” was more difficult)—an SSH session for an x86_64 PC machine.
There, I run my Peg2 and A1 systems on a Linux x86_64 PC with QEMU passthrough for GPU, SND, JOYSTICK/PAD, etc.
You can switch between AOS4 sessions only remotely. The integrated graphics are disabled. It automatically boots into AOS4 A1.
I installed a Belkin Components F5D5050 in the x86_64 PC case. It is connected via USB and LAN to the x86_64 PC. You can see the blinking LED when using the network.
In Linux, the cards are configured with static IPs, and there is MASUARDE for the ETTH output.
My x86_86 PC has very few slots. It has to use a PCI Wi-Fi card, so for internet access on Linux x86_86, I use the Belkin Components F5D5050 USB card under AOS4.

Now my machine is complete. Nothing freezes due to the network under QEMU. There is a “modern” graphics card under AOS4.
The final cost is 60 euros (not including the cost of the system and software licenses).
P.S. I still have the UP3 update ahead of me on these machines, so... it might be interesting

@MightyMax
Quote:

Latest Balaton suggestion were in right way : access of DAM and RAM at the same time => something with cache coherence.

Short story: When you have MEMATTRF_CACHEINHIBIT | MEMATTRF_COHERENT , you didn't have second one working ! It simple bypass some bits of first one, and there you go:

Amigaos4/CFE were set as "cache-inhibited + coherent" , while Linux are "cached + coherent". Simple removing MEMATTRF_CACHEINHIBIT deal with everything.


Long story:

I start stripping out Linux driver to minimum to find that it still works even in base form as i have on os4 and in raw-CFE version. Then after dumping whole PCI config space, registers and co inside of os4, linux and cfe find out they practically identically : damn.

Then wrote marker after EVERY single operation in the poll loop (it was without interrupts in test case), which like our "debugprintf()" way: where it stop writes, then there we died. And i wrote this marked to the CFE physical memory which survive the "reset" button (at 0x7f000000).

Then 4 tests, in a row, all show that we stop on the clearing of descriptor , always same. So CPU suck smock at descriptor clearing, i.e. writing zeros to DRAM while DMA writes nearby. That was it and clear that what Balaton says (DMA vs CPU fight) is it. And now i were sure too it's clearly something with memory sets. Checked how Linux maps that same memory -> checked how we (not by code, but what bits sets, etc) -> changed in CFE test case - WORKS ! Changed in OS4 test case WORKS ! Fixed in drivers - WORKS !

It may sounds like simple stuff and loosing of a week for just finding wrong settings of memory at init stage, but then, i lear how to write code over CFE, how to hack MCE trap, how to deal with Linux stuff on X1000, and many other things ! That was surely cool journey, if we can say so about sitting a week over 2 monitors :)

@kas1e

And what was the reason or the solution for the lock up?

@kas1e
Thank you!
More than 30% speedup - very nice work!

@All
Thanks you all for tests, much apricated !

Its now in upload query on os4depot.

Also, there is todo i want to do for next version:

- Add interrupt driven TX channel + pre-allocated buffers.

Currently TX is "fire and forget", which add to have speed worse than it can be.

- Re-use RX buffers

Those one also can speed things up.

- Disable promiscuous mode (so not catch whole traffic in the
network)

That one which Petrol found : i just for tests originally enable promiscuous mode which mean all the network traffic flying in the network are filtered through.

- Auto-discover free RX/TX channels instead of hardcoded rx1,tx1

Currently it's hardcoded to RX = 1 , and TX = 1 ( 0 is used by pasemi_dma.resource, which not by resource itself, but by graphics.libraries's PA6T DMA support). So will be "auto" , like if 1,1 fail choose next, etc. I just release it as it, so users will have something stable and usable already, while i can cookie next one when can.

- Remove diagnostic crash hunter

That one was added to catch this damn lockup bug : in each irq fireup i wrote debug info of registers state and co to the physical memory which is survaved when i hit "reset" button, so i can do "d 0xaddress" in CFE after reboot. I still leave it for this version just maybe someone else crash, etc.

- Replace internal Roadshow's copy functions by own AltiVec
based replacement

I already have function for replace, but, it's to be tested and seen if it will give _Any_ benefit, because Roashow it's Roadshow, and have all own internal things even if external copy routines will be used.

- ENV variables with minimal set (choose between internal and
external copy functions, speed, duplex, MTU, etc.)

That one low priority, but maybe worth to have some bits of control there too, so it will be amiiiga, etc :)

If you have any suggestions , feel free

Thanks again !

@Rigo

yup, it works - Thanks again.

@yogi32

Quote:

Thanks for your feedback. Not all shaders are working, but they’ve always been broken in other builds as well. I’ll take a look at the problematic shaders last, once we’ve created an even more stable build. For now, the priority is to make sure it works on as many systems as possible.

Quote:

Of course, I’ll be adding more engines—the build is modular, which is why I kept the plugins separate; this will allow us to add more engines and games step by step. Coming in the next release.

*sigh*

OK, this should work correctly now.

Simon

@Maijestro

Hi Everyone!

Okay, testing ScummVm 20216.1.1. I have an updated AmigaOne 500 with Radeon Rx 550.

Okay, when you choose some shaders, you get an error "Failed to apply some of the graphic options changes: the shader could not be changed". This appears to be the same no matter what OpenGL you are using or Software (SDL2D). I just realized this is happening with ScummVM 2.8.0 Dec 25 2023. So maybe this is something I am doing LOL.

I tested the sierra games. They are working well. I am using the OpenGL graphics mode with OpenGL mit Shaders (ODLES2).

Saving and loading works well. No problems with the interface, no grim reapers over here.

I am looking forward to the rest of the engines being updated and ported over since I am currently playing Ultima 8 with ScummVM.

Keep up the good work Maijestro!

Yogi

I did grab the trace file, will try the extra stack, and if that doesn't work, will get you the trace

@Rigo

User login page has an error

Quote:

@smarkusg

Thanks for pointing this out, it was due to one of the extra feature I added and it pointed out several places that needed better error handling!

Link to new version in original post.

@swisso @Nuder_Try

Thank you for your feedback. Just saying that there’s a DSI doesn’t really help me. I need more information; if possible, please post the DSI—preferably with a stack trace—so I can take a look at it.

Otherwise, it could be anything. As a first step, you can try increasing the stack size from 32768 to 2000000 in the icon information and then run ScummVM again.

As I mentioned before, I just need more information. I also use EnhancerSoftware myself and don’t have these problems. It might also be helpful to know which graphics card you’re using.

In addition, I've also created a ScummVM instance with debugging enabled, which could provide us with more information. In this case, the log is copied directly to the RAM Disk, and we could then analyze it as well.

@yogi32

There is debug output turned on for this release, so if anyone has a crash/freeze and you can get serial output or use DumpDebugBuffer please add it here or on github so I can look into it. Thanks for using VulkanOS4!

Thank you

Hi Everyone,

Testing Odyssey 3.0. These are in no particular order. I am using an completely updated AmigaOne 500 with Radeon Rx 550. Okay, first the network activity in the bottom left is off. I only have 8 open connections and it is showing 16 and they are not lighting up as it loads data. Second,some sites bring the entire computer down, eBay is one of them. The loading speed for most sites does not improve when JavaScript is disabled. Third, it is not caching the fonts upon loading. Fourth, when changing the prefs and saving the program you get the Grim Reaper and when you ignore DSI, it closes the program. Google Search appears to work. That is not the case on a lot of our browsers.

I appreciate all the work everyone is doing for this. We need an updated browser. I am wondering if AI can help us with this?

Looking forward to the next update.

Yogi

@Maijestro
thankyou for your work, it is much apppreciated. I have tried the program, i too get a dsi upon launching at Address 0x01838bb8 but i can ignore the dsi and scumm loads. i am using Aeon X5000 with enhancer which i think might be the cause of the error. of course i dont rule out my stupidity either :?