Yeah, don't use these guys. They have a tendency to swap translation direction in the presence of electrical noise, which means your input is now an output, cross-driving something. Sometimes everything survives just fine and switches back on the next edge. Sometimes the magic smoke comes out. And sometimes, if the stars align just wrong, you get an industrial accident.
This is one of those classes of parts that has hidden dangers and really should not be as prominently advertised as it is. They look simple, but they're for experts only. Don't use them unless you really know their failure modes and don't have another reasonable option.
Bunch of pulldown restrictions too, though if you pulled both ends the same way when not driven, that usually worked ok
- U6 and U8 need nearby decoupling. LVC logic has horrid power consumption during transitions, so best to feed it well if you expect any kind of transition rate out of these gates. It doesn't have to be explicitly dedicated to these parts but it needs to be physically close.
- That goes extra for the big fat WideBus 16-wide level translators. They have multiple power pins for a reason. They are vicious little devices. Decouple every last power input pin with its own individual capacitor.
- U6 outputs appear to have wrong bus directions? Probably not important (also maybe not a problem at all, I usually do Altium not KiCad)
- VBUS is not logic level, so you shouldn't use it as a logic signal if you want reliability (it will work... mostly... but also be weird sometimes), but you absolutely cannot drive multiple things with it and expect them to work (their input thresholds will be slightly different and you will be sad when they switch at slightly different times because it's moving slowly). Clean it up with a Schmitt trigger (1G17 etc).
- No ESD protection on the USB port. Do you want it to live? Try something like ECMF02-4CMX8, nice and simple to implement (mildly annoying to solder though).
- Whatever is going on with Q1 is poorly enough drawn that I can't understand it at a glance. Best to just draw these parts as two ordinary MOSFETS with A and B suffixes, then the circuits can be legible.
- On IC2 (why not U2?) lines 4, 5, 6, 7 are being cross-driven. Do not ground both sides, you will be sad. Ground the input sides and let the outputs be unconnected, because they're strongly driven by the chip. Or use resistors to pull things places if you must satisfy someone somewhere who loves that kind of stuff (medical! medical? medical.).
- U7 SENSE pin draws not-much current (~25nA) so no reason to burn power in that resistor divider
- Consider stuffing a big fat electrolytic or two down somewhere and making your PDN nicely damped.
.. Now go build and sell some nice IOT gadgets that do not track users, and become a millionaire. Like a simple water leak detector.
Edit: Oh, yuck.
"A software development kit (SDK) is provided royalty-free,[13][14] though the ability to commission a finished product into a Matter network in the field mandates certification and membership fees,[15][16] entailing both one-time, recurring, and per-product costs.[17] This is enforced using a public key infrastructure (PKI) and so-called device attestation certificates.[15]"
Most of the links were already long-long-dead, but there were some cool inspirational projects on there.
Keyboards can also survive dishwashing with gentle soap. So can motherboards
I don't advise it, but tech can take quite some abuse.
Strategically placed underwear and socks can do wonders to protect things.
(never tried it with a wireless one, so...)
While there's no region lockout, don't you need to pass the logo check?
Plus, Sega v. Accolade killed that practice. I don't think anyone has tried to enforce it since.
I found something on nataliethenerd's GitHub, but the license is non-commercial.
https://github.com/nataliethenerd/CGB_ReverseEngineer
>I scanned, sanded and redrew the CGB schematics using a CGB-CPU-04 board. The original schematic was used as a refrence for values.
Could you attach faster storage if the underlying hardware its plugged into isn't changing. I guess you could but I don't have a lot of experience in that area.
People built cartridges which stream game footage from a PC to the gameboy and relay the inputs back to the PC to "play" GTA 5 on an original gameboy. https://www.youtube.com/watch?v=pX1opw_gsBs
And there isn't really just one thing that gets outdated on phones. You usually want a better screen, better camera, better CPU, more ram, new battery. And at that point why swap each one individually vs just buying a new phone. I guess you save on the metal case?
I can't help but notice that you don't mention the part that makes it a phone (e.g. the 2G/5G/Wifi modem chip). Maybe one should actually sell those as cartridges... Nevermind, that would be a PC-Card.
Normally we'd have the firmware loaded from elsewhere on system boot at the cost of a few hundred miliseconds, but for the current project we need a much larger firmware and the bootup time is prohibitive. So we've ended up with a three-way partition of functionality. A "standard library" of mature functions in ROM, an application-specific set of medium maturity functions in OTP (one time programmable) which can be changed without needing an expensive metal layer respin, and finally the actual application in RAM.
For my game Cubeat[0], I put an OPL3-L chip on the cartridge connected to the GB's otherwise unused audio-in pin, which allows for FM music in the game. For the MBC logic I just used a bunch of 7400 discrete logic chips. I'm hoping to finish this thing and get it published at some point since I think it's going to be a really cool little parlor trick for the GB.
CaliforniaKarl•6mo ago