Turns out if you do this, then hold the up key, it would appear that you avoid collision detection. Also, it appears your X position is preserved between levels, allowing you to hold the up arrow to rapidly advance levels.
I have an ET-3400 on the shelf behind me! I was just playing with it the other day.
After watching Jason Turner's CppCon talk on writing an i386 to 6502 assembly translator [1][2], I started working on a fork that would target the 6800. I only got about 3 instructions working, but that's really all you need for some really simple test code with optimization turned to the max. It also turns out that someone wrote a fantastic emulator specifically for the ET-3400 trainer [3], and I managed to get my application running on it!
There is something special to me about the idea of writing modern C++, and compiling it for such early microprocessors. The 512 bytes of RAM is a pretty big limitation though. I wanted to try and emulate an EEPROM using an Arduino or FPGA, but got stalled out on the project. From time to time I like to browse through the LLVM backend documentation, but I can't seem to commit to trying to build a backend.
About 10 years ago, I met Al Alcorn at an event. Prior to that, I had studied the original pong schematics in school as part of an interesting challenge in a digital design course, where the goal was to figure out what the schematic did, without knowing it was pong.
So when I met Al, I mentioned that I found the schematics fascinating, and had some questions. He was happy to walk me through the whole thing! After that, he told me all kinds of great stories about the different versions of pong that they built, including color support, the home version, and PAL support.
The earliest commits from fabianoriccardi include git messages like:
> replacing "Google" with "Microsoft", removed PressCoverage
Anyway, great code recycling at least right? It's a fun thought that the author of killedbygoogle ultimately wrote most of the code on killed-by-microsoft.
I deal with this every day, because we only notarize our electron app in CI if we're building the master branch or an RC branch. I don't see it mentioned in the article, but what gets me every time is that the "right-click" trick only works the second time you try to launch the app. The first time, right-click or not, MacOS won't let you launch the app.
I do wish Apple had a free tier for open source projects, just like many other tools on the web.
As an alternative, I wish there was an easy way to "sponsor" open source projects for this sort of thing. (I guess there is in some cases, but it's pretty hit or miss)
On Windows, although it's pretty easy to run unsigned applications, it's a huge pain to install unsigned 64 bit drivers, even if it's just the inf file that's custom. I've ended up signing open-source drivers several times with my own code signing certificate (a few hundred bucks every few years) although I haven't distributed the result. Drivers for things like USB SDRs.
Absolutely. Data corruption from VIA based host controllers was probably the worst issue we've seen, and the USB 3.0 ASMedia host controllers are probably the worst now that VIA was able to solve their issue with a driver update.
Most hardware on the market today was released before the xhci spec 1.0 was finished, and I agree that ALL hardware on the market does not even properly implement the spec that was available during its design. Fortunately, most issues can be worked around using quirks.
The hardware is the root of the problem, but I would also add that the xhci_hcd kernel module, even in the latest kernels, is well behind Microsoft in terms of handing these device-specific quirks. The Microsoft USB 3.0 stack introduced in Widows 8 solves just about every host-specific issue we've ever seen. ASMedia is the only host controller vendor that bothers to provide their own Windows 8/10 driver (both for their USB 3 Gen1 and Gen2 chips). No one else provides an alternative to the Microsoft provided usbxhci.sys.
That said, all of our tests have been limited to bulk transfers, and we're only using existing user space libraries (WinUSB, LibUSB, IOKit). We do push throughput, we have tight latency requirements, and we keep a large number of buffers queued at all times, which does push the host controllers further than your typical storage device. (We make streaming data recording equipment for electrical engineers and embedded developers)
I don't want to bash xhci_hcd though; their progress has been fantastic, despite the minefield of problems created by all these host controller vendors. I would like to say a special thanks to @sarahsharp, for all of the hard work put into the xhci host controller module. Without Sarah, I don't know who will answer when the xhci_hcd doorbell rings.
We've done a similar analysis of USB 3.0 host controllers and the state of their drivers cross-platform. It's amazing how bad the state of USB 3.0 is, even 5 years after devices started shipping. Even the latest Intel host controllers (8 & 9 series) initially shipped with bad drivers. I look forward to getting our results posted.
Instead, I want to build a tool that constantly scans your plate number for tickets and auto-pays them as soon as they show up to avoid late fees.
...Because I deserved every ticket I've ever received.
Looks awesome! I would love real time updates of counterfeit products as they are posted to ebay, etc - especially in all regions/locales. We automated the process of sending the take down notice once a listing was identified, but we're manually searching & identifying right now. Seems like a good fit for us.
Interesting perspective - we deploy our QT app on Linux, osx and Windows, but I find that the best experience has been on Windows. (we statically link QT and boost, which may cause more headaches than the default dynamic linking).
Specifically, maintaining backwards compatibility on OSX while marching forward with newer versions of the os has been a very big pain. We recently dropped support for OSX 10.6 because we simply could not get QT to statically compile on Yosemite, even after extracting the 10.6 SDK from a legacy xcode download. We did manage to keep 10.7 support though, thankfully, using the same SDK extraction method.
On Linux, the upgrade from QT 4.8 to 5.4 was the roughest. the number of dependencies dramatically increased, complicating the compilation of QT and breaking compatibility with older distros (specifically CentOS 6.x, where we hear the most complaints)
Windows & visual studio has always been our preferred developer environment, with the latest version of both. Maintaining support back to Windows XP has been particularly easy and painless. Where on Linux, it seems like the glibc requirements march forward with every release of gcc, and on osx it becomes dramatically more difficult to support older versions of the os with each new release.
A side note about QT on Windows - compiling QT and your application on the newest version of Windows helps a lot for customers on that platform - for instance, before we compiled on Windows 8, the application UI would default back to the legacy battleship grey theme, and simply rebuilding on Windows 8 with no source modifications fixed it.
This almost feels like legal cover more than anything else. At least they "tried" to protect the music files from easy duplication & piracy. I wonder if circumvention of XOR is illegal under the DMCA. It feels just about effective as renaming the file extension from .mp3 to .shh
I would argue that analog FM radio has a pretty bad user experience, and I completely understand a manufacturer not including it because of that. The audio quality is usually poor, it's location and environment sensitive, and the system for distributing and the RDS text is slow to update, and often incomplete.
Then what happened? Did he get his stuff back? Did the police make an arrest? The cynic in me assumes that the police just ignored the lead, and no justice was served.
I really wish iFixit would do a formal root cause analysis every so often. As an electrical engineer running a small manufacturing operation, I'm always very interested in the failure rates and root causes that much higher volume products see.
Lead free solder melts somewhere in the 200C-300C range. The solder we use melts at 230 degrees, and we reflow our PCBs in a Vapor Phase Soldering oven, which precisely limits the PCB temperature to 230C. Reflowing a PCB multiple times risks solder paste flux exhaustion, and also risks parts on the bottom side of the PCB falling off. Also, some parts are rated only for a very limited time at these temperatures, even when they are not running. Cooking these parts multiple times results in a dramatic reduction in lifespan.
It wouldn't surprise me if Apple did an x-ray inspection of every BGA part on every device they produce. This isn't common practice in the manufacturing lines that I know about, but I know that it's done in some cases. This would help catch cracks or other defects that would result in a reduced lifespan of the device, as well as detect show stopper issues.
There are a lot of other things that can fail on a PCB due to heat long before the solder will melt on a BGA pin. My guess that this was a mechanical failure inside the PCB. Either a through hole failure (such as a via disconnecting from a PCB trace, since the PCB is undoubtedly a very high layer count producing many fragile connections to long copper vias, which would expand vertically and in radius during temperature cycles) or an inner layer connection defect due to PCB or copper expansion. In either case, cycling the temperature by a large amount could temporarily fix the problem by creating a good enough connection for operation.
The bottom line is higher operating temperature always hurts mean time between failure. This is well studied, and many manufacturers will include plots of the operating temperature vs MTBF. Even though the laptop is working now, all of the components have been exposed to additional extreme additional thermal stress. Everything in the laptop is now much closer to failure. I don't expect the laptop will last much longer.
I'm not familiar with the guts of a MacBook Pro, but if there was a larger than normal gap between the chips and their heat sinks, then this would definitely explain the higher than normal system temperature. Even if the heat sink compound was able to bridge the gap with minimal air bubbles, it's still a pretty poor thermal conductor. This may have been a manufacturing defect that Apple could check for in the future. (Although I would hope they already run the devices for some length of time in their final enclosures while monitoring component temperatures)
fascinating. I assume that was the first kinect. Was the vision processing separated from the USB interface in different chips? Sounds like a fun project.
This is a fundamental in FPGAs. The mode where the bit is unstable is called metastability. Most FPGA tools can automatically infer gray code for state machine states, and pretty much all cross clock domain FIFOs will use grey code to indicate where the read and write pointers are located.
keep it, with the intention of using it as a development platform for a robot or something, but then never end up doing anything because who wants to learn another toolchain, right? Instead, lets just drop that in the box next to the palm pre and the old windows mobile phone.
Turns out if you do this, then hold the up key, it would appear that you avoid collision detection. Also, it appears your X position is preserved between levels, allowing you to hold the up arrow to rapidly advance levels.