> TI’s TXB0108 for this purpose as well, which has an automatic direction sensing feature that obviates the need for all of the direction logic that I mentioned above.
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.
These parts are bonkers. The ringing on its own outputs with a few inches of trace or (heaven forbid) a connector is regularly sufficient to self-trigger the automatic direction reversal. These things genuinely deserve the "experts only" label - they are close to unusable in the situations where you'd be most inclined to reach for them.
I've had them oscillate, though I don't remember the exact conditions, but they'd switch directions at very high speed, causing noise, causing them to oscillate.
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.
Cool, I wish this article was available when I made my custom cartridge design :)
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.
I assume they mean you don't need to modify the device's hardware or hack any software – you just need to include a blob in your ROM's header (which RGBFIX will automatically insert for you, if you're using the RGBDS toolchain).
Plus, Sega v. Accolade killed that practice. I don't think anyone has tried to enforce it since.
Pretty cool idea to ship ram and disk space with the application. It makes a lot of sense when you think about it. Imagine if phones worked like that and you could buy a new cartridge every couple years when chip technology improves or if you want to run some hard-core application. Or if you want to attach a new type antenna. My mind is wandering now.
Modular phones have been proposed for ages now but seem not viable or useful. Having everything on sockets increases latency between chips and decreases reliability. Especially something that's getting banged around in your pocket all day.
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?
> 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.
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.
It's more like a separation between backend and fronend. All the hidden tech goes in the cartridge and your screen and touch inputs are your frontend. Most people like their UIs to stay consistent even when new stronger, faster technology comes around so idk man.
Sitting here at work negotiating on an increasingly complicated hotpatching system for microcontroller ROMs, I can totally see why it fell out of favor. It is a great help to have the whole application on chip ready to go, but people keep wanting to change things.
Full custom. That is, not only is it our own DSP architechture and own instruction set, but the firmware running on it.
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.
I think its a good idea too, however does there come a point there you're also limited by the hardware it is plugging into? You might be able to include faster RAM in the cartridge, but will it work as intended with the original board its being plugged into.
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.
You can do pretty much anything if the cartridge is advanced enough. At that point you just output a framebuffer from the cartridge the screen should show with no computation happening on the actual gameboy CPU.
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
My Pokemon blue version went through the washer and dryer probably 20 years ago and it still works to this day. Talk about some hardware. I wonder if an SD card would take that sort of abuse.
I have an xBox series X, a 32" 4K monitor, an HP EliteDesk SFF PC/homelab/media server and all the assorted gubbins to make everything work, that survived a 15h international flight with one layover packed in my checked luggage.
Strategically placed underwear and socks can do wonders to protect things.
I just started learning KiCad and PCB design this month as a larf, and I was wondering if anyone has tried making a full original Gameboy PCB and open sourcing it?
Very cool. He could have probably skipped that voltage conversion.. it’s a very persistent myth across repros on retro gaming. Most of those 3.3V components will run happily at 5V
"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]"
> TI’s TXB0108 for this purpose as well, which has an automatic direction sensing feature that obviates the need for all of the direction logic that I mentioned above.
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.
These parts are bonkers. The ringing on its own outputs with a few inches of trace or (heaven forbid) a connector is regularly sufficient to self-trigger the automatic direction reversal. These things genuinely deserve the "experts only" label - they are close to unusable in the situations where you'd be most inclined to reach for them.
I've had them oscillate, though I don't remember the exact conditions, but they'd switch directions at very high speed, causing noise, causing them to oscillate.
Bunch of pulldown restrictions too, though if you pulled both ends the same way when not driven, that usually worked ok
Also (because I feel like it/am procrastinating on other stuff), some first-glance review on the design at https://git.sr.ht/~aparrish/abc-pcb/tree/main/docs/abc-pcb.p... :
- 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.
Cool, I wish this article was available when I made my custom cartridge design :)
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.
[0] https://nickfa.ro/wiki/Cubeat
I was sad to see that one of my old favorite GB dev resources is gone: https://web.archive.org/web/20150410063839/http://www.devrs....
Most of the links were already long-long-dead, but there were some cool inspirational projects on there.
> You don’t need to circumvent copy protection or region lockout hardware to write custom software for the Game Boy, since the Game Boy has none.
While there's no region lockout, don't you need to pass the logo check?
I assume they mean you don't need to modify the device's hardware or hack any software – you just need to include a blob in your ROM's header (which RGBFIX will automatically insert for you, if you're using the RGBDS toolchain).
Plus, Sega v. Accolade killed that practice. I don't think anyone has tried to enforce it since.
False, this is exactly as much as I wanted to know about how Game Boy cartridges work. Thank you! :)
Stole my comment!
Pretty cool idea to ship ram and disk space with the application. It makes a lot of sense when you think about it. Imagine if phones worked like that and you could buy a new cartridge every couple years when chip technology improves or if you want to run some hard-core application. Or if you want to attach a new type antenna. My mind is wandering now.
Modular phones have been proposed for ages now but seem not viable or useful. Having everything on sockets increases latency between chips and decreases reliability. Especially something that's getting banged around in your pocket all day.
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?
> 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.
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.
It's more like a separation between backend and fronend. All the hidden tech goes in the cartridge and your screen and touch inputs are your frontend. Most people like their UIs to stay consistent even when new stronger, faster technology comes around so idk man.
Sitting here at work negotiating on an increasingly complicated hotpatching system for microcontroller ROMs, I can totally see why it fell out of favor. It is a great help to have the whole application on chip ready to go, but people keep wanting to change things.
What sort of microcontrollers? Could it just be the interface is not yet mature?
Full custom. That is, not only is it our own DSP architechture and own instruction set, but the firmware running on it.
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.
I think its a good idea too, however does there come a point there you're also limited by the hardware it is plugging into? You might be able to include faster RAM in the cartridge, but will it work as intended with the original board its being plugged into.
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.
You can do pretty much anything if the cartridge is advanced enough. At that point you just output a framebuffer from the cartridge the screen should show with no computation happening on the actual gameboy CPU.
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
Or even a camera
For real! I imagine you could do some really cool shit with something like that. Like massive lenses or purpose build rendering chips.
My Pokemon blue version went through the washer and dryer probably 20 years ago and it still works to this day. Talk about some hardware. I wonder if an SD card would take that sort of abuse.
I suspect the heat of the dryer would be more of a problem than the water.
I've washed SD cards, cf cards and memory sticks and they all still work.
Keyboards can also survive dishwashing with gentle soap. So can motherboards
I have a working(!) motherboard that survived an international flight in checked luggage, wrapped in nothing more than cotton t-shirts.
I don't advise it, but tech can take quite some abuse.
I have an xBox series X, a 32" 4K monitor, an HP EliteDesk SFF PC/homelab/media server and all the assorted gubbins to make everything work, that survived a 15h international flight with one layover packed in my checked luggage.
Strategically placed underwear and socks can do wonders to protect things.
In that case I'd be worried about header pins getting bent
That's nothing. I've shipped electronics to space, to fly through the Van Allen belts to be showered by protons and electrons ;)
I just started learning KiCad and PCB design this month as a larf, and I was wondering if anyone has tried making a full original Gameboy PCB and open sourcing it?
FunnyPlaying has done their own version of the GBC and GBA PCBs you can buy. I don't know of any open source versions.
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.
any good resources for PCB design?
Youtube videos, lol. Almost finished with my first PCB... Won't know if I learned anything until I get it flashed then running off battery power
See also the Ultimate Game Boy Talk from 33c3: https://www.youtube.com/watch?v=HyzD8pNlpwI
I find this really fascinating, thanks for sharing!
Very cool. He could have probably skipped that voltage conversion.. it’s a very persistent myth across repros on retro gaming. Most of those 3.3V components will run happily at 5V
*she
Congrats, Nice work!
.. Now go build and sell some nice IOT gadgets that do not track users, and become a millionaire. Like a simple water leak detector.
There are already plenty of those, and they're super cheap too.
Do you know of any fully open source matter/thread hardware?
Doesn't Matter require proprietary certification?
Certification, yes, but it's an open standard.
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]"
I don't, I use Zigbee for everything.