Raven060 (luciodra build).

[luciodra]

I received the two 68150s, the 40 is used, the 33 is new. From the first initial tests, the 33 doesn't even seem to start, while the 40 seems to go better than the other but then it stops. At 96MHz not even talking about it... very unstable.

[Oldskool]

So I have a 68150 33 from littlediode and a 40 one from aliexpress.
Both work at full speed with LC and Full (and all inbetween frequencies I tested).
You can pick one for Christmas.

Babbo Natale

[agranlund]

apart from the loading artifacts.

What are these loading artifacts and how do they look?
In case it gives some clue about the general issue that seems to be plaguing your machine.
(are they graphics corruptions of sorts?)

[luciodra]

https://youtu.be/MV6ptx4ijqo

@agranlund
Everything freezes when running programs, the most problematic one seems to me to be Sndplay.
I have now run several hours of memory testing with Yaart, both ST-ram and TT-ram and it has never crashed and zero errors.
It's definitely better but we're still talking about 48MHz.

@Oldskool
Thank you again, but I would like to test better first...

[luciodra]

https://youtu.be/Kuy3XmI95xg

I made this video now at 96MHz. Then I ran Gembench in continuous mode and after a while:

IMG_1679.jpg (597.75 KiB) Viewed 179 times

I tried pressing NMI but nothing.

[Oldskool]

When looking at the video and reading your description I don’t think another 68150 will solve it indeed.
It’s however for me still somewhat unclear and a bit hard to understand.
Can you maybe make one table or crisp overview of the problem maybe per frequency.

[luciodra]

When looking at the video and reading your description I don’t think another 68150 will solve it indeed.
It’s however for me still somewhat unclear and a bit hard to understand.
Can you maybe make one table or crisp overview of the problem maybe per frequency.

What you say about the MC68150 is right, but it is clear that by replacing it with another the improvements are notable. If before at 96MHz it blocked immediately, now I can work on it for 20-30 minutes before having problems.
My doubt is: can a component work at 30% and then at 90%? I knew it could be yes or no.
This morning I'm trying with a solution that I found many years ago by replacing the 68000 of my Amiga 600: I took out the 68150 and cleaned everything with isopropyl alcohol. We see...
I keep thinking that it could really be something very stupid, for example: what do you have in the AUTO folder? I also read about ISA_BIOS.PRG
Last thing: can the graphics card play a role? The ET4000ax is really hot and I put a heatsink on it...

[luciodra]

@agranlund

In the first ISA slot I inserted a network card for testing and I have the impression that by removing it the system is more stable... is this possible?
I wonder about the usefulness of the isa_bios.prg in the auto folder...

[agranlund]

Last thing: can the graphics card play a role? The ET4000ax is really hot and I put a heatsink on it...

From the video I share Oldskool's suspicion that the 68150 is probably not the issue, or at least not the one I would suspect first.
If that was the case I'd expect it to crash or behave incorrect almost immediately.

Incompatibility with the graphics card could be something for sure. I've only tested with the few I have.
But since they are expensive I'm not sure I'd rush out and replace it without more proof - unless you happen to have a bunch just lying around.
Read/Writes to the card stalls the system until the card says "done!". If something is not quite correct somewhere and the "done!" never arrives - then you will end up hanging forever and with a non-responding NMI.
(Not saying the card would be faulty as such - if this is what is happening then I'd be more willing to place the blame on Raven not being compatible with it)

I keep thinking that it could really be something very stupid, for example: what do you have in the AUTO folder? I also read about ISA_BIOS.PRG

If searching for a specific issue I would try with as little as possible in the AUTO folder to get rid of the number of different variables that it can be.
Exactly the same with hardware, but since you need pretty much everything to get to the desktop there's not much you can remove.

Does the same issue happen with _nothing_ in the auto folder and just a black-and-white EmuTOS?
(You may want to keep rvbios.prg in the auto folder though, it contains the official Motorola support package which is required to make some programs compatible with 68060)

In the first ISA slot I inserted a network card for testing and I have the impression that by removing it the system is more stable... is this possible?

It is possible. Basically anything that disturbs the bus could be the cause at this point. RAM/ROM too but I think it's less likely (but certainly not impossible) based on what you told me about the NMI button behavior.

I would remove all cards except for the graphics card if hunting for what the issue can be.

A more throughout test could be to also remove the graphics card and see if commandline-only EmuTOS over serial connection can trigger the same issue to happen, but it'll be harder to find programs to run..
I think the YARTT memory tester runs as textmode only so that could be one.
The though process there being; if it's rock solid without graphics card but has issues with graphics card then we could start suspect it's either:
a) graphics card specific or b) isa-bus in general

[agranlund]

I wonder about the usefulness of the isa_bios.prg in the auto folder...

For now, if you are just hunting for the general instability issue I would not use it at all (and no other ISA cards except for the graphics card).
The graphics card is not plug-and-play and doesn't require isa_bios at all.


But in general.
You need this program in the auto folder for using ISA cards.
It needs to come before anything that use the ISA card so I'd put it somewhere early in the boot process. I have mine right after rvbios.prg.

Its most important function is to activate + configure ISA plug-and-play cards and by default it configures all cards to whatever they claim is their "preferred" settings.
It makes no attempt to automatically resource manage to avoid conflicts between different cards.

If you have conflicts between two ISA cards you would need to edit "isa_bios.inf" and manually assign io/mem resource overrides for the ones you want.
"isa_bios.log" lists all your plug-and-play cards, the devices within each card, and the valid configuration options they accept.
Finally at the very bottom it lists how it has configured all your available devices.

If there is a resource conflict (for example, two devices wants to use the same IO range) you would need to reconfigure one manually using "isa_bios.inf".

Manually jumpered non-plug-and-play cards are not managed by isa_bios and needs to be configured using whatever jumpers they have on the card.

It's very much like being back in the "good old" MS-DOS days again.
Though this is perhaps worse with having to deal with textfile instead of GUI to configure plug-and-play cards.