I saw this card while I was out, and I’ve seen mention of some Radeon’s working on the Lemote A1901 board, although it didn’t like my Asus Radeon R9 380 Strix, I’m guessing it’s too old? I can’t find it now, but there was some mention somewhere of someone using a 500 series card (I don’t understand the AMD number schema), so I figured I’d get the 570 as it was just over $100 USD, and it has 8GB of VRAM, so it ought to be somewhat usable if I guessed wrong on the compatibility.
But I did get lucky! The card not only was able to initialize, but UOS came up to the desktop!
glxinfo -B gave the following output:
name of display: :0 display: :0 screen: 0 direct rendering: Yes Extended renderer info (GLX_MESA_query_renderer): Vendor: X.Org (0x1002) Device: Radeon RX 570 Series (POLARIS10, DRM 3.27.0, 4.19.0-loongson-3-desktop, LLVM 7.0.1) (0x67df) Version: 18.3.6 Accelerated: yes Video memory: 8192MB Unified memory: no Preferred profile: core (0x1) Max core profile version: 4.5 Max compat profile version: 4.5 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.2
So there we go, 8GB of memory, and ‘Accelerated: yes’. It’s also FPS locked to the screen refresh so it’s running a steady 60fps for the display I’m using. I need to build some later games that use GL to really push the machine.
The one big ‘negative’ is that the video card sits over the SATA ports, so I need to get an L connector SATA cable, as now I can’t use my 2TB spinning rust disk with the fancy GPU in place. And it makes my 800 watt PSU all the more justified.
I’m just glad that the portable drivers, well are portable!
Way back in the late 90’s from the University of Utah there was this fantastic project that promised to bring Operating System construction to mere mortals but taking existing PC operating systems, Linux, NetBSD, FreeBSD and break them down to their best components, and then interlink them using COM allowing you to glue the best parts together like lego.
And the project was called OSKit.
It was fantastic for something unknown at the time for creating so called ‘bare metal programs’ that didn’t have a real operating system, but rather could use operating features like LIBC, or the EXT2 filesystem. It was almost that level of ‘MS-DOS’ like feeling from protected mode, but being able to take more stuff with you.
And of course transforming the ELF into a multiboot executable that GRUB can load:
/oskit/bin/mkmbimage hello
And now you are ready to boot, on say Qemu?
I was kind of surprised it never really took off, maybe it was too far ahead of it’s time. The most notable project I’ve seen that used it was OSKit-Mach, although they later on abandoned OSKit.. I’m not sure why but I would suspect the lack of updates post 2002 would have something to do with it.
Building this was… Interesting as I recall this being somewhat difficult, and I know I’ve probably made it more difficult, but I thought it would be ‘fun’ using the tools of the time. And 1999 has us at Debian 2.2r0. Which thankfully is on archive.org and is a mere 3 CD-ROMS for the i386 binaries. Installing that into VMWare wasn’t so difficult, and swapping CD images around I was able to get enough installed to start building things. For those of you who don’t want to install Debian, here is my pre-compiled Linux on Linux toolchain: i586-linux2.tar.gz. It’s i386 on i386, so you will need to be able to run i386 ELF exe’s. For OS X users that haven’t installed Catalina, you can try OSX-Linux-2.00-i586-gcc2723.tar.gz
I should point out, that although things have to be patched around for older versions of OSKit, 20020317 does build fine using GCC 2.95.2 (20000220) from Debian 2.2r0. So if you want to build in a VM, then you really don’t need any of this. But I’m strange, and I have my WSL2 Debian 10 to think about. So the easiest way to build GCC 2.x is with GCC 2.x so why not start in Debian?
First let’s prep our destination directory, and populate it like a good little cross compiler:
With that out of the way, we can build the ‘patched’ binutils that was on the old OSKit archive, I used this binutils-990818-patched.tar.gz
./configure --target=i586-linux --prefix=/usr/local/i586-linux2
make install
Next I’m going to build GCC 2.7.2.3 as OSKit mentions to use 2.7 and I figured why not the last of the line? It seemed like a good idea to me.
./configure --target=i586-linux --prefix=/usr/local/i586-linux2
make LANGUAGES=c libgcc1.a
make LANGUAGES=c
make LANGUAGES=c install
Building is a little weird, as I build the libgcc1.a first, then ONLY the C language, then install that. OSKit is written in C, and I didn’t feel like even looking at dependencies for C++/ObjectiveC
Unix person, I’m not a great one, so a quick hack to get the new GCC onto the path:
And now I can build stuff!… I then tar’d if up and copied it to my WSL instance, and now I can cross compile fine (a big plus of WSL2 is that you can install the 32bit support, and run old EXE’s! Take that Apple!)
Now it’s worth noting that a few things need to be edited, the ‘OSKit on UNIX’ thing won’t build cleanly and I didn’t investigate as Qemu is a thing now. So disable it in the modules.x86.pc file. Then run configure like this:
sh configure --host=i586-linux --prefix=/oskit --build=i586-linux --enable-modulefile=modules.x86.pc
Despite using the host, build or target setting it doesn’t pick up prefix of our cross compiler, so you have to manually edit Makeconf
Be sure to change the tool exports to look like this:
And finally remove -fno-strict-aliasing from OSKIT_FFLAGS, and now you can build!
The bonus is that it’ll build well under a minute on a modern machine.
As mentioned above you should now be able to take the hello world example kernel, and transform it to a multiboot, and boot it via grub.
Again this was such an exciting project I’d hate for it to just suddenly die in absolute obscurity. Maybe it’ll inspire others to try “assisted bare metal” programs, there was a DooM OS, among others in the era.
So here we go again, yet another major vendor that has been around since the 1970’s decides that all their prior content needs to be purged ‘because reasons’.
Kind of sad that a few people in an old church can preserve the internet, but a megacorp like Intel cannot even be assed to keep their downloads available.
I’m sure the virtus/spyware/scamware/ransomware people are just salivating at this, as now they can easily add these named & tagged downloads to their lists, as more and more people run into intel branded gear, and attempt to recycle it’s use.
A few months ago I made a guest-post about my personal experiences with the Gravis UltraSound cards. In this article I mentioned there were a few variants
besides the standard GUS “Classic”, MAX, and PnP series. I was unable to
comment on the other cards since I did not own them. Well, that all changed
a few weeks ago when I contacted someone who wrote some pack-in software that
was included with most GUS cards and surprisingly he still had all his cards.
Even better, he was willing to give them to me!
One of the cards I received was the Synergy ViperMax. I have read some usenet
posts and have talked to other people who were active in the demoscene in the
mid-90s and apparently this card was originally designed by STB and then STB
produced their own card that has an ESS1688 chipset (for SB Pro compatibility
and better Windows drivers) and the GF1 chipset (the IC that makes the GUS
it’s own). How true is this story? I have no clue, as I have never seen an
STB variant of this card, but I have seen STB GUS PnP (the AMD Interwave
version) as Compaq OEM clones for sale occasionally.
In any case, Synergy started producing this card and it’s kind of a rare
number. Again, rumours afloat, that the guy from Synergy was coming to
demoparties and giving these away to groups that won competitions in an
effort to stir up some interest/sales. And before Advanced Gravis all but
gave up on the sound card market they took the Synergy ViperMax cards and
simply placed stickers over the Synergy logo and card name. Gravis also maxed
out the onboard RAM to 1MB (the ViperMax comes with 512kb by default). It is
exactly the same board, which leads me to believe Gravis may have purchased
remaining stock of the Synergy cards and unloaded them. The UltraSound Extreme
may be even more rare than the ViperMax. It’s hard to say as I have personally
never seen either of these cards for sale on ebay.
Keeping the GUS roots, the card is almost completely plug and play. The only
thing you must change is a jumper for CD-ROM Enable/Disable. Like the GUS MAX
there is CD-ROM interface support. Contrary to rumours, this card is NOT GUS
MAX compatible! It does not contain the Crystal CS4231 CODEC chip or emulate
it. This means no MAXSBOS and no special demos that will output 48khz (I only
know of one, The Secret Live of Mr. Black by Orange). I feel this
misinformation was started because of the CD-ROM interface that was also unique
to the GUS MAX. To setup your card you just run viprinit in DOS with your
appropriate SET BLASTER and SET ULTRASND variables and it configures the rest.
However, I noticed viprinit will not properly change your base address for the
ESS chipset (i.e. you want to change it from A220 to something else). No fear,
Synergy included the ESSCFG.EXE utility as well allowing you to change the
base address. Initial configuration is set with VSETUP.EXE from DOS.
Windows 95 installation is basically the same as the earlier cards. You
run the setup.exe and it will install the ESS drivers. It tries to setup
some extra stuff for UltraSound as MIDI device. And it does work just fine
but a gotcha is that the DOS stuff will break. I never had a reason to use
GUS’ MIDI capabilities from within Windows so this wasn’t a deal breaker
for me. After a reboot you will likely have to reconfigure your card
manually from the device manager but after that it’s smooth sailing. And yes,
you can install the updated ESS1688 drivers with no ill-effects. However,
if there are any differences in performance I have yet to notice it. Last known
official ESS drivers for Windows 9x at http://dk.toastednet.org/GUS/drivers/WIN95/VMAX-GUS_Extreme/1688_v1087.zip
The ESS chip is really nice, it sounds very similar to the OPL3 and it has
SB PRO compatibility (take THAT SB16!). Whats the difference? The SB16 only
states that it’s Sound Blaster compatible, not Sound Blaster PRO compatible.
This means some earlier titles like Wolfenstein 3D will only output in mono
on the SB16. With the ViperMax, you can hear stereo sounds again.
Wolfenstein 3-D
Someone asked me if SBOS and MegaEm work. SBOS, no. MegaEm, yes but with no SB emulation. You can probably make MegaEm work with the SB emulation if you
want to play around with running ESSCFG, changing your PnP settings, updating
your BLASTER and ULTRASND variables then running viprinit. But, you’ll need
a lot of free resources and quite frankly I fail to see a point. If anyone
out there has pulled it off drop me a comment.
Since the card has a GF1 IC there is no comparision between the earlier GUS
cards. They will all sound the same. The signal-to-noise ratio is acceptable
though I haven’t measured what it truly is, but for gaming and watching some
demos it’s capable.
All in all, this is a great card. If it was released earlier and through
Advanced Gravis they could have still been in the market. Another nice
side effect of this card is that Windows XP has ESS1688 drivers. Just install
the cards as a non-pnp legacy device, configure manually and enjoy sound!
I made a few more rips comparing the differences between the ESS mode and GUS.
The few module files are played with XTC-Play and two of them (ATBIA3 and
Parallel Universe) are XM modules over 1MB. XTC-Play has a way of quadrupling
the RAM usage by downsampling. However, the modules still sound quite good
and it’s quite a thing to hear the GUS playing large high-quality modules.
VMAX 3D
Before I bring this article to a close, here is some ViperMax/GUS Extreme
Resources:
Enjoy the rips! In a few weeks I’ll have a write up on the Gravis UltraSound
Plug and Play Pro (waiting for my RAM upgrade) and finally some last minute
thoughts and information about a few other OEM cards and the GUS ACE.
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.
Ultrasound Classic
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.
Doom
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.
ViperMAX board
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, …
Well I went hunting through all my junk, and I did manage to find Windows CE Platform Builder 3.0 on CD… all 14 of them! It’s amazing something that generates such small OS images, is so massive!!!!
Anyways, I did a BUNCH of stupid bugfixes on the ATA driver, as Windows CE 3.0 likes to transfer in big blocks resulting in all kinds of buffer overruns, and memory traps. So with that stuff cross compiled from the CE 2.11 Platform builder it’s happily running on CE 2.11 & 3.0
So for the 2 or 3 people interested, you can get my driver here.
I guess I ought to up it to sourceforge, I’ll think about it later.
For anyone that wants to test, here is the genned Windows CE 3.0 image, along with the loader. It works great on Qemu, as long as you setup an ISA NE2000 on 0x320 and IRQ 10.
I feel a lot better about this version of the driver, as I’ve been able to download stuff from the internet (CE 3.0 includes IE!) and boot back to MS-DOS, and unzip and run stuff… So that’s a MAJOR plus!!!!
So I was thinking about the idea of an embedded version of SIMH to run on small machines (old cellphones) and maybe a PC or something, else weird… Sure Linux & BSD would work, and be so easy, but where is the fun in that?
Years ago I’d picked up a copy of the “Windows CE Platform builder 2.11”, but I never really did anything with it. So I thought this would be a great little project for the thing, starting with the CEPC, an x86 version of Windows CE that runs on any normal PC.
After I gave up fighting the installer, I just decided it’d be best to run this on Windows NT 4.0, and the install went smooth, I just selected the x86 platform for now, as I don’t have any physical SH3/MIPS/PowerPC gear I’d want to play with, and at any rate I think adapting Windows CE must be a major chore, as nobody has done it, even to Qemu….
So within a few minutes I was well on my way to building my own MAXALL version of Windows CE 2.11, when I found out that there are a few snags with this old version.
First is that there is no shell. That’s kind of lame. Then there is no built in apps, like Pocket Internet explorer, hell even NOTEPAD. That’s pretty lame as well. Finally the only included NDIS driver I can quickly run is the NE2000, under Qemu (I assume I haven’t even tackled the networking yet), and on Qemu I’m stuck at 320×200…..
Then the final straw was that the “ROM” can’t access IDE hard disks.
Yes, that’s right, Windows CE cannot access IDE disks.
So something like SIMH with data files of several hundred megabytes would be out.
The paper is titled “Designing a Hard Disk Driver for Windows CE 2.12”, by Stephen Hague & Chris Wood which certainly is a step in the right direction! The best part, is that the archive also snagged the source code!!!!
So I followed the instructions as best as I could, compiled the driver & the loader, inserted them into the ROM, built the CEPC, and booted up and… nothing happened!
What I also didn’t get is that the dll was only 4kb. And that’s pretty damned small for some 90kb of C code.. Something was wrong. After some poking around, I then remembered the great “dumpbin” utility. And it confirmed what I had suspected, there was no exported symbols.
I couldn’t figure out how to feed a ‘.def’ file into the Platform Builder system, so I kind of was at an impas. Then I remembered a while ago I had posted about creating DLL’s and how Visual C++ could call GCC’s dlls and vice versa (C only, I never said C++!!!) so looking back, I then went to the needed procedures, and set them up as “__declspec(dllexport)”. Now when I re-compiled my dll was larger, and dumpbin verified that there were exports.
So with that I was all happy, and rebuilt everything then found the next few limitations… The driver doesn’t use the disks geometry, it just makes it up. The driver only uses 5MB. The driver also doesn’t flag the disk as MBR so it’ll WIPE YOUR DISK. And the real deal breaker is that the FATFS driver will pass 4kb chunks to be written out to disk in a sequential manner, but the driver only writes the first 512b.
So a few hours later, and LOTS of printf’s and googling around I’ve improved the driver to go around all of these issues. I still think there is some things to go around, but so far it’s looking good. The only ‘issue’ I don’t understand is that files seem to copy from the ROM to the disk fine, my text files look just fine, but copying an EXE from ROM to the disk, then into the ramdisk produces an exe that won’t run. however the same exe once on the hard disk, I’ve been able to diff the two, and they are ok….
I don’t know how much of that is a show stopper, and how much is it me not knowing CE all that well.
So with all that fun, I partitioned a 500MB disk on Qemu with MS-DOS 5.0, and copied in a file…
Then I booted up CE:
And my file is there, and even copying things around, booting back to MS-DOS didn’t result in a corrupted disk…
So now I’m back to trying to port SIMH to Windows.. which is difficult as CE has no real console that I can figure out how to program, so I’m hacking up “tty.c” an example dumbterm, with really mixed results so far… It’ll really be interesting if it works.
For anyone that cares, my ata driver for CE 2.11 is here.
I have no idea if it’ll work on CE 3.0, 4.0, 5.0 or 6.0 … Maybe the newer ones include ATAPI/ATA (IDE) drivers? Hell they could support NTFS for all I know, but again I’m working with what I have on hand…. Also the ‘maxall’ rom for 2.11 is 4Mb. !!
So I got a new Acer 5800 pc… CHEAP.. A quad core cpu, 4 gigs of ram and 600+ GB of diskspace for slightly over $500 CDN. Talk about POWER on the cheap!
So I wanted to load up the new Microsoft Hyper-V stuff, and check out the new “core” windows.
First this core thing is weird… And not very intuitive. I hope you are good with netsh!
Also, loading device drivers was a MAJOR pain. Let me say loading the marvel lan drivers was really strange until I came acrosss something about pnputil.
It would have been nice to have some kind of pop up help guild along with the CLI window so that us n00bs could have at least a guide as to what the hell is going on in server core.
Anyways for me the fun was:
pnputil -i -a yk60x64.inf
Then it worked like a champ. I know as time goes on, people will need this little tidbit on how to load device drivers on Windows 2008 core server. So I thought I’d put it out there.
Needless to say, i’m on the road, so I don’t have access to my Netware 3.12 CD, nor my Qemu VM so I can’t get into some kind of networking with Qemu thing like I want to. But I’ll do so soon. Honestly!
From what I hear about this Hyper-V is that it’s faster, and more feature filled then the prior versions of Virtual Server… I’ll have to see as now I’m loading the network drivers….
Oh, and another thing, is that all the services are IPv6 native, and Windows 2008 server, like Vista defaults to IPv6 then fails to IPv4. It seems like a good time for some 6to4 guides, or new DSL/WAP’ that do the 6to4 dance.
