Disruptor wrote on 2022-08-24, 10:40:

Can you extract the contents of its ROM please?

The board works with FLEXI-DRIVERS. Shows normal speed for VLB. The cache controller is fake. The chip labeled "Cache Controller" has no electrical connections to anything. Just planted on the board for the view 😀.

bedlam wrote on 2022-09-10, 17:30:

Disruptor wrote on 2022-08-24, 10:40:

Can you extract the contents of its ROM please?

OK, so this shows that the Hornet VL-200 actually allows to access to full memory plugged into it. The card is actually a multi-function card: It's a quite decent cacheless VL IDE interface based on the Adaptec 25VL01Q chip, as well as an ISA multi-I/O controller based on the Acer M5101 chip (cheap edition: only 1 joystick supported, as they use the NE556 for 2 axes, not the NE558 required for 4 axes). The Acer M5101 could provide an ISA-based IDE interface, but that feature is not used in favour of the VL IDE interface. Up to here it's just how your standard VL IDE multi-I/O controller is built - nothing special about it.

But this card has one extra function: It's also a banked 16-bit ISA memory expansion, built completely from 74-series logic chips, some PALs and an electro-magnetic delay line (i.e. that's how we built memory cards in 1987). The memory interface is controlled using ports 130&134, 230&234, 330&334 or 300&304, and uses a 32KB window at C800, D000, D800 or E000. Bit 7 at port xx0 selects whether the ROM is visible (bit set) or RAM is visible (bit clear). Bit 0 of that port selects whether the first bank of memory modules is selected (bit clear) or the second bank is selected (bit set). Bits 1 to 6 of the port xx0, as well as bits 0 and 1 in port xx4 select a 32KB block in the selected bank to be visible. The bits in port xx4 are only used if 4MB SIMMs are installed in the selected bank (i.e. they are mapped to row and column bit A10); Bits 6 and 5 in port xx0 are only used if 1MB or 4MB SIMMs are installed in the selected bank (i.e. they are mapped to row and column address bit A9). Bits 4 to 1 are used even for 256KB SIMMs. The ROM does not support 64KB SIMMs. If only one bank is to be used, the modules have to be installed in the first bank. If both banks have modules installed, they should both have the same size of modules. Otherwise the bank with the smaller modules limits how much of the bank with the bigger modules is used (That's a software limitation, the hardware seems to work fine with mixed memory sizes). If the memory tests passes, offset 7FF0h of page 0 is set to 05Ah, and the word at offset 7FF1h (yeah, misaligned) is set to the amount of 32KB pages that are present. Be aware that if only a single bank of memory is installed, only even "page numbers" work, because bit 0 in port xx0 is the bank select bit. All banking bits are read/write; bits 2 and 3 of port xx4 are also read/write (that's tested in the POST), but not used. Possibly they are wired to A11, and 16MB SIMMs would be supported. Bits 7 to 4 of port xx4 are hardwired to the pattern binary 1001 (9 decimal), and not writeable. This pattern is used to auto-probe the base port.

The ROM is programmed in a funny way. They have no number printing algorithm, but 257 copies of the string "xxxxx KB OK" with different numbers between 00000 and 16384, and just select the appropriate copy of that string while testing the memory.

mkarcher wrote on 2022-09-10, 23:23:

OK, so this shows that the Hornet VL-200 actually allows to access to full memory plugged into it. The card is actually a multi- […]
Show full quote

bedlam wrote on 2022-09-10, 17:30:

Disruptor wrote on 2022-08-24, 10:40:

Can you extract the contents of its ROM please?

OK, so this shows that the Hornet VL-200 actually allows to access to full memory plugged into it. The card is actually a multi-function card: It's a quite decent cacheless VL IDE interface based on the Adaptec 25VL01Q chip, as well as an ISA multi-I/O controller based on the Acer M5101 chip (cheap edition: only 1 joystick supported, as they use the NE556 for 2 axes, not the NE558 required for 4 axes). The Acer M5101 could provide an ISA-based IDE interface, but that feature is not used in favour of the VL IDE interface. Up to here it's just how your standard VL IDE multi-I/O controller is built - nothing special about it.

