80386 Memory Pipeline
nand2mario.github.io
80386 Memory Pipeline
1–10 of 19 posts
Re: 80386 Memory Pipeline
#2Interesting article. I learned some things.
How hard would it be for Mr Github to add rss/atom feeds, I wonder?
Re: 80386 Memory Pipeline
#3Voodoo mode is the ultimate test. Imagine having access to 4GB of memory from real mode.
Re: 80386 Memory Pipeline
#4Voodoo mode is the ultimate test. Imagine having access to 4GB of memory from real mode.
Shameless plug for my https://blogsystem5.substack.com/p/beyond-the-1-mb-barrier-i... article from a couple of years ago. You'll find a deep dive on unreal mode (I just learned it's also known as "vodoo mode") and some hands-on code to play with it ;-P
Re: 80386 Memory Pipeline
#5wasn't this basically the consensus among numerical analysts like 20 years ago? i remeber reading similar arguments in goldberg's paper and various game dev forums circa 2005, so genuinely curious what keeps making this idea feel "new" to each generation of programmers who rediscovers it
Re: 80386 Memory Pipeline
#6wasn't this basically the consensus among numerical analysts like 20 years ago? i remeber reading similar arguments in goldberg's paper and various game dev forums circa 2005, so genuinely curious what keeps making this idea feel "new" to each generation of programmers who rediscovers it
I think you’re missing the point. This person is implementing various CPU cores on FPGA. The insights they can share from that complex process are sometimes interesting, because they are looking at the system from a new angle.
Re: 80386 Memory Pipeline
#7Voodoo mode is the ultimate test. Imagine having access to 4GB of memory from real mode.
Shameless plug for my https://blogsystem5.substack.com/p/beyond-the-1-mb-barrier-i... article from a couple of years ago. You'll find a deep dive on unreal mode (I just learned it's also known as "vodoo mode") and some hands-on code to play with it ;-P
I want vooDOS 5.0 which is 32 bit clean :)
Re: 80386 Memory Pipeline
#8Again a very interesting look at how this chip works internally!
I've decoded the entry point PLA of the 80286 (not the actual microcode though). It also has separate entries for real and protected mode, but only for segment loads from a general purpose register, HLT, and for those opcodes that aren't allowed in real mode like ARPL.
Loading a segment register from memory on the 286 uses the same microcode in both modes, as does everything else that would certainly have to act differently, like jump/call far. That was a bit surprising, since it would have to decide at run time which mode it's in. Is this the same on the 386?
Tested on my 286 machine what happens when opcodes are decoded while in real mode but executed after PE is set: Segment load from memory works (using protected mode semantics), whereas the load from register only changes the visible selector and nothing else. The base in the descriptor cache keeps whatever was set there before -- I assume on the 386, SBRM would update the base the same way it does in real mode in that situation, because it's also used for V86 mode there. Illegal-in-real-mode instructions trap, but do so correctly using the protected mode IDT.
Also seems like executing three pre-decoded instructions without a jump after setting PE causes a triple fault for some reason.
Re: 80386 Memory Pipeline
#9Voodoo mode is the ultimate test. Imagine having access to 4GB of memory from real mode.
Shameless plug for my https://blogsystem5.substack.com/p/beyond-the-1-mb-barrier-i... article from a couple of years ago. You'll find a deep dive on unreal mode (I just learned it's also known as "vodoo mode") and some hands-on code to play with it ;-P
There are things like DOS4GW that you can use as loaders.
Re: 80386 Memory Pipeline
#10wasn't this basically the consensus among numerical analysts like 20 years ago? i remeber reading similar arguments in goldberg's paper and various game dev forums circa 2005, so genuinely curious what keeps making this idea feel "new" to each generation of programmers who rediscovers it
I think you’re missing the point. This person is implementing various CPU cores on FPGA. The insights they can share from that complex process are sometimes interesting, because they are looking at the system from a new angle. https://nand2mario.github.io/projects/
OP probably meant to post in another thread: https://news.ycombinator.com/item?id=47767398