Hello every one.

I present the consistently curious case of the constantly crashing computer.

So it all started around two weeks ago. I wanted to load up Odyssey on my X1000 OS4 machine but my Internet dock went missing. This is something that has randomly occurred every few years. When a dock would suddenly disappear with no clue as to why and no sign when checking the settings. So I decided to just leave it. Ten tabs open does slow it down.

I then took my X1000 to a friends place for the weekend so he could compare with his Sam system. Soon after he had found some 68K software crashed on my system that worked on his. He also found my video players were old and not good at playing common videos. Guess I never noticed for a while. So he set about rectifying this and installed both 68K and OS4 software. Shogo however played well. But Spencer crashed on load for some reason so I couldn't show that. Even though it had been working fine so this surprised me.

I took my X1000 back home and set it up again. For two nights I just edited files in Cubic IDE and compiled in shell. Pretty boring I suppose given it could play videos again. So I had no issues at that point. The next night I try and open a text file, a crash log as it happens, when ironically doing so instantly crashes! It had crashed MultiViewer. I'd never seen that just crash on a text file. So saved the log and examined it. Some 68K program at the top of stack track which was nameless had crashed which was strange. How did a 68K program get called from native code?

Here's the rogue code from the crash log I needed to trace:



So I set about checking files and not knowing it would become an extensive search. I first wanted to compare to backup files. So tried to run CompareDirs and then that crashed! How was the system even usable? Well it wasn't now! I then loaded DirOpus. I compared libs, classes, and devices and couldn't see any major differences apart from extra binaries added. I ran a program I wrote that lists 68K binaries and gathered a list of 68K programs on my system. Checked with DirOpus and again nothing stands out. So in the crash log I decided to copy out a section of the 68K code and do a search. I modified another program I wrote that searched for hex codes to search only in 68K binaries. So ran it over the whole Workbench to catch what 68K program contained it. I plugged in $2029007c from the crash line. Nothing showed up!

Even though I had gone beyond what should be needed to trace a crash, modifying and writing code to scan files, I still needed to go deeper. So I then set about searching the whole filesystem for this one hex code. But, it was just taking too long, and too many irrelevant files were taking up the search. After filtering them to 68K only had failed. So I decided to get out the all round disk monitor for all occasions--DiskMonTools. I really should have got it out first instead of going down a rabbit hole. So I navigated the Workbench in question to search the whole volume for $2029007c. Boom! It found it! I check and it appears to be embedded in some IFF file which is a strange place for 68K code. I look around the code and it's an IFF datatype file. I check out my datatypes and do another hex search. It's a ZX datatype file from 1996!

So I move it out the way and reboot. MultiViewer, CompareDirs and Spencer now start working! A rogue ZX datatype had crashed them. Strangely, MultiView, the core system program for viewing datatypess, didn't crash. ZX is a Spectrum image datatype. I've never had a Spectrum and no interest in viewing ZX files so no idea how a ZX datatype was installed on my system. At first I thought ZX was some kind of compression format.

This is the one:
http://aminet.net/package/util/dtype/ZX_DataType

Next I set about trying to solve the missing Internet dock issue. I examine the settings and and did a diff of XML setup files. As you can see I'm again going too far to find the issue. But OS4 lacks sophisticated tools to scan and find the problem for you. So does modern OS in a lot of respects. When I clicked on my Internet dock it just showed the grey bar. I've checked the settings and compared it with other subdocks. There's only one difference. One difference I noted was a hidden setting in GUI and XML. But I changed it and it made no difference! In the Misc tab the option "Dock is hidden" is off, while others have it on. Given I want to see it, it's funny it would be missing when hidden is set to off. So I tried setting it to hidden. But it wouldn't save it! It kept turning it off.

Then I found the problem! It was that hidden dock setting. I couldn't get it to work from the check box correctly. And saving didn't make any difference. But I accidentally double clicked the tiny bar below the dock which still showed. The icons came back! Then I checked the hidden setting and it turns it on and off. Suddenly the hidden check mark decides to work. So for hidden setting to work the dock needs to be visible or it doesn't work, while ticking on and off, looking like it does. And you need to double click this tiny grey bar to hide and unhide the dock as well as activating the hidden check mark despite it turning on and off. Seriously who does that!? What sort of stupid design is that?

With my Internet dock now visible again I set about loading up a browser. Only to be greeted by Odyssey crashing. FFS what now?!?

The clue this time was some native code calling a Webkit open file routine:


Both Odyssey and OWB crashed on the same function. Somehow Timberwolf was able to load. Then it too became unstable. So again I start another investigation. Do things appear in threes?

This time the code was fully native. So I couldn't directly trace it to any rogue 68k code. But why did they both crash inside their own routine? Something had to have infected the system like before but somehow had remained more stealth. Was it hidden in plain sight?

