TF536 + 68000 relocator and ROM board project.

[stephen_usher]

I've rebuilt the drive on the TT and I'm back operational again.

However, the new fun thing is that the machine won't reliably read the floppy if the UltraSATAN is plugged into the ACSI port but not turned on. Very strange.

Anyway I get these results from last week's EmuTOS snapshot. The speeds seem a little low.

IMG_2114.jpg

[JezC]

However, the new fun thing is that the machine won't reliably read the floppy if the UltraSATAN is plugged into the ACSI port but not turned on. Very strange.
IMG_2114.jpg

I've seen this reported on other topics on this site... but old age is hindering me remembering much more than that... have a Google for it and I hope that helps you a bit at least!

[stephen_usher]

I know. I seem to remember people asking questions about the first couple of characters of file/directory names getting corrupted. I wonder if the DMA chip is dying.

It's just happened again with xcontrol.acc (though it's somehow still loading).

Anyway, I have gembench running on loop mode at the moment to check the non-I/O parts of the system thoroughly.

[stephen_usher]

My Google foo is not good today. All STE DMA issues and vfat long filenames.

I do remember seeing posts though.

[stephen_usher]

Actually looks like the standard DMA problem that Exxos describes in The LaST upgrade pages. Seeing as this has got worse over time I'm guessing this is dying silicon.

I can try the pull-ups on the DMA first as that's an easy fix and I have some 2.2K matrix resistors.

[DoG]

When I run TF536 and US (and IDE stuff) it got scrambled filenames. Someone else reported the same. So something is screwing up dma. I got pullups resistors on dma and changed address and data bus resistor arrays. This was on a Mega and you got a 070789? Seems that old boards is screwing with us since it working on H4/H5?

Or are you using the on board IDE on TF card?

[stephen_usher]

No. There's nothing connected to the IDE.

Floppy reading is starting to become iffy now too, even with the TF536 removed. It gets better the more reads are done, almost as if something's warming up in the chip.

I've got Carrier Command running from floppy and TOS 1.04 (EmuTOS has stopped being able to read the floppy reliably at all as it seems to be running things faster). It took a few tries to get it loaded and running. The first few times it read the music it was getting corruption but after about the 3rd time it was reading the music samples correctly (from a Goex drive, so it's not the physical floppy.)

I think I might buy a replacement -38 DMA chip from Exxos, along with a socket. (The current chip is a -38.)

[agranlund]

Anyway I get these results from last week's EmuTOS snapshot. The speeds seem a little low.

I don't know what you're "supposed" to get without NVDI installed but CPU speed seem normal, as do ROM and ALT-RAM speeds.

The GEM display stuff is going to be doing huge amount of ST-RAM access and that's not blazingly fast. Not sure what normal numbers are but I don't think these look obviously wrong somehow?
It'll be little bit faster in Atari TOS with the blitter enabled (running blitfix.prg, else you'll crash and burn).

The thing really takes off if you have NVDI installed though..

[stephen_usher]

Under PAK/3 3.06 and 2.06 it was definitely quite a lot faster for the VDI stuff. (All with MAPROM run so that the ROM image was in Fast-RAM)

From what I remember, the last time I tried EmuTOS 1.0 that was faster too, but I may be mis-remembering.

[czietz]

Bother CHKDSK3 broke things even more.

I did an "Analyse FAT" and it came up with a dialog saying that FAT1 and FAT2 differed and aske which to use, to I clicked on Cancel... and then it overwrote the second FAT and used the first one anyway! That's broken, as it shouldn't have touched the disk at all.

I'm aware that I come too late, but still: I have had good results using the disk repair from the (formerly commercial, now open-source) Diamond Edge. Oh, and as you surely know, it's good practice to only attempt disk repair on a 1-to-1 copy/image of the damaged filesystem.