Ha! Nice! So, not surprising that the game runs that badly on the SX CPU. However, I am still shocked how important the FPU is and what difference it makes! Of course, raising exceptions and handling them is such an additional strain to performance.

@@bitsundbolts Exception handling alone is bound to add around 100 cycles worth of overhead to every FPU instruction. 486 is pipelined so it approaches one simple integer instruction per cycle.

Isn't that because the voodoo cannot do geometry and the cpu has to take care of this? You pretty much need an fpu for that, and preferably a decent one.

I personally would like to hear that. As a person who grew up with these games and making games now these are of utmost pleasurable readings for me.

Cyrix FPU for the 486sx??

Very true! I remember being scared of melting my CPU back in the day... A 486 DX4-100 overclocked to 120 MHz. I reverted the overclock after a few days because it made me feel uncomfortable.

My coed proposed me to OC my P100 in 1996, I refused with same fears. But after a year other guys convinced me to do that, saying that it will just turn erronious and will revert everything back. So I set 133MHz and it was fine, I used it boosted for 3 more years.

I've always wondered how much difference that makes.

It probably doesn't make much difference but when i was a young lad, it always made sense to me to disable what i'm not using or will use. Back in the day of 25mHz-100mHz, a single rogue CPU poll could be all it takes to slow things down or cause an interrupt failure. Old Linux and FreeBSD manuals specify to disable Serial and Par. ports in BIOS if you're not using them so i've just always made it a habit. Weird thing is my current AM4 mobo has the same BIOS settings for serial and par. ports but i have no physical ports so I disable them too, out of habit. @@SeeJayPlayGames

Ah, Sony guys taking shortcuts ;) I never had a PlayStation; however, I do remember the endless debates between PC and PlayStation owners which platform is better 😒

Fixpoint was basically how these things were done back in the day lacking a suitable FPU. Saturn has a streaming DSP to accelerate fixpoint transformations, Playstation has a SIMD co-processor.

Geometry is usually calculated and stored as floats on PS1, which then gets converted into integer screen co-ordinates before getting rendered out. It's what allows PGXP to work, a hack that fixes the polygonal and texture distortions by snooping the vertex co-ordinate data from RAM prior to it's transformation.

The main issue with the PS1 wasn't the fixed point calculations though, but the affine texture mapping instead of perspective correct texture mapping, which produced some horrible wobbling textures. Also the lack of depth buffer didn't help much.

@@scheeseman486 Nope it's NOT floats. There are absolutely zero floats supported by PS1 hardware. PGXP works by creating a shadow memory that stores alternative representations of every number touched by the GTE, the Geometry Transformation Engine co-processor of PS1. So when integers come into the GTE, PGXP performs two calculations, one imitating the GTE fixpoint logic directly, and one replicating the same in floating point, and for every GTE store, the shadow calculation performed in float is stored in shadow memory. In the original early PGXP implementation, it just hopes that the GTE store is going directly into the render bucket queue and isn't actually touched by the CPU further, but a more complex evolved implementation keeps propagating the shadow values through the complete CPU implementation, also tracking all load/store instructions and general purpose registers. You need to track CPU stores to invalidate the shadow memory locations overwritten regardless if you do comprehensive propagation. So when it comes to GPU submit, whenever a shadow memory location isn't empty, the floating point value is subsituted instead by PGXP. I suggest you read the classic "Everything You Have Always Wanted to Know about the Playstation But Were Afraid to Ask.", you can refer directly to the GTE chapter for the register layout and the fix point formats supported, there are for example 1 bit sign, 3 bit whole-part, 12-bit fractional format used for rotations etc there's a whole bunch of these dedicated fine tuned formats. Crucially, the PSX GPU only supports integer vertex coordinates, so effectively the GTE math is formulated such, that the output is a screen space integer, and you absolutely have to re-do the math to recover any fractional part. An extra neat trick is that you can add yet another shadow memory of Z values corresponding to given X and Y values, since Z is normally discarded by GTE during perspective divide, allowing to retrofit perspective correction into the GPU emulation. PGXP does this as well. PGXP is such a spectacularly refined software solution of very nontrivial complexity, which is why it took nigh on 20 years for someone to actually tackle it. If all it took was just taking the floats that were already there, we would have seen this all the way back in PSEmu Pro era, as the GPU plugins of the era already supported rendering at arbitrary output resolutions. So the PS1 look is a combination of: - fixed point GTE which is a little jittery at angle and scale related calculations, especially if you have hierarchical matrices such as character animation, which accumulate angular and displacement error along the depth of the hierarchy, so say hands are more jittery than the pelvis. - integer only vertex inputs to the GPU, which are also only X and Y values without Z - affine mapping which renders each triangle as a scaled and sheared 2D surface, introducing a visible perspective midpoint drift and triangle-boundary crease into every oblique-transformed piece of geometry.

