tyfighter · HackerTrans

tháng trướcdiscuss

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

tháng trướcdiscuss

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

4 tháng trướcdiscuss

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

5 tháng trướcdiscuss

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

6 tháng trướcdiscuss

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

7 tháng trướcdiscuss

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

7 tháng trướcdiscuss

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

9 tháng trướcdiscuss

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

10 tháng trướcdiscuss

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.

tyfighter

11 tháng trướcdiscuss

How is anyone just supposed to know that? It's not hard to find vim, but no one says, "You need to be running this extra special vim development branch where people are pushing vim to the limits!" Yes, it's fragmented, and changing fast, but it's not reasonable to expect people just wanting a tool to be following the cutting edge.

tyfighter

11 tháng trướcdiscuss

You're (they're?) not alone. This mirrors every experience I've had trying to give them a chance. I worry that I'm just speaking another language at this point.

EDIT: Just to add context seeing other comments, I almost exclusively work in C++ on GPU drivers.

tyfighter

năm ngoáidiscuss

Modern x86 implementations don't even do the XOR. It just renames the register to "zero".

tyfighter

năm ngoáidiscuss

I don't know which strains credulity more:

1.) In the 1960s, the Air Force developed a top-secret device power enough to simulate the EMP of a nuclear blast, i.e. some form of Non-nuclear Electromagnetic Pulse device that wouldn't be developed into a weapon for a few more decades. Rather than a controlled scientific test, they then decided to secretly drive it up to an operating missile base. They proceed to set it up on a 60 foot tall portable stand without anyone at the site noticing. I guess people at the site had their AirPods in for hours while giant generators run to charge the banks of capacitors necessary to run something that huge. No one noticed anything of this happening until it was hovering over the gate, they had their rifles pointed at it, and the mad scientists behind this plan were justified in their fear that our missile launch facilities were vulnerable to EMP.

2.) In the 1960s, a UFO disabled a missile at a launch facility.