exxos's Atari, Amiga & retro forum

The 40 mhz did not solve the issue.
Also tested the 060LC also runs fine however also unstable with gus playback yam (does not work with mxplay it seems).
1x or 2x does not matter.
Also cleaned all contacts with deoxid.
Midi and opl playback is fine. (even with your old drivers)
Switching the mfp around does also not change anything.
Tested two PSU’s..
Only have et4k’s.. so can’t test that that fancy pancy Mach one you have..
Running yarttt together with playback does not show any errors during testing as long as it runs..

Some interaction with the et4k maybe? No video driver just emutos seems most unstable for gus.
But it always crashes after a while.

The picogus is more stable vs the AMD one.AMD is unable to play files correctly and crashes way earlier.
With the LC cpu it seems a bit more stable vs the rev 6 full one…. I don’t understand…. But it will still crash however the AMD seems to play files a bit better.

@Oldskool

Right, so just to be 100% on the same page:
1) midi and opl playback works fine and without crashes?
2) gus playback result in crash with both PicoGUS and the AMD, but more frequent/earlier on on AMD
3) gus playback sounds correct on PicoGUS but wrong on AMD

When it crashes, can you press the NMI button and see if you get the monitor app to appear on the serial connection?
Basically to narrow down if the machine is still "alive" and can run code, or if it's a buslogic lockup of sorts (in which case it wouldn't be able to process the NMI and execute that code)

The sounding correct on PicoGUS but not on AMD is a good piece of information too.
The sample upload, and parts of playback code is slightly different between GF1 and AMD so that could be quite helpful in narrowing down what's going on.
There is a hardware-side difference too, in that a 16bit access to AMD becomes a single 16bit ISA cycle vs two back-to-back 8bit ISA cycles.
Midi and OPL are both exclusively accessed by 8bit.

Some interaction with the et4k maybe? No video driver just emutos seems most unstable for gus.
But it always crashes after a while.

I'm a little bit on the same page as you on that.

I have couple of other et4ks and I'll try another one to see if I can somehow repro something on this side.
I've not used the Mach32 for quite some time and when I tried it again recently it appears I must have broke support for it at some point so it's something to look into some other time in the future.

With the LC cpu it seems a bit more stable vs the rev 6 full one…. I don’t understand…. But it will still crash however the AMD seems to play files a bit better.

This makes everything weird and I'll pretend I didn't hear that for now :)


All in all there are some good info-points to help solve the puzzle I think, and with some special firmware + mod-plugin builds we can most likely get to the bottom of what's causing this and what needs to be fixed.

1) midi and opl playback works fine and without crashes?
2) gus playback result in crash with both PicoGUS and the AMD, but more frequent/earlier on on AMD
3) gus playback sounds correct on PicoGUS but wrong on AMD

1) Yes midi on the Picogus and on the yamaha sb clone is fully stable. Opl is also fully stable
2) Yes!
3) Yes!

When it crashes, can you press the NMI button and see if you get the monitor app to appear on the serial connection?
Basically to narrow down if the machine is still "alive" and can run code, or if it's a buslogic lockup of sorts (in which case it wouldn't be able to process the NMI and execute that code)

Just tried when it crashes everything crashes. So no NMI.

This makes everything weird and I'll pretend I didn't hear that for now :)

Yes but it is repeatable. And even more strange the LC is not 100 mhz stable on an Amiga. The rev6 runs stable in an Amiga @ 100 mhz.

The 68150 which is really unstable is from aliexpress. The 33 one which works OKisch is from ebay UK seller (sold as 40 mhz part). The 40 mhz is from aliexpress again. So maybe….. still bad part…..Maybe…

Oldskool wrote: 10 Aug 2024 20:11 Just tried when it crashes everything crashes. So no NMI.

Thanks! I was hoping for exactly that.
So a bus cycle is not being ended. Most likely a cycle that gets handled by the 68150, and most likely an ISA cycle.

Oldskool wrote: 10 Aug 2024 20:11 Yes but it is repeatable. And even more strange the LC is not 100 mhz stable on an Amiga. The rev6 runs stable in an Amiga @ 100 mhz.

I think some test firmwares should help narrow down what it going on.
The info we have, including the behaviour of the cpus are valuable and I think we can work with that :)
The problem could very well be that something is dodgy in the firmware, perhaps just on the edge and happens to work on my specific machine.

We can still suspect the 68150 too of course, if it's not happy being overclocked to 48mhz.
I can lend you my 68150 too of course to either verify or get rid of that as a variable.

The 68150 which is really unstable is from aliexpress. The 33 one which works OKisch is from ebay UK seller (sold as 40 mhz part). The 40 mhz is from aliexpress again. So maybe….. still bad part…..Maybe…

The ones I bought both came from LittleDiode in the UK, I got a 40 and a 33 at the same time to be able to test both versions.
Way overpriced when compared to Aliexpress, and who knows where they actually get them from -- for all I know they could be sourcing them from the same place as the Aliexpress sellers. But they were marked correctly and both appear to work (I have mostly used the 40mhz one though)

At the time I was looking they were the only place where I could find 40mhz versions and it appears they are still selling them:
https://www.ebay.co.uk/itm/165866132534 ... Swg8lmkOeJ
https://www.ebay.co.uk/itm/175559431072 ... SwlJ9mkOp8