You're welcome! Thanks for watching!

Thank you!

GTE matrix is FP16 math.

Haha, yeah... A lot of vintage hardware needs some sort of bending metal back in place! I hope all transistors made it!

@@bitsundbolts Yep, all legs straightened and all transistors tested good.

I sure hope so 😃

Thank you!

Haha, the people who wrote the minimum specs for Tomb Raider would not expect someone to try it on a 386, would they?? 😂 .. 😊.. 🤔

@@bitsundbolts but we are warriors! I wonder how one of the top "386" processors like the DRx2 with a nice Fasmath or ULSI FPU would run compared to that real DX2-66...

​@@ccanavesHonestly I was coming here to request similar! Trying to push a game as far as it can go is cool, but "as far as it can go" goes two directions - people know about fast, obviously, but slow can be amusing, too. I was running the _Quake_ demo in Phil's Computer Labs's benchmark suite through the slowest emulated 386DX in PCem, just to get a theoretical lower-bound for how that would go - best (worst?) I got was 3378.0 seconds to run DEMO1 (which is 969 frames, so that's 0.2868561278863[...] frames per second! Or, about 3.486 seconds per frame, if you prefer). Would be funny if somebody who had access to actual 386DXs and ISA VGA cards (preferably the least-performant ones) could verify just how bad it gets.

@@ccanaves That's the beauty of 386, you can choose different FPUs. 🙂 It's just a matter of time when somebody creates 386 FPU board like PiStorm (board with CPLD and RaspberryPi SBC emulating different CPU for Amiga). It would be cool to have 386 system with powerful AVX512 vectors and AMX matrix multiplication 😀

@@richard.20000 Oh and another thing: I didn't see you mention that the Cyrix 486 CPUs have/support WB cache. Did you make sure it was set that way? You could also run a test with WT vs WB on those CPUs, like with the Intel SX955. I remember chipset plays a role there, as does L2 cache setting. Sometimes it's faster when CPU is set to WB and L2 to WT, instead of both set to WB. Quite counter-intuitive. UMC chipsets are picky.

Wow, I didn't know P90 revisions with the FDIV bug existed.

@@bitsundbolts It was mostly on 60 & 66 MHz models but there were early 75, 90 & 100 MHz chips shipped that also had the bug. My friend bought his PC as soon as the 90 MHz chips became available specifically so he could use it in college. As part of troubleshooting in 1994 before the bug became widely known we temporarily setup MATLAB on my 486 PC and got results (that also took longer to run) that agreed with what he got when he used the machines in the computer lab which I think may have been Sun workstations. I remember there was a fairly simple equation you could enter into Excel that would tell you if you had a bugged chip along with simple dedicated programs people created that basically did the same thing.

Thank you! I do have a 387 from Cyrix for my 386 build, but never really tested it. Unfortunately, I doubt Tomb Raider will work on 386 😂

I have a video on my channel testing Tomb Raider on a Pentium 120/133. I also use a Voodoo accelerator. Most of the time, the game is just stuck at the frame limit of 30 FPS.

The more I look at 3D accelerated Tomb Raider, the more I am impressed with what they were able to do back then. But yeah, Tomb Raider needs to take a break

@@bitsundbolts Here's an idea for a new, but similar series: RollerCoaster Tycoon. It's notoriously well optimised assembly code, runs in 2D and mainly starts getting hard to run with larger parks, so it'd be interesting to see how slow of a CPU you can run it on and how complex the park can get before it starts lagging out on each CPU. Officially it requires a Pentium 90Mhz but I've seen a number of people talking about how it was one of the only new games that was playable on a 486 by the time it came out over the years so it'd be interesting to see just how well different 486s do with it.

Turns out, you can't really run Tomb Raider without FPU ;)

@@bitsundbolts So true I once had the cyrix MII was either the 266 or the 300 variant can't recall which now this was years ago. It could barely run Tomb Raider with a decent fps I think I even tried software mode which just made it look worse. I've still got my original Tomb Raider cd's in big box from back then too sitting gathering dust lol.

Thank you!

Haha, wow... The longest installation ever 😂

That would be a fun comparison. I just remember all the arguments of PC vs PlayStation

I'm also surprised that it even started without an FPU. I also would not have expected to see such a huge difference in performance.

@@bitsundbolts I certainly would have expected a huge difference. In fact, I'd have thought it would be worse. I say this with some experience in dealing with MC680x0 fallback routines when a 68881/68882 wasn't present (this was specifically on the Amiga). On average, even well optimized integer code required successive iterative operations (as nested loops) that amounted to around 15-20 instructions each, with something like 10 cycles per instructions (even or relatively simple things like 32bit floating point multiply). This meant, when executing the same math, at the same clock speed, on the same machine (25MHz A3000), running on my code path via the 68030, it was around 20 times slower versus running on the 68882 FPU. And that's despite the 68882 being a pretty weak floating-point processor. Anyway, DOS and Windows have a long history of interesting x87 emulation solutions. If memory serves me (and at 49, this was the stuff of my late teens) real mode DOS has a pretty interesting transparent x87 emulation strategy where compilers spitting out 16bit 8086 code would prefix x87 instructions (actually it was like an encoded instruction hint) with an int (software interrupt) that would vector to a handler that would either invoke software routines for the x87 instructions or, if the x87 was present, it a really strange instruction fixup and pass it to the x87 for execution. This ensured that a compiler could spit out a binary that would work without modification (even if it incurred some cycle penalty by raising the interrupt and invoking a handler). Later implementations (either with the 286 or 386) could actually trap and vector handling of invalid opcodes directly without the need for the int. However, once well into the Pentium era, especially when dealing with the float heavy math of a true 3d pipeline (e.g. not the doom engine, which is a masterclass in avoiding FP math and careful precalc values) and DOS extenders, and a lot of hand-tuned floating point routines and custom 32bit protected mode handlers, I assume programmers like Carmack just decided to have a custom handler for the invalid x87 opcode trap that throws a "your CPU sucks" error. That said, I've never even thought to check if Quake will run on a 486SX, because it says in the readme that you need an FPU. Maybe it's like Tomb Raider and actually falls back to x87 emulation and just runs in slide-show mode. You should test that in one of your videos for science. Edit: I just fired up PCEM (which I'm in the process of poking at testing updated SIMD vectorized optimizations, building for AMD64 and ARM64 - hopefully will do a PR in the next couple of weeks to the project as a contribution), and Quake totally doesn't like a missing FPU on an emulated 486SX2-50, complaining about "Coprocessor not available..." as part of an exception handler output.

