That design is badly missing some registers (D-type flip-flops) -- the whole "let's read/write multiple bytes and discard the first one because the ESP is not ready yet" seems like a super hacky solution.
A pair of something like 74574's would make this so much easier. When sending to ESP, register latches the last byte written and then ESP can read it at its leisure. When reading from ESP, ESP pre-loads the data into register, and then gameboy reads data from the register. This generates interrupt which ESP uses to load next byte into register.
Moreover, there might be a right logical series which will be compatible with both 3.3 and 5V busses. Then one could replace the level converters with register, keeping the overall complexity about the same.
That's the first thing that popped out to me reading this too, bit then ended up on 'there's a perfectly good SPI bus on the link cable". With it hooked up there, you can power the esp with its own battery, and switch out carts (or more likely roms on a flash cart) for the application you want to run. IRC and Gopher ROMs can just share a wifi module.
I'm not an expert, but I think a better solution would be to use a dual ported RAM that both the ESP and the Gameboy can access. The Gameboy has a dedicated memory area for cartridge RAM, A000 to BFFF.
I think gopher would be better, just by how much content is available on it and how stupid simple it is. But either option would be really flipping cool to see!
Gemini actually has more domains than Gopher these days, from the statistics I've seen. Maybe not more content, due to Gopher's history, it's hard to say.
So starting there will let you branch off to whatever you find interesting!
If you dig enough, there's content you won't find anywhere on the modern web too, especially from really old sites that are still being hosted from back in the heyday. The further you go, the more old stuff you'll find.
It feels like exploring ancient ruins that have been long abandoned.
What's unique about Gopher (at least to me,) is it goes a bit beyond just hosting content like how we see the modern web. There's a lot of history and culture around it.
The protocol itself is extremely interesting to dig into. It's simple enough you can use telnet or curl to browse (clunkily of course), but there were many attempts to extend it in crazy ways. For example:
How it started and became popular is very cool to look into as well.
Currently, the main content creators on gopher share a deep "counter-culture" attitude towards the modern web. You'll almost never find an ad, or junky blog posts that are nothing but fluff. No popups, no politics (like the EU banner thing), or even seeing a webpage being rendered as it loads.
It's all so simple the only thing you can host is pure content and links. And users/content creators take a lot of pride in that fact.
Anyways, apologies for the ramble. It's just a big passion of mine. Good luck on your first dive :)
"Malicious Activity Detected
You appear to be using software associated with or exhibiting bot-like activity. This is banned for security reasons. If this is a legitimate access, please E-mail gopher@floodgap.com with an explanation.
httpi/1.7.2 (nano_inetd_turbo/AIX) by Cameron Kaiser"
Please do send me the explanation. The proxy gets a lot of crap from bad bots (which in turn can make it burdensome on downstream sites) which requires controls, but the heuristics are just that, heuristic. If there's something to whitelist, I will.
FWIW, I got exactly the same message, and all I did was click the floodgap.com link in spicybright's post. Floodgap.com has never seen another request from me so I don't know what it could be detecting. I'm just using Microsoft Edge on Windows 10.
Very cool project, and impressive he got it working!
I feel like possibly a better way to deal with the communication though might be to put a dual-port RAM [e.g. 1] in-between the gameboy and the microcontroller, and load in a program to it so the Gameboy is just waiting for certain areas of memory to be updated (with flags that one side sets as 'new data' and then the gameboy flips). Basically some kind of circular buffer of commands, and as long as there's enough space in there and you only fill it from the microcontroller slower than the Gameboy can process them, you wouldn't need to have careful synchronisation. The microcontroller just has to check that the next slot in the circular buffer has had its status bit flipped to 'processed' (or hasn't been used yet) before putting the next command/data in.
It seems a little like cheating to put modern microcontrollers inside the cartridge that do all the heavy lifting. At what point are you basically just using the game boy's screen connected to a much more powerful external computer? It would be like me creating a new "SNES game" with a raspberry pi stuffed inside the cartridge with GPIOs mapped to the SNES cartridge interface and saying "there oughta be a full 3d SNES game" but at that point the SNES is doing very little processing compared to the pi's SoC which is doing 100% of the 3d rendering.
All that said, this project is still pretty sweet and I enjoyed the writeup.
I get what you're saying, but it's worth also mentioning that your full 3d SNES game example is pretty much exactly what games like Star Fox[0] did, back in the early 90's. The Super FX chip is inside the SNES cartridge. From the wikipedia page:
> The Super FX was so much more powerful than the SNES's standard processor that the development team joked that the SNES was just a box to hold the chip.
Really interesting to read about, but there was a whole selection of other chips that various SNES games took advantage of: [1]
And really, from its very launch the base SNES couldn't handle most of its library - even Pilotwings, a day 1 launch title, needed an extra chip to handle its enhanced mode 7 background effects.
The most interesting one being the SA-1 chip, imho. It's the exact same processor as in the SNES except clocked three times faster, 10.74MHz instead of 3.58MHz. This means you can hack games to have their original code run on the SA-1 instead of the original CPU. Which is exactly what Vitor Vitela did for numerous games to remove their massive slowdowns.
> It seems a little like cheating to put modern microcontrollers inside the cartridge that do all the heavy lifting.
As a sometimes hobbyist homebrewer, instinctively I am inclined to agree. But I'll argue the counter-case.
The Game Boy (and consoles like the NES and SNES) were intended to be expanded with additional hardware in the cartridge, from the beginning in anticipation of new technology. There were commercial GB games in Japan that included an infrared transceiver, for example. Same with vibrators and battery-backed save RAM and so on. While extra cartridge hardware was never more than marginal on the Game Boy, it was fairly prominent on the NES/Famicom and especially the SNES.
And it was used to make full 3D games for the SNES. Much of Star Fox is drawn with 3D polygons, and would have been impossible without a co-processor to do the 3D rendering. So it includes the Super FX chip on-board, which is a fast coprocessor with vector facilities. In some Super FX games, the console's baseline hardware was basically relegated to being a glorified framebuffer displaying the coprocessor's rendered output.
And in some cases, no amount of extra hardware will circumvent the limitations of the hardware, which makes it a legitimate programming and game design challenge, IMO. You just can't display a full-screen bitmap on a Game Boy without tricks. There simply isn't enough onboard video RAM to hold a distinct 8x8 tile for every tile on screen. No coprocessor will work around that. It might give you an infinite source of tiles rendering a 3D scene for example, but you still have to shuffle them in and out of VRAM, which is a major bottleneck for complex Game Boy designs aiming for full screen and full framerate effects.
Actually you can display one full screen bitmap. Vram can hold 384 tiles, and the screen needs 360 tiles. It's gonna be difficult to update that, since there's no more vram for double buffering, you can only access vram during vblank and hblank, and there's no dma into vram (on the gbc it's possible, since it has a dma and double the vram).
The SNES example may be working against you here, since there were lots of commercially-released SNES games that included coprocessors in the cartridge to do heavy lifting the console wasn't otherwise capable of. At least one of those games actually used an ARM processor in the cartridge.
"I thought using loops was cheating, so I programmed my own using samples. I then thought using samples was cheating, so I recorded real drums. I then thought that programming it was cheating, so I learned to play drums for real. I then thought using bought drums was cheating, so I learned to make my own. I then thought using pre-made skins was cheating, so I killed a goat and skinned it. I then thought that that was cheating too, so I grew my own goat from a baby goat. I also think that is cheating, but I’m not sure where to go from here. I haven’t made any music lately, what with the goat farming and all."
That's pretty common for cartridge based games. Want your gameboy to support RTC? Add an RTC chip on the cartridge. Need more RAM or persistent memory? Slap more in the cartridge. This is no different.
I think the general vibe from the OP comment is that a lot of the fun with low spec and retro hardware is working with restrictions and squeezing new and novel amounts of use out of old hardware. But once you get to the stage of putting a much much more powerful computer in the cartridge, you come to the realization that you can do basically anything at this point and treat the gameboy as a dumb display/input device. Now it's just regular embedded programming.
Not to detract from the project, it is very cool. But the excitement kinda feels dwindled when you realize that you now have limitless power and ability. It becomes just regular programming rather than a puzzle.
For some perspective, even the oldest network enabled addons sold for the GB/GBC did the same exact thing (such as the official Mobile Game Boy Adapter). It's more like, without doing it this way, it's not even possible.
I don't see the complaint as "it's wrong to use powerful chips in a cartridge". As has been pointed out, even contemporary cartridges did things like that.
I see the 'complaint' is that there's a creative/artistic appeal to seeing what can be squeezed out with limited/constrained resources.
Or, at worst, does it make sense to use an old console like the Game Boy if you're going to use such a fancy cartridge?
I'm reminded of the MythBusters episode where they tried to make a cannon from a wooden log. They resorted to using modern power tools. "I'm not doing anything they wouldn't have done if they had access to these tools!".
You have protocol offload engines on modern NICs, what's wrong with basically a "Wifi Offload Engine"?
> It would be like me creating a new "SNES game" with a raspberry pi stuffed inside the cartridge with GPIOs mapped to the SNES cartridge interface and saying "there oughta be a full 3d SNES game" but at that point the SNES is doing very little processing compared to the pi's SoC which is doing 100% of the 3d rendering.
And that's the point of these esp modules in the first place. They were originally intended as sdio wifi modules to give plug and play wifi support to various embedded systems.
The programmablity wasn't the initial selling point. They were very much designed originally to be a shrink wrap addon to another embedded system.
Most little single purpose ucontroller based products not made by Broadcom have an SDK for writing code for the device too, it just normally doesn't go anywhere. Espressif just sort of won the lottery and an ecosystem formed around them, but that wasn't their initial market as it would be foolish to bet the company on that.
I didn't say they were sold as programmable/hackable. They were used in many simple smart devices like bulbs and power controllers already without any other microcontrollers. It was pretty obvious that it was doing all the work.
Use cases where they are the only processor (and thus necessitate use case specific programmablity like you're saying) came later. That wasn't the intially planned market.
It came before they were hackable. I have been following it for years. It was fun seeing cheap Chinese smart devices being exposed and each WiFi enabled one would have an ESP8266 and only it aside from some SMD capacitors and resistors. I’m not saying they were sold as hackable. I’m saying they were deciphered easily as the only microcontroller required for the smart devices.
I'm including Chinese system integrators here, they just figured out that these devices were hackable prior to the western maker community. I have it under good authority that those weren't espressif's original target market either.
Not surprised, there’s some very capable chips that aren’t fully utilized, I think a lot of smart watches have a certain Nordic chip too. Know of any more ESP like chips?
A ucontroller with way more compute and peripherals than it need for it's task, with either no or shoddy encryption on it's flash allowing you to write your own code or binary patch the existing code with a little elbow grease? That's most microcontrollers out there with the exception of chips by Broadcom (no flash and the patch RAM is already basically full fixing bugs in their crappy code ROM) or Nordic (because of the ubiquitous use of per device encrypted flash). Specific devices I've worked on in that capacity though are all tied up in NDAs with my employers though.
But what makes ESPs special is the community. Because of all of the public work put into them, it's an order of magnitude easier to manipulate them than pouring over a disassembly. You'd know about tchips like that if they existed. Bunnie tried to get that kind of community around the MT6260 chips, but it didn't really go anywhere.
Thank you. I think these hacks will be seen as a historical curiosity with an influx of RISC-V chips that will be more open, ExpressIf is moving to it and hackable IoT chips are utilizing them more too.
I think it could go either way. I get where you're coming from, but think it's equally likely that it'll go in the opposite direction. The underlying economic reasons behind why the internals of these chips aren't publicly exposed have a good chance of being exasperated by the in progress democratization of fabless chip design. More chips will be designed to fill a specific niche and not be publicly documented; that's because public documentation is a huge schlep that's not work towards their niche or value add. Yeah there'll be more RISC-V but most cores today are something supported by GCC as it is; that's not the impediment to understanding the chip, but instead everything custom around the CPU core is. And the openness of RISC-V could lead to fragmentation (but we have yet to see that, and I'll admit that's mainly an ARM propaganda talking point at the moment).
Good points. They’re entitled to their research and development not being cloned. I think that fracturing is likely with RISC-V in the short term but a natural hegemony will form under some protocols, hopefully they don’t suck and can scale.
The first esp modules were originally marketed and sold as simple serial ttl-to-wifi bridges, but it didn't take hardware hackers long to discover they were hiding a lot functionality underneath. It took some doing but eventually espressif opened up their toolchain and _that's_ when they became "powerful adruino with wifi."
They still are simple ttl-to-wifi bridges aren't they? They just had more processing power, it needed to be stronger than an arduino to run a web server and control with wifi. I don't think it was hidden as much as underutilized, like the linksys routers.
I agree with you, but understand the critique others used. The problem is standardization, if you need special hardware to do things you get fragmentation. For the people who rely on the other cartridges, those games are all standardized. The SNES had optional networking https://en.wikipedia.org/wiki/Satellaview, and the PS2 also had an optional expansion bay https://en.wikipedia.org/wiki/PlayStation_2_Expansion_Bay that would limit all games from utilizing it, and also as a requirement it would prevent much adaption.
Whats the point of developing on a device that needs lots of other parts that most people won't have? Its like selling a game system with no controllers and each controller can be used for only a few games (like eyefi).
This is why I don't bother with seeing m.2 SSDs enhancing online gameplay for faster loading. You always wait for the weakest and slowest loading game and network to start.
To be pedantic, the Famicom had audio bypass, but the NES really didn't (unless you hack around with the expansion connector, which wasn't used for anything Nintendo approved in the US)
Yeah, the cartridge pinout is slightly different. The famicom has a 60 pin connector and the NES has a 72 pin connector, but ten pins go to the expansion port and four pins are used for the license chip, so two pins were lost, and those two pins were the audio out/in. Castlevania (and some other games) has significantly different audio for Japan vs the rest of the world.
There's a few different ways that people modify their NES if they want to use cartridges with audio hardware, using the (otherwise unused) expansion port pins.
Yeah I've seen some youtube vid about famicon audio chips and it was insanely high fidelity for a tiny video game console. Must be weird to play such games as a kid back in the days.
Many people here are mentioning the SNES, but actually, outside of classic SNES games like Star Fox, Stunt Race FX, and Yoshi's Island using co-processor chips, SEGA also produced what they called the SVP chip for Virtua Racing on the Genesis.
Then we got the SEGA 32x - which was literally dumping a giant chain of extra chips onto the Genesis in order to do things like primitive 3D and scaling.
Beyond the SNES as well, the NES also had a habit of packing in small bits of extra hardware on their carts.
Mode 7 is a feature of the SNES's basic video hardware, not a cartridge add on.
Most cartridges are just ROM, perhaps some battery backed RAM, and if needed some bank switching / address decoding logic to glue things together. Nothing particularly smart. Certainly no extra processors running the show. All the smarts was in the console.
There are exceptions, like the SNES games with coprocessors, but not all of them are full CPUs, and even then there are 1500+ SNES titles in total, and less than 100 with extra chips in them[1]. The mapper chips in NES games often did a bit more than just bank switching, but they weren't in control either.
Cue someone mentioning the MB Microvision...
[1] Based on Wikipedia, and I hope I roughly counted the number of entries in the coprocessor game table correctly.
Mode 7 wasn't a cartridge feature, it was a background layer that could be rotated and scaled in the SNES hardware. You may be thinking of the FX chip (mentioned by others in this thread).
If you want to take that cheating to the logical extreme, check out this project made by a friend. It's explicit in the title that it's just streaming, but pretty fun nonetheless!
My favorite example of an expansion chip is a 32-bit ARM V7 at 21.47 MHz on a cartridge for SNES, which itself had a 16-bit CPU that is an enhancement of 6502, at nominal 3.58 MHz. All for a game of shogi, a Japanese variant of chess: https://twitter.com/Foone/status/1177652135841779713
Gonna pile on the bandwagon here and add, it shouldn't be a "central computer" that has all the cool shit and you attach peripherals to it. We should be merging equally powerful computers together, it should be a symbiotic relationship between different parts that get better over time. Two computers are better than one
Yes, it's a completely logical thing to do. It just makes the project a little mundane and back to the practical computing of the real world. With a modern microcontroller you can do anything you want without limits. The gameboy becomes mostly irrelevant.
It seems like everyone in tech does this. Someone has a mind blowing feat of engineering, but leave out the part where they cheated and arguably lied about it because "it's just some minor detail that doesn't really matter"... For some reason they think these are bragging points that put them above all other engineers.
"I built a calculator completely from scratch by myself with no help" (by importing calculator.*)
"I invented my own cloud microservice in a language I wrote completely myself" (It's hello world split in 2 files on google drive and the language is just JavaScript but it you added a "framework" (it's single method) that already exists in the wild but your version is slower and worse)
"I built my own computer" (by buying a prebuilt computer but swapping out the ram, or buying an essentially prebuilt computer but it comes disassembled)
I’m a billionaire with 22in, my dinner with Bezos went well, I had to ignore 22 messages from hot models wanting to fuck to post this, I could have been working for 12k an hour but I decided your post was worth replying to even though satellite Internet costs on my huge yacht costs a lot more than you make in a day.
I’m going to fly on my private jet now, feel free to contact me about how you can invest and fall for my crypto margin trading that ends badly for you.
There are some similar efforts to add WiFi to old 8-bit computers.
The TRS-IO is pretty neat. It bridges the wifi to an IO bus, and provides both a "retro app store" program and a way to make samba shares look like local drives.
I know this isn't a humor website, but I'm seriously tempted to post the "but why?" meme. My personal mantra is that everything worth doing is difficult, but I've always had the perspective that this is not a symetric relationship.
This was certainly difficult for him to do, and the engineering aspects of it are "cool", but this doesn't solve an actual problem. With the same amount of effort he could have written new/better drivers for a raspberry-pi peripheral, or contributed to one of the open source OS projects in a meaningful way. Hell, if this he did this just for fun, then this is definitely the kind of guy who burns out well before they turn 40.
Efforts like this shouldn't be applauded or critically reviewed with advice to make it better, they should be discouraged. This kind of project is not merely a waste of time, if it were I would have no valid complaint to make. It is a waste of time that burns out a highly capable person, and too many people in the tech community are ready to applaud the effort.
It's a very weird opinion. In this way : good writers loose their time by writing good books while they would better write good documentations and advertisements for tech products, good political leader would better lead tech companies instead of taking care of the people every day life, and so on. I personally think the world would be far better if everybody was able to deploy such skills and talent in everyday life instead of giving all their full potential to private companies.
This would be great. Playing unmodified multiplayer games w/ others locally wirelessly and, if latency allowed, over a network, would be a ton of fun. It would also allow for some players to be on physical hardware vs. emulators.
Oh, I didn't think about that. It'd probably take some interpretation of the individual game protocols to get over the hump of the latency, but probably doable.
I wonder if he talked with the developer of Super Tilt Bro whom is doing a Smash Bros clone for the NES that includes online gaming through a WIFI chip in the cartridge.
All The Woulda-Coulda-Shouldas
Layin' In The Sun,
Talkin' 'Bout The Things
They Woulda-Coulda-Shoulda Done...
But All Those Woulda-Coulda-Shouldas
All Ran Away And Hid
From One Little Did.
-Shel Silverstein
That being said, the way I would have done it is...
A pair of something like 74574's would make this so much easier. When sending to ESP, register latches the last byte written and then ESP can read it at its leisure. When reading from ESP, ESP pre-loads the data into register, and then gameboy reads data from the register. This generates interrupt which ESP uses to load next byte into register.
Moreover, there might be a right logical series which will be compatible with both 3.3 and 5V busses. Then one could replace the level converters with register, keeping the overall complexity about the same.