douglar wrote on 2023-06-17, 19:54:

Very true. There are also a good percentage of the early VLB IO controllers with two IDE connectors run the secondary IDE port […]
Show full quote

jakethompson1 wrote on 2023-06-17, 19:13:

You remind me that it might not affect pshipkov's card but it's worth mentioning somewhere on this thread, that there were some combo VLB IDE+VGA cards where only the VGA part is VLB and the IDE part is ISA.

Very true. There are also a good percentage of the early VLB IO controllers with two IDE connectors run the secondary IDE port off the ISA bus.

My experience is that an 8mhz ISA usually peaks at about 1.5 MB/s to 1.8MB/s. You could get close to 2.5MB/s with 12mhz overclock.

Are there ISA cards that benefit from 32bit transfers?

When I've tried forcing 32-bit IDE transfers on an ISA machine (on linux) all access to the drive comes to a halt.
I'm not sure why it wouldn't just break down into two 16-bit transfers.

jakethompson1 wrote on 2023-06-17, 21:44:

When I've tried forcing 32-bit IDE transfers on an ISA machine (on linux) all access to the drive comes to a halt.
I'm not sure why it wouldn't just break down into two 16-bit transfers.

A 32-bit I/O instruction to the IDE data port (1F0h for the primary controller) will be broken down to multiple transfers. The first one will be a 16-bit transfer to 1F0h, which will read/write 16 bit of IDE data. The remaining 16 bits will be transferred from/to 1F2h, which is not the IDE data port, and as it is not the data port, it is likely split into two 8-bit transfers: One to read/write 1F2h, the IDE sector count register and one to 1F3h, the IDE sector number register. So trying to transfer a whole sector using 128 32-bit I/O instructions will only perform 128 16-bit accesses to the 16-bit data port, which will only transfer the data of half a sector. The remaining data transferred is not considered an IDE drive data transfer, so the drive still waits to transfer the remaining half before getting ready for the next operation.

A VL controller that supports 32-bit I/O splits a 32-bit I/O into two 16-bit I/O transfers, which both target the IDE data port, which is different from the processor/mainboard splitting the transfer for a 16-bit ISA card.

mkarcher wrote on 2023-06-18, 08:10:

The remaining 16 bits will be transferred from/to 1F2h, which is not the IDE data port, and as it is not the data port, it is likely split into two 8-bit transfers: One to read/write 1F2h, the IDE sector count register and one to 1F3h, the IDE sector number register. So trying to transfer a whole sector using 128 32-bit I/O instructions will only perform 128 16-bit accesses to the 16-bit data port, which will only transfer the data of half a sector. The remaining data transferred is not considered an IDE drive data transfer, so the drive still waits to transfer the remaining half before getting ready for the next operation.

A VL controller that supports 32-bit I/O splits a 32-bit I/O into two 16-bit I/O transfers, which both target the IDE data port, which is different from the processor/mainboard splitting the transfer for a 16-bit ISA card.

Thanks for the explanation. It’s hard to find this kind of info so long after the product became obsolete.

One question if I may, why is the second 16 bit transfer split into a pair of 8bit transfers?

douglar wrote on 2023-06-18, 14:47:

One question if I may, why is the second 16 bit transfer split into a pair of 8bit transfers?

On the ISA bus, there may be 16-bit and 8-bit cards. A 16-bit cards identifies itself as 16-bit capable by driving "IOCS16" if the current address on the ISA bus matches a port address that can handle 16-bit transfers. For IDE, only port 1F0 can handle 16-bit transfers. All the other ports are meant for 8-bit transfers only, so IOCS16 will not be driven for those ports. When the chipset presents the second 16 bits on the ISA bus at port 1F2, the IDE interface card will not drive IOCS16, so it signals that only the low 8 bits have been accepted. In response, the chipset will issue another 8-bit cycle to port 1F3.

I got side tracked a bit because one of my best performing devices, a 32GB msata ssd in a 2.5 inch package with a jmicron bridge, isn't playing nice with the Promise 20630 chipset.
The msata device gets unbuffered reads ~ 70MB/s on a UDMA 6 controller on a Nforce motherboard. It should be fast.