FPUs weren't that common until the 486 came along, they were expensive add on chips for specialist uses, so most games and applications at the time didn't make use of an FPU. Not having one wasn't a big loss for most people. Of course, the situation gradually changed as the 486 got cheaper and more popular. The advent of real 3D games and rendering 3D images pushed the limits of integer only CPUs

@another3997 Yes, my first pc was a 386dx40 and I had no fpu. I was more surprised by the time the faster(40mhz and above) 486 clock speeds came out that yields were not good enough to just leave the fpu enabled. I guess that didn't happen until the 80mhz plus models for AMD as they had no sx release that I can remember for the dx2-80, dx4-100, dx4-120 or 5x86-133. I ran a 5x86 for over a year at 150Mhz, and paired with a Diamond Stealth 32 vesa card it almost ran Quake acceptably full screen, whixh was the first big fpu centric game that I can remember.

Looks like the minimum system requirements are a Pentium 90 and a 3D accelerator. It probably is a bit more demanding than Tomb Raider, but maybe we can lower the resolution. Might be interested 🤔

@@bitsundbolts The interesting thing here is that the game was developed with Pentium's pipelined architecture and very fast floating point in mind, so the question is: how much of the load will the 3D accelerator will take? Will that be enough for the fastest Socket 3 CPUs to perform with at least 15 fps? The game itself supports both software rendering and glide, but I recall it was more or less enjoyable to play on my friend's Pentium 133 and really cool on Pentium 200MMX. There are two executables, as I remember, nfs2sen.exe is for software and nfs2sea.exe is for glide and you can lower the resolution by pressing the F2 key while in game in software mode while it is locked in 640x480 in glide, but I personally tried it only in the software mode on my 486 - 3dfx were way too expensive, so was the Pentium. Despite my Am DX4-120 was quite a decent version along the 486 lineup, I had a slow Cirrus Logic 1MB card and almost no experience in understanding how to tune the system (like the caches, latencies and etc.) + the game was built for Pentium. The game was special to me, I dreamed about playing it on my 486, but it was completely unplayable. Slideshow :) So I'm just curious: what if I tuned the system properly and had a Voodoo card...