But this card has one extra function: It's also a banked 16-bit ISA memory expansion, built completely from 74-series logic chips, some PALs and an electro-magnetic delay line (i.e. that's how we built memory cards in 1987). The memory interface is controlled using ports 130&134, 230&234, 330&334 or 300&304, and uses a 32KB window at C800, D000, D800 or E000. Bit 7 at port xx0 selects whether the ROM is visible (bit set) or RAM is visible (bit clear). Bit 0 of that port selects whether the first bank of memory modules is selected (bit clear) or the second bank is selected (bit set). Bits 1 to 6 of the port xx0, as well as bits 0 and 1 in port xx4 select a 32KB block in the selected bank to be visible. The bits in port xx4 are only used if 4MB SIMMs are installed in the selected bank (i.e. they are mapped to row and column bit A10); Bits 6 and 5 in port xx0 are only used if 1MB or 4MB SIMMs are installed in the selected bank (i.e. they are mapped to row and column address bit A9). Bits 4 to 1 are used even for 256KB SIMMs. The ROM does not support 64KB SIMMs. If only one bank is to be used, the modules have to be installed in the first bank. If both banks have modules installed, they should both have the same size of modules. Otherwise the bank with the smaller modules limits how much of the bank with the bigger modules is used (That's a software limitation, the hardware seems to work fine with mixed memory sizes). If the memory tests passes, offset 7FF0h of page 0 is set to 05Ah, and the word at offset 7FF1h (yeah, misaligned) is set to the amount of 32KB pages that are present. Be aware that if only a single bank of memory is installed, only even "page numbers" work, because bit 0 in port xx0 is the bank select bit. All banking bits are read/write; bits 2 and 3 of port xx4 are also read/write (that's tested in the POST), but not used. Possibly they are wired to A11, and 16MB SIMMs would be supported. Bits 7 to 4 of port xx4 are hardwired to the pattern binary 1001 (9 decimal), and not writeable. This pattern is used to auto-probe the base port.

The ROM is programmed in a funny way. They have no number printing algorithm, but 257 copies of the string "xxxxx KB OK" with different numbers between 00000 and 16384, and just select the appropriate copy of that string while testing the memory.

