When you asked whether it uses FPU, i paused the video, dumped the demo version of the game into IDA Pro, and seached real quick, so there's around 700 total invocations of instructions fld and fild. That's a rough indication of how many floating-point functions times parameters there are in the game. It's chock full of FPU use. I would like to bet that the game also contains no fixpoint fallback in the code. Instead the dos4g (DOS extender, acting as a little operating system) does the floating point trapping and emulation, which is spectacularly slow, since every single fpu instruction has to raise an illegal instruction exception first. Then of course IEEE floating point representation isn't the optimal way to emulate floating point with integer instructions, since you spend a fair bit of time packing and unpacking the binary representation. The funniest FPU usage in a game i have seen so far was in Build engine, as known from Duke Nukem 3D. I could write about it some other time, maybe after i grab a bite and do some grocery shopping, in case anyone is curious.
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 have followed all your videos in this series with interest. You have performed a very detailed forensic examination of a range of CPUs. It is a shame that at the time back when these CPUs launched no one could afford to do such tests. The cost would have been prohibitive 🤣
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.
Also, on these old motherboards, Disable the Serial and Parallel ports in BIOS, it won't make much difference but it keeps the CPU from polling those I/O ports and returns some cycles back to the game. I know, i'm nitpicking but on old board, I always disable them because they're never needed.
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
That makes a lot of sense. The OG Playstation used a sort of crude integer-based FPU for 3D calculations resulting in "shimmering" as rounding errors occur. It allowed them to get away with much less powerful hardware for 3D rendering.
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.
This is extremely interesting! Because… the Sony Playstation doesn’t have a floating point unit, and ran this fine! While the PSX CPU is different (something like a 20-40 MHz 32-bit RISC CPU), and while it has a fixed-point ‘geometry transform engine’ coprocessor… I wrote a 3D graphics engine that rendered ‘full rotation’ 3D scenes at 640x480, and I got 16-20FPS on a random 486-66 with a basic 2D card, back in the 1990s, inspired by Tomb Raider, and I used only integer maths there (I know this seems impossible when looking at Quake, but my engine did exist!) Given the ‘weak’ FP performance of pre-Pentium Intel CPUs, it means that if the programmers had made on optimised graphics engine (actually easy as the PSX did it), this would have run stupidly smoothly even on non-FPU CPUs!
Woah woah woah! I lived through this era of computers as a teen and read so much... you dropped an AMD 586 SX? How had I missed this??!?!??!?!! Thank you for highlighting this odd ball of a chip I some how missed and/or do not remember.
Oh hey, what a coincidence, I just spent the last few hours straightening pins! Although not CPU pins, it was transistor pins. I bought a big bag of genuine vintage transistors that came in the to-39 metal can package, and they came bulk in an anti-static bag so all the pins were bent. I had to straighten them out so I can run them through my tester. Needless to say I have a new appreciation for your CPU pin straightening skills.
Strange! The FPS counter is an integer number. The SX should crush this🤣 And as always: thank you for your effort! I think today i will play some Tomb Raider on an old rig. Caves-Level are appropriate for the actual weather.
Not surprised to see the the SX chip take seconds or even minutes per frame. The FPU is so important to proper 3D on the PC. The FPU of the Intel Pentium was so much better than any 486 class chip (except for the late Cyrix w/ extra features turned on) which allowed for for complex 3D engines like the Quake engine to be feasible. It is also why the FPU bug on the early Pentium chips became such a big deal back then. I had a good friend that was in college from 93-97 and the Pentium FPU bug affected his work. He had a Dell PC with a very early revision of the Pentium 90MHz and it had the FPU bug. It cause his work in MATLAB to be incorrect. He had to do all of his work using the on campus computer lab until he was able to get a later revision P90 shipped out to him under warranty which took a few months to happen at the time.
@@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.
Great video! The FPU was a weak spot for Cyrix from 486 onwards (I seem to recall reading they made very good FPUs before that?). AMD's 486 was a clone of Intel's, while Cyrix used its own design, that explains the difference in performance.
I'm curious if the Need for speed 2 SE is playable on any of these with the 3dfx. I had an AMD DX4-120 in the year 1997, but it was completely unplayable in software render.
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 would like to see you run one of the optimized ports of Open Lara on this platform, because someone got it running on the GBA with a decent framerate, which is far less powerful than any of these 486 CPUs, and it also has no FPU... I think if there is an optimized DOS port that it would be worth looking at.
@@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.
I had a 486 DX 120 with 8MB RAM, a cheap Blaster clone and the cheapest Avance video card available at the time I bought TR (the last one that had been sitting for about a year in the shelf of our small town bookstore). It ran playably with processor rendering only, with resolution decreased one step form the top quality IIRC. I say playably, because there was some occasional stutter when there was a lot of animation, but it was manageable.
A hella nice change for a 486 video. DX2 66 is so overused that it's started to be a BORING CPU, I like whenever I see anything else. SX2-66 is waaay more interesting! :)
Aloha, It would be interesting to see how it work with the Intel Pentium MMX. Not long ago I came across your TH-cam channel. Keep up the good work and great weekend!
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.
If you can get your hands on a Intel POD83 it would be a nice comparison since it has a decent FPU. If you want to go really wild (and get lucky) you can try booting it at 100mhz with a 40mhz bus but I've yet to see one doing that without bumping the voltage on the onboard regulator.
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.
Those clock doubled 486 SX chips are really rare. I've only ever seen one in my lifetime, and I've gone through hundreds upon hundreds of 486 systems. I found it in a CPU drawer in the computer lab in high school. I thought it was a counterfeit at the time, until I looked it up. Intel/AMD must have had a bad batch of clock doubled DX chips, or some obscure industry needed them for some specific reason. Because by the time the clock doubled 486s were coming out, there was an increasing need for FPUs. I remember loathing my SX33 because I couldn't run some software that required it. Maybe if you can find a system with a DM&P Vortex86 in it, you could try running benchmarks on that. It's supposedly related to the Rise MP6.
Yes, Cyrix had a notoriously poor FPU. Even with the 6x86 it couldn't keep up with Intel Pentium's FPU in anything that actually hit the FPU relatively hard, despite being marketed as a Pentium competitor. AMD's 486's were basically direct clones of the Intel models, and hence had more or less identical performance. Cyrix' design seems to have been different, and the FPU was the most obvious difference in terms of performance. In fact, in a lot of integer only tasks, the Cyrix 486s could usually keep up really well.
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.
Bro you're really hammering this WombRaider point home! :D YA CANT play TOMB WAIDER on a 486! Well I guess you can, as proven by yourself, if you have the 3Dfx VooDoo card! I remember my friend and I played TR demo, from a PC Zone magazine demo CD, way back in 96 on his Pentium 133. We spent hours just marvelling at the realism, the animation, we repeatedly dived from the ledge onto the hard ground just to hear her scream and see her smash the ground. What an amazing game (English devs ofc....) for it's time! But let it go! The only game that matters is Quake. Always will be.
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.
There was talk on the internet of Socket 3/4 motherboard adapters that would allow a socket 5/6 CPU to be installed in it. I would love to see some of that if it actually existed.
I am just trying to figure out how the sound effect would even work, considering you usually had to set IRQ etc. for your soundcard in every game you play, the logo wouldn't know how to even play a sound. Or you had to setup your soundcard in your graphics driver. :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"
It would be interesting to compare an early Pentium 60/66 MHz using as much of the same hardware as possible. Like you, I didn't have a PlayStation, so I'd quite like to see how the original PlayStation version compares to the best 486 + Voodoo 1 combination. 😉
If I remember correctly, there were FPU emulator drivers that could be tuned to be more or less accurate for some functions, which could boost performance 10x or more in order to make quick previews of raytraced scenes or fractal animation sequences. I wonder if this could be found, would it be useful to test how Tomb Raider used certain FPU functions?
@@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.
I always wondered why the sx2 existed. I guess there was bad enough yields to justify them at rhe time though. A friend of mine had one in a Compaq system and it was perfectly capable in Doom. I think I ended up with that cpu because I do have a sx2-66 in my collection, but I forgot I had it until recently when I ran across it.
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.
I’m shocked that Tomb Raider (and Glide) will run at all without dedicated x87 hardware. Falling back to emulated FP is brutally slow. The entire front-end of the pipeline (setup, transform, lighting, including projection and clipping) are being done on the CPU and are float heavy. The 3dfx glide offloaded (rasterization) portions of the pipeline involve fixed function hardware for receiving vertex data (coordinate location, texture location and ordering) and performing all the pixel pipeline and rasterization work (texturing with perspective correction, Gouraud shading, fog, z-buffering and a few other bits). John Carmack’s attitude to non x87 FPU hardware for the Quake engine was “doesn’t work, get a better CPU”. I’m very surprised the game even launched without a check for floating point hardware.
@@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.
My family hat a Compaq with this CPU. years later, properly on one of the the first ubuntu releases, my dad installed star office on this CPU/PC. he started the installation it in the evening, let i run over night and forget about. the family was on a 10 day holiday trip and as wee cam back, the installation was 99% and finished in the night after.
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.
Well I didn't expect that Tomb Raider would start at all without an FPU. I was counting on you starting up an FPU emulator to get a terrible frame rate. But, alas, we got our terrible frame rate without that external emulator. Wow.
It would have been rather complicated for that animation have sound effects considering all the different types of sound cards one could have when using dos.
I have two of those i486DX4/100 &EW CPUs. Both clocks up to 133MHz with Asus PVI-486SP3 which has 66MHz FSB option so 2x66. Quite fast CPUs but 150MHz is just too much with small overvoltage.
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!
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.
@@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
Just for the fun of it, I think you should see what computer that is the oldest would run tombraider smoothly. An old SGI 80sDesktop for instance with a sparc cpu and high end GPU for the time.
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...
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.
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 ;)
То что 486SX будет очень слабым в игре, я не сомневался. При выполнении команд FPU, CPU выполняет прерывание int 13 и передаёт команду в блок FPU. Но если отсутствует физически FPU, то происходит выполнение подпрограммы DOS, где эмулируются команды FPU целочисленной математикой. Скорость эмуляции аналогичных команд FPU примерно 7-30 раз медленнее. Отсюда вывод - тормозить будет очень сильно. П.С. Объём кэша не влияет на скорость выполнение команд FPU.
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.
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
@@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
The content of your videos is good, but you kinda ruin the mood with this AI crap. Use artwork from the actual 90s games for your thumbnails. Plenty of that is still around,
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.
@@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.
![486DX4-100 MHz Benchmark Battle [ Intel, Cyrix, AMD, TI, ST]](/img/n.gif)
When you asked whether it uses FPU, i paused the video, dumped the demo version of the game into IDA Pro, and seached real quick, so there's around 700 total invocations of instructions fld and fild. That's a rough indication of how many floating-point functions times parameters there are in the game. It's chock full of FPU use.
I would like to bet that the game also contains no fixpoint fallback in the code. Instead the dos4g (DOS extender, acting as a little operating system) does the floating point trapping and emulation, which is spectacularly slow, since every single fpu instruction has to raise an illegal instruction exception first. Then of course IEEE floating point representation isn't the optimal way to emulate floating point with integer instructions, since you spend a fair bit of time packing and unpacking the binary representation.
The funniest FPU usage in a game i have seen so far was in Build engine, as known from Duke Nukem 3D. I could write about it some other time, maybe after i grab a bite and do some grocery shopping, in case anyone is curious.
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??
I have followed all your videos in this series with interest. You have performed a very detailed forensic examination of a range of CPUs. It is a shame that at the time back when these CPUs launched no one could afford to do such tests. The cost would have been prohibitive 🤣
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.
Also, on these old motherboards, Disable the Serial and Parallel ports in BIOS, it won't make much difference but it keeps the CPU from polling those I/O ports and returns some cycles back to the game. I know, i'm nitpicking but on old board, I always disable them because they're never needed.
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
That makes a lot of sense.
The OG Playstation used a sort of crude integer-based FPU for 3D calculations resulting in "shimmering" as rounding errors occur.
It allowed them to get away with much less powerful hardware for 3D rendering.
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.
It would be great to compare these results against a Pentium 66Mhz and 100Mhz, just to highlight the generational improvement in IPC.
This is extremely interesting! Because… the Sony Playstation doesn’t have a floating point unit, and ran this fine!
While the PSX CPU is different (something like a 20-40 MHz 32-bit RISC CPU), and while it has a fixed-point ‘geometry transform engine’ coprocessor…
I wrote a 3D graphics engine that rendered ‘full rotation’ 3D scenes at 640x480, and I got 16-20FPS on a random 486-66 with a basic 2D card, back in the 1990s, inspired by Tomb Raider, and I used only integer maths there (I know this seems impossible when looking at Quake, but my engine did exist!)
Given the ‘weak’ FP performance of pre-Pentium Intel CPUs, it means that if the programmers had made on optimised graphics engine (actually easy as the PSX did it), this would have run stupidly smoothly even on non-FPU CPUs!
GTE matrix is FP16 math.
Woah woah woah! I lived through this era of computers as a teen and read so much... you dropped an AMD 586 SX? How had I missed this??!?!??!?!! Thank you for highlighting this odd ball of a chip I some how missed and/or do not remember.
Oh hey, what a coincidence, I just spent the last few hours straightening pins! Although not CPU pins, it was transistor pins. I bought a big bag of genuine vintage transistors that came in the to-39 metal can package, and they came bulk in an anti-static bag so all the pins were bent. I had to straighten them out so I can run them through my tester. Needless to say I have a new appreciation for your CPU pin straightening skills.
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.
Great Review! I want to see that intel dx4 overclocked and even better add a Pentium overdrive 83 on that motherboard
Strange! The FPS counter is an integer number. The SX should crush this🤣 And as always: thank you for your effort! I think today i will play some Tomb Raider on an old rig. Caves-Level are appropriate for the actual weather.
Thanks for making this video, this answers an age old question I've always been asking myself
You're welcome! Thanks for watching!
impressive to see how much the FPU matters for the game. I wouldn't have guessed that!
A sound effect with the 3Dfx logo would have been cool (at least a toggle in driver panel for one). Nice video, as always.
Thank you!
Not surprised to see the the SX chip take seconds or even minutes per frame. The FPU is so important to proper 3D on the PC. The FPU of the Intel Pentium was so much better than any 486 class chip (except for the late Cyrix w/ extra features turned on) which allowed for for complex 3D engines like the Quake engine to be feasible. It is also why the FPU bug on the early Pentium chips became such a big deal back then.
I had a good friend that was in college from 93-97 and the Pentium FPU bug affected his work. He had a Dell PC with a very early revision of the Pentium 90MHz and it had the FPU bug. It cause his work in MATLAB to be incorrect. He had to do all of his work using the on campus computer lab until he was able to get a later revision P90 shipped out to him under warranty which took a few months to happen at the time.
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.
Great video! The FPU was a weak spot for Cyrix from 486 onwards (I seem to recall reading they made very good FPUs before that?). AMD's 486 was a clone of Intel's, while Cyrix used its own design, that explains the difference in performance.
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 😂
Cyrix DX2 80MHz was my first CPU.
I'm curious if the Need for speed 2 SE is playable on any of these with the 3dfx. I had an AMD DX4-120 in the year 1997, but it was completely unplayable in software render.
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...
Always great videos
Thank you!
I would like to see you run one of the optimized ports of Open Lara on this platform, because someone got it running on the GBA with a decent framerate, which is far less powerful than any of these 486 CPUs, and it also has no FPU... I think if there is an optimized DOS port that it would be worth looking at.
Thanks for this review... Lara will be proud of you
I sure hope so 😃
Ok, now we want a 386 (or a 486 DLC) with (different) FPUs.
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.
I had a 486 DX 120 with 8MB RAM, a cheap Blaster clone and the cheapest Avance video card available at the time I bought TR (the last one that had been sitting for about a year in the shelf of our small town bookstore). It ran playably with processor rendering only, with resolution decreased one step form the top quality IIRC. I say playably, because there was some occasional stutter when there was a lot of animation, but it was manageable.
A hella nice change for a 486 video. DX2 66 is so overused that it's started to be a BORING CPU, I like whenever I see anything else. SX2-66 is waaay more interesting! :)
Aloha, It would be interesting to see how it work with the Intel Pentium MMX.
Not long ago I came across your TH-cam channel.
Keep up the good work and great weekend!
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.
If you can get your hands on a Intel POD83 it would be a nice comparison since it has a decent FPU. If you want to go really wild (and get lucky) you can try booting it at 100mhz with a 40mhz bus but I've yet to see one doing that without bumping the voltage on the onboard regulator.
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.
Those clock doubled 486 SX chips are really rare. I've only ever seen one in my lifetime, and I've gone through hundreds upon hundreds of 486 systems. I found it in a CPU drawer in the computer lab in high school. I thought it was a counterfeit at the time, until I looked it up.
Intel/AMD must have had a bad batch of clock doubled DX chips, or some obscure industry needed them for some specific reason. Because by the time the clock doubled 486s were coming out, there was an increasing need for FPUs. I remember loathing my SX33 because I couldn't run some software that required it.
Maybe if you can find a system with a DM&P Vortex86 in it, you could try running benchmarks on that. It's supposedly related to the Rise MP6.
Yes, Cyrix had a notoriously poor FPU. Even with the 6x86 it couldn't keep up with Intel Pentium's FPU in anything that actually hit the FPU relatively hard, despite being marketed as a Pentium competitor. AMD's 486's were basically direct clones of the Intel models, and hence had more or less identical performance. Cyrix' design seems to have been different, and the FPU was the most obvious difference in terms of performance. In fact, in a lot of integer only tasks, the Cyrix 486s could usually keep up really well.
Just a random question with the SX cpu - did you try it with an external FPU?
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.
Bro you're really hammering this WombRaider point home! :D
YA CANT play TOMB WAIDER on a 486! Well I guess you can, as proven by yourself, if you have the 3Dfx VooDoo card!
I remember my friend and I played TR demo, from a PC Zone magazine demo CD, way back in 96 on his Pentium 133. We spent hours just marvelling at the realism, the animation, we repeatedly dived from the ledge onto the hard ground just to hear her scream and see her smash the ground. What an amazing game (English devs ofc....) for it's time!
But let it go! The only game that matters is Quake. Always will be.
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.
There was talk on the internet of Socket 3/4 motherboard adapters that would allow a socket 5/6 CPU to be installed in it. I would love to see some of that if it actually existed.
I am just trying to figure out how the sound effect would even work, considering you usually had to set IRQ etc. for your soundcard in every game you play, the logo wouldn't know how to even play a sound. Or you had to setup your soundcard in your graphics driver. :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"
I'd be curious to see what the jump in performance is like when comparing the fastest 5x86 CPU's to some of the earliest socket 7's like the K5-PR75.
It would be interesting to compare an early Pentium 60/66 MHz using as much of the same hardware as possible. Like you, I didn't have a PlayStation, so I'd quite like to see how the original PlayStation version compares to the best 486 + Voodoo 1 combination. 😉
That would be a fun comparison. I just remember all the arguments of PC vs PlayStation
Pentium Overdrive and Socket 7 after ?
I didn't even know that there was an AM486-SX! O.O
If I remember correctly, there were FPU emulator drivers that could be tuned to be more or less accurate for some functions, which could boost performance 10x or more in order to make quick previews of raytraced scenes or fractal animation sequences. I wonder if this could be found, would it be useful to test how Tomb Raider used certain FPU functions?
Very interesting thought... Reminds me of the 'Fast Inverse Square Root' constant: 0x5F3759DF
Why does TR1 with voodoo only allow 640x480? 320x240 would've made almost any 486 run smoothly.
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?
Very interesting!
Loving the thumbnails of the video's :D
Thank you!
Floating point unit makes the difference hands down. Having lived through this era I wouldn't run old TR without 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.
I always wondered why the sx2 existed. I guess there was bad enough yields to justify them at rhe time though. A friend of mine had one in a Compaq system and it was perfectly capable in Doom. I think I ended up with that cpu because I do have a sx2-66 in my collection, but I forgot I had it until recently when I ran across it.
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.
Back in those days I was 100% sure the 3dfx logo was rendered by the 3dfx card itself, totally bypassing the computer.
Ah, yes, another episode of my current favourite series on the tubes of U. uwu)/
I’m shocked that Tomb Raider (and Glide) will run at all without dedicated x87 hardware. Falling back to emulated FP is brutally slow. The entire front-end of the pipeline (setup, transform, lighting, including projection and clipping) are being done on the CPU and are float heavy. The 3dfx glide offloaded (rasterization) portions of the pipeline involve fixed function hardware for receiving vertex data (coordinate location, texture location and ordering) and performing all the pixel pipeline and rasterization work (texturing with perspective correction, Gouraud shading, fog, z-buffering and a few other bits).
John Carmack’s attitude to non x87 FPU hardware for the Quake engine was “doesn’t work, get a better CPU”. I’m very surprised the game even launched without a check for floating point hardware.
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.
Качество генерации поражает. Починили пальцы?)
My family hat a Compaq with this CPU. years later, properly on one of the the first ubuntu releases, my dad installed star office on this CPU/PC. he started the installation it in the evening, let i run over night and forget about. the family was on a 10 day holiday trip and as wee cam back, the installation was 99% and finished in the night after.
Haha, wow... The longest installation ever 😂
hello you could put in the mix one AMD K5 cpu and a pentium 66 or 90/100 to see the diference
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
Well I didn't expect that Tomb Raider would start at all without an FPU. I was counting on you starting up an FPU emulator to get a terrible frame rate. But, alas, we got our terrible frame rate without that external emulator. Wow.
It would have been rather complicated for that animation have sound effects considering all the different types of sound cards one could have when using dos.
Yeah, probably. And the focus was on visuals, not sound.
Uuuu, the elusive SX2 ❤
I have two of those i486DX4/100 &EW CPUs. Both clocks up to 133MHz with Asus PVI-486SP3 which has 66MHz FSB option so 2x66. Quite fast CPUs but 150MHz is just too much with small overvoltage.
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 surprise fpu emulation works so slowly.
Going to do Socket 7??
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
Try finding a 487 Math co processor that will preform at 66 MHz and maybe a Voodoo 2 ?
SX didn't surprise me one bit. I'm like this is going to be a waste of time. lol
Pretty much...
Just for the fun of it, I think you should see what computer that is the oldest would run tombraider smoothly. An old SGI 80sDesktop for instance with a sparc cpu and high end GPU for the time.
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...
Setting the FSP at 50 MHZ will probably set the PCI bus speed at 25 MHz. Try to see if you can set the PCI but at 50 MHz also.
Now do the same test with a 7800X3D. You know, just to make sure.
i wonder what is the fastest cpu with no fpu?
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.
Try to overclock that SX66 cpu to its limits for 2nd chance (just for fun)
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
You should try to run Intel dx100 at 120
Maybe I'll do that when I get the &EW version...
Awesome series! No problem with AI art for preview at all
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 ;)
Personally I always preferred Womb Raider to Tomb Raider
On N-Gage...
Try with fpu emulator.
Short answer: unbearably slow. Actually, I am surprised that it didn't crash. On 286s without 287 coprocessor, programs simply refused to work.
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
То что 486SX будет очень слабым в игре, я не сомневался. При выполнении команд FPU, CPU выполняет прерывание int 13 и передаёт команду в блок FPU. Но если отсутствует физически FPU, то происходит выполнение подпрограммы DOS, где эмулируются команды FPU целочисленной математикой. Скорость эмуляции аналогичных команд FPU примерно 7-30 раз медленнее. Отсюда вывод - тормозить будет очень сильно.
П.С. Объём кэша не влияет на скорость выполнение команд FPU.
My understanding is that 486 SX chips were effectively 386 cores. That would explain the lack of performance here.
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
The game boy advance runs Openlara faster than this =D
These video title cards are amusingly silly. Are they AI generated or did you create them?
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
please stop using AI to make your thumbnails
Stop putting that impostor in your thumbnails. THAT IS NOT LARA CROFT! That is a pale imitation. Retro Lara deserves proper representation!
Knock it off with shitty AI „art“ would ya
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
The content of your videos is good, but you kinda ruin the mood with this AI crap. Use artwork from the actual 90s games for your thumbnails. Plenty of that is still around,
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 😉