I only figured out that I have the write-through model when I started with this project. Running those CPUs at a 66MHz bus frequency is not easy. You must have pretty good hardware that is capable to work at such speeds!

@@bitsundbolts PCI-bus starts fooling around if CPU-PCI post writes are enabled in BIOS. If I disable it PCI-bus gets quite slow but works. 😅

That sounds plausible. The harder you push a system out of spec, the more compromises hinder the performance gain. Better to go for a balanced compromise.

No, I did not try that. I think that is also not possible. A 487 CPU is actually a 486 DX, which, when installed on the same board as the SX, would disable the CPU without the floating point unit. Therefore, I don't think it's possible to run a 486 and add floating point capabilities to it.

I wonder if it would be possible to convince Tomb Raider to utilize the capabilities of such hardware. I have no access to SGI machines, but maybe someone who has will test it one day...

I do have a Pentium OverDrive - and the video you suggest is planned. I am waiting for an original fan though. Hopefully, I can make this video some time in March.

yes the PODP5V83 running at 100MHz on a 40MHz FSB (boosted at 4V with diode mod) is a great option for the socket3 platform.

Very interesting thought... Reminds me of the 'Fast Inverse Square Root' constant: 0x5F3759DF

Yeah, probably. And the focus was on visuals, not sound.

Would you have had the ability to unlock the hidden features of the CPU back then? Because i never knew about hidden features and unlock utilities. There might also be a reason why they weren't ulocked out of the box, possibly not a good reason but a reason. It's not wrong to buy and use a product based on the capabilities that it ships with and which are guaranteed, rather than relying on a hack. But also i understand that such things are fun :D

For most newer DOS games, certainly those released after the Voodoo the BLASTER environment variable took care of that so as long as you had a Sound Blaster compatible card or a TSR that provided emulation and the IRQ and DMA were set correctly in the BLASTER variable it should "just work"

Pretty much...

I'm looking forward to that one, because I have one PC Chips blue socket board and a POD83 waiting to potentially replace a DX5-133 build. I run AMD at 160MHz with relative stability. It matches P-75 in synthetic benchmarks, but games could use a little more FPU kick. I heard Overdrive was also on par with a P-75, with system bus being a bottleneck.

