ISA USB board

[NeXT]

I mean you will be hitting some stiff penalties trying to convert a USB interfaced mas storage device to the 8-bit ISA bus.
Think of it like the SCSI2SD: It's slower than the real deal, but compared to the alternatives for moving data between new and old, there's not much else.

 

[Plasma]

I don't see why it can't be close to polled XTIDE. Which IIRC is 170 KB/s in a 5150. Even if you cut that in half for copying between the two, 14-18 KB/s is still way under par.

 

[Malc]

18 KB/s is double the speed of the floppy in my 5160, The Chinese DOS driver is slow but it works, It's a handy bit of kit to have, It would be nice to have better / faster drivers but i can live with it as is.

 

[sorphin]

I'm a little salty here because I goddamn know I talked about these here five or six or so years ago and nobody cared. I couldn't get anyone to get motivated to even try them out because everyone was getting hung up on it not working out of the box.
Now suddenly, they're hot.

Want some fries for that salt? 5 or 6 years ago, I barely even paid attention to the forum and only had the Tandy 1k sx and didn't do anything serious with it.. i stumbled across the threads a couple days before I made the post in this thread and only used this thread because it was the most recent. Just because people weren't interested in something five or six years ago doesn't mean they can't be interested in it now. Different people. </antirant>

 

[sorphin]

18 KB/s is double the speed of the floppy in my 5160, The Chinese DOS driver is slow but it works, It's a handy bit of kit to have, It would be nice to have better / faster drivers but i can live with it as is.

I put it in my 5150 as a simple resource because that's the only machine that doesn't have other storage other than floppies. Everything else has spinning rust or a combination of that and Diskonchip (as a backup). I would have used DOC in the 5150 and 5160, but its rom code freaks out the CGA and reboots during POST. 18k a second is fine with me for the purpose. If someone really needs super speed on a 5150 or 5160 class machine they're looking at the wrong machine.

 

[Eudimorphodon]

I mean you will be hitting some stiff penalties trying to convert a USB interfaced mas storage device to the 8-bit ISA bus.
Think of it like the SCSI2SD: It's slower than the real deal, but compared to the alternatives for moving data between new and old, there's not much else.

I don't see why it can't be close to polled XTIDE. Which IIRC is 170 KB/s in a 5150. Even if you cut that in half for copying between the two, 14-18 KB/s is still way under par.

Even with the 8088 code a simple eight-bit XT-CF implementation can do north of 200KB/s, which is about three times as fast as the original 5160 HD. On my 7.16mhz V20 box a cheap PATA to SD bridge on one of those 8-bit ports does around 560KB/s. (Around 400KB/s @4.77mhz) Unless hot-pluggability is an absolute requirement there are certainly more performant sneakernet solutions than these USB cards out there already, definitely can't argue that.

The performance numbers from this are so poor it really has me wondering what the bottleneck is. The CH376's datasheet claims the bus can run at "2MB speed" and if it's running the USB port at 12Mbps it certainly should be capable of performance in the same ball park as an XTIDE/XTCF, but reading between the lines in the datasheet it looks like the time taken to execute all the disk storage related functions are pretty indeterminate. Maybe its own embedded MCU is just really weak?

That all said, I kind of want to order a few of the chips to play with, even if the performance does kind of irrevocably suck. Its built-in FAT filesystem support might make it pure gold if you're making your own homebrew computer and don't want to spend much time implementing a disk operating system.

 

[sorphin]

18 KB/s is double the speed of the floppy in my 5160, The Chinese DOS driver is slow but it works, It's a handy bit of kit to have, It would be nice to have better / faster drivers but i can live with it as is.

Did you clock w/ the driver or the ROM? (I'm going to do both once i figure out an effective way to check... all the disk benchmarkers ignore it because it's not 'real')

 

[mbbrutman]

A floppy drive on a PCjr doing sequential reads or writes clocks in at about 11KB/sec. The 5150 should be similar.

Comparing USB mass storage to the IDE interface is not a terribly fair comparison. USB is a packet based protocol, and forming the command packet and parsing it might be taking forever on an older machine like a 5150. It's going to be a lot more effort than punching values into 5 or 6 registers, hitting "go", and getting 512 bytes back on an I/O port.

Yeah, it's interesting, but not really viable as a mass storage device. CF cards are getting more expensive, but even an XT-IDE derivative with a CF adapter, and then a CF to SD Card adapter is going to be faster than this solution.

 

[Chuck(G)]

I wonder if the thing has any internal buffering at all. Do the SD-to-CF adapters use single-bit SPI or 4-bit SDIO?

 

[Plasma]

Comparing USB mass storage to the IDE interface is not a terribly fair comparison. USB is a packet based protocol, and forming the command packet and parsing it might be taking forever on an older machine like a 5150. It's going to be a lot more effort than punching values into 5 or 6 registers, hitting "go", and getting 512 bytes back on an I/O port.

Isn't that the entire point of the CH375? It does all the USB protocol stuff for you.

 

[Hak Foo]

Yeah, it does all the heavy lifting for USB. Once the device is initialized, you send a command for "Queue up NNN blocks starting at LBA NNNNNNN", wait for a go-ahead, and tell it you want to read it back 64 bytes at a time.

It uses an 8-bit bus interface, although I think they can be jumpered to use some serial constructs too. There are a bunch of commands for setting serial modes, which I haven't gone near.

