exxos's Atari, Amiga & retro forum

stephen_usher wrote: 28 Aug 2023 22:05 Well, folder name corruption on the TT (TOS 3.06, HDDriver 10.10 running in TT RAM, UltraSATAN)

So it seems whatever the fault is, it's pretty common then.

My only thought is to try and compile TOS206 but with a previous version of the AES. Not sure what chaos that would cause but even so, if the problem is in the later AES versions, there's no way to know where.

I mean NVDI replaces a lot of the VDI stuff. So there must be some buffer overflow relating to the desktop somewhere. I can only assume something in ram gets corrupted and trashes maybe something in lower ram causing the desktop to crash but not the entire system as the interrupts are still triggering.

Looking here http://www.avtandil.narod.ru/tose.html
T0S2.00 still had the older AES. So that would be simple to flash a ROM and try it as a fair bit of stuff must have changed by then anyway.

I attempted to test this with TOS 1.62 on my STE, but I couldn't even get the damn thing to boot without crashing with either Cosmosex or Ultrasatan (They are basically the same though) and HDDRIVER.

Very strange behaviour.

exxos wrote: 28 Aug 2023 22:18

stephen_usher wrote: 28 Aug 2023 22:05 Well, folder name corruption on the TT (TOS 3.06, HDDriver 10.10 running in TT RAM, UltraSATAN)

So it seems whatever the fault is, its pretty common then.

Given that it's not breaking the underlying operation it's probably just a display bug in the desktop code and not GEMDOS.

stephen_usher wrote: 29 Aug 2023 10:11 Given that it's not breaking the underlying operation it's probably just a display bug in the desktop code and not GEMDOS.

But most of the time it bombs out.

I wondered if it was text related like calling text routines a lot, but NVDI didn't fix it.

exxos wrote: 29 Aug 2023 11:34

stephen_usher wrote: 29 Aug 2023 10:11 Given that it's not breaking the underlying operation it's probably just a display bug in the desktop code and not GEMDOS.

But most of the time it bombs out.

I wondered if it was text related like calling text routines a lot, but NVDI didn't fix it.

It looks like an uninitialised pointer or overwritten pointer bug, probably the latter. Something has a memory leak and has overwritten the folder text pointer. If the data pointed to is in real memory and has a zero byte early enough then all's fine. If the overwritten pointer is pointing to a memory address which is invalid or there's no NULL value early enough for the maximum data the VDI will take then *BANG* you get a bus error.

So my journey with TOS200 is a odd one because it was actually a PRG. after loading nothing happens it looks like the machine just locks up. Regardless of if I boot from 104 or 206 from ROM.

My 4 EPROMS won't program. Well they do, just come up blank. So found a old ROM which was blank in the upper bank and used that.

Tried TOS205. Didn't boot. Tried in Steem, didn't boot. Tried german 205 didn't boot. Then read it doesn't work in Steem. So god knows what's up with that.

Like everything, always has to be maximum chaos for something which should take like 5 seconds :roll:

Trying my test files in steem and the weird folder corruption happens in there as well. My make it a little bit easier to diagnose where the problem is somehow :shrug:

As I said previously, it looks like it's a Desktop display bug. Something seems to be overwriting the pointer to the string passed to GEMVDI.

stephen_usher wrote: 31 Aug 2023 11:33 As I said previously, it looks like it's a Desktop display bug. Something seems to be overwriting the pointer to the string passed to GEMVDI.

Yes I know, I don't disagree with you. It is finding it which is the problem. I just wanted to rule out the hard drive driver itself because Steem does its own thing there. Also debugging in steem will be the order of magnitude easier than on real hardware.

I posted on Steems forum to see is Steve can help diagnose the problem. It needs someone who is familiar with how the operating system works, steem, and the steem debugger. If he is unwilling to help then I don't know what to do, it will just have to remain broken I guess.

The best way to rule out the driver is to not use the normal GEM desktop and instead either use a shell such as Gulam or a replacement desktop, such as Kobold.