What is the delay line needed for? (Having just successfully repaired two turbo XT boards I'm a little familiar at the moment with their schematics)

I haven't totally thought through what you've described as to whether it offers enough to implement true real-mode (no emm386) EMS? That would seem to be its only redeeming quality.

It can't even offload PIO IDE transfers to/from the card's onboard RAM instead of under CPU control? And even if it could, that would be replacing VLB PIO with ISA RAM access...

jakethompson1 wrote on 2022-09-10, 23:52:

What is the delay line needed for? (Having just successfully repaired two turbo XT boards I'm a little familiar at the moment with their schematics)

The delay line generates the access timing, i.e. when to assert /RAS, when to switch the row/column multiplexers, when to assert /CAS and when the data is ready. You send a pulse into the delay line when the cycle starts, and the different taps output the important timing points. On the VL-200, it's the 14T5151 chip, which has 5 taps, each 30ns delayed from each other, so from "IN" to "OUT", there is a delay of 15*10^1 = 150ns. That's why the model number ends in 151.

jakethompson1 wrote on 2022-09-10, 23:52:

I haven't totally thought through what you've described as to whether it offers enough to implement true real-mode (no emm386) EMS? That would seem to be its only redeeming quality.

It does not. For EMS, you need four independent 16K windows building the page frame of 64KB. This card only offers a single 32KB window. But the concept of banked memory is indeed very similar to EMS. You can use the card as RAM disk, though, if you write a custom driver for it. It should be straightforward. If the card was supporting 16MB SIMMs, you could get a capacity of 64MB. Support for 16MB SIMMs would be easy to add not already present - I know that it can store enough page number bits, because the POST verifies that the bit is there. I expected the 74LS158 to be row/column multiplexers at first, but there are four of them (good for 16 bits), on the other hand, for row/column multiplexing, you only need 11 bits for 4MB SIMMs and 12 bits for 16MB SIMMs. So there should be only three '158 chips if they are row/col switches. So maybe they are data multiplexers that choose between the 16-bit RAM and the 8-bit ROM. In that case, it doesn't seem to be that easily verifyable how row/column is multiplexed. If it's inside one of the PALs, the 12th bit needed for 16MB SIMMs might be unimplemented. Placing that card into a 16-bit machine (e.g. 286, 386SX), not connecting the VL at all, and inserting 16MB (or 64MB?) would provide a decent RAM drive. You could put the Windows 3.1 swap file on it, and get nice swapping performance.

jakethompson1 wrote on 2022-09-10, 23:52:

It can't even offload PIO IDE transfers to/from the card's onboard RAM instead of under CPU control? And even if it could, that would be replacing VLB PIO with ISA RAM access...

Looking at the pictures of the card and the software provided with the card, there is no sign of the RAM interface and the IDE interface being connected at all. And you are perfectly right: The RAM access isn't spetacularly fast in a machine that has VL slots.

EDIT added:

It might be fun to patch the driver supplied with the VL-200 to use the on-card RAM instead of XMS for caching (perhaps that's what they planned to be implementing, and the XMS-based cache is meant as a "proof of concept") and do some real-world benchmarking with IDE drives of different quality. It might also be fun to actually implement the RAM disk driver. But I am not spending the 250 western bucks on getting this kind-of novelty card, though.

Interestingly, there even seems to be a "rev 2" of the VL-200, called VL-230, as seen on this twitter thread: https://twitter.com/cls2086/status/1245464261838737414

It still has the Appian ADI/2 VL IDE controller chip (it's the same chip as the Adaptec 25VL01, one is rebranding the other, people say the CL-PD7220 is also the same). That VL chip has no cache support in itself. The card now has a fancy big HT2000 93VL200 chip on it instead of the bunch of TTL chips and PALs. I see traces from the new chip to the ISA bus, and I see traces likely going to the RAM. To me, it is likely that the 93VL200 just integrates the discrete TTL stuff, and the card still behaves the same.

As identified on that twitter thread, the card is obviously the one listed as EX-3135 in Total Hardware 99 (see https://arvutimuuseum.ee/th99/c/A-B/20951.htm), and the I/O address choices are exactly the same as on the VL-200. In this case, though, it seems they added software support to work with mixed bank sizes. It would be interesting whether this revision shipped with a driver or BIOS that used the on-board RAM (which is likely still slow) as second-level hard disk cache below a software-based cache like smartdrive. Even slow ISA bus RAM is faster than the access time of a magnetic IDE drive.

So, I found the official VL-230 drivers here on vogons: Re: VOGONS Driver Library - let's see how much they differ from the VL-200 drivers 😉

Sounds like management came with a novel idea of having cache integrated on the IDE controller. Neither cache controller ever worked nor the driver was finished. Even if the driver was finished, data transfers would have to go through the ISA bus which seemed like an idea from 286 era (EMS ISA cards) when VL Bus was the norm. Perhaps engineers eventually succeeded in persuading management of obsolescence of the technical solution being used which lead to development being stopped.

It would be an interesting project if someone with this controller could write a proof of concept code to validate that access to on-board RAM works.

AlexZ wrote on 2022-09-11, 09:48:

Sounds like management came with a novel idea of having cache integrated on the IDE controller. Neither cache controller ever worked nor the driver was finished. Even if the driver was finished, data transfers would have to go through the ISA bus which seemed like an idea from 286 era (EMS ISA cards) when VL Bus was the norm. Perhaps engineers eventually succeeded in persuading management of obsolescence of the technical solution being used which lead to development being stopped.

It would be an interesting project if someone with this controller could write a proof of concept code to validate that access to on-board RAM works.

OK, I took a look at the VL-230 controller software. It includes an all-new caching driver. They no longer ship a (most likely) pirated version of SMARTDRV.SYS, but instead they ship a (most likely) pirated version of HyperCache, extended to probe for the VL-230 card. This time, the cache actually accesses the RAM on the controller (during initialization only) and detects the cache size as initialized by the BIOS. No matter how much cache is installed, on a machine with 1024KB extended memory (according to CMOS 30/31), 768KB cache will be loaded, and on machines with at least 1024+384KB extended memory, 1024KB cache will be loaded. The VL-230 BIOS obviously is able to handle differently sized banks, and sets up the byte at 7FF3 in the first page to indicate a split-bank configuration, which should be read as "BCD number". 0x25 indicates "2.5MB", 0x85 indicates "8.5MB" and 0x10 indicates "10MB". Furthermore, the string "HORNET" at offset 9 in the BIOS which is clear text in the VL-200 BIOS seems to be obfuscated in the VL-230 bios. The cache driver expects to find the characters with 0x30 added to them at that offset.

There already is a proof-of-concept code to validate the on-board RAM access: The POST included in the BIOS of both the VL-200 and the VL-230 does just that.

This is thoroughly fascinating, but let me make sure if I get this right: this controller actually acts as an ISA RAM expansion card and then proceeds to use that RAM for caching with the use of main system CPU? So while the card does have working cache, it interfaces over a very limited bus and suffers from a lot of overhead because of all the back and forth that is caused by a lack of onboard CPU?

This sounds at least a little bit less ominous than "let's just make our customers buy expensive RAM and have it do nothing". Seems like they were actually trying to do something, it just wasn't a good idea.

jheronimus wrote on 2022-09-11, 10:58:

This is thoroughly fascinating, but let me make sure if I get this right: this controller actually acts as an ISA RAM expansion card and then proceeds to use that RAM for caching with the use of main system CPU? So while the card does have working cache, it interfaces over a very limited bus and suffers from a lot of overhead because of all the back and forth that is caused by a lack of onboard CPU?

This sounds at least a little bit less ominous than "let's just make our customers buy expensive RAM and have it do nothing". Seems like they were actually trying to do something, it just wasn't a good idea.

Well, what you describe is how the card could have worked. But it is missing any software that actually uses the memory on the card for something. Likely the onboard RAM is slow enough that you lose on most benchmarks compared to a software cache, so they gave up on it. How the card really works: A driver pretends to activate caching using the cache RAM on the card and just uses 512KB (VL-200) or 768KB/1024KB of extended memory of the host CPU as cache. The VL-200 has a rebranded SMARTDRV, the the VL-230 has a rebranded HyperDisk software cache. Neither of them bothers to use the slow on-card RAM.

mkarcher wrote on 2022-09-11, 12:06:

jheronimus wrote on 2022-09-11, 10:58:

This is thoroughly fascinating, but let me make sure if I get this right: this controller actually acts as an ISA RAM expansion card and then proceeds to use that RAM for caching with the use of main system CPU? So while the card does have working cache, it interfaces over a very limited bus and suffers from a lot of overhead because of all the back and forth that is caused by a lack of onboard CPU?

This sounds at least a little bit less ominous than "let's just make our customers buy expensive RAM and have it do nothing". Seems like they were actually trying to do something, it just wasn't a good idea.

Well, what you describe is how the card could have worked. But it is missing any software that actually uses the memory on the card for something. Likely the onboard RAM is slow enough that you lose on most benchmarks compared to a software cache, so they gave up on it. How the card really works: A driver pretends to activate caching using the cache RAM on the card and just uses 512KB (VL-200) or 768KB/1024KB of extended memory of the host CPU as cache. The VL-200 has a rebranded SMARTDRV, the the VL-230 has a rebranded HyperDisk software cache. Neither of them bothers to use the slow on-card RAM.

So its like a spoiler on a sedan ..its just there to look pretty but is useless otherwise.

mkarcher wrote on 2022-09-11, 12:06:

Well, what you describe is how the card could have worked. But it is missing any software that actually uses the memory on the card for something. Likely the onboard RAM is slow enough that you lose on most benchmarks compared to a software cache, so they gave up on it. How the card really works: A driver pretends to activate caching using the cache RAM on the card and just uses 512KB (VL-200) or 768KB/1024KB of extended memory of the host CPU as cache. The VL-200 has a rebranded SMARTDRV, the the VL-230 has a rebranded HyperDisk software cache. Neither of them bothers to use the slow on-card RAM.

Just why the hell anyone would sell something like that is beyond me. I mean, PC Chips fake cache scheme looks relatively benign in comparison — at least you're not tricked into buying extra stuff and still having no performance benefit.

jheronimus wrote on 2022-09-11, 12:18:

mkarcher wrote on 2022-09-11, 12:06:

Well, what you describe is how the card could have worked. But it is missing any software that actually uses the memory on the card for something. Likely the onboard RAM is slow enough that you lose on most benchmarks compared to a software cache, so they gave up on it. How the card really works: A driver pretends to activate caching using the cache RAM on the card and just uses 512KB (VL-200) or 768KB/1024KB of extended memory of the host CPU as cache. The VL-200 has a rebranded SMARTDRV, the the VL-230 has a rebranded HyperDisk software cache. Neither of them bothers to use the slow on-card RAM.

Just why the hell anyone would sell something like that is beyond me. I mean, PC Chips fake cache scheme looks relatively benign in comparison — at least you're not tricked into buy extra stuff and still have no performance benefit.

Having lived through that era using that hardware ...you have no idea just how many sketchy as fuck things got sold to unsuspecting consumers.

Like the ram doubling software for Win3.11 and Win95 ....yup they got sued for it too.
https://www.youtube.com/watch?v=8rxssVFeKr8
https://www.youtube.com/watch?v=o9bCkDrdECo - Follow up for previous link.

On a side note .. another Sketchy thing .. this time by MicroSoft
https://www.youtube.com/watch?v=oa3xp1xNwvM

There were lot of sketchy thing back in the day.

mkarcher wrote on 2022-09-11, 10:39:

but instead they ship a (most likely) pirated version of HyperCache

Found the original. HT2000.SYS is a hacked version of HYPERDKX.EXE, version 4.65. You can find the original HYPERDKX.EXE (shareware version) as part of the HyperWare SpeedKit, e.g. at Metropoli BBS.

TrashPanda wrote on 2022-09-11, 12:23:

There were lot of sketchy thing back in the day.

Like the Spintel windows accelerator ISA card. In fact, it is a dongle that unlocks a software driver that actually does something useful: It replaces a commonly used GDI call for drawing with a mask (which is often unaccellerated) by a sequence of first applying the mask to the screen memory (which is usually accelerated) and then merging the data to write to the screen memory (which is usually accelerated, too). Because unaccelerated graphics operations are replaced by accelerated operations, there actually is an improvent in certain applications.

The card was sold as a magic coprocessor that accellerates windows by some crazy amount of percent, though.

jheronimus wrote on 2022-09-11, 12:18:

Just why the hell anyone would sell something like that is beyond me.

Well, that's easy to explain: Because someone would buy something like this. That's just capitalism. Doesn't make it less of a fraud, though.

So it seems VL-200 and VL-230 are best used without the official driver (or an alternative driver to configure the controller chip) and without any memory as it will have no effect. You can just use smartdrv and configure any cache memory size you want.

Back in 286 times an EMS ISA card was a good solution as ISA bus speed and memory speed was similar. This hardware solution became inefficient with faster clocked 286s or 386s. Having a working access to VLB controller memory would have potentially allowed the company to provide genuine implementation of caching in case of a law suit. It didn't provide it because they knew the solution would have had inferior performance to competition. Maybe they even planned to sell VLB controllers bundled with memory sticks.

AlexZ wrote on 2022-09-11, 14:26:

So it seems VL-200 and VL-230 are best used without the official driver (or an alternative driver to configure the controller chip) and without any memory as it will have no effect. You can just use smartdrv and configure any cache memory size you want.

Exactly. You don't even need to search for an alternative driver. The VL-200 drivers posted here include a driver called INITADI2.SYS which is for some unknown reason put into the "NETWARE" directory. It's a sensible driver to configure the cacheless VL IDE controller chip. I didn't see a comparable setup tool in the VL-230 driver set, though.

mkarcher wrote on 2022-09-11, 07:05:

jakethompson1 wrote on 2022-09-10, 23:52:

What is the delay line needed for? (Having just successfully repaired two turbo XT boards I'm a little familiar at the moment with their schematics)

The delay line generates the access timing, i.e. when to assert /RAS, when to switch the row/column multiplexers, when to assert /CAS and when the data is ready. You send a pulse into the delay line when the cycle starts, and the different taps output the important timing points. On the VL-200, it's the 14T5151 chip, which has 5 taps, each 30ns delayed from each other, so from "IN" to "OUT", there is a delay of 15*10^1 = 150ns. That's why the model number ends in 151.

Interesting--I thought an ISA card could derive those timings from CLK or even OSC. Or would the delay line have the advantage of making those timings independent of CLK since it could vary anywhere from 4.77 to 10 MHz or higher (or rethinking this, the DRAM access timing diagram is much more fine-grained than the 210 ns resolution of the 4.77 MHz clock so I guess it gets around that problem)?

Somewhat similar to this, when repairing the most recent XT board I was wondering why the ALE signal needed to go out to the expansion cards. It's been on the same pin going all the way back to the Datamaster. IBM's memory expansion card doesn't use it. I was wondering if ALE could allow an ISA card to get a "head start" on a memory access by loading the row into DRAM chips based on ALE, and if the ISA memory cycle ends up not even being for that card, no harm done--just don't put in a column the correct row will be substituted in time when a memory access comes later. Thoughts?

mkarcher wrote on 2022-09-10, 23:23:

OK, so this shows that the Hornet VL-200 actually allows to access to full memory plugged into it. The card is actually a multi-function card: It's a quite decent cacheless VL IDE interface based on the Adaptec 25VL01Q chip, as well as an ISA multi-I/O controller based on the Acer M5101 chip (cheap edition: only 1 joystick supported, as they use the NE556 for 2 axes, not the NE558 required for 4 axes). The Acer M5101 could provide an ISA-based IDE interface, but that feature is not used in favour of the VL IDE interface. Up to here it's just how your standard VL IDE multi-I/O controller is built - nothing special about it.

But this card has one extra function: It's also a banked 16-bit ISA memory expansion, built completely from 74-series logic chips, some PALs and an electro-magnetic delay line (i.e. that's how we built memory cards in 1987).

Wow great hardware/software deducing ! So in laymans terms the card is not a caching controller but a VLB multi I/O IDE HD controller with XMS/EMS capability ?