tyfighter · HackerTrans

el mes pasadodiscuss

I never encountered any encryption/protection of any kind on the II (had 3 bootloaders: a simple memory loader -> a huffman tree decompressor -> another simple memory loader) and even though I got pretty far on the III I could see there being some kind of key embedded in the firmware somewhere. I was able to disassemble any .syx firmware release that came out. I wrote my own IDA Pro modules for the TigerSHARC (II) and TI-C66x (III). II took a while but I learned a lot. When the III came out I started over. I spent a lot of time reverse engineering the amp block code, but stopped about 8 years ago. Back then he wasn't even compressing the firmware yet, so it was easy.

tyfighter

el mes pasadodiscuss

Nice :) I did this for my Axe-Fx II and III a long time ago, but I never published any of it for fear of being sued. Really, I just wanted to learn about DSP techniques and that was enough for me.

tyfighter

hace 4 mesesdiscuss

I just can agree with any interpretation of the article's code that believes programmers should desire silent sign extension when everything about the expression and data types involved is explicitly written to avoid signedness. At the end of the day, programming languages should naturally express intent and not rely on memorization of surprise. Here, I believe that Microsoft correctly employed principle of least surprise, and that ultimately the spec is broken and because of the amount of code in existence just can't be fixed.

tyfighter

hace 5 mesesdiscuss

I think the lack of a real usable emulator for SGIs is holding back any kind of homebrew. I say this as one of the developer's that got SGI Indy emulation working in MAME. Yes, it works, but it's too slow and too old to be usable. I spent some time after the MAME effort working on a custom high performance emulator for Crimson/Onyx/Reality Engine, but I've kind of burned out again. Maybe some day if I'm really driven again, and had help. I've done most of the reverse engineering already, it's just a lot of code.

I think that if a high performance, usable emulator for some of the big systems existed I think some of the old software might be rediscovered and show up on the internet.

tyfighter

hace 6 mesesdiscuss

Another amazing piece of gaming and art by an incredible, dedicated community. I'm thoroughly enjoying it so far, and I've still got a long way to go.

tyfighter

hace 7 mesesdiscuss

Hardware bugs can be found during chip bring-up within the first couple of months back from the fab, but since I've worked in this area I've never actually seen a bug that couldn't be worked around. They happen, but they're rare and I've never experienced a chip needing a respin because of a bug.

There is documentation, but it's not as well organized as you might imagine. Documentation is usually only necessary when implementing new features, and the resulting code doesn't change often. There are also multiple instruction sets as there are a bunch of little processors you need to control.

Vulkan/DX12 aren't really "low-level" APIs. They're "low overhead", and honestly, no. Their code base is just as large and complicated, if not more so, than OpenGL/DX11.

tyfighter

hace 7 mesesdiscuss

I haven't made a website of any kind since a C&C: Red Alert fan site somewhere on GeoCities in the late 90s.

I work on graphics drivers. They're hard write and even harder to debug. You have to be a huge nerd about graphics to get very far. It's a relatively rare skill set, but new, younger, nerdier people keep on coming. Most people in graphics are quiet and are just keeping the industry functioning (me). It's applied computer architecture in a combination of continuous learning and intuition from experience.

tyfighter

hace 9 mesesdiscuss

This is something I heard through the grape vine years ago, but when you're a very large corporation negotiating CPU purchasing contracts in quantities of millions, you can get customizations that aren't possible outside of gigantic data centers. Things like enabling custom microcode (and development support) for adding new instructions for the benefit of your custom JIT-ed server infrastructure. The corporate entity here is likely a hyperscaler that everyone knows.

tyfighter

hace 10 mesesdiscuss

Actually, the reason Transmeta CPUs were so slow was that they didn't have an x86 instruction hardware decoder. Every code cache (IIRC it was only 32 MB) miss resulted in a micro-architectural trap which translated x86 instructions to the underlying uops in software.

comments