Marcus10110

> Do not move off the left or right side

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!

[1] https://www.youtube.com/watch?v=zBkNBP00wJE [2] https://github.com/lefticus/6502-cpp [3] https://github.com/CalPlug/Heathkit_ET-3400

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.

It's not just a rip-off, it's build directly on top of the killedbygoogle repository!

https://github.com/fabianoriccardi/killed-by-microsoft is not a fork, but it has many of the commits from https://github.com/codyogden/killedbygoogle

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.

Contributor summary: https://github.com/fabianoriccardi/killed-by-microsoft/graph... https://github.com/codyogden/killedbygoogle/graphs/contribut...

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.

I would have guessed closer to the world's GDP, maybe a few orders of magnitude more.

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.

The company's blog has updates, but still no resolution: http://blog.buildzoom.com/buildzoom-office-burglary

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.

2030s? Why wait 5-15 years after SpaceX gets there? I'm guessing it will be a little awkward when they try to plant the flag on Elon's lawn.

side note, you can get SpaceX flags here: http://shop.spacex.com/accessories-58/spacex-flag-bundle.htm...

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.

I'm wearing mine to Interstellar tonight!

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.

Next time I get a parking ticket, I'll be sure to investigate the temperature stability of the parking meter's clock.

This is exactly the sort of thing I want to do next. Good luck guys!

It's perfect. A real world problem with world changing impact. It's hard. Its orders of magnitude harder than anything else startups are doing around here! The opportunity is almost infinite, and there are potentially billions of dollars to be made. I wish I was working on it!

I really hope these guys go all the way – although I'm sure there will be a ton of offers along the road. I wouldn't be surprised if Google X hadn't already made an offer, but if it comes down to it, I hope they go with Tesla over Google X. I got an inside look at their autopilot project a few months ago, and I'm really excited about it!

Honestly though, there are probably a lot of other big players who could be interested – Amazon especially. Again though, I really hope they take this all the way to a mass market consumer product, preferably with multiple iterations, while expanding the capabilities toward what Elon described as the 99% Autonomous autopilot.

The good news is that we have cross platform software & and APIs for using the device without our software and writing your own analyzer plugins.

These products won't sample fast enough for decoding USB 2.0 high speed, but we do support low speed and full speed with the existing products and the new stuff.

-Mark (Saleae)

Saleae LLC - www.saleae.com We're a hardware startup in SF. We're hiring software developer interns for C++! (this summer, but any time really)

We make logic analyzers, debugging tools for electrical engineers and embedded programmers. It's also a pretty popular reverse engineering tool. If you like playing with Arduinos & electronics, you might have heard of us.

Check out the hiring video on our site, www.saleae.com/jobs. Shoot us an email to jobs@saleae.com! I love talking about what we do so if you're curious at all, feel free to write in!

Oh, and if you don't have a hardware/EE background, don't sweat! Although that helps, there is no need to have any electronics background at all.

attend Nerd Nite SF this Wednesday: http://sf.nerdnite.com/