VOGONS


Copam U-series 486

Topic actions

Reply 40 of 46, by aitotat

User metadata
Rank Member
Rank
Member

Just a few minor things I've observed:

No buffer overflows with old type rev 1.07 MT-32 so 486 @ 33 MHz is really nice for that also. Another thing I could have tested with DX2 is when the overflows start to happen. I suspect the CPU cannot be much, if any, faster.

I mentioned earlier about having problems finding 286 compatible later ISA graphics cards. I tested the ICL CL-GD5426 on my 286 and it works! It does have a BIOS related feature I didn't like (I did notice it already when testing it with Copam). Text modes use 85 Hz refresh rates (70 Hz is typical for VGA) to reduce flicker but I didn't like the noise monitor makes when switching from text modes to graphics modes and back again. So I tested another BIOS from here. That Diamond SpeedStar PRO BIOS does work so it too is 286 compatible and has normal 70 Hz text modes.

I tested the CL-GD5426 and both of the WD90C30-LR based cards on my 286 and run 3Dbench with them. 6.4 fps with all three cards (all have wait state jumpers at zero wait state) so again the performance is equal. I'd like to keep the WD on my 286 because it is closer to being period correct but the other with Bt RAMDAC has the snow and the other with Samsung RAMDAC has less sharp image quality. So while performance is the same, other features makes the CL best. But maybe I should make a new thread for my 286. I just made some changes to it.

Reply 41 of 46, by aitotat

User metadata
Rank Member
Rank
Member

Anyone interested how fast the 60 GB 1,8" Toshiba hard drive is? I must admit that I'm positively surprised. It easily outperforms any period correct drive from socket 7 era and perhaps from super socket 7 era as well.

I installed last of my HDD-CF-drives to my 486DX4 system (I had to disassemble it completely before I was able to install it) so it was a good change to test few different drives with HDD Speed. Here are some results. It is a text file saved with HDD Speed 2.1.