1) First issue is that the jmicron SATA bridge doesn't get along with some of the BIOS or drivers.
The card came with V3.3 SIIG option rom from 1995 on the card. It locks on drive detection when the msata device is connected.
I tried the Promise v116 LBA Rom . Looks lik that image contains two drivers. My card is not using the "Promise EIDE MAX LBA Control Driver External BIOS V1.16, 1996" from the ROM. It is using the "EIDE2300 External BIOS V3.3 1995". That also locks on drive detection when the msata device is connected.
If I leave out the option Roms, the motherboard (MrBios 1.6) cannot detect the drive, but I can manually configure a random CHS setup. The Promise 3.3 device driver can load if I boot off floppy, but writes to the storage device fail.
I can get the system to work if I add the DTC 1181 option rom
EZ Drive threw errors on the automatic install but I was able to get things done manually, however the driver was not stable with DMA mode enabled
XUB works pretty well with this board

2) Second issue: Strange performance
Using the DTC 1181 option rom and the Promise VG4 3.3 driver
If I enable the fastest DMA mode "M8", I get ~10MB/s on the buffered reads and about 2.6MB/s on unbuffered reads
If I enable the fastest PIO mode "D8", I get ~8.5MB/s on the buffered reads and about 5.5MB/s on unbuffered reads

I'm trying to account for BIOS, Driver, DMA support and LBA here but perhaps there's some other variable that isn't accounted for that is making things go strange.

This was curious-- Same Name: "Acculogic sIDE-4/VL" , Same IO Chip: "FOC37C666GT", Very different cards

The top one is CMD PCI640b based with an FCC date of 1995-01-18
The bottom one is ADI/2 based with an FCC date of 1993-09-20 and one of the IDE ports is ISA.

The advances in board construction in those 16 months is pretty clear.

This one looks really weird. It's a GSI Model 21 with a 1645-V1 Vesa Extender Module

It comes in two pieces, sure, but it also has the dual floppy connectors, and an AT28C64 EEPROM, a XILINX 7236A chip and an Cirrus Logic CL-PD7232 .

And it looks like you could double up on those last two chips.

Strange.

Edit: Just a guess here, but would the XILINX 7236A be some sort of programmable logic controller and Cirrus Logic CL-PD7232 would be a glue chip to attach it to the Vesa bus, yes?

I've been getting my best benchmarks using Promise 20630 based boards using the Promise v3.3 driver like this:
device=C:\VG4\VG4.SYS /M0:8
Where "M0" means DMA on drive 0 with speed = 8 where the speed can be between 0 - 8 with 8 as the fastest.

I get about 2MB/s without a driver, 5-7MB/s using the fastest PIO mode, and I get about 10-12MB/s using multiword DMA.

However the DMA is surprisingly touchy. Not many modern storage devices are willing to do it and fall back to PIO.

For example, the two colorful consumer CF's don't do DMA with the promise 20630 controller. The driver switches to PIO when it loads. However the industrial CF on the bottom does multiword DMA no problem.

The SINTECHI SD adapter does multiword DMA. I didn't have luck getting devices using a JM20330 serial bridge with the Promise 20630 controller, but that might have been BIOS limitations and I need to go back to that.

douglar wrote on 2023-04-29, 03:05:

Intel486dx33 wrote on 2023-04-28, 19:34:

What about this one. It’s a Mystery to me. I bought it NEW on eBay but I can’t find any drivers or jumper setting or documentation for it.

Its a “Acculogic sIDE-4/VI”

I’m testing with that exact card. I’ve had the best luck with the IDE driver in this bundle: http://vogonsdrivers.com/getfile.php?fileid=9 … menustate=59,55

I’ve been getting 8KBs to 8.5KBs thoughput

douglar wrote on 2023-06-30, 17:17:

This was curious-- Same Name: "Acculogic sIDE-4/VL" , Same IO Chip: "FOC37C666GT", Very different cards […]
Show full quote

This was curious-- Same Name: "Acculogic sIDE-4/VL" , Same IO Chip: "FOC37C666GT", Very different cards

Photo Jun 30 2023, 1 07 47 PM.jpg

The top one is CMD PCI640b based with an FCC date of 1995-01-18
The bottom one is ADI/2 based with an FCC date of 1993-09-20 and one of the IDE ports is ISA.

The advances in board construction in those 16 months is pretty clear.

