Makes me wonder. The PC-98 for the most part uses all the same hardware, down to CPUs and sound cards, and OSes as IBM PC, yet, it's 0% IBM compatible. What's unique about its architecture that makes in wholly incompatible with IBM PC programs, and similarly, what's up with sub-100% IBM compatibles?
I would have to look at the system architecture details to give you an accurate answer, but my guess is that the memory and IRQ mapping was different. The IBM PCs expected a certain configuration which was essentially arbitrarily chosen by IBM and not necessary for the underlying hardware to function.
If you do, I would love to see the results. The trick will correcting for system differences such as chipset, FSB, and core clock speed. It could also be interesting to see how these results change as a function of some of those parameters as well (specific FSB and core clock, which will demonstrate the importance of the L2 cache - e.g. K6 vs K6-III at 100 and 200 MHz core clocks).
@@RTLEngineering Now that you say, yes, it would be good to try the K6-3,2+,3+ with disabled L2 cache too, that can separate its effect from the other architectural improvements. Otherwise I plan one same motherboard, one same clock. As 233MHz is about the highest the old 350nm K6 core can go it should be my choice - and maybe a second tier too, like 500 or 550MHz...? The board will probably be some ALI Aladdin 5 one - I don't know yet which one, but it must know the + versions. I can't rule out a TX with a hacked BIOS either. Some can go as low as 2.0V which is viable with the + CPUs.
I don't really have a good book to recommend, or at least I can't think of one that provides a good overview. The intel manuals do a decent job, and I was using "Pentium Processor System Architecture" by Anderson and Shanley, for the extra background in this video. However, I don't recommend that textbook - it has a bunch of detailed information missing from other sources, but it also misses out on some simple stuff. If you are more interested in the architecture, the intel manuals are probably the best place to start. The older architectures can require a bit of searching though, for example, manual 24142805 is for the P5/P55C, but I could only find it on an archive. Regarding the decoding steps, was the issue with understanding the 8086, 386, the Pentium walkthrough, or all of the above? I could probably do a quick video showing the decoding via an animation. Also re: your other comment. I use Lucid chart for papers, but I still find it quicker to iterate with google slides (Lucid chart produces nicer diagrams though). Animating the color guides with Lucid chart also would have been more challenging, where in slides I could just duplicate the slide and quickly change the color, then step through them using OBS to get all of the states into the video editor at once.
Man, I hate to say it, but x86 is ugly. I can see why RISC was a huge deal back in that era. It would be cool to see the architectures compared. Early ARM was very odd with it's barrel shifter in every instruction, though MIPS and Power were more popular in the 90's. Even just looking at how the Z80 did it's instructions.. DJNZ is just a little dirty.
While I like the detail of your videos (I once was also ASM-optimizing code for the Pentium), it's really tiring to listen to a computer generated (albeit well generated) voice with no variance in it. I had to pause several times... Try using your own voice, I bet a lot of people would appreciate it!
Thanks! I can see how that might be frustrating, but the videos which I did use my own voice in (older ones on the channel) resulted in a similar pattern. The reason for the synthesis is production time - recording and editing my voice is a tedious task which usually takes me around 1 hour for every minute of audio (so this video would have taken 24 hours of work). Maybe the newer AI tools can help speed that up, but I have not had the time nor motivation to try doing so.
@@RTLEngineering I don't mind the AI voice. Also I think for a performance oriented channel a 24x reduction in execution latency is an affirmative defence against complaints about architectural choices.
This channel is an absolute gem.
Amazing video!
Makes me wonder. The PC-98 for the most part uses all the same hardware, down to CPUs and sound cards, and OSes as IBM PC, yet, it's 0% IBM compatible. What's unique about its architecture that makes in wholly incompatible with IBM PC programs, and similarly, what's up with sub-100% IBM compatibles?
I would have to look at the system architecture details to give you an accurate answer, but my guess is that the memory and IRQ mapping was different. The IBM PCs expected a certain configuration which was essentially arbitrarily chosen by IBM and not necessary for the underlying hardware to function.
* Hm, VERY interesting, especially what you say about the different K6 revisions' Quake performance. Now I feel tempted to test all these versions...
If you do, I would love to see the results. The trick will correcting for system differences such as chipset, FSB, and core clock speed. It could also be interesting to see how these results change as a function of some of those parameters as well (specific FSB and core clock, which will demonstrate the importance of the L2 cache - e.g. K6 vs K6-III at 100 and 200 MHz core clocks).
@@RTLEngineering Now that you say, yes, it would be good to try the K6-3,2+,3+ with disabled L2 cache too, that can separate its effect from the other architectural improvements. Otherwise I plan one same motherboard, one same clock. As 233MHz is about the highest the old 350nm K6 core can go it should be my choice - and maybe a second tier too, like 500 or 550MHz...? The board will probably be some ALI Aladdin 5 one - I don't know yet which one, but it must know the + versions. I can't rule out a TX with a hacked BIOS either. Some can go as low as 2.0V which is viable with the + CPUs.
Nice video, but I couldn’t quite follow the decoding steps. Is there maybe a book available you can recommend on x86 architecture?
I don't really have a good book to recommend, or at least I can't think of one that provides a good overview. The intel manuals do a decent job, and I was using "Pentium Processor System Architecture" by Anderson and Shanley, for the extra background in this video. However, I don't recommend that textbook - it has a bunch of detailed information missing from other sources, but it also misses out on some simple stuff. If you are more interested in the architecture, the intel manuals are probably the best place to start. The older architectures can require a bit of searching though, for example, manual 24142805 is for the P5/P55C, but I could only find it on an archive.
Regarding the decoding steps, was the issue with understanding the 8086, 386, the Pentium walkthrough, or all of the above? I could probably do a quick video showing the decoding via an animation.
Also re: your other comment. I use Lucid chart for papers, but I still find it quicker to iterate with google slides (Lucid chart produces nicer diagrams though). Animating the color guides with Lucid chart also would have been more challenging, where in slides I could just duplicate the slide and quickly change the color, then step through them using OBS to get all of the states into the video editor at once.
Man, I hate to say it, but x86 is ugly. I can see why RISC was a huge deal back in that era. It would be cool to see the architectures compared. Early ARM was very odd with it's barrel shifter in every instruction, though MIPS and Power were more popular in the 90's. Even just looking at how the Z80 did it's instructions.. DJNZ is just a little dirty.
While I like the detail of your videos (I once was also ASM-optimizing code for the Pentium), it's really tiring to listen to a computer generated (albeit well generated) voice with no variance in it. I had to pause several times... Try using your own voice, I bet a lot of people would appreciate it!
Thanks! I can see how that might be frustrating, but the videos which I did use my own voice in (older ones on the channel) resulted in a similar pattern. The reason for the synthesis is production time - recording and editing my voice is a tedious task which usually takes me around 1 hour for every minute of audio (so this video would have taken 24 hours of work). Maybe the newer AI tools can help speed that up, but I have not had the time nor motivation to try doing so.
@@RTLEngineering I don't mind the AI voice. Also I think for a performance oriented channel a 24x reduction in execution latency is an affirmative defence against complaints about architectural choices.