Here are the drives found in the result file:
160 GB SAMSUNG SP1634N (I replaced this with my HDD-CF-drive)
6 GB Hitachi microdrive HMS360606D5CF00 (this is one of the microdrives I like so much)
60 GB TOSHIBA MK6006GAH (this is the 1,8" HDD)
1 GB Seagate ST51080A (highend IDE drive from 1995, so likely the best period correct drive for my DX4 system)
6 GB Seagate ST36531A (typical super socket 7 era drive)
500 MB QUANTUM MAVERICK 540A (one of period correct drives for 486DX2 systems with 500 MB BIOS limit)
130 MB Seagate st3144AT (this came with Copam)

First note that the transfer rates are not fully comparable between all drives. The test uses old BIOS INT 13h functions to test the drives and this means maximum of 8 GB can be accessed. For drives larger than this the minimum transfer rate is incorrect because the slowest area of the drive cannot be accessed by old INT 13h functions. But if you are going to use DOS versions with only FAT16 support, then the slowest is the slowest you are actually going to get. But for FAT32 supported DOS versions (FreeDOS, Windows 9x) that transfer rate is not the real minimum. It is the transfer rate at around 8 GB and for that 160 GB drive, for example, that is pretty much still at the beginning of the drive so at the fastest area.

But does that even matter? For those large drives PIO4 will be a bottleneck even at the real end of the drive.

I have another thing to note. I'm not sure what kind of transfer rates you are used to for 486 VLB systems. My DX4 system has a VLB multi I/O card with Vision QD6580 IDE controller and XTIDE Universal BIOS has support for it so best PIO mode supported by the drive will be used and 32-bit transfers between CPU and I/O card (the VLB IDE controller buffers the data so 32-bit CPU instructions can be used).

So the pleasant surprise was that the 1,8" HDD has the best transfer rate, over 10 MB/s!!! I don't know why it is that fast, the 160 GB Samsung I've been using on the DX4 system only reads 6,8 MB/s and I was under impression that it would be the max I can get since PIO4 already limits the drive. So the Toshiba 1,8" drive has excellent PIO transfer rates! Very good for retro computers.

But perhaps more important it the seek times. CF cards have practically no seek times and that is one reason why they are popular solutions for retro computers. Toshiba has average seek time of 6,3 ms and average access time of 14,1 ms. The 160 GB 7200 rpm drive is naturally faster: 4,3 and 9,1. As expected, small silent 1,8" HDD cannot seek that fast. Also note that the 8GB old INT 13h limit affects these seek results just like transfer rates so not much seeking is needed when accessing only the beginning of the drive but for FAT16 DOS versions that is what you actually get.

Lets compare 6GB drives next, the Hitachi microdrive and old 6GB Seagate HDD. Microdrive is slow: 12,8 and 21,7. It puts it to about same speed as 500 MB hard disks so it is good if you want period correct access times but larger capacity. 6GB Seagate HDD has average seek time of 9,8 ms and average access time of 16,3 ms. So it is slower than the 1,8" HDD. It has only 128k cache but it is almost enough to get transfer rates comparable to 160GB Samsung, but no where near the fast 1,8" Toshiba.

What about older drives? The 1GB period correct (for my DX4 system, not Copam) highend Seagate IDE drive is simply slow (and noisy). At least it has better access times than the microdrive but transfer rates are no where near the PIO4 limit even though the drive support PIO 4. But the transfer rates are a lot better that what ISA multi I/O card would be capable of.

One thing to note about even older drives. The 500 MB Quantum and the 130 MB Seagate are both so slow that VLB controller is completely useless. This kind of performance is reachable with ISA multi I/O controller.

This post was not very Copam related but I think it had good information about when VLB multi I/O is needed (only the IDE controller uses the VLB extension, not the other stuff in it) and that the 1,8" HDD is actually a very good drive for retro computers. I'll benchmark the 1,8" HDD on a Copam later for comparison. The Copam does not have VLB IDE controller so performance will be limited by ISA.

Reply 42 of 46, by aitotat

User metadata
Rank Member
Rank
Member

Here are the results from Copam. No surprises there. I tested the Toshiba 1,8" HDD and Hitachi microdrive. Both have the same transfer rates because ISA limits the speed to 3,1 MB/s (actually that is a very good for ISA). Seek and access times are about the same as seen on a DX4 system previously.

Reply 43 of 46, by aitotat

User metadata
Rank Member
Rank
Member
aitotat wrote on 2021-06-29, 16:14:

One thing I did notice is that the HDD seems to automatically enter some sleep mode. It is not unexpected that it has such feature. XTIDE Universal BIOS has power management support but it is for enabling it. I'll need to check if it is actually left at drive default when it is set to disabled from xtidecfg.com.

Fixed in XTIDE Universal BIOS r615 and that sure took a lot of testing. This is again more related to DX4 and not Copam but I'll continue here since this Toshiba issue needs a solution and it just happened to be worst on the DX4 system.

After I installed my CF-HDD-drive to DX4 I decided to once again test FreeDOS. I installed 1.3RC4 and installing was pain since I could not boot from CD. There is install floppy available as well but it is horrible! It constantly accesses the disk drive and installing was very very slow because of it. I was sure the disk will have bad sectors before install is complete. Well the disk survived but my DVD-ROM-drive did not. Install was success but the DVD-drive no longer worked couple of days later. It was detected but could not spin a disc. So if you want to install FreeDOS to a system without support for bootable CDs, I recommend not to use the install floppy. Instead install on another computer or emulator and then transfer the system yourself. I really hope install will be better on 1.3 final.

But install was successful and I started copying files from microdrive to the 1,8" Toshiba. Norton Commander always failed to copy few files so I started to test with XCOPY. There were always some not ready errors with it when copying large number of small files from microdrive to Toshiba. First I started to suspect the FDAPM from FreeDOS but that was not the problem. Disabling interrupts maybe helped a bit but that was not it either. Eventually I blamed FreeDOS since MS-DOS 7.10 (DOS related Windows 98 files I copied from my Super Socket 7 system) seemed to work much better. I was able to copy everything without problems.

But I did have some very occasional problems, like pauses when executing config.sys and autoexec.bat step-by-step, especially when microdrive was connected. I suspected Master-Slave-issues since the 1,8" HDD adapter did not have jumper but the CF-adapter did. I tested different cables and the 1,8" HDD adapter without the CF adapter connected but that was not it either.

Eventually I had to suspect power management again since Doom had some pauses, like loading and I sure did not remember it had those. So I started to read Toshiba datasheet a little better. The drive automatically enters Idle mode after command so it was not enough that XTIDE Universal BIOS disabled the idle timer (=power management disabled). Toshiba required power management to be disabled by disabling stand by timer. It is a timer to enter stand by mode from idle mode. Now XTIDE Universal BIOS r615 sets the same time (configurable on xtidecfg.com) to idle and stand by timer. That change alone fixed the Toshiba issues.

But I went a bit further. The drive supports advanced power management. It can be used to balance the drive between performance and power consumption. ATA6 specs define 254 stages but they translate to only three different modes on Toshiba and default is the middle mode. Now XTIDE Universal BIOS r615 sets the fastest mode when power management is disabled. There is still some work to to since there is no check at the moment to make sure APM is supported.

Since the Toshiba is a good drive, I ordered few more. Those good Hitachi microdrives were no longer available when I wanted more so I don't want to make the same mistake again. But there is one more issue, or actually two. For some reason HDD led does not work for Toshiba. It works fine for the CF adapter. I suspect that the 1,8" HDD adapter is to blame. When I get more Toshibas, I'll try to modify known good CF adapter for it.

By the way, here is how the Toshiba performs on my Super Socket 7 system:
uc?export=download&id=1p_oeTS1jq2MPbUsO38ENQtQev0oXD99u

and DX4:
uc?export=download&id=1mieePxAeEX7jkAVHz7jkc3enqpjjfQ6G

and finally Copam:
uc?export=download&id=1K1NQkq1gOrBj6ZVVglrt4dB9t6m7v1gA

Notice how the Toshiba performs better on DX4 than on the Super Socket 7 system. I'm sure UDMA drivers would fix that but I haven't even searched if that SIS chipset has those for DOS. But the DX4 and Copam pictures show something else as well. The verify speed is missing. I don't know why. I couldn't find anything wrong with XTIDE Universal BIOS verify function.

Reply 44 of 46, by aitotat

User metadata
Rank Member
Rank
Member

There is third issue as well. Notice in the pictures above that the Toshiba in DX4 system has a bit larger capacity. It is what it is supposed to be, 117 210 240 sectors, as defined in Toshiba datasheet. Why the two are less than that? All the drives were new (sealed bag) but none were empty. They had some chinese Windows installation. I wonder what device these were originally intended to. The Chinese windows did try to boot on a 486 but not very far.

Since they had some factory installation, maybe they are intentionally limited for some reason (but why the one was not?). I could not find any Toshiba utility to set the drive features so I'll have to experiment myself. Well almost all of the capacity is available already so this only a very small issue.

Reply 45 of 46, by aitotat

User metadata
Rank Member
Rank
Member

And now we have verify speed on speedsys. It was a bug in XTIDE Universal BIOS verify functions after all. All I did was a quick dirty fix without proper error handling. I'll need to make it a better one before I commit code to repository.
uc?export=download&id=1Y3Z2504vuY0mSfsQIG9rEEmMXna01Mks

Reply 46 of 46, by aitotat

User metadata
Rank Member
Rank
Member

I forgot to mention that I got two new CRT monitors. The older is 14" Hyundai HCM-421E manufactured in June 1991. This is older than Copam but I think its size and appearance is close to the monitor that likely came with Copam. But I think this one is better for my 286, although I really like that Nokia made ICL I mentioned early on this thread. The other Monitor I got is Forefront DH-1570.

It is manufactured in June 1996. It is a good looking monitor without anything really special, except it has very easy and fast to use OSD. But what I really like about this monitor is that I used to have one. I got one when I bought a Pentium 120 system in August 1996. And I kept that monitor many years until I finally had to sold it in 2012, I think. I needed to sell some stuff because I was moving to another city. So I kept the 12" IBM already mentioned in this thread and sold the Forefront. It was a good choice. Now I have very good IBM monitor (and those PS/2 monitors are not cheap today) and Forefront that is less yellow than mine was nearly 10 years ago. I really like this monitor and I want to keep it on my DX4 system. In fact, the DX4 system is the very same where I used my old Forefront before selling it. But I definitely need make a thread about my DX4 system sometime. It is really great system.

But back to Copam and sound cards. So it has Orpheus now because real Sound Blaster Pro 1 and 2 had those mixer problems mentioned in this thread earlier. And the Orpheus does have intelligent mode midi controller needed by the real Roland MT-32 now connected to the Copam so the other ISA slot was free to something. If I could have left the SB Pro in there, I would have used the other slot for Roland SCC-1. That would have given great GM/GS support (although not really needed for this system) and intelligent mode midi controller for connecting MT-32.

So now the other ISA slot has Gravis Ultrasound Classic in it. It is very hard to understand that it is actually period correct for this system! It is technologically far ahead of period correct Sound Blasters that would be the SB Pro 2 and the noisy CT17xx models of Sound Blaster 16.

My first GUS was GUS Ace I bought in late 1996 or early 1997 (and I have it with box and all) for the Pentium 120 system. I very soon upgraded GUS memory to the max 1 MB it supports so I've pretty much always used GUS with RAM maximized (and you should do that if you want to use GUS for MIDI) and I've always had a Sound Blaster or compatible in the same system with GUS. Getting a GUS was almost as great experience than getting my first sound card (that was Sound Blaster 2.0 for 12 MHz Commodore 286). Nothing ever came close to those two ever again, well maybe Roland MT-32 did when I finally got one but that was much later for a retro system.

GUS is at its best with games using tracker music (MOD, X3M etc). Epic games usually has great support for GUS but there are many others as well. But games with MIDI music are a different story. GUS has 5 MB of MIDI instruments and that is a lot for example compared to Sound Blaster AWE32 with 1MB ROM. So 5 MB of instruments and 1 MB of RAM (at max). How does it work? Well, I think the idea was that only the necessary instruments are loaded and replaced when playing another midi file. That way even less than 1MB would have been enough for great sounding instruments. But that would have required game developers for such special midi support for GUS. I don't know if there are many games (or any, in fact) to actually do so. Instead another route was taken.

The other way is also used by Mega-EM. It is a General Midi / MT-32 emulator for GUS. When it is not known what instruments are needed, some substitute is used instead. Like using acoustic piano for all pianos. This is the reason sometimes GUS uses wrong instruments. Then it is possible that the instrument is converted to 8-bit when loading it to reduce space. These are the methods how Mega-EM creates 1 (or 0,5 or 0,25)MB sound bank from 5 MB instruments. And games with not so great support for GUS essentially do the same.

But still, I've always thought that GUS midi sounds better than AWE32 midi. And Mega-EM works better than Aweutil for the emulation. At least for MT-32 support. Mega-EM does work with Sierra games (normally needing intelligent mode) but there are stuck notes and such. Maybe Larry3 was especially bad or maybe I played it more than other Sierra games but I can remember that whenever note was stuck, I saved a game, quit, ran ultrinit to quiet the card, then started and loaded game again. And there was not going back to FM synthesis, GUS sounded so much much better, even with Mega-EM with instrument substitution and such. General Midi emulation worked really well but did not work with protected mode games but those usually had support for GUS anyway. Sometimes the MT-32 emulation did not have any problems at all (like with Monkey Island) but I think the requirement for intelligent mode was the only thing causing the problems. Still, you at least had some sort of support for some intelligent mode games.

I experienced wavetable synthesis with GUS so it brings a lot of memories and good feeling. Still, would I use GUS for midi today? No I would not. Real Rolands, both SCC-1 and MT-32 and variations are way better than anything else. If GUS was technologically way above Sound Blasters at the time, then what Rolands were? MT-32 was released in 1987 and SCC-1 in 1992 (like the GUS Classic).

So for the Copam the GUS is there for tracker music, not for MIDI. Star Control 2 is one of my favorite games and it runs great on Copam (but the /g:bios command line switch is needed because of the RAMDAC issues). Back in the days I couldn't use GUS with Star Control 2 because I didn't know this. There was another solution as well. I think GUS support should work if GUS is set to normal Sound Blaster parameters (a220/i5/d1) but I couldn't do that since I always had real SB or compatible with GUS.