Jackhead wrote on 2023-05-05, 10:44:
Ok i got the new eproms, and some ram (8MB) and installed the Controller.
I used a CF(4gb)-IDE Adapter connected to primery and a cd drive to second port. So first start went not to bad.
The controller boot from the cf. But i had 3 partitions on that cf. Only C: is there, d and e dont show up. Do i need to create them new with fdisk?
Partitioning depends on the geometry (virtual number of cylinders, heads, sectors per track). Your screenshot shows that you have "track remapping" disabled, which is equivalent to "NORMAL" mode in "modern" IDE BIOses, so you are limited to 504MB anyway. If you enable track remapping, you should be able to get at least 64 virtual heads, which allows up to 2GB, I don't know offhand whether it also can work at 128 virtual heads, which would allow the full capacity to be used. Track Remapping enabled is like "LARGE" mode in "modern" IDE BIOSes. Neither the controller firmware, nor the IDE BIOS supplied with it support standard LBA mode.
The current partitioning scheme of the CF card is likely 63 sectors/track, 255 heads. The controller BIOS does not support emulating this geometry, so you likely have to repartition.
Jackhead wrote on 2023-05-05, 10:44:
Also in the manual is writen that you can connect a cd drive to second port when you use only 1-2 on first port. You have to set the jumper on JP3.
On the controller are a JP3 jumper but it has 3 pins. I tryed 1-2 and 2-3 but on boot the cd driver is not loaded?
The DC-680T, and AFAIK also the successor, the DC-680C do not support CD drives at all. The DC-680CD does, because it integrates a dedicated IDE interface for the CD drive. The Tekram caching controllers work by emulating up to two virtual hard drives using the 80186 processor on the controller. The on-board processor then checks whether the requested sector is in the cache, and sends a read or write command to the drive if required. At no time, the host computer directly communicates with the IDE devices on a DC-680T. The host only ever communicates with the 80186, and the 80186 communicates with the drive. The firmware for the 80186 does not understand ATAPI, so it can't emulate a CD drive. I'm unsure whether the integrated logic in the DC-680T would be able to emulate ATAPI, or whether it only supports 512-bytes data blocks. I reverse engineered by DC-660 built from discrete logic far enough that I can tell you that other block sizes are only implementable (if at all) with crude firmware hacks, the hardware is not intended to cope with it.
Jackhead wrote on 2023-05-05, 10:44:
First dosbench show the buffered read goes up to 19MB/s (40MHz) linear read are as expected around 2MB/s marked as PIO Mode 2.
At FSB40, the DC680T will read data from the CF card at 750ns/word, which is around 2,6MB/s. This is slower than PIO0 permits (although it is faster than default-waitstate ISA on most mainboards). PIO0 is 600ns/word which is 3,3MB/s. This is the burst transfer rate, any command overhead adds to it. 2MB/s is quite good at FSB40. I found some notes I took when I benched that controller at FSB40, and I got 1650KB/s linear read speed from a fast mechanical drive.
The hardware on the DC680T aims to hit exactly PIO0 on the drive interface. It nails it perfectly at FSB25, FSB33 and FSB50. The firmware, starting with version 1.5, also recognizes FSB20 and FSB40, but treats those speeds just like FSB25 and FSB40. As the PIO timing is derived from the VL clock, this is the reason for around 20 to 25 transfer speed drop at those bus clocks. With firmware version 1.3 and 1.4, the tipping point beetween recognizing FSB33 and FSB50 is at 40.6MHz. The uncertainty of the measurement, as performed by the firmware makes the old firmware revisions run at the 33MHz or the 50 MHz configuration randomly. If firmware 1.3 or 1.4 initialized the controller for FSB33 operation at FSB40, it would transfer at 500ns/word, which is between PIO0 and PIO1.
Jackhead wrote on 2023-05-05, 10:44:
What are the best settings for cache line size?
The idea of bigger cache lines is to reduce management overhead and allow more bulk transfer. IIRC the firmware doesn't do more readahead depending on the cache line size (but I might be wrong on that), and the algorithms in the 2.x firmware are efficient enough to not influence performance significantly even at the lowest cache line size supported by the firmware. CF cards profit even less from bigger linear read/write chunks than magnetic drives, so there is no point in choosing a big cache line size. On the other hand, small cache line size ensures less "wasted space" in the cache by assigning cache RAM to hard disk sectors in a more flexible way. The smaller the cache line size, the higher the hit rate. As the DC680T is only fast on hits, you want a high hit rate. So: Choose as low as possible.
