Another suspected issue is dodging the draft during WW2 by pretending to be too old. In rural areas with shoddy record keeping you can get away with pretending to be your dead uncle.
The US (as well as other countries) has weird hangups because there's not a lot of granularity in prescription rules and insurance won't cover things unless they require a prescription.
So patients and doctors fight to have things continue to be restricted so that their workplace insurance will pay for it.
Does anyone have a video of it on an actual CRT TV? Looking at the youtube gameplay, it looks like it would have some problems with text on the overscan getting cropped.
I am curious how some of the effects look on a CRT.
I'll throw on some screenshots if there's any interest. I could actually use some feedback from someone who knows a bit about music, my knowledge is pretty minimal.
Its big weakness is that they didn't realize how much multilayered backgrounds made things pop.
The sprites look really good, but the single background layer makes things look flat compared to the SNES / Genesis. Devs started working around that by updating some of the background tiles on each frame or using some of the sprites.
The SNES also could do layer blending effects. So while all of the input data could only be 256 colours, the PPU was spitting out a high colour signal after the effects were applied.
CD drives were still expensive and a bit flakey at that point. It might have worked by packing in extra games.
Sega of America was just really good at understanding the US market.
Sega did a US launch (August 29, 1989) of the Genesis 9 months after the JP launch. They had EA releasing sports games on the console in 1990.
The TG-16 came out in 1987 in JP but they waited 1 year 10 months to do a US release, so it came out after the Genesis. They didn't get any US developers on board.
A 1988 release of the TG-16 combined with some decent sports games probably would have been a success.
It was actually a big success in Japan. NEC America completely botched everything in the US market.
In Japan it came out in 1987, two years before the Sega Genesis. In the US it launched a few weeks after the Genesis. The pack in game was based on an anime that didn't come out in the US.
It's big weakness was probably that putting button batteries on HuCards was awkward, so it didn't really have many longer slower paced games with save systems.
So for anyone looking into old school graphics programming, bit planes are pretty confusing when you don't understand why they exist.
Two big reasons. First, it's about running memory chips in parallel to increase bandwidth. Image data was hard to get to the screen fast enough with hardware in that era.
Second it allowed for simple backwards compatibility. Programs were used to writing directly to video memory, and in an EGA card the start of the video memory was valid CGA data. The rest of the colour data was in a separate bit plane.
Window management is one thing that MacOS has long been weirdly bad at.
I think there's a conflict between the users who use it on studio displays and users who use it on 13 inch laptops. The Mac team at apple won't pick a side or come up with two solutions.
That's not completely true, they've been pushing swipe between fullscreen apps for a while.
But that doesn't make any sense on an iMac.
So the recommendation from pro users is to use Alfred to manage windows.
The difference is that the server gives a description of the api it understands in enough detail that the llm can make use of it.
MCP is still going to be handy enough for iot type devices, where an llm can discover what's actually supported by that device without needing to query about the specific version.
Swagger / OpenAPI just aren't detailed enough to use without other documentation.
Skills & instructions will always have the limit that they run locally, so if they don't match the server there is a problem.
https://youtu.be/qn_1dwIxvs8
https://youtu.be/VgDA9iCbkow