I have that later version of the Acculogic sIDE-4/VL card (CMD PCI0640B based). It came from my family's 486 so I have the manual and driver floppy it came with. It supports >540MB drives, I think the limit I remember advertised was 8.4GB (but those didn't exist yet and I've never tested it that high). I remember it also being advertised for PIO Mode-4 (16.6MB/sec) transfer rate. Installing a driver enables this (or at least, it definitely gets a lot faster).
I saw some comments on the forum about this chip being a bad one. I don't recall having any problems with it, but our 486 was a mess in general so any subtle corruption coming from the IDE controller probably wouldn't have been noticed.
I guess I won't use this card for imaging my floppy disk collection, though. I kinda wanted to use a vintage machine for that but I'll stick to something more reputable.
I think the PCI0640B only controls one IDE channel. I believe all the other ports (including the "ISA IDE") are controlled by the SMC FDC37C666GT.
Having the PCI0640B on just one channel probably cuts down on corruption issues. We did have dual hard drives on the same channel, but this is back in the days of DOS and Win95. I don't remember the partition scheme but I bet there was little to no time when both drives would be trying to talk at the same time.

There is a DOS TSR which I remember making the card a lot faster. Disk transfer speed rarely matters in DOS but I thought it was cool at the time.

I attempted to image the driver floppy, but it's gone bad. Regular floppy drives don't recognize it at all, saying it's not formatted.
After a struggle involving two LS-120 drives and 'ddrescue', I did eventually recover the whole disk except the first sector, which seems to be truly dead.
ddrescue is a cool program. At first there were 8KB bad, then after trying a 2nd drive it got down to 1.5KB bad. Then after numerous retries in each drive, it got down to just 512 bytes bad (the first sector). That boot sector seems to be a lost cause.
I used 'testdisk' to generate a new boot sector for the floppy image. So the first sector is not original but the rest of the image is. I don't know much about testdisk, I could have easily done something wrong here but it seems to work.
Good news is I made a simple copy of the floppy like 20 years ago, so the image isn't really necessary.

I also scanned the manual which has the jumper settings. As you can see in the picture my jumper settings were... uninspired.
Basically, if you put all jumpers on the top pair of pins, you're at defaults. According to the manual this *disables* the secondary (ISA) IDE channel.

============
Attachments are:
1) An old .ZIP backup of the driver floppy ver1.1 from when the disk was still good. This is all you should need.
2) A recovered raw .img of the same floppy, with the first 512 bytes being a modern "repair" generated by testdisk. If I did something wrong there, then replace this part of the data as needed. There's probably no need for this raw image but I wanted to make one out of principle.
3) A scan of the manual. Sorry, it's a bunch of .JPG files. I tried making a PDF but VOGONS won't let me upload it because the file is over 5MB. The JPEGs are smaller, apparently making it into a PDF of decent quality made it grow. If somebody is better at making PDFs and wants to convert this, please do so. When I tried, I had problems with the text getting blurry and/or the size growing.

I don't know if any of this is useful for the older version of the card which has a different chip on it, and a different jumper layout.
It's needlessly confusing that they used the same name for 2 different cards. I remember Linksys doing that with some network cards, also.

Nice. Thanks.
Few times i passed on CMD based controllers because was not able to find drivers.
Now i need to find one of these guys ...

shamino wrote on 2023-09-05, 22:28:

1) An old .ZIP backup of the driver floppy ver1.1 from when the disk was still good. This is all you should need.

Windows Defender thinks there is a virus in the driver zip file. Malware bytes doesn't find anything.

[edit]Windows Defender says:
Trojan:DOS/CMD640X
This program is dangerous and executes commands from an attacker.
driver_Acculogic-sIDE4VL-PCI0640Bversion.zip->DOS/CMD640X.SYS

[edit]Looks like this was a real thing:
https://www.f-secure.com/v-descs/cmd640x.shtml

The message is not caused by a virus, nor has the original program file been tampered in any way.
Rather, it seems that the driver's programmer has added a Trojan Horse routine to CMD640X.SYS as a "joke".
CMD640X.SYS activates randomly. It keeps printing the following message on the screen for a while, after which it crashes the computer.

1 A poX oN yOu!! yoU wiLl bUrN iN tHe fiReS of HeLl!! A poX
2 oN yOu!! yoU wiLl bUrN iN tHe fiReS of HeLl!! A poX oN
3 yOu!! yoU wiLl bUrN iN tHe fiReS of HeLl!!

Huh. And who said retro computing is boring?

The DOS driver in your version is V2.07. Do people want to preserve this version?

I have DOS driver v2.09 here: http://www.vogonsdrivers.com/getfile.php?fileid=2064
I have DOS driver v2.13 here: http://www.vogonsdrivers.com/getfile.php?fileid=2073