Some performance thoughts:
* You have to stop and poke the module every 64 bytes, and wait for a response. This is sort of inefficient when loading non-trivial amounts of data (duh) but I don't know offhand how long we spend sitting in "waiting for the response".

* Won't ANY I/O mapped, 8-bit-wide polled solution peak out at about 200-250k bytes/second on a 4.77MHz 8088 machine, assuming zero overhead elsewhere in the task. Reading a port to a register, then writing to memory, then any loop management, seems to add up to around 20 or more clocks per byte. You can do noticably better than that on a V20/186 with tighter repeatable string instructions.

An interesting concept might be to try memory-mapping the device, I'm expecting a memory-memory MOV might be faster than reading a port and pumping it back out to memory.

I suppose the ideal would be some sort of intermediary controller that managed DMA and pulled bytes from the CH375 as fast as it could cycle.

I'll be digging out my machine with the CH376S and the BIOS I mentioned over the weekend likely (ordered a serial pointing device for it so I can use GeoWorks properly )-- is there a specific benchmark people want to see (bear in mind it has to run in 512k)

 

[Eudimorphodon]

I wonder if the thing has any internal buffering at all. Do the SD-to-CF adapters use single-bit SPI or 4-bit SDIO?

I don’t remember the exact benchmark result I got from the SD adapter I have installed in a Via C3 thin client but they’re “fast”, IE, multi-megabytes per second, so I would assume it would have to be SDIO. I’ve tried looking up the datasheet for the bridge chip but it’s only available under NDA.

 

[Malc]

Did you clock w/ the driver or the ROM? (I'm going to do both once i figure out an effective way to check... all the disk benchmarkers ignore it because it's not 'real')

DOS Driver, I didn't bother with the ROM this time because it's, well, Crap, and the last time (A few years ago ) i tested with the Dos Disk Tester it reported about a Million KB\s with the ROM.
Try the DOS Disk Tester and also run the Media Test.

 

[pearce_jj]

you send a command for "Queue up NNN blocks starting at LBA NNNNNNN", wait for a go-ahead, and tell it you want to read it back 64 bytes at a time....You have to stop and poke the module every 64 bytes, and wait for a response.
...
Won't ANY I/O mapped, 8-bit-wide polled solution peak out at about 200-250k bytes/second on a 4.77MHz 8088 machine, assuming zero overhead elsewhere in the task. Reading a port to a register, then writing to memory, then any loop management, seems to add up to around 20 or more clocks per byte. You can do noticably better than that on a V20/186 with tighter repeatable string instructions...An interesting concept might be to try memory-mapping the device, I'm expecting a memory-memory MOV might be faster than reading a port and pumping it back out to memory.

The 64 byte transfers will certainly nobble performance. Even with CompactFlash cards that only support single sector transfers, there is a very measurable impact on XT class machines because of all the jumps back through the BIOS which take forever.

Re memory-mapped IO. There is a benefit on Intel 8088/8086 because they lack the form REP INSW, which 286 and V20 both have, but do have REP MOVSW. Electronically there is little difference, except the strobe lines generated. I've listed the performance at 4.77MHz for a few options here. Using 8-bit transfers will also increase code size and hence reduce throughput, this is the basis of the 'chuck mod' (or BIU mode) in the XTIDE terms, as it enables 2 bytes to be transferred on a single instruction cycle (with some bus logic generator wait states obviously). The effect of the single-instruction port-mapped limitation on 86/88 can be seen here from line 24 - REP INSW replaces all of that.

I've not looked at the USB BIOS source for a very long time but loop unrolling is the usual way to achieve some gains.

To add; I put together a version of the CH375 many years ago (here) which added 16-bit transfers via partial address decoding. This should help improve the throughput.

 

[Malc]

To add; I put together a version of the CH375 many years ago (here) which added 16-bit transfers via partial decoding. This should help improve the throughput.

That's the one i have and still use, I was hoping your Rev 2 would be completed and available but never was. I modded my card to use the same 260h address as the Chinese cards.

 

[pearce_jj]

I'd completely forgotten you'd got so far with it. Perhaps it would be worth spending some time to sort the BIOS for the 16-bit transfers and complete the rev.2 card.

 

[Malc]

That would be super cool, ASM is way over my head but i'm happy and willing to help in the testing, I'd prefer to get a Rev 2 card from within the UK, I can build it myself.

 

[sorphin]

Seems TechTangents did a video on it too now.. and gives a lot more info... eventually had really good results from it..

using it on a 5150 as well..

 

[Malc]

I noticed he's using ver 1.9 of the DOS driver, I use ver 1.9A of the DOS driver and have successfully used it with CF or SD in my multi card reader, 1 / 2 / 4 and 32Gb flash drives and spinning rust with the aid of external power in my PC 5150 / XT 5160, It's a lot better in a faster 486 / pentium, I don't have the Chinese card to compare to my Lo-Tech card though.

 

[twolazy]

I don’t remember the exact benchmark result I got from the SD adapter I have installed in a Via C3 thin client but they’re “fast”, IE, multi-megabytes per second, so I would assume it would have to be SDIO. I’ve tried looking up the datasheet for the bridge chip but it’s only available under NDA.

Curious if you use it as a dos machine or not? Was looking into them for a friend as a simple dos gaming machine, but curious if there is an ok-ish ms-dos sound driver... Guessing it is a thin client, like a Wyse Cx0.