Yes indeed got that 33mhz one from that uk seller however it was sold as 40mhz.
Plugged in a really different looking et4k. No difference.
Although the samples sound less wrong on the Gus maybe still crashes very fast.

Graphics cards seem to have an effect…
One of them the AMD always plays left channel louder…

Very strange behavior….

The more I test the stranger it becomes….

Oldskool wrote: 10 Aug 2024 21:11 Yes indeed got that 33mhz one from that uk seller however it was sold as 40mhz.
Plugged in a really different looking et4k. No difference.
Although the samples sound less wrong on the Gus maybe still crashes very fast.

The type of cf also seems to matter. I’m testing with a very old one (128mb) others seem very unstable.
Newer one also crashes….

Do you by any chance have a slower oscillator for testing? It would be interesting to see if everything behaves if running the bus at the rated speed.
Or well, 32 mhz was the closest to rated speed I could buy at Mouser.
They also have a bunch of 40mhz in stock now too, I ordered one ages ago when there were none in stock and had to wait for them to be manufactured and one eventually shipped to me :lol:

ACHL-32.000MHZ-EK
ACHL-40.000MHZ-EK

I assume they must be available somewhere in EU too. I just usually turn to Mouser because I usually end up over the free shipping threshold anyway.

Edit: if you are getting oscillators, I'd get myself an ACHL-50.000MHZ-EK as well because why not? They're all very cheap and if either 68060 or 68150 don't like that additional overclock it's no big deal. I'm running mine with the 48mhz one to keep similar to your build but 100/50 works fine here too.

Tried a different cf card.
And played around with the autofolder.
It does not crash anymore it seems now with one of them..
Testing with the AMD one. Still sounds strange.
The videocard seems important for the crash behavior…

How does your autofolder look..
What is the order….

Currently don’t own other crystals.
Asked that little diode guy for a 40mhz one as he send me a 33…

I have found a cf-Gus amd-videocard combi we’re it does not crash but still does not sound correct.
The PicoGUS sounds correct but still crashes.

Something strange with that bus….

Oldskool wrote: 10 Aug 2024 22:47 How does your autofolder look..
What is the order….

This is the EmuTOS config, the Mint one is similar but skips wdialog and includes Mint.
That's the EmuTOS config. The mint one is similar but skips wdialog and includes mint.
Accessories are cops, nova_col. And mintsett when running mint.
(I believe xcontrol is unfriendly to 060 machines, hence cops)

emulator,menu,sta_vdi,saveoff,nova_col all comes from the nova driver website.
nova_col is configured to remove mouse acceleration as well as setting the (broken?) screensaver stuff to 0 seconds which I think is supposed to mean off - which may or may not work correctly(?), hence also the saveoff.prg supplied from the same website. belts and braces and all that :lol:

I don't have NVDI currently installed but when you have it, you want it after sta_vdi.
You'll also need to configure nova properly for this fact in menu.prg options.
I'm not sure if you need to manually rename/remove the nvdi screen drivers from the gemsys folder or if nova takes care of this for you. I suspect you need to do it yourself (or install nvdi with the nova option).


I use Mint 1.16.0 because I never had much luck with 1.19+NAES.
Just random freezes with that setup. Same thing on my 520ST, the V4SA, and Raven. Extremely frequent with network enabled but also even without.
I'm sure it must be something with my Mint setup but reverting to 1.16 on all machines solved the issues for me so I'm happy using that version.

The videocard seems important for the crash behavior…

I wonder if the videocard is not releasing the databus fast enough for how it's being accessed. I'll try some different cards when I'll get a chance, and also my current card but with the "zero waitstate" jumper set to off.
I'll make you a firmware with some absurd amount of additional waits between 68150 bus access too as a way to see if that makes a difference.

Silly question but I'll have to ask; the ATF1508 is the 7.5ns version and both ATF22V10C's are 10ns versions right?

Found an 28,6363… mhz crystal.
The crashing is gone.
Playback sounds a bit slow especially on the AMD card.
Not sure if the left right channel was OK on the AMD one.
However it is stable at 28….mhz.
No more crashing during GUS. (Both cards)

ATF1508as 7
ATF22V10C's 10

Ordered 33, 40 and 50 mhz crystal.

Edit/Update:
Nessi 240705 seems also stable with the AMD Gus @48. No crashes!!

But on my GUS it seems that the right channel is off a bit (plays a bit softer) but maybe that is a problem with my GUS clone. But everything is there just a bit too low in volume.
My friend has a real GUS AMD so maybe try that one as well.

Great that you keep the older versions as well in the github. You mentioning NAES + Mint 1.16 vs the newer Mint crashing which triggered a thought about trying the older Nessi....... and yes that one is stable... with GUS playback

So results are

Stable
Old Nessi (240705) @ 48 GUS playback
New Nessi @ 28,6363 (no other crystal available) GUS and PicoGus playback

Unstable
New Nessi @ 48 GUS and Picogus playback (full crash when playing mods stuff).

So you will probably know what this means I hope……. I hope it makes sense..

I tried the MOD plugin on Panther/2, and GUS. It plays, but for example: the mouse doesn't work properly (it runs to the left). OPL and MID not working.