I recently needed to install Windows XP. Because I don’t do that very often nowadays I decided to document the “pro way” of doing it.
First you should consider getting a volume license copy of Windows XP CD because it doesn’t require activation over the internet. The process below will work with any version, but it will require activation.
Then you need to download and install nLite which lets you add SATA/AHCI, network, display, audio, drivers and customize a fully unattended installation, including the product keys, and some tweaks like autologin, themes or show extensions/hidden files in explorer. Create your own bootable XP .iso file. You should probably test it in VMware/Vbox/Qemu first to see that all the settings are to your liking and the setup prompt screens are gone.
Second you need WSUS Offline Update, version 9.2.1 (which is the LAST version supporting Windows XP). It will let you roll out your own Service Pack 4 for Windows XP, including all the updates and goodies like .NET framework, Silverlight and DirectX updates. Create your own SP4 .iso file.
Booting Windows XP from a regular USB pen drive is notoriously difficult, so this is where ISOSTICK comes handy. Put both of the iso files on to the stick, insert to the PC and watch the magic happen.
It’s quite easy to integrate the SP4 in to the boot cd itself, but then it outgrows size of a physical CD, which is not a big deal with ISOSTICK, but I don’t mind installing the updates in a second step.
Finally if you need to install apps automatically you can consider something like Ninite.
In previous posts from ASV series I have explained why I got hooked on Atari System V UNIX and what I had to do to get a decent resolution out of Atari TT. Having built the VGA monitor adapter, the next challenge was to replace the internal SCSI hard disk with a flash storage of some sort. I really don’t like spinning hard disks and especial the old ones.
I have mentioned that there are two surviving ASV disk images. The better one was made out of a rather large old, loud and obnoxious Maxtor. I’m definitely not having this monstrosity inside of my beloved Atari!
So how can you replace an old SCSI hard disk with a modern flash device? There actually are several different ways.
If you have the money you can go industrial route, which is a SCSI disk replacement for various machinery and embedded systems produced by ReactiveData. You can buy one of these for a little over $1000 USD. The good part is that they substitute a specific real hard disk model and are exceptionally good in quality of emulation. However, spending a lot of money on my TT and TenoxVGA already, this really wasn’t an option without getting a divorce.
Another approach is to use SCSI to IDE bridge combined with IDE to CF adapter or possibly SCSI to SATA bridge and SATA SSD disk. These are widely used by Atari / Amiga / Mac 68k community. The most popular bridge come from a company called Acard. I actually had one of these at hand, AEC-7220U which I used for TOS/GEM work.
Did it work? As you can guess – of course it didn’t! The initial boot loader errors out unable to read disk capacity.
Atari SYS V failed to boot
Atari ST/TT, somewhat similarly to 68k Macs require a hard disk driver, present on the hard disk itself. There are several 3rd party implementations, some of them, like HDDRIVER maintained up to present date. Unfortunately these drivers are TOS specific and obviously don’t work with Atari Unix. The system comes with it’s own hard disk driver which seems to be obsolete and with limited hardware support.
The next step was to research and try out some other SCSI to IDE bridges in hope one would just work. And surprisingly there are several to choose from.
The second on the line was I-O Data R-IDSC21-E/R. No longer produced and supported, however still fairly popular. Usually regarded as the ultimate bridge with most fancy options bells and whistles. It has most jumpers and modes of all tested devices. For instance ATA PIO and DMA modes. Unfortunately this didn’t help at all and same error was observed.
Another device tried was Yamaha v769970. This bridge was conceived to allow use IDE CDROM and Hard Disks with Yamaha samplers. No longer produced and obsolete, it’s somewhat most easy to set up, robust and stable. It’s actually my favorite bridge for day to day use, except for ASV where it just doesn’t work.
More recent kid on the block is an integrated SCSI2IDE + IDE2CF in one device called Aztec Monster. Recently designed and currently produced in Japan (you can buy one on eBay) is a fairly decent choice, which I recommend to every one. I had a lot of luck with these, except for ASV of course…
I also looked in to SCSI to SATA bridges, like this one, but they have additional issues, like need to convert LVD to SE on one end and SATA to IDE to CF on the other. Little bit too complex for what I wanted.
Being out of luck I started researching if it would be possible to build an open source version, which can be easily diagnosed and fixed. Doing so I found out that there in fact is one open source SCSI adapter called SCSI2SD.
I was bit skeptical in the beginning but then I though that being open source it can be debugged and fixed if it needs to be. So I immediately ordered one.
Once it arrived, I plugged it in, applied the image to the card and BAM! It worked! The system booted fully and worked flawlessly!
Sometime around 1992, Advanced Gravis teamed up with Forte/E-Tek to design a wavetable synthesis card around the ICS11614 IC. This card offered 32 channels, 14 channels @ 44khz and more channels would start dividing down in sound quality until you got to 32 channels at ~19khz. The mixing was done on-board which saved precious CPU cycles in the days of 286 and 386. The card originally advertised sound blaster support, but reading usenet posts from these days you can tell a lot of people were agitated that it was through a TSR, SBOS, that had hit or miss support and sometimes sounded better or worse than the FM because SBOS mixed it all into stereo.
I found out about these mythical cards a few years ago. A buddy went along with me to the local flea market out in the country-side of York, PA and we found a fellow who was trying to sell some P2-era laptops with USB wifi dongles and Windows XP loaded laptops for $100(!). I started talking with this gentleman and eventually convinced him to let me take a trip to his house and see what other stuff he may have. I took home a healthy share of various SB clones (mostly of the ESS variety, but a few Yamahas were in there as well) and some S3 Virge cards all for free. I built a computer with some of these parts, enough to play Doom and Heretic and started hitting up vogons and was reading some fanboism on the Gravis UltraSound cards. Where did I hear that name before? Oh, yes, in my mid-late 90s days of Doom I remember the setup.exe listed this card as an option and so did Duke3D and some other games I used to play quite frequently.
I did a lot of research on the card. Reading about how it used wavetable synthesis instead of FM. Basically, you can upload real MIDI-like patches to the cards RAM to get exceptional sound quality out of these older games and this also opens the window to creating your own patches if you wanted to tweak the sound of the songs.
Fast forward a couple of years later, I finally broke down and bought a GUS Classic v2.4 on ebay for $60. Unfortunately, it didn’t work out of the box. Failing to detect the card every single time, even if I removed everything from the computer and even disabled everything in the BIOS, including the FDC, Serial and Parallel ports. I got a refund, but a few days later I noticed some resistor had a broken leg and I soldered this and it started working! Immediately I loaded up Doom and the music sounded so much better than my SB or any of it’s clones.
Enjoying the sound, I started loading up other titles I played a lot back then that I remembered supporting this card: Descent, Heretic, Duke3D, Quake 1. I got a taste of some infamous Gravis issues when it came time to load up any Build engine title (Duke3D, Blood, SW, etc.) and Rise of the Triad. The music sounded great, but the digital voices had some weird clicks and somewhat static-like sound at the end of their samples. More research revealed that the GUS was known for this with those particular titles, and a ìsimpleî workaround is to get an SB card coexisting in the same box.
I amazingly got the SB and GUS living in the same machine after a few hours of fiddling around with some jumpers and tweaking autoexec.bat. Originally, I used one of those stereo to stereo cables. Running line out of the SB to the line in of the GUS, but the GUS’ mixer ìcolouredî the sound of the line in and mic in with entirely way too much bass. I made a cable that ran from line out of the SB16 to the CD-In of the GUS and it sounded excellent. I even found a way to keep my SB working in Win98SE this since it was known that the GUS had shitty support for the Win9x family (more on this later).
There are some shortcomings of the classic cards, the main being the Win9x drivers have no DirectSound support, only software emulation and usenet says that this had unpredictable results. Another annoying thing was no volume mixer(!), they expected you to hook this card up to powered speakers or ideally an amplifier. The v3.7 revision has a volume mixer but had problems with flip flopped stereo (whoops!) and v3.74 (the final GUS classic) fixed this problem. For those curious, for the most part revision versions don’t have bug fixes in their firmware, they just started finding ways to shrink the number of ICs on board. The exception to this was the v3.7 and v3.74 adding the volume mixer. GUS MAX v1.7 apparently had some sort of DMA or IRQ bug (forget these specifics) according to usenet, v1.8 fixed this problem and v2.1 is a v1.8 but lower component count and everything is now soldered on instead of sockets.
Other gotchas include: sound clicking and corruption on High-DMA, sometimes you can resolve this by setting 16-bit delay transactions but not all motherboards have this option and some just won’t work either way. Doubling up on the baseport, i.e. 220 also steals 320. Gravis claims you need to set the GUS and SB Emu IRQ to different values but they can be the same usually and have no problems. Same with the Playback and Recording DMA, unless you want full-duplex. If you’re just gaming it’s irrelevant.
Ultrasound MAX box
At some point, I was hungry for more, wanting to try out the later GUS models like the MAX, ACE, and PnP. Particularly the GUS MAX because it included the volume mixer, had a special Crystal CODEC chip for 16-bit recording (was released late in GUS classics life as a daughterboard but it is very rare), the CODEC chip allowed for Windows Sound System, but the port is non-standard (gotcha!) and a special SBOS, MAXSBOS, takes advantage of the CODEC chip as well, and finally some CD-ROM support on board but I was uninterested in that since most of you know how much of a nightmare it is to get that shit working properly. Back to ebay, found a fellow selling a boxed GUS MAX for $100. I didn’t have the total cash on me at the time and it was buy-it-now. Considering the card was fairly hard to find, at least from what I researched at the time, I contacted the guy about paying half now and the other half in a few days. He agreed, and asked that I send it as a gift via paypal. Long story short, he never sent it, stopped replying to my emails and since it was sent as a ìgiftî I had no recourse through ebay or paypal. Learn that lesson when dealing online everyone! Always offer to pay a little extra for the processing fee if they claim this is why they want it set as a gift!
Bummed out, I found another classic, this time a v2.7 and well what do you know, this one doesn’t work either! Tried for 3 days all kinds of things. Cleaning the entire board off with electrical contact cleaner, reseating the contacts on the socketed chips, reflowing solder joints, replacing capacitors, but nothing ever brought it back to life. A year or two later, I found another GUS MAX for sale on ebay, purchased it immediately and it did not work. I tried it in 3 separate PCs and got no results. It always just said baseport UNAVAIALBLE FOR ULTRASOUND for whatever baseport I set it to. However, it wasn’t a total loss. On a whim, I took the GF1 IC from this MAX and placed it in the broken v2.7 classic and it made this card live again.
I setup daily searches for ebay to alert me immediately of any GUS developments appearing. If you’re new to the whole Gravis thing you’ll see theres a guy in Hungary who always has overpriced ones for sale and is unwilling to budge on price. If you check out his feedback you will see that he has been selling GUS cards of all flavours since at least 2010(!) almost monthly. Months and months went by with no MAX showing up and when one finally did it went for way more than I was willing to spend especially with the track record of 2 (almost 3) DOA cards that required soldering and intense cleaning to live again. If you’re planning to experiment with GUS cards be sure the card was tested recently, if you get the typical responses of not having an ISA PC around any more to test it, get the card cheaply and be certain that they will honour the return policy if it does not work.
MAX 2.1 board
Finally, after a couple of years I did some networking and found some fellow demosceners with GUS MAXes for the price of shipping. I’m waiting on my v2.1, but received two v1.8s. The first one did not work at all, would never detect properly. Tried the usual suspects of cleaning it up, reseating, rocking the caps a little back and forth to make sure everything was making contact, etc. The second one, actually detected the card saying UNAVAIALBLE FOR ULTRASOUND yet again, but this time after I disabled my FDC, Serial and Parallel ports it worked! Excited, I loaded up the usual games and all worked great and the CODEC chip’s mixer program worked properly. Now, I was read to add the SB16 back in but now no matter what base port I would select it always complained it was unavailable, yet again! At some point I got it working sort of but then it wouldn’t let me set any DMA properly in the setup utility. Enough of this nonsense, I thought, I have a few socket 7 towers not being used.
I popped it in to a P1 166MHZ living by itself. Now we can try out that special MAXSBOS!… and unfortunately it doesn’t sound better than SBOS, in fact it sounds worse! And yes, I tried a separate IRQ for SB emulation and low-DMA, high-DMA, making sure the CD-ROM baseport doesn’t conflict with GUS’ baseport and I have 1MB RAM onboard that is 70ns.
At this point I should stop and mention a few other gotchas on these MAX cards. The GUS ìdoublesî up on the baseport. i.e. if you set 220 it will also grab 320. The CD-ROM baseport on these cards will be set, even if you disable the rest of the CD-ROM interface. So make sure you don’t have the CD-ROM set to the same or else it will always complain it’s unavailable for ultrasound in the setup utility. And yes, you just have to remove the IRQ and DMA jumpers on the card and put the jumper on the CD-ROM disable. Panasonic enable jumper appears to make no difference regards to enabling parts of the CD-ROM circuit, unless of course you planned on using the CD-ROM interface. I’m assuming most of you out there won’t be. You also need 70ns rated (or better) 256kx4 chip. The MAX has 512kb RAM on board but you NEED 1MB on any GUS card to get great results or live with missing instruments and all kinds of funnies happening to you. The CODEC also uses some baseport, but this is software selectable so you should have no serious problem there.
Now I go on to try this bad boy out in Win98SE with the special DirectSound enabled drivers. When you install the Gravis GF1 (non PnP) series drivers it will tell you that you have to install the card as a non-PnP device and restart, then manually set the DMA, IRQ, Baseport in the advanced properties for the card. This is fairly trivial if you’re used to DOS, but for newbies just keep it in mind. Another gotcha here is that the drivers will blank out your SET ULTRASND= and SET ULTRA16(for MAX users)= in your autoexec.bat after the reboot so write these values down. I believe this was done on purpose since most people auto loaded SBOS or MEGAEM (the other SB emulator they had) and this conflicts with Windows big time. The drivers do work and the sound quality is fine, but the biggest issue I’ve had is that sndvol32.exe never loads now. You can not adjust the volume or disable the mic-in and line-in and you really should as every card I’ve owned the recording inputs pick up a lot of interference. Moving the mouse and the HDD just all come through your speakers. I haven’t tried Windows 95 yet, maybe the mixer works okay there? At some point I’ll post an update and let internet-land know.
Gravis Ultrasound ACE
SoundBuddy 1.0 prototype
I don’t own these cards, but will mention them for clarity. The GUS ACE (internally referred to as the Sound Buddy) is simply a GUS Classic without the recording capabilities or the gameport. It was meant to be a supplement to a sound blaster or similar clone. You simply run the line out of this card to your line in of your SB16 (or maybe it’s vice-versa? Correct me if need be). You have to update your ultrinit to the last known version because there’s a bug in the official drivers(!) that does not disable the nonexistant gameport and it will steal your other sound cards gameport cause conflicts. For those who need the fix, GUS0047.ZIP. At one point, Gravis struck a deal with AMD to make an enhanced chip, called the InterWave which had GUS support and allows 8MB of samples (16MB apparently if you solder some stuff, but I have yet to see any pictures or even a textfile on this hack). Pouet.net sceners say that it has problems with long loops so some demos may sound wrong. IWSBOS is based from MAXSBOS so I assume it probably sounds just as bad compared to the final revision of SBOS. Usenet posts of users crying that the Win9x drivers are awful too, but again, I don’t own this card so I’m only just passing on what I have heard. Feel free to prove me wrong in the comments.
Other weirdo cards included the Synergy ViperMAX, which is basically a GUS with an ESS chip for SB compatibility. In theory, this means you should get decent Win9x support through the ESS. These cards are kind of rare now. I have yet to see one appear in the US. But, fellow Pouet.net users have found them across the EU so maybe they are common there. There were some other OEM variants, most similar in design to the ViperMAX. Check out Wikipedia for information on those if you really must know more.
My final thoughts on this long (still not quite yet over) journey is that the GUS Classic is a fun card for breathing some life into the soundtracks of older id and apogee titles with a few silly hang ups on getting it to work initially. The MAX did not live up to its mythical hype with the mixer, special CODEC chip, and Win9x drivers. These cards appear to be very delicate because I have had 3 out of 5 cards DOA and required fooling around to get them to work again. Even though 2 MAX cards still do not work no matter what I’ve tried. Expect to buy more than one to get a working card. The ideal setup would be to get a GUS Classic or ACE and get that to coexist with an SB or compatible clone. I can’t comment on the ViperMAX as I have not located one yet.
Gravis Ultrasound MAX 2.3 prototype
As much frustration these cards have brought me, they still sound nice when they work! But, it really does make a lot of sense why they are rare today. It is quite aggravating to get one working properly!
All of this would be useless without some samples of what a GUS sounds like, all samples were recorded at 44,100Hz, …
I’m pretty good at finding bugs in Windows and I get a new one every couple of weeks or so. Today I found out this unbelievable gem:
So there is this (cmd.exe) command called timeout. It works roughly similar to sleep(1) under Unix. It is supposed to stop execution of a batch script for a given period of time. Example:
In reality just wishful thinking, because apparently this is not always the case. Sometimes it does and sometimes… it doesn’t.
Sounds unbelievable but it appears the timeout command uses Real Time Clock for it’s sleep function. If you change the clock while timeout is running…
I found this because my batch scripts were stuck for rather long time when a machine would have time changed by NTP. If the change was negative the timeout command would wait x thousand seconds. When the change was positive the integer rolled and timeout stopped immediately causing avalanche of problems.
In the previous article I explained how I got hooked up on Atari UNIX and brief efforts in the hardware department. TL;DR I got stuck on lack of a specialized Atari “high resolution” 1280×960 CRT monitor, which operates using ECL rather than VGA signaling.
So what is ECL signal? Without going to too much in to the details ECL is a differential signal much like LVD SCSI. These are basically more interference resistant and therefore allow higher bandwidths.
ECL signaling was used for high resolution monochrome monitors for Sun, SGI, DEC, HP, NeXT, etc. before VGA got it’s high resolution modes via VESA extensions.
During the research phase I came across a device made by Extron, which basically converts ECL to VGA signal. These were made to allow SUN/SGI/HP/NeXT workstations to be hooked up to a VGA projector.
Despite hours spent attempting to get these working by myself and other Atari users alike, this just didn’t work.
At this time the only viable approach would be to make such adapter from scratch and specifically for the Atari TT. I have rather limited experience in electronic circuit design. I was not the first to come up with such an idea. Over last 20 years or so adapters like that were made and tried before by much more experienced people, but still with rather crappy results. It was obvious I needed a professional help. Fortunately for last several years I have been living in the Silicon Valley, which is abundant with required skills.
I have found a helpful company with an extensive expertise in video signal processing, described the problem, they understood, gave me a reasonable quote, I delivered my Atari computer and waited patiently. After a few weeks I’ve got an email that I can come in ad see a preliminary results. They have made this device:
And Atari TT was operating in the monochrome 1280×960 mode on an LCD panel! Well nearly there…
The signal was shifted a little bit, and the board was operating from a lab bench power supply. Not a big deal. After a few days they have added a small bread board with a circuit to shift the horizontal sync and a voltage converter to obtain -5V needed for ECL components. Everything was just perfect.
I have ordered qty 25 of the unit to be made and knowing the final price went to look for more serious commitments from Atari users who previously expressed interest. Being out of touch with Atari for quite a long time I realized that most of the interested users are musicians who still use TT for Cubase, and would like to have a larger and more modern LCD screen. They were delighted so see this:
Also in the mean time I started testing more and more LCD panels and realized a rather big issue. TT High mode is 1280×960 where as most LCD panels operate in 1280×1024 mode. This is a 64 pixels difference vertically and also 4:3 to 5:4 aspect change. I have assumed this would work just fine if monitor was set to so called 1:1 mode or expansion/scaling off. Unfortunately to my utter surprise almost zero monitors out there had this mode! Only the newer, larger Dell monitors had it. But who would want to waste a 24″ monitor to run such a small resolution on, with large black border. I went through endless monitors, new and used, user manuals, specs, computer junkyards like HSC and WeirdStuff, etc. Nothing seemed to work. Everything was getting anti aliased and blurred. And then someone has recommended me a NEC 1990 LCD panel:
It did have 1:1 mode as well as custom aspect ratios and most advanced display settings known to an LCD panel. Worked like a dream. The screen was 100% perfectly sharp like you were looking on Atari ST emulator on a PC or Mac. The black bars on top and bottom are the lacking 64 pixels, but they are almost not noticeable. Fortunately the NEC monitor goes for $50 USD on eBay and matches Atari TT in case color. It’s a perfect TTM 19x replacement. Most users who bough the adapter would also invest $50 and get the same monitor to avoid anti aliasing and have a perfect image display. I also became an instant fan of NEC 1990 and now see it as THE LCD panel for all my retro computing activities.
Back to Atari, one problem solved, I was hit with another disaster. The finally assembled converter units were producing rather crappy picture. The picture was oscillating and there were a lot of nasty artifacts and imperfections on the screen. The NEC LCD panel couldn’t even auto adjusting to the signal. Long story short, once components from the bread board were incorporated on to a much smaller PCB they started interfering with now un-differentiated and unshielded video signal. Also some of the ICs were overheating and changing properties after a while. The investigation and problem solving went over budget rather quickly. The company stopped charging me at some point and worked in spare time to solve the problem. Unfortunately it took several months to finish. This is mainly because each try requires a new PCB reprint, at low cost / priority which is of course made in China. So about 1 month for 1 try just to see if it’s any better. From a time perspective now I can understand why all previous attempts to construct such a device failed miserably. It required a LOT of patience and professional expertise to finish it.
This is how a final version of TenoxVGA looks like:
In the mean time I had some time to come up with a case for it. I have experimented with a water jet cutter:
but finally settled for a 3d printed version. It’s much cheaper and easier to produce than cutting and bending a sheet metal:
Once I have received a shipment of 25 units and got appropriate power supplies and cables I have winged a website with paypal payment and started selling to the happy Cubase users.
Having fixed the 20 year old video problem I was now ready to install Atari System V UNIX…
I needed to use Windows PE with paravirtualized SCSI driver under VMware. Most blog posts I came across mention the same very wrong thing: grab pvscsi driver folder from VMware Tools location and insert to WinPE .wim file using dism /add-driver. Wrong, on two levels!
First of all the mentioned folder C:\Program Files\VMware\VMware Tools\Drivers\ contains only one subfolder “hgfs” and does not contain pvscsi, vmxnet3 or mouse drivers. In order to find the required drivers you need to extract contents of the VMware Tools CD Image (windows.iso). Once you can grab setup.exe you need to extract it’s contents to a separate folder using a special switch. There is a KB article how to do it exactly.
Unfortunately above does not work either. Even with the pvscsi driver correctly inserted in to the .wim file, diskpart was still unable to see disks attached to PVSCSI controller. After some research I’ve found that one must have so called text-setup mode driver for it to work correct. For example if you are installing Dell PERC driver it will come with characteristic txtsetup.oem file.
Fortunately VMware distributes text-setup drivers on a floppy disk image formerly called vmscsi.flp. My VMware Workstation has a file called pvscsi_windows2008.flp under “C:\Program Files (x86)\VMware\VMware Workstation\Resources” folder. Upon mounting the floppy image a correct pvscsi driver with txtsetup.oem showed up and I was able to copy and insert it to WinPE .wim file using dism /add-driver. Now I can see my paravirtualized hard disks.
I’m not going to go in to detail how to add these drivers to a .wim file as you can find it elsewhere on the web pretty easily.
Lately I’ve been very busy with several projects and noticed Aclock was lacking love for quite a while. For those who don’t know Aclock is a tiny C application that a small number of trusted volunteers and myself have been compiling to run on as many computer platforms as possible. The number of unique binaries is approaching 200 but is still short by few. As summer time sets in, some more fortunate of you will get extra free time, so I’m calling for volunteers to help to bring the gap and possibly go beyond.
Additionally I see more people looking for some particular operating system or piece of software and unfortunately nothing new for me to trade for and the gap is ever growing. Here is a chance to trade your time for some otherwise unavailable pieces from my collection. 😉
iOS (as in iPhone iPad) needs updating, I can pay dev license
Windows RT on ARM
More IA-64 platforms
More x64 platforms
Any other platform you may think of…
Operating system are mostly available. For some I will supply the OS. For others you will know what to look for. Whats required is your time and determination.
Some house keeping rules. I’m looking for a large amount of platforms (CPU+OS combination) and not multiple versions of the same OS. Generally if you can compile for OS version 1 and this binary works through v2 and v3 I would prefer version 1. Only if the OS has changed dramatically between versions I would want to get a separate binary. Secondly I’m currently NOT looking to get aclock ported to language other than C. So if a particular operating system doesn’t have C comparator, I’m not interested.
If you decide to work on any of this please let me know ahead of time.
I’m always interested in more screenshots and pictures of aclock running on various terminals and windowing systems.