I decided to run Snoopy to assist which can also list library and device open calls as well as typical DOS calls. It's not always obvious what is failing as it's also common for functions to fail in normal use, such as looking for ports and environment variables. However amongst the needles in the hay stack as it were something looked strange. A library interface fail.

Here's the log:


The "library.main" and "l.main" suffix are a vestige from when libraries were not fully OS4 native and OS4 interfaces were split into additional library files. Why was it looking for and failing to find an OS4 interface?

So I again compared against a backup. I was familiar with "asyncio" from years ago but it wasn't in my backup. I check my local copy and then it all comes to light. It's a 68k library dated to 1997! What the?! What on earth is that doing there!?

This one here:
http://aminet.net/package/dev/c/AsyncIO

So I found this one there:
http://os4depot.net/?function=showfil ... =utility/misc/asyncio.lha

I copied that in and rebooted. Suddenly everything is working again! Unbelievable!

As i side note part of the issue is the above OpenLibrary() calls are using 0 as version. This is unacceptable on OS4, and since the 90's even, as programs are required to specify a minimum library version. A 0 will default to any version. To be coded correctly for OS4 and above it should use 50 as version which would have caught the above case.

I've never seen a system come unstuck suddenly from a few old rogue files that took ages to track down. It happened over Easter and it was like three days and three nights all over again. Freak file accident. I've looked through my recent downloads and just cannot track down where it came from. Not that I was doing much lately so one reason I didn't get tripped on it sooner. Glad it's over now.

Well, I hope you enjoyed reading the consistently curious case of the constantly crashing computer, as much as I enjoyed writing it, and didn't enjoy experiencing it!

@Gebrochen

I've found sometimes window dragging can go weird and jump around. And scroll bars as well. For example CompareDirs is practically unusable with large files as I try and drag the scroll bar but it just keeps jumping up. And it doesn't support any common keypad shortcuts.

Anyway I checked my settings on the XE which has a 9200SE. Classic. Try that out in the video bench site. Lol. So in GUI Prefs Effects section I have Compositing enabled but Optimise for video memory. I have also have vertical Synchronise on.

It's connected to a full HD monitor and default to 1920x1080x32 mode. Video ram is 128MB. I have about 80MB free with a few windows open on Workbench.

@sailor

Quote:



Quote:

Well there's your answer!

Quote:

Definitely an invaluable resource on graphic card comparisons.

@skynet

It's common for AmiDVD to give those SCSI errors in sloppy windows. It used to happen for me when I had a damaged disc. I suspect it sends SCSI commands to the driver which then converts internally to ATA. Or some kind of SCSI command encapsulated in an ATA command. Since I recall some standard where SCSI wass encapsulated in ATA.

As to the device it will examine CD0: and extract the device and unit so you shouldn't need to configure it. IIRC it can be set in tooltypes. But if you have one drive it should pick it up.

I liked FryingPan, but on OS4 I found it can be faulty, and it was never finished to be fully stable AFAIK. What driver are you using for MakeCD? The SCSI3_ATAPI driver should work or it used to for IDE on my A1/XE. Also are you running the latest patched version? Here is 3.2d if you don't have it.

http://aminet.net/package/disk/cdrom/MakeCD_3.2d

@MamePPCA1

Have you tried EUAE included with OS4 in the Emulation drawer? The only thing is you will need to add your HDF file and I don't recall if the GUI makes this easy or if it needs to be added by hand. It's easy enough to boot WB but it's made for games or single executables under the included OS3.1 WB. Why I ask is if you don't specifically need high speed JIT for your OS3.9 setup then EUAE may be good enough.

@kas1e

Has HKvalhe made negative comments lately? He's quote vocal on feedback and looks like he's tested a lot of updated stuff. But the comments I've read lately and that would include last year were positive or just asking for info and weren't bad in any way I could see.

@geennaam

Quote:

I would say yes to be compatible with both. So both would be supported. The only question would be is if original PPC libraries would be supported or need custom ones. To work like a PiStorm does original should be supported.

Why I would say to support this is because a PPC card, either real or a PiStorm virtual PPC, would be expected to support this when plugged into an Amiga. So the point isn't to be compatible with old WarpOS games or software. The point would be to implement the classic PPC standard so PPC software can work.

In doing so, it also means it would be compatible with OS4.1. While a PiStorm optimised OS4.1 would be nice I doubt that is going to happen. So a Classic OS4 would also run by extension by being compatible.

@MartinW

Quote:

That's the thing. A 1 or 2 Ghz machine is expensive. Checking the prices of the A1222 it looks about as much as I paid for my X1000 and doesn't offer much more.

And unlike those this would plug into a real Amiga. It's rare for a real Amiga to have a 1Ghz CPU though it is possible. So this would really be competing with unobtainium or brokenium that didn't go over 240Mhz.

If it ran on average to a 300Mhz level it wouldn't be much better. But it would open up a market previously locked to old expensive cards. And it would help the main criticism against OS4 not running on a real Amiga.

