So I saw this controller for sale for 20. I figured that there ought to be a way to hack it to do something useful so it may be fun. Turns out all it needs is a re-flash of new firmware and it’ll become a generic controller.
You might be slightly scared that the browser can talk directly to bluetooth devices, including the unlock, and re-programming the controller.
And yeah after that it’s all unlocked and good to go!
Not sure if it matters all that much, but for anyone wanting either a controller on the cheap, or if you bought into Stadia when it was a thing (did anyone remember other than the announcement and the expected cancellation?).
I guess it’s nice that google is providing an unlock service but I’m sure that won’t be around forever, so yeah. yay.
One thing that’s been bugging me for years at this point is the ability to run Touhou 6 on my PC-9821 V166. For a good few years I’ve been stuck with nothing more than a Matrox Mystique graphics card in that thing, which can’t create a D3D6 HAL context for rendering the game’s 3D elements. In 2021 I snatched a 12MB 3dfx Voodoo 2, in hopes of being able to play more 3D games on that machine. There were two major problems….
1) The USBHID.SYS driver for PC-98 Windows 9x conflicts haaaard with Voodoo drivers. Moving the cursor around corrupts memory and makes the system unstable or kills the driver in mere seconds of use
2) None of the Touhou games support secondary Direct3D devices
For those not in the know in regards to the second issue, DirectX allows you to use multiple DDraw and D3D capable GPUs on one system. By default it’ll set the video card outputting a signal on the primary monitor as the primary DirectX device, the secondary output as secondary, and so on. Most people only used one monitor on their Win9x PC back in the day, hooked up to their 2D capable card. The Voodoo 1 and 2 aren’t meant to act as 2D video cards, yet they had to support D3D initialization somehow, so they presented themselves as non-primary DirectX devices, usually secondary, in hopes that game developers would allow the end user to select their 3D accelerator of choice.
This was standard practice at the tail end of the 1990s, but it was falling out of use at the turn of the millenium with the demise of 3dfx and the general lack of need for multiple graphics cards in one system for 3D gaming. This presented a problem, as games that technically could be played on a Voodoo 2… didn’t, as they could never be told to use it through normal means. Hacky solutions existed, like 3dfx’s unfinished, buggy attempt at a Voodoo 2 driver for Windows 2000 that allowed it to behave like a primary display adapter for general 2D and 3D use, but it’s notoriously unstable and isn’t possible to use on 9x. I’ve used this method before to play Touhou 6, Max Payne 1, GZDoom, GTA 3 and Vice City on the Voodoo 2 through Windows XP with mixed results.
Once I got an NEC bus mouse for use on my PC-98, I could finally use the Voodoo 2 on it without constant crashing. This got me interested in trying to get Touhou 6 to work on it, which lead me to a path of pure pain.
For starters, Touhou 6 is one of those games that only use primary DirectX devices, like the unsupported Mystique, so I had to somehow coax it into initializing the secondary device instead. My first approach to handling this was through direct binary patching. I didn’t know where to look for the init routines, so I asked 32th System for some heads up, and he pointed me to a rough location in process memory where the appropriate CreateDevice calls reside:
I then searched for the appropriate opcodes in the game binary, and patched all 6A 00 (push 0, A.K.A D3DADAPTER_DEFAULT) opcodes to be 6A 01 (push 1), forcing the game to init the secondary D3D device.
While this initially did in fact work, the approach ultimately sucked for two reasons.
1) Static binary patching only works for that specific binary, and doesn’t carry across different versions.
2) This requires manually patching every CreateDevice call, of which there are many in Touhou 6
It is at this point that I started sharing my progress with friends. jbit was quick to hop in and say “Why the fuck are you doing it this way? Just make a d3d8.dll wrapper DLL”. This was absolutely the smarter approach, I just didn’t know how to do it since I don’t know jack about DirectX programming. Fortunately, he handed me a little VS project he worked on called d3dcutter that, among other things, wrapped the CreateDevice function, which I promptly modified to always push 1 instead of 0 to the stack for the device selection parameter.
This solved the two patching problems, and I had something to show for starters:
Now, I’m sure you can tell that the performance is absolutely atrocious. This came as no surprise to me, as while the Voodoo can absolutely render the game at a full 60FPS most of the time, the dinky little Pentium MMX 166 struggles hard at doing triangle setup for the backgrounds every 16 milliseconds. Remember, 3dfx cards had no Hardware T&L, so the game has to fall back to Software T&L. I think the following wireframe screenshot will help illustrate the amount of work the CPU has to do every frame:
“Well, I’m in luck!”, one might think as they remember that older Touhou games support framerate division by 1/2 (30FPS) and 1/3 (20FPS) as options in custom.exe… There’s just one problem.
The game just… fails to initialize the D3D HAL on the Voodoo 2 in the frame divided modes. Why? Beats me, I still haven’t figured it out and likely never will. Just more ZUNcode bullshit I suppose.
I then figured out that framerate division is handled by a variable (that can be set even lower than 1/3, by the way) which could be set at runtime, even when the normal 60FPS mode is used. I suspected that the game uses a different initialization path for the two modes, so I once again tracked down opcodes that expect the variable to be set to 0 in process memory, this time with Cheat Engine, and patched them in the binary. Well guess fucking what, the game fails to initialize even when the regular init routines are modified to expect 30FPS or 20FPS frame division to be set.
This approach simply wasn’t going to work. so I went with trying to set the variable at runtime. Unfortunately, I had to go back to version specific patching once more for this, since there’s no way to wrap this functionality through DLL means. Additionally, while this wasn’t hard to do with the game running in windowed mode with Cheat Engine on the side on a modern system, it was basically impossible on a Voodoo 2 equipped machine, as the game ran in fullscreen and it wasn’t possible to restore the window after an Alt+Tab.
My final solution was to generate a trainer in Cheat Engine for version 1.02d of the game, as it’s the last one with a working logic speed limiter, that would forcibly set the frame divider variable at runtime with a hotkey:
This finally allowed me to play the game in 1/3 framerate mode on the Voodoo 2. This allows the game to run at full logic speed most of the time, as the CPU now has 40 miliseconds per frame for triangle setup, however there’s something wrong with how the card handles buffer swaps in this mode of operation, leading to a very back-and-forth stuttery image that’s very unpleasant to look at.
Can we do better? Well yes! The game uses so-called STD scripts for certain stage-specific data setup, but also handling camera movement and geometry generation. Using Touhou Toolkit, I was able to unpack the appropriate DAT file, decompile all the STD scripts, remove all geometry commands, and recompile them for in-game use. As there are no more backgrounds to draw, there’s a trail effect left behind every frame, but thankfully custom.exe has an option to forcibly clear the back buffer every frame.
The end result? A nearly tripled framerate in 60FPS mode, recovered just by not drawing any 3D backgrounds. The game still lags when lots of bullets are on screen, but this doesn’t really come as a surprise.
(this is a guest post by Antoni Sawicki aka Tenox)
As I was preparing the Windows NT RISC exhibit for VCF west, I realized that I’m missing a rather important piece of the history. While I will be showing the potentially last DEC Alpha Windows build ever – AXP64 2210, I don’t have anything earlier than NT 3.51. It would be nice to showcase the very first RTM version – NT 3.1. From time perspective, NT did not get popular until the version 3.5 and later. Windows NT 3.1 would be considered rare even on a 386, let alone on a RISC CPU! So what RISC hardware does Windows NT 3.1 run on?
Not many! The HCL published on gunkies has a few more systems, but nothing that I have. The early MIPS based systems are all but unobtanium as of today. This is probably a good time to mention a little known port of Windows NT 3.1 to the DECstation 5000. However these builds are not found even on earliest NT betas. Not to mention lack of ARC firmware for this machine.
The Alphas were looking a little more reachable. The DEC 2000 Model 300 and DECpc AXP 150 are one and the same machine, packaged in a server and workstation cases. Code-named Jensen, DEC designed and marketed these specifically around Windows NT. Unlike prior Alphas, this model used a lot of “PC” components for increased compatibility and lower cost. Eventually paved way for the more well known DEC Multia. The Jensen has been seen floating here and there and many people have these.
I was able to get a loaner from Chris Satterfield aka Compgeke for the VCF. Having a working specimen at hand, I started looking at part numbers of various components. In an amazing streak of luck, in practically zero time I was able to find, buy and assemble a complete DECpc AXP 150 from spare parts on eBay! Without a case, but nevertheless. Also big thanks to Christopher Rivett for help with some fine details!
PSU – DEC/HP 30-37197-02, however a standard AT PSU may be OK
If you going to build one yourself, beware of overheating. Jensen runs rather hot and needs good cooling. Not only for the CPU. There is a section of the motherboard just under the EISA cards that runs incredibly hot. See the picture, where I have installed a large Noctua fan.
OS Install
There are many Windows NT 3.1 CDROMs floating around. I purchased a DEC branded, shrink-wrapped CD on eBay to use as a prop along with the machine. You can download the iso image here.
Installation of Windows NT 3.1 on DECpc AXP 150 is pretty straightforward and not that much different from the later versions. However as a prerequisite you will need the ECU floppy disk to configure the EISA slot assignments, card and jumper settings. After that you will have to go through various setup screens in ARC BIOS to configure system settings. Then you run arcinst to create a system partition and setupldr to install the OS. The rest of it is pretty uneventful. This is somewhat expected, as this was pretty much the only one and supported hardware combination, so must have been well tested. The only curious part is that the NT OS Kernel does not display any text during normal boot. Later versions of NT will display the build number and MP or UP kernel variant and dots indicating subsystem load progress. This is rather odd because I expected more text mode stuff from older NT version, but who knows.
Jensen NT 3.1 Boot MenuWindows NT 3.1 on DEC Alpha AXP, DECpc 150 aka Jensen
Service Pack Saga
If you are even vaguely familiar with installing Windows NT at all, you will know that the very first thing you have to perform after installation, is to apply a service pack. NT 3.1 did have service packs, up to SP3. The problem is that, as you may very well expect, non-x86 editions were nowhere to be found in 2023. The only thing I could come up with was http://www.win31.de/ent31.htm, which had a German AXP and MIPS SP3, but no English! [It since has been updated…]. I had to do some real detective work to track down an US-English AXP SP3 version. I spent a few days going through various random CDs and ftp site mirrors of that era, with little luck. Eventually I stumbled on this README file, stating:
Due to space constraints on the Windows NT Service Packs for
International Versions CD, the USA Service Pack version 3 is located on
the Additional Windows NT Service Packs, Windows 3.11 versions, SDKs,
and DDKs CD in the NTSRVPC3\USA directory.
My general impression of NT 3.1 on DEC Alpha is pretty awesome. If you can overlook the age and some obvious shortcomings, the OS is pretty stable, solid and even snappy for such old hardware. An OS itself without apps is not much. While overall Alpha NT application outlook is pretty scanty I was able to find a several very interesting gems!
DMC Calamus desktop publishing on Windows NT 3.1 DEC Alpha AXP
Also a demo version of a vintage, text-mode SlickEdit, way before it was replaced by the Visual SlickEdit known today.
SlickEdit 2.3 on Windows NT 3.1 DEC Alpha AXP
There also is WinDev editior, which is quite superior to Notepad and has some code editing goodies and shortcuts to SDK tools, making it something of a simple IDE.
One of the coolest thing found there is a graphical text editor called WinEdit. It has a ton of features and even syntax highlighting! It has since became my default to go editor / IDE on this system!
WinEdit 3.0E on Windows NT 3.1 DEC Alpha AXP
There of course is a Windows NT SDK with the M (MEP) editor.
Windows NT 3.1 SDK with M / MEP Editor on DEC Alpha AXP
There also are quite few public domain apps and games, ports of GNU software, Micro Emacs, Kermit, etc.
Update: CICA NT Shareware Collection has some interesting apps under the /alpha directory.
High Resolution GPU
One of things that was troubling me for some time was rather low resolution of the default QVision graphics card. The maximum being only 1024×768 is just not acceptable. Talking to several Jensen’s owners, no one even heard about anything better. However looking at the Windows setup options, I curiously noticed that the system does support one 1280×1024 video card – Number 9 GXE.
I simply assumed that such card would simply be unobtanium in 2023. However, digging through some old catalogs and spare part listings, I managed to find a DEC part number, which is 30-41800-01. Armed with this, I was able to find it via DEC spare part reseller that I often use. They had it in stock listed as “HIGH RES EISA 1280 x 1024 GRAPHICS”. The price wasn’t too bad either, at least compared to the whole endeavor. A few days later I received this:
After installation of the S3 driver (must be the Service Pack 3 version!) I was finally able to get 1280×1024 from the poor thing!
With this I should have a more cozy environment to compile and port even more apps 🙂
In future I want to try the Advanced Server edition as well as some early Betas with Alpha support.
So I had gotten this Boca Ram/2 card with 2MB of RAM, with space for an additional 6MB. Unfortunately trying to find matching memory has been a lost cause. Since the existing memory is 9 chip modules, I take that to mean it’s parity RAM, so I went shopping for much more available 3 chip modules.
2MB!
I picked up 2x 1MB modules for £10.
Slotting them carefully into the ram card, taking great care as the clips are plastic!
4MB of ram slotted, made in the USA!
Now from what I can remember being told is to never ever ever mix memory types like this. But logically I have to think that 9×1 = 4+4+1, right? RIGHT?!
I copied the @7A7A.ADF onto the reference disk image, slotted the card and booted up to the config, and toggled the card to 4M
4M (4 SIMM modules)
I didn’t trust the auto-config, plus I just wanted to see what was there. Also I’ve always wondered if the PS/2 model 60 (or 30? 50z?) can slot higher density than the 256kb SIMM’s that IBM had used. I guess one day I’ll give it a shot.
Anyways thinking that this is about done, I save the config and reboot and now It’s Bocaram/2 issues.
Immediately, on reboot I get error 164.
164 POST detected a base memory or extended memory size mismatch error.
1. Run F1 Setup. Check System Summary menu for memory size change. 2. Run the Extended Memory Diagnostic tests.
Booting from the reference disk just crashes the PC.
Fantastic.
Pressing F1 however does let you boot, ignoring the issue.
After a bunch of digging I found this zip file with some utils. And just guessing br2pmems ‘fixes’ the CMOS settings allowing the machine to boot normally.
So now it’ll recognize the 5MB of RAM, and just boot normally. GREAT. But booting the reference disk still hangs the machine.
Which then brings me to the next upgrade:
The IBM SCSI with Cache
The IBM SCSI with Cache aka the SPOCK. Since I ruined the one SCSI card, and ended up picking up a second card, but this time with the appropriate cable I’ve caused a massive market panic on Microchannel SCSI cards. Seriously check eBay, and you will see that the pricing has collapsed with many now selling in the £20-30 range. You’re welcome!
Not really wanting a 3rd SCSI card, but my eye saw this one with the cache RAM, and I figured if I wanted the ultimate PS/2 of course I’d want a caching controller. This looks to be the first rev of the PCB, but with the ‘hot fixes’ in place from the second rev. While the ROMs are stepping back to 1990, I don’t care much about the 1GB disk limit, as the BlueSCSI can emulate all the available devices in the chain, so I’m not losing anything in the way of capacity. This is a 286 after all.
Since the RAM card screws up the setup program, I have to remove it, and the old SCSI controller, re-configure the system with all the RAM and disks removed first. Then put in the new controller, and re-run setup.
I just accept the defaults, and reboot to check what happened. So far it looks good, slot 8 being near the middle of the PCB, and closer to the disk cage where the blue SCSI rests.
placehold all the drives!
Remembering that the IBM controllers inventory the disks backwards, the 380MB disk image on SCSI ID 6, is the primary boot disk. I didn’t set it to the full 1GB as I want to later see how older versions of DOS/OS2 work with this, and I know they have issues with disks bigger than 512MB, but I figured matching a disk that did exist in 1988 would be more realistic.
With the SCSI setup, I could put the troublesome Boca board back with the RAM, and get my system booting up with the new “faster” SCSI controller, and all that new RAM.
Old SCSI controller
Of course I did a few benchmarks on the old SCSI controller so I would know how much more awesome the new one is.
As you can see this is booted with my normal config.sys with a himem.sys and smartdrv from Windows 3.1 on a MS-DOS 5.1 install.
2,345.8 KB/sec With himem.sys & smartdrv
2,347.5 KB/sec with no himem.sys
2,316.6 KB/sec with runtime xmsmmgr & smartdrv
2,334.0 KB/sec with Windows 3.1 himem.sys no smartdrv
So, with these scores in hand, you can see that the penalty for various XMS memory access being turned on is there, but it’s nowhere near as massive as I’d have thought for performance. Even with it just being there, although again it’s so minimal.
Now for the real shocker:
2,079.2 KB/Sec
That’s right, the advanced card is slower. A good 11% slower. Well, that was disappointing. I’m still keeping it in the machine, as having a hardware caching controller was all the rage, just like Mach microkernels. Maybe it’d make more of a difference in a 32bit system, but it’s performance is very underwhelming. For anyone wondering, the WDC AC2340, is an EIDE 340MB hard disk, with a 64kb cache. Im sure it was considered very fancy, and fast for the era, and it’s nice to know that no matter the SCSI controller, the BlueSCSI blows it out of the water. Also keeping in mind that MFM data transfers are usually sub 400KB/sec, so this is much more faster.
Okay you have all this XMS what are you going to do with it?
Well, after I did manage to get this original copy of Word for Windows 1.0, I thought that it would be a good test. One fun thing is that it includes the ‘runtime’ version of Windows 2.11, which can also upgrade an existing install of Windows 2 if detected. Running Windows 2 on MS-DOS 5, does involve loading the setver command in the config.sys, and rebooting. Windows 2 cannot use XMS (more on that) but instead uses the older LIM EMS standard that allows a 64kb page to be viewed from a far larger card. Since the 8086/80286 still use 64kb segments it’s not all that crazy to use.
And that brings me to this great program EMM286!
It allocates a 64kb page in low ROM, and backfills it from XMS. So I give it 3MB, and now I have 1.3MB of XMS left, and 3MB of LIM EMS ready for Windows!
So now I have EMS & XMS! And didn’t have to get some pesky EMS board either. I am pretty sure you need device drivers to use EMS, so how do you use LIM EMS under OS/2 1.x? I have no idea. Probably not I guess?
Anyways I run word, everything is great, it sees extra ram. I exit windows, and unload EMM286, and ..
3.4MB of XMS available? Somehow I lost a megabyte of RAM from Windows 2?! I’m not sure what is going on, or why or how Windows even touched it. Needless to say if you want it back, you need to reboot.
DOS 10.21494KB free!
That’s right 494KB free! I thought MS-DOS under OS/2 just used some stubs in real mode, and called back to protected mode. No doubt this is totally wrong, there has to be some weird version of DOS+OS2 that actually runs in real mode going on here. I know that ‘bimodal drivers’ were a thing, but it sure seems like there really is a ‘real mode OS/2’ kernel with MS-DOS tacked onto the side.
Windows 3.0 standard mode, 286 + 5MB of RAM
It’s annoying OS/2 can’t tell you how much ram it sees and what is in use, but at least Windows 3.0 can. It’s more than enough to run Sim City, clearly making this one of the more expensive machines to run the game as intended. With the added RAM it doesn’t thrash as hard, but having emulated disks probably doesn’t matter as much as access time is always zero, and it’ll stream data as fast as it can. You can feel the difference moving between tasks, but things like the OS/2 file manager that loads a view into every directory is still incredibly slow. What were they thinking?!
Thouhts?
Back in the day this would have been an incredibly expensive upgrade. And is it worth it? The machine is still locked at 10Mhz. The FPU is also locked at 10Mhz, and you can feel it. The lightening fast disk access, despite it being some 11% slower is really hard to tell. Does the caching help at all? Applications don’t have to page in/out like crazy before as there is enough RAM to actually run them, but that is where the 10Mhz processor just isn’t there.
Just like the caching SCSI controller, I’m sure we’ve all heard how having that magical EMS memory would help out games like Wing Commander.
XMS/DOS High + EMM286 on the left, and just XMS + DOS High on the right
Well, I had to put them side by side, as I couldn’t believe it, but adding EMS made it noticeably slower. I was *NOT* expecting that. I should add that I used Vegas & this quick tutorial, on how to pan & resize one video to get them side by side. No doubt it’s not perfect but it’s enough to see that once the ship explodes, the performance on the EMS configuration is greatly throttled. It’s moments like this that makes me wonder is this something the caching SCSI card would do better implicitly? Or is it snake oil as well?
3MB is enough to load OS/2, and one application, just as Word v1 or Excel v2/v3 load just fine, but swapping between them is basically unloading one from memory, and loading the other back out to disk. It’s a shame RAM cost so much 1987-1992 as people really could have benefited from it. It’s just utterly bizarre that on such an outrageously expensive system that you even need RAM upgrade cards, it really should have been baked into the main logic board.
I’ve been wanting a cheap Big Endian RISC machine, and of course I want to do it on the cheap! From a few tips it seems its possible to re-activate the ‘otheros’ feature of the PS3, and get the newer ones running Linux!
There is a LOT of warnings about breaking your system, bricking things, so of course I’m not going to buy something nice, and I found this beauty on eBay
Sure it’s beat up, but look at the price!
What a beauty! Only £23 with shipping! The way inflation is going its like McDonalds money.
Anyways a mere 3 days later, and it showed up!
yeah…
The cover promptly fell off, and I was a bit worried. I hooked up the power, and the red light came but but it didn’t turn on. The power switches are these weird sensors, and it looked like the power one was pushed in. I guess its more of an antenna rather than closing a circuit, so I genitally bent it apart, and it sprang to life. There was no video, but it did chirp pretty loudly so I assumed it was working. I figured there was no disk, so I found the process to reset the video (turn on, holding power and it’ll power off. Power on again, and wait for it to do 2 chirps while holding power down, then let go, and it’ll hopefully lower all video to minimal levels on both composite and HDMI. And yeah, it sprang to life!
The PS3 had version 4.50 loaded, and the first step to bringing back otheros was to update to 4.90. The last version that had otheros was 3.16, so sadly it’s long gone.
Updating was pretty uneventval.
But now starts the real fun.
It’s scratched pretty bad, but you can make out it’s a CECHK03.
, meaning it’s NOR type flash. This matters as the launch devices used NAND, and a heck of a lot more too! And of course totally incompatible. So yeah be careful!
So the first thing to do is to patch the flash. And shockingly this is VERY very easy… It’s so scary it’s easy! Just open the browser after you’ve flashed to 4.90 and go to
Yep it’s a web browser exploit that should terrify you.
Using FLASH buffer overflows we’re going to reprogram the FLASH. WOW could you imagine a world where iPhones ran Adobe Flash?
From the web page, it’s a snap to backup the flash to USB, and then you can download and merge the flash patch right from the UI
With the image loaded and merged, we can now re-flash the PS3.
It’s really this easy.
wow.
Now you need to power it off.
Next up is to install the Evilnat CEX 4.90 hacked firmware. It’s pretty simple, much like the production image, it installs from the XMB after copying the file to USB in the appropriate directories. I downloaded “CFW 4.90 Evilnat Cobra 8.4 [CEX].rar“.
And now you are a reboot away into modified OS
There was a bunch of users, and installed games, I removed the users, deleted the games, and formatted the disk. I’m not going to be playing games anyways.
Now it was a bit more things to do.
Partition the flash, and re-program it again with the otheros support. And then now finally you can boot to the BusyBox ramdisk.
I’ll have to touch on this part a bit more, it’s involved, and again you can brick your PS3. If you worry about it, now is the time to do it, as many are being sold effectively as garbage.
Finally running Linux on the PS3!
For the heck of it, I exploded out an old Red Ribbon ISO, and was able to ‘live image’ boot it from USB.
So this gets me part of the way here.
The next thing to figure out is if I can downgrade the OS to something where I can partition part of the hard drive for Linux. And how to get that installed.
2×3.2Ghz PowerPC with altivec
So I’m going to have to leave it here, at least for my usage case I may have to just be happy using the slow USB for the root filesystem. I’m pretty sure when it comes to partitioning the disk you need the lower OS version to do so. Obviously for me I can leave it there if it runs, as I don’t care about playing games on this one anyways.
Which I’m sure won’t be as bad once I turn off X11 and everything ‘nice’ for a user.
Also you probably want to get a PS3 controller, as at any point you need to do a recovery you need to be able to hit the ps3 button. And that’s where I am currently stuck, but not bricked.
As a follow up to Installing a Gotek floppy emulator, this time I’m adding something desperately needed, mass storage using a SCSI card.
IBM SCSI / A adapter
The machine is the 40Mb MFM based model, the cheapest option of getting a PS/2 model 60 back in the day. MFM hard disks are incredibly old, and sadly the eventual end point for these old disks is death. While I had investigated a MFM disk emulator they are very costly, with prices starting at $299 USD. Ouch. However, from my Dec Alpha experiments I do have the BlueSCSI was available for a more reasonable £52. So all I would need was a SCSI adapter, and I’d be good to go, right? Mostly.
Looking at the card, you can see that it doesn’t use a standard 50 pin connector. I guess it being the 1980s and IBM trying to re-capture the PC market by going all in with proprietary connectors, they used a 50 pin IDC connector to attach the 50pin SCSI ribbon cable. This would prove to be disastrous for me later on. I initially had no luck finding an original cable, while the SCSI cards themselves seem to be plentiful on eBay. I guess me buying 2 of them has triggered a lot of movement in the market. Another source of concern is that the 286 is 16bit, and the card is advertised as being 32bit, but rest assured the notched middle part seems to indicate that the card is 32bit/16bit compatible. I can attest it works in my PS/2 just fine.
My terrible idea + terrible soldering
I had decided that since I do have a bunch of jumper cables, I could just solder them directly to the card fingers. I only have one device, so I don’t really need a ribbon cable, the BlueSCSI can emulate multiple devices, so I figured it’d be fine. Of the 50 pins in a SCSI ribbon more than half are ground, so I figured I only needed to solder up about 25 connections, just like how Apple got away with 25 pin connections. I did tone out the pins looking for the +5v power signal, along with checking the common ground, where the flip side of the SCSI card is all ground.
I had connected it up, and the machine saw the blue SCSI, but for some reason it was always reading 25Mb.
I was unable to figure out what was going on, so when I went to inspect my setup, I had seen one of the cables had disconnected. Uh-Oh.
Card edge fingers torn off
As I pulled the card out of the computer, 3 more cables had popped off, revealing that the fingers were nowhere near as strong as I had thought, and the fingers had been torn off the card. Very sad. The card still ‘works’ but it’d need someone with a good eye and soldering skills to re-attach the pads, or just solder bodge wires from the test points on the card to the IDC connector.
Obviously if I’d known the fingers were so fragile, I’d have not done this. But I was impatient for the IDC connector to arrive (it took about a month), and I really thought I could get away with it. So I don’t know if it matters for anyone else, but yeah it turns out these fingers are nowhere near as strong to side to side forcers as I had thought. Also I was told “on the internet, so you know it’s true”‘ that various super glues are conductive, so test before you think about trying to do it live.
IBM SCSI Adapter FRU 15F6561 IBM MICROCHANNEL SCSI 32 bit MCA Card + Cable
And that is when this pair showed up, another SCSI card, but this time with the illusive cable. There is something weird how the universe times things.
So got this card & cable set (If it was available 3 weeks ago, obviously I would have ordered this one as it has the ribbon!).
Where the magic happens, BlueSCSI!
Not knowing much about the IBM PS/2 SCSI/A adapter, I went ahead in BlueSCSI, and setup a 380MB disk on SCSI ID 0, a 1GB disk on ID1, and a 2GB disk on ID2. That’s when I found out that the adapter initialises the bus backwards.
I had thought it was a weird thing in the setup utility, so I booted up MS-DOS and ran FDISK to reveal that it really does read the ID’s backwards.
Obviously with the BlueSCSI they are just files on a SD card, so it’s trivial to just rename them.
I had also thought it was weird that the reference disk reads the disks being 2GB just fine, so I double up with both data disks being 2GB.
And sure enough, MS-DOS only sees 1GB per bigger disk. After search for a bit, it turns out that the 1GB limitation is a known thing and newer ROMs can work around the issue. Eagle eye’d might have noticed the first adapter had ROMs from 1990, while the second card has ROMs from 1991. But the better ROMs come from a totally different card. Normally I might have been annoyed, but since my disks are virtual I can just give myself 5x1GB data disks, along with that 360MB OS disk.
ALL THE DISKS!
This is the best part of virtual peripherals, is that you can load out what would have been super expensive, and impractical for being era correct. Instead, now it’s super easy, barely an inconvenience. I can’t imagine trying to use physical disks in 2023.
One of the reasons I kept the smaller ‘C’ drive was to make for installing OSs a bit easier, as many older things hate ‘large’ disks. But being able to connect so many gives so much flexibility.
It’s a shame the MFM hard disk emulators are a bit expensive, even with my screwup it was still cheaper to go with SCSI, and the BlueSCSI basically just works, the only weird behaviour is all on the ‘tribble’ SCSI / A adapter.
Well like everything else, once you know what to do, its pretty self explanatory and easy. But until that point it’s a lot of trail and error.
The PS/2 model of computers went away from the PC/XT/AT design for something that would be more toolless and allow for more automation in the building & assembling of these machines. That means they removed loose wiring where possible to give not only great airflow, but an overall clean aesthetic to the PS/2 build. What this also means is that the old 34pin floppy ribbon will not do.
The PS/2 version uses and edge connection and integrates the 5v/12v power rails into the interface. You can try to add an old floppy to the mix, but there is 5 pins that need to be held high through a resistor pack to get an old floppy drive working. I didn’t want to fight it that much so instead I ordered an adapter from eBay, being sold by markgm.
Yes I don’t know what is up with the shipping either.
After much trial and error I found
After a lot of trial and error I found jumpering it for S0 was what worked. While I had read that JC was also needed, it just didn’t work when I tried. S0 puts the gotek into the first floppy position, in the older PC/XT/AT’s they jumper every drive as S1, but have a twist in the cable to negate it on the primary position.
The other catch is that it absolutely required a FF.cfg file
interface = ibmpc-hdout
host=pc-dos
Even though so many other systems didn’t need it, mine sure did. And Obviously I flashed my drive to the latest version of flashfloppy (3.41 as of now.). That also meant checking the processor type, which, is simple enough to check by opening it up, and setting your camera to maximum zoom.
Gotek AT32F415 processor
Or checking the gallery of microcontrollers in the various Gotek’s. The prices have shot up dramatically over the last few years for unknown reasons, so they switched to from the ST to the AT line or similar processors.
Can’t say I blame them.
So with the drive updated, and config file loaded, along with a disk image, it finally booted up!
First boot!
And with that in place I was able to boot the reference disk, and setup the system. The inside is a bit ugly but, I wanted to get this thing fully loaded, so I picked up an 80287-10.
One interesting thing about the PS/2 line of machines is that the 286’s could run their math coprocessors in synch. The IBM-5170/AT ran it asynchronously at 2/3rds the clock value. I would have imagined they convinced someone somewhere how at big step up from a 6Mhz 80286 & 4mhz 80287 to get into a PS/2 model 50/60 with a blistering 10Mhz 80286/287.
Happily the 80287-10 I had gotten from fractal2015, worked just fine.
Wow. awesome.
I’m waiting still for some cables to hook up the bluepill to the SCSI card, and the memory card, so I can run meaningful applications like SimCity for Windows, and OS/2.
PS/2 60 playing battletech, from a gotek emulated floppy
In the meantime I can do simple stuff from floppy. I’m still trying to keep an eye out for either an ethernet card, or a Token Ring card & MAU, along with cisco cards to at least let me use NetBEUI.
But for anyone else needing a solid answer on how to get the Gotek working with an IBM PS/2 model 60, here you go!
And there is a map of all the locales and when the launch. I was busy working and didn’t notice that Hong Kong had already launched.
many geo zones!
Thankfully I did get a payment voucher which fully covered the super fancy edition. Sadly there was no option for GPU’s so I’m going to try this with an OG 6GB GTX Titan.
It was a bit weird to figure out if I could run the game or not but I did get a pop up that today was the day so I guess so.
0% verified
I’ll have no choice but to update as it goes, so nothing yet to report.
I’m just hoping it’s not the hollow world experience of Fallout 76.
After all that downloading, turns out it doesn’t like my video card at all.
So yeah GTX 1070ti minimum. wow.
So I abused a work machine that ironically has a decent mobile GPU. swapped some storage and booted into the game, played a few hours.. And yeah
Old tyme Bethesda quality
When |I could, I took a detour to Earth’s moon, and went out for a walk. Naturally there was a base less then half a click away, and naturally it had 30 insurgents automatically hostile. What a vast but populated world. And then the NPC following me around suddenly took off her space suit, and broke the whole thing. I wanted to maybe get an ARC but apparente it doesn’t run at all on ARC. Seems kinda fishy to me tho. NVIDIA released a new driver like today for the special launch. I don’t know if there will be any fallout.
So, I rebooted my Windows laptop after some update, and was greeted by this surprise!
well that was a surprise
I guess lucky for me I had the machine tied to a Microsoft account which in turn had the key backed up. After some tedious typing later and I was back in business.
I guess this was the culprit?
BitLocker was so transparently well working I didn’t even know it was even running. Got to give it that much credit. And if anything, probably should just give up and run it everywhere.