The Voodoo cards had no right to look as good as they did for their time. Someone rebuilding one from scratch is exactly the kind of project HN was made for.
Thank you! These things do pack in a ridiculous amount of functionality for what they do. Probably why they look so good but also why it took 30 years for a hardware re-implementation.
I exhausted my teenage savings to buy the Voodoo 1 due to the Linux support. Granted, I was running Red Hat at the time so the installation consisted of installing what, two RPMs? Played a lot of Q3 and Unreal on that card.
I find it odd the author adds all these extra semantics to their input registers, rather than keeping the FIFOs, "drain + FIFOs", "float to fixed point converting register", etc as separate components, separate from the task of being memory mapped registers. The central problem they were running into was one where they let the external controller asynchronously change state in the middle of the compute unit using it.
I'm noting down this conetrace for the future though, seems like a useful tool, and they seem to be doing a closed beta of sorts.
Maybe I'm misunderstanding, but that functionality is implemented in another component. The register bank only records the category of each register and implements the memory-mapped register functionality.
This list of registers and their categories are then imported in separate components which sit between incoming writes and the register bank. The advantage is that everything which describes the properties of the registers is in a single file. You don't have to look in three different places to find out how a register behaves.
Well still, why tie this kind of processing to the registers themselves? Sure having a shorthand to instantiate a queue of writes I could see, but float to fixed conversion has no place being part of a memory mapped register bank.
Wouldn't it be more sensible to have one module for converting the AXI-Lite (I presume?) memory map interface to the specific input format of your processor, and then have the processor pull data from this adaptor when it needs it?
That way still all handling of inputs is done in the same place.
Edit: maybe, what it comes down to is: Should the register bank be responsible for storing the state the compute unit is working on, or should the compute unit store that state itself? In my opinion, that responsibility lies with the compute unit. The compute unit shouldn't have to rely on the register bank not changing while its working.
[delayed]
The Voodoo cards had no right to look as good as they did for their time. Someone rebuilding one from scratch is exactly the kind of project HN was made for.
Thank you! These things do pack in a ridiculous amount of functionality for what they do. Probably why they look so good but also why it took 30 years for a hardware re-implementation.
My first video card.
Getting it working in linux in ~1999 was really not easy, especially for a teenager with no linux experience.
My networking card wasn't working either, so I had to run to a friend's house for dial-up internet access, searching for help on Altavista.
Very cool project. Way above my head, still!
I exhausted my teenage savings to buy the Voodoo 1 due to the Linux support. Granted, I was running Red Hat at the time so the installation consisted of installing what, two RPMs? Played a lot of Q3 and Unreal on that card.
I find it odd the author adds all these extra semantics to their input registers, rather than keeping the FIFOs, "drain + FIFOs", "float to fixed point converting register", etc as separate components, separate from the task of being memory mapped registers. The central problem they were running into was one where they let the external controller asynchronously change state in the middle of the compute unit using it.
I'm noting down this conetrace for the future though, seems like a useful tool, and they seem to be doing a closed beta of sorts.
Maybe I'm misunderstanding, but that functionality is implemented in another component. The register bank only records the category of each register and implements the memory-mapped register functionality.
This list of registers and their categories are then imported in separate components which sit between incoming writes and the register bank. The advantage is that everything which describes the properties of the registers is in a single file. You don't have to look in three different places to find out how a register behaves.
Well still, why tie this kind of processing to the registers themselves? Sure having a shorthand to instantiate a queue of writes I could see, but float to fixed conversion has no place being part of a memory mapped register bank.
Wouldn't it be more sensible to have one module for converting the AXI-Lite (I presume?) memory map interface to the specific input format of your processor, and then have the processor pull data from this adaptor when it needs it? That way still all handling of inputs is done in the same place.
Edit: maybe, what it comes down to is: Should the register bank be responsible for storing the state the compute unit is working on, or should the compute unit store that state itself? In my opinion, that responsibility lies with the compute unit. The compute unit shouldn't have to rely on the register bank not changing while its working.
The project is cool, but the LLM generated blog bothers my brain.
+1
I love the names and branding of that era. Technology today is far more advanced but it doesn’t have that same excitement for consumers.
The bar is a lot lower- it was practically implied that you were already an enthusiast if it was in your awareness at that time I think.