The installer has a logging option that may help. But it may freeze before it saves it. However being able to log it to a console window would show what it's doing if possible.

@328gts

Quote:

I think it would be feasible now. It might not be the difference a PiStorm makes against 68K where it easily beats an 060 and runs Doom on planar like it was native fast VGA. But this would be cheaper and more attainable than a BlizzardPPC.

@LiveForIt

Quote:

That would be fast enough I think. Since real cards back in the day only clocked up to 240Mhz or so. The only problem is the modern Sonnet cards that average 400 or 500Mhz with some clocking in at 1Ghz! But, those would surely be rare. And an Amiga system with one of those would be both rare and expensive.

I would say this could be done as an independent project. Without Hyperion needing to have any involvement. Though given the effort put in the A1222 which needed an FPU emulator why not go all the way and emulate RISC PPC on another RISC like ARM?

Most sales for OS4 Classic were for emulation. So a project like this would also benefit sales. Last I checked Classic was also the only edition you could buy as digital.

It would make sense if it simulated a Blizzard PPC and associated powerpc library. Possibly a Cyber PPC. But what matters is a PPC library. Given it would take space and resources it may make sense to only emulate the PPC if possible. That would mean it would still need to run 68K code on the built in 68K. And there would be context switching. However, for running OS4, once it boot straps that would be a non issue.

OTOH, it would be good to have a mixed 68K and PPC without any context switching. In this case, a master emulator would detect a change from one CPU to the other, and switch emulator.

Using JIT or not would be a consideration. As it takes up RAM in the host CPU board. Given the focus is on PPC 68K emulation could be static and only PPC use JIT.

@kas1e

Quote:

Zip? Oh no. That's yukky PC thing. On Amiga we use LhA. Or second to that GZip which has native firmware support.

They did some tests on compressed Kickstarts a few years back. But the result wasn't worth it according to results. Still, I wanted to test it myself once I had my X1Boot loader working, since I can control it. And can use XZ for best compression. Takes ages to compress the best but unpacks real fast!

Also, after reading through the latest posts in thread, it looks like the bridge issue is worked around now. I don't have any real Pegasos hardware so cannot test on the real thing. I can only test under qemu like every one else.

@jabirulo

Quote:

Just found your comment. I have the same issue with my X1000 and R7 250. For me the issues started when I installed Update 2.

Did you have the same issue with Update 1? And is your issue confined to Update 2?

@Hans

Quote:

One thing that was definitive of AmigaOS was the RAD drive. And Ramb0. Which OS4 people still used. You could do a soft reboot and it would survive. This doesn't happen with a cold reboot. Unless the firmware erases memory on reset I would consider this a bug. Because Exec always checked the memory for a existing ExecBase which a RAD would depend upon. If Exec isn't doing that but instead creating a new one every time it's not an Amiga Exec.

Quote:

How would this work?

@balaton

Quote:

Oh no. This happened to me on my X1000 with Update 2. It has a conflict with my R7 250. Disabling compositing and interrupts works around it but it's slow after that and not efficient.

I wasn't aware of any similar issues in the RX driver so I'll check that thread out.

I would consider this a software issue in the RX driver. Or graphics drivers as a whole. I wonder if the same issue occurs with Update 1 if that can work.

@sailor

Quote:

Debbie Harry is asking as well?

I'm glad you asked. I was getting a bit lost with all this boot talk. UBoot. BBoot. AmigaBoot.

Now I can only guess BBoot means Balaton Boot.

@balaton

Quote:

Yes that's what I meant. For some reason I had startup in my head. Kickstart/Kicklayout is the correct location and would also point the CD to files at System/Kickstart.

By the looks of it it has just copied the whole dir to system and the post fix failed. Given a CD Kicklayout was installed I wonder if it just blindly copied the whole lot and then overwrites the Kickstart with the proper version at the last minute. Thought that would be slightly lazy if it did.

If it suddenly broke or crashed before postfix that would explain it.

@joerg

Quote:

It was around the time there was that project to rebuild UBoot I got hold hold of the sources. But I wasn't aware the sources were complete and just sitting online. All I know is in the sources I had there were some internal UBoot functions that had no source and were linked in from a binary only. It was also a but quirky looking. Like one of those compiler setups that was hacked together and didn't have a clean way to configure and make easily.

@balaton

Quote:

Isn't this something already emulated by QEMU? I mean, how does it emulate a Mac machine? A Mac relies on nvram in the same kind of way and that has to be stored somewhere.

As to shutting down, no the XE cannot. It was a hardware flaw. The closest an A1 gets to shutting down is a blinking cursor on a blank screen.

The Quit item in Workbench seems rather useless and has been since it was first introduced in OS2 or what ever release had the item there. No Workbench I've seen can actually quit and always complains about some process running. Even if it could quit it would just quit to DOS into a shell window. Or quit to a blank screen without window.