exxos's Atari, Amiga & retro forum

The general rule of thumb when debugging is always take the machine "back to stock". Trying to debug stuff with various add-ons just making the problems worse to diagnose.

Steve wrote: 26 Apr 2022 11:59 @Dbug I do not think you have a power issue, why? Because my TT has exactly the same PSU as your MegaSTE & you have re-capped it. My TT has: NOVA, Ati Mach64, Stormy RAM, Thunder IDE, Lightning VME, Internal fans x2, RaSCSI (PiZero2), Belkin powered HUB - all inside - all powered by that same PSU, all is well.

Ok.

Steve wrote: 26 Apr 2022 11:59 You haven't mentioned your graphics drivers yet, are you using Ideks? or NVDI's? If one, try the other ...

I'm using the latest Idek's drivers MSTE_Mach32_V301.zip from https://silicon-heaven.org/atari/nova/MegaSTE/Mach32/
Tried in 800x600 and 1024x768 in 256 colors, did not change Kronos crashing.

Last time I used NVDI was a veryyyyyyy long time ago, is there a tutorial somewhere that explains how to install/configure a good version of NVDI that supports graphics cards, I thought NVDI still required some third party driver, does it knows about to use a VME Mach32 card by itself?

NVDI is usually important to run *with* Idek's driver. You just install it as 'standard shifter' graphics mode, then in Idek's NOVA driver menu (the one that counts down for a few seconds) press space to enter the menu, select 'choose GDOS' and type 'NVDI.PRG' and then save.

It won't support a Mach32 by itself only et4000 afaik. So use in conjunction with Idek's driver.

NVDI fixes & improves the GDI/VDI so this may fix your Kronos issue perhaps?

exxos wrote: 26 Apr 2022 12:08 The general rule of thumb when debugging is always take the machine "back to stock". Trying to debug stuff with various add-ons just making the problems worse to diagnose.

I totally agree, my problem in this case is that the machine is stable when everything is still installed in the machine, except the nova drivers are not enabled and the Mach32 is not in use.

Case in point, I tried to install NVDI 5, first running with the graphic card not running, the installer did work properly, no error at all, except on startup it somewhat ran in a weird resolution (640x350 monochrome) totally ignoring the Nova VDI selected resolution (800x600x256), so I guessed I did something wrong [*], deleted all the nvdi/gemsys/assign.sys/drivers, etc... stuff, rebooted with pure Nova to make sure I was back to a working baseline, even ran GEMBench to make sure everything was fine.


Then I tried to install NVDI again (from the same exact source, to the same exact destination) and during the "Unpacking archives ..." it started to print out some "bad tablebad table.... CRC error" text, ultimately closing with a "Program termination!"


To me it looks like some data corruption when the machine is going through a lot of memory juggling, but only when the VME card is active.

I've not done any of the motherboard modifications with resistor bridges, etc... (was not sure if that concerned the MegaSTe) or DMA chip replacement either because all the corruption problems I had copying files disappeared after I replaced the 68000 by the low power model.

[*] just realized what Steve wrote: "then in Idek's NOVA driver menu (the one that counts down for a few seconds) press space to enter the menu, select 'choose GDOS' and type 'NVDI.PRG' and then save." :sorry:

Boot up the MSTE with press CTRL with a SM124 Monitor connected and install NVDI5 maybe with new files ...

Post a picture from your MACH32 ISA card ...

frank.lukas wrote: 26 Apr 2022 18:01 Boot up the MSTE with press CTRL with a SM124 Monitor connected and install NVDI5 maybe with new files ...

So I managed to reinstall NVDI, so that the README.1ST said that "If you use NVDI together with the NOVA-VDI, then make sure that NVDI loads after MENU.PRG" (in this case MENU_E), I did that, making sure the running order is correct with XBOOT.

Then I selected NVDI.PRG in the GDOS Menu on boot... and ended up on the desktop without NVDI enabled (the NVDI desk accessory and gembench both tell me that), and in the AUTO folder NVDI.PRG has been renamed to NVDI.PR.

Question regarding the running order: Do I still need STA_VDI.PRG, and if yes, should it run before or after NVDI?

frank.lukas wrote: 26 Apr 2022 18:01 Post a picture from your MACH32 ISA card ...

There you go:

Your MACH32 is not a normal standard ATI MACH32 2MB DRAM or VRAM card with 135Mhz RamDAC. Your card has a special little BT RamDAC with a max of 85Mhz and the card is a 1MB one so the max is 1024x768 /256 Colors. You need to run the VMG program and edit the sta_vdi.bib so delete all resolutions above 256 Colors and 1024x768 pixel and save the new one ...

frank.lukas wrote: 26 Apr 2022 18:29 Your MACH32 is not a normal standard ATI MACH32 2MB DRAM or VRAM card with 135Mhz RamDAC. Your card has a special little BT RamDAC with a max of 85Mhz and the card is a 1MB one so the max is 1024x768 /256 Colors. You need to run the VMG program and edit the sta_vdi.bib so delete all resolutions above 256 Colors and 1024x768 pixel and save the new one ...

Sure, I had all these higher resolutions that would not work, but was that a problem as long as the one I selected was the 800x600x256 @60hz?
(I removed them and saved, now all I have is 640x480, 800x600, 1027x768, in 2 and 256 colors)

I have a feeling that you are having DMA transfer issues to do with bus loading... I doubt it is anything to do with the graphics driver to be honest.

I don't know if anyone has ever replaced the data/address bus resistors on a Mega STe before:
https://www.exxosforum.co.uk/forum/viewt ... 235#p27504

But I know that I had to do this on my TT to resolve bus-loading issues.

Is there a difference, from a "bus loading" point of view, between using 800x600x256 vs 640x480x2 (both on the Nova card), because just to test I tried Kronos in 800x600x256 -> Kaboom, but in 640x480x2 it launches just fine


EDIT: I ran all the tests just fine... up to "raytracing with inkshape" and then bombs and back to desktop