Unfortunately, I do not have a K5 yet. In another video on my channel, I tested Tomb Raider with a Pentium 120. I do have a Pentium 75 for socket 5 if I'm not mistaken, but that is all hardware that I haven't tested yet.

@@bitsundbolts I can search a K5 for you

512x384 is the lowest resolution V1 cards support.

@sfurta really? Weird. I had no idea. So would 320x240 in quake with a voodoo 1 also not be possible?

Maybe I'll do that when I get the &EW version...

I don't think this will make any difference :( This CPU is missing the crucial piece of technology that is required by this game: the FPU.

@@bitsundbolts still just for the audience for fun :3 it doesnt hurt to test for curiosity

Maybe. Next up are a few graphic card repairs and some PCB projects. I need to find a few interesting Socket 7 CPUs to look at. Maybe Socket 5 first?

You're going to need a new showcase game, since Tomb Raider hits its framerate cap a little easily.

Oh, I am done with Tomb Raider for now ;)

@@bitsundbolts FYI I have a (working when last tried in 1999) Soyo 5EMA with some intel cpu, a Cyrix of some sort and an AMD K6-2/400 which is presently fitted. That rig was just able to use Windows 98. Also a spare K6-2/400

Thank you! I also don't understand why those AI thumbnails created such a controversy. Also, there is still time required to "fix" the AI pictures for my needs. Anyway, it was a fun experience and I'll probably add a short AI bloopers part in the Pentium OverDrive video - since there will be time ;)

AMD FX "Bulldozer" CPUs famously only had one FPU per pair of cores, so technically one of those cores on its own I guess, although modern operating systems treat the FPU-less half as a logical core. 😅

To give a more serious answer, probably some kind of ARM chip, they had already reached several hundred MHz by the time hardware floating point support became common.

As others have mentioned, there may be some fallback in place and floating point calculations are executed in a less efficient way on the CPU

I am not sure about that. I always thought that a 386 DX-40 should be comparable to a 486 DX-25 (or even SX-25?). I think I need to test this once when I get my 386 board setup.

Do I remember wrong, that the SX had disabled FPU unit due to faults in the manufacturing process?

486SX are fully fledged 486 minus floating point. the differences between the 386 and 486 are significant regardless of the FPU

Both. Lara and her pose are generated by AI. However, it took me about an hour to get a usable result. Then it comes to photo editing to make it usable for my needs

Well, this is going to be the second last video of this series anyway. The Pentium OverDrive is still pending, but that will come in a month or so. That also means, no more AI generated thumbnails for the videos to come.

Hard disagree. The thumbnails are fun and creative. AI art is a tool, why not have fun with them? Another great video, sir.

Thank you! I had fun creating those thumbnails. Plus, nobody ever commented on the thumbnails of my videos before.

@@bitsundbolts here's why I don't like them: 1) You're using pictures of modern Lara Croft while showcasing the original 90s game 2) It's an AI generated image which many people (myself included) dislike on principle I suggest doing a search on why AI "art" isn't liked by some folks, especially actual artists, if you're interested in the subject.

@@blakecasimirtotally agree with you - but perhaps you have to have a particular name to enjoy them 😉

You made it through. It's the last thumbnail generated by AI because this series is finished.

⁠@@bitsundbolts😢 I really liked the AI thumbnails, don’t know why people would hate them. The image of Lara with a soldering iron was priceless and really fused the subjects of the video together.

​@@kasimirdenhertog3516the art by itself is fine, but almost all ai art is generated from stolen art/uncredited artists who weren't asked for permission for use of their work, and have no way of knowing that their work is being used like this, nor have any means of scrubbing their creations from the datasets fed into the generative tools It's also getting to the point where ai is using previously generated art with glaring faults that are exacerbated by multiple generations of backfeeding, which many people can find disturbing or just looks wrong Again ai art by itself is not the issue, but rather the ethical issues behind its creation and subpar quality of successive generations that rubs people the wrong way