Extending a request for ATronics 2015PL cross-check, if somebody has controller based on this chip and is willing to spend some time on it.
The late DOS driver (version 3.27 06/08/95) offers control parameters, but seem to be problematic in general. Performance is really bad. ~0.35Mb/s according to speedsys, coretest. Need to spend more time on this, but does not look good so far.
The early DOS driver (version 3.00 04/29/94) does not offer control flags, but boosts performance about twice compared to the base line. So that is ~3.2Mb/s according to speedsys, coretest. But even that is too bad.
Both cases are with CF card that supports multi-word transfers.

At the same time @gerwin shows good performance in Windows when using the corresponding driver.
486 VLB UMC-Chipset, what is it?

Anyone ?

pshipkov wrote on 2023-09-11, 21:44:

Anyone ?

I have a Boca Research 4475 based on an Atronics2015pl
https://arvutimuuseum.ee/th99/c/A-B/20774.htm
https://fccid.io/EUD5U9BRI4475

I've been really busy at work for the last few months and my project sort of stalled.

I ran these tests a while back without any dos driver when I was checking to see if it worked:

Processor : AMD Am5x86(tm) 133 MHz
BIOS vendor : MRIcroid Research, Inc. 23 (01/26/94)
OS version : MS-DOS 7.10

132GB Msata SSD on a PATA adapter
2                  Tested in FAST mode
3                  Random access time     : 0.26 ms
4                  Linear read speed      : 1088 KB/s
5                  Min/Max read speed     : 1085 KB/s / 1103 KB/s
6                  Linear write speed     : 1024 KB/s
7                  Min/Max write speed    : 937 KB/s / 1207 KB/s
8                  Buffered read speed    : 5867 KB/s

1512MB SD on a Sinitechi
2                  Tested in FAST mode
3                  Random access time     : 0.80 ms
4                  Linear read speed      : 1479 KB/s
5                  Min/Max read speed     : 1479 KB/s / 1479 KB/s
6                  Linear write speed     : 1777 KB/s
7                  Min/Max write speed    : 1776 KB/s / 1779 KB/s
8                  Buffered read speed    : 1481 KB/s

Let me know if you want to see some other test and I'll run it

douglar wrote on 2023-09-11, 19:10:

Windows Defender thinks there is a virus in the driver zip file. Malware bytes doesn't find anything. […]
Show full quote

shamino wrote on 2023-09-05, 22:28:

1) An old .ZIP backup of the driver floppy ver1.1 from when the disk was still good. This is all you should need.

Windows Defender thinks there is a virus in the driver zip file. Malware bytes doesn't find anything.

[edit]Windows Defender says:
Trojan:DOS/CMD640X
This program is dangerous and executes commands from an attacker.
driver_Acculogic-sIDE4VL-PCI0640Bversion.zip->DOS/CMD640X.SYS

[edit]Looks like this was a real thing:
https://www.f-secure.com/v-descs/cmd640x.shtml

The message is not caused by a virus, nor has the original program file been tampered in any way.
Rather, it seems that the driver's programmer has added a Trojan Horse routine to CMD640X.SYS as a "joke".
CMD640X.SYS activates randomly. It keeps printing the following message on the screen for a while, after which it crashes the computer.

Copy code to clipboard

1 A poX oN yOu!! yoU wiLl bUrN iN tHe fiReS of HeLl!! A poX
2 oN yOu!! yoU wiLl bUrN iN tHe fiReS of HeLl!! A poX oN
3 yOu!! yoU wiLl bUrN iN tHe fiReS of HeLl!!

Huh. And who said retro computing is boring?

Weird. I've never seen that before.
I looked through DOS/CMD640X.SYS with a hex editor and didn't see that string in it anywhere, but I guess it could have been obfuscated.
It does light up a lot of warnings on virustotal.

I checked the raw disk image and it produces the same warnings, so I'm glad it's not something I "added" to my backup back in 03.

shamino wrote on 2023-09-12, 01:22:

Weird. I've never seen that before. I looked through DOS/CMD640X.SYS with a hex editor and didn't see that string in it anywher […]
Show full quote

Weird. I've never seen that before.
I looked through DOS/CMD640X.SYS with a hex editor and didn't see that string in it anywhere, but I guess it could have been obfuscated.
It does light up a lot of warnings on virustotal.

I checked the raw disk image and it produces the same warnings, so I'm glad it's not something I "added" to my backup back in 03.

This write-up (https://www.virusbulletin.com/uploads/pdf/mag … 1995/199504.pdf p.3) suggests that the message is triggered if the copyright message doesn't match an obfuscated copy. Indeed, there are two calls to the deobfuscation function, one to the obfuscated copyright string and one for the burn in hell message, and we can decode them in Python3:

1import struct
2
3def decode(buf):
4    i = 0
5    obuf = b""
6
7    while buf[i] != 0:
8        c = buf[i]
9        i += 1
10        c -= i
11        c = ((c >> 1) & 0xff) | ((c << 7) & 0xff) # ror
12        c &= 0x7f
13        obuf += struct.pack("B", c)
14        
15    return obuf
16
17fin = open("CMD640X.SYS", "rb")
18buf = fin.read()
19ostr = b""
20fin.close()
21
22print(decode(buf[0x364c:]))
23print(decode(buf[0x367a:]))

Unsurprisingly, we get:

1$ python3 decode.py 
2b'Copyright (C) 1993-1994  CMD Technology, Inc.'
3b'A poX oN yOu!! yoU wiLl bUrN iN tHe fiReS of HeLl!!'

Interestingly, their deobfuscation algorithm doesn't bother to un-set bit 7, so I guess it must get un-set elsewhere before displaying. Stupid Python arithmetic shift.

douglar wrote on 2023-09-12, 00:18:

I have a Boca Research 4475 based on an Atronics2015pl https://arvutimuuseum.ee/th99/c/A-B/20774.htm https://fccid.io/EUD5U9BRI […]
Show full quote

pshipkov wrote on 2023-09-11, 21:44:

Anyone ?

I have a Boca Research 4475 based on an Atronics2015pl
https://arvutimuuseum.ee/th99/c/A-B/20774.htm
https://fccid.io/EUD5U9BRI4475

I've been really busy at work for the last few months and my project sort of stalled.

I ran these tests a while back without any dos driver when I was checking to see if it worked:

Processor : AMD Am5x86(tm) 133 MHz
BIOS vendor : MRIcroid Research, Inc. 23 (01/26/94)
OS version : MS-DOS 7.10

Copy code to clipboard

132GB Msata SSD on a PATA adapter
2                  Tested in FAST mode
3                  Random access time     : 0.26 ms
4                  Linear read speed      : 1088 KB/s
5                  Min/Max read speed     : 1085 KB/s / 1103 KB/s
6                  Linear write speed     : 1024 KB/s
7                  Min/Max write speed    : 937 KB/s / 1207 KB/s
8                  Buffered read speed    : 5867 KB/s

Copy code to clipboard

1512MB SD on a Sinitechi
2                  Tested in FAST mode
3                  Random access time     : 0.80 ms
4                  Linear read speed      : 1479 KB/s
5                  Min/Max read speed     : 1479 KB/s / 1479 KB/s
6                  Linear write speed     : 1777 KB/s
7                  Min/Max write speed    : 1776 KB/s / 1779 KB/s
8                  Buffered read speed    : 1481 KB/s

Let me know if you want to see some other test and I'll run it

Thanks.
This is inline with what i see here. More or less. Basically, ATronics 2015PL is just slow in pure DOS mode.

I only own 2 but if you need photos for the wiki, there you are..

shamino wrote on 2023-09-12, 01:22:

I checked the raw disk image and it produces the same warnings, so I'm glad it's not something I "added" to my backup back in 03.

Certainly the most interesting VLB driver that I've seen so far!

After getting the explanation about how it works, it seems to be more of a copy protection scheme than a virus or trojan.

pshipkov wrote on 2023-09-12, 06:44:

This is inline with what i see here. More or less. Basically, ATronics 2015PL is just slow in pure DOS mode.

I did some more testing with the board and tried to get the DOS driver to work. While it was easy to get the driver to load, I couldn't find switches that would let the speedsys benchmark complete for my usual CF's or the Sinitechi. I was able to substitute a different consumer grade CF and that worked, so I put those results in.

I thought this quote from the driver readme was pretty great:
The latest ATA-2 defines an even faster flow-control timing called Mode-4 (there are even spec's for Mode-5).
The 2015PL driver supports Mode-3 and Mode-4 drives, and should be able to support Mode-5.
[Narrator's voice:] The device driver didn't support a "P5" parameter

Here are the results:

XUB did pretty respectably across the board except for the MSata/JMicron
On the other hand, the DOS driver did poorly everywhere except for the MSata the device driver said it was doing MST (multi sector transfers) = 16, while none of the other devices would do MST > 1

Here are the results from my QDI testing in the other thread.

MR and DTC bios got the same scores on the consumer CF. I double checked.

The 6580 was a little slower than the 6500 without XUB or the DOS driver, but excels with XUB or the DOS driver.