Flashcarts don't work unless you devote the entire flash to a single ROM (some of them can do this). This is because the console snarfs the entire contents of the ROM into RAM first, rather than mapping the ROM directly into the CPU's memory space like the original consoles did. So the bank-switching tricks that flashcarts use to provide multiple ROM options on original hardware don't work on these. This is also why the 2600+'s pack-in multicart has a janky, DIP-switch solution to select a game.
Many large carts (8K and larger) also don't work, at least not without the firmware knowing how to bankswitch to read the whole ROM, so a fw update may be required.
> This is because the console snarfs the entire contents of the ROM into RAM first
The console itself should never know the cart is not a simple ROM with some bank-switching logic. Since Flash (or an SD card) isn't ROM, the ROM image will always be loaded into the cartridge RAM by the microcontroller software. There were many different strategies back then, so the ROM would need to have a file attached telling the on-cartridge microcontroller how bank switching worked on that title.
All you'd need is some UI to make it easier to switch between titles.
Most flashcarts have a UI that is shown on first boot; when a game is selected, the ROM for that game is loaded into the flashcart RAM, the appropriate bank switching or mapping logic emulated, the ROM banks remapped into the console address space replacing the UI code, and the console reset or told to jump to boot the game.
This doesn't work on the Atari 2600+ and 7800+ because those systems attempt to load the entire game ROM into their own RAM on boot and run the game from there. You might get the UI, but unlike in the actual hardware there is no rereading of the ROM directly. It's all done from what the system captured into RAM on first boot. So if a new game were to be loaded into that address space, the modern console wouldn't see it.
The boot menu uses some form of bank switching to get to the actual game ROMs and their specific switching strategy, if any. The 2600+ and 7800+ would need to know the method (a write to a specific address, perhaps) to get to the specific part of the ROM on a bank-switched game anyway.
I never tried that, so I might be very wrong in my assumptions.
In the case of the imaginary cartridge with the UI, changing the ROM that’s mapped to the cartridge space with the physical UI and resetting the console without resetting the card controller should do the trick.
The bank switching mechanisms in all commercially released games can be enumerated and emulated by the 2600+, but I think they just haven't gotten around to updating the firmware. Many bank-switched commercial games still don't work afaik.
Flashcarts are more of a crapshoot. They use unknown bank switching mechanisms and Atari does not want to support their use.
> In the case of the imaginary cartridge with the UI...
Not so imaginary! This is what the pack-in cart that comes with the 2600+ does, there are DIP switches for game selection on the cart itself. I don't know of any flashcarts that do even this, let alone something more sophisticated with buttons and an LCD readout like a Gotek drive emulator or something. Would be nice though...
This isn't the first time I've read a comment criticizing PDF, but it is the first time I can recall the Portable Document Format (PDF) being accused of low portability.
I'd call it low-portability. They're designed for large screens yet they're often viewed on phones where you need to manually zoom in and view each page some tiny portion at a time.
Was at a restaurant with a QR code that led to a PDF if their paper menu. It was horrible. For reference it was the Ralph Lauren Cafe in Omotesando Tokyo.
I'd prefer a static PDF I can pinch, zoom, and move about on my own than some crappy, overwrought, slow, "mobile" website that forces me to jump around to different sections of the menu with links that it *hides* anytime I scroll, which of course I have to because only 3 menu items are going to be able to fit on the screen at a time.
All that, VS a PDF that shows the entire menu that I can navigate spatially, show as much as I want depending on light levels, interest, and screen size, and can all fit in one, static tab.
Of course, the real answer is that electronic menus at sit down restaurants opened with QR codes are trash. Paper never really had these problems unless the restaurant was bad at menu design. I dislike being forced to use my phone at all when I'm out with friends or family for a nice dinner. Growing up, if I used my phone at the dinner table I would've been scolded.
PDFs were born to make real life documents manageable in digital form, that is, letter, legal, A4 etc; nothing that would (and could) have been used on a phone back then. If they don't display properly on a phone I'd say it's on the phone itself. They're not computers usability-wise, not even close: too many compromises with ergonomics, information density and readability fighting against each other in the name of portability. That restaurant had sloppy management/techies, as finding that the .pdf was the wrong size would probably take ten seconds to any of them, the correct the problem by having the QR point to a correctly sized .pdf generated automatically by reading the same db the bigger .pdf was created from. PC sees the link to the bigger one, phone reads the QR containing a link to the mobile one. not hard at all to solve, it's not a .pdf format fault.
Dynamically generating PDFs on the fly based on the user’s screen size sounds downright Kafkaesque. I feel a deep sense of dread any time I have to touch PDF-rendering code. Any halfway decent CMS (or just plain old HTML and CSS) can easily create a good-looking, responsive, accessible webpage with a fraction of the work. Leaning on PDFs in this case is a classic example of, “When all you have is a hammer, everything looks like a nail.”
The PDF format can’t necessarily be blamed for its inability to be responsive to screen size, but that’s one of several good reasons to discourage the use of PDFs for purely digital documents. Its design is linked to a specific historical context, and it should be limited to that context.
(Of course, I imagine the actual reason for the PDF is that it’s just an export of the InDesign/Photoshop/whatever file that was used to create the original paper menus. There probably is no “database.”)
> Any halfway decent CMS (or just plain old HTML and CSS) can easily create a good-looking, responsive, accessible webpage with a fraction of the work.
Easily? Because it's not a fraction of the work. Let's just assume you mean to use someone else's solution (of the literal thousands, each with their own quirks), to make your bespoke website.
PDFs have a standard. Libraries to resize are not difficult to find. Most people are able to run a PDF through their printer driver for a resize, because it's a solved problem.
I would say creating a job that outputs a bunch of PDFs is going to be easier than a build system for different devices (CMS or not), every time.
Sure, they can render at different resolutions, but I don’t think I’ve ever seen a PDF that has a responsive layout. A restaurant website is probably going to use some very user-friendly CMS like Squarespace that can absolutely provide you with easy responsive layouts.
A pdf should not reflow nor be responsive. Aside from zoom/pan, how else could you possibly interact? I think it works fantastic, like holding a magnifying glass and panning around a surface
When the PDF is a version of the paper menu, we can understand they only produced one version, and the alternative was no digital version at all (which is the case for an awful lot of restaurant)
If it's PDF or nothing, I'll be glad to take the PDF.
No one wants to carry a 10 tons rol of steel in a sports car. The majority of people getting a PDF on their phone though, do want to be able to read the information in it easily and they can't.
I don't know much about steel coils, and I'm hoping that something that fits in your back seat isn't as dangerous as those featured in YouTube videos, but the idea that the primary concern is just strapping the thing down is kinda funny
Shouldn't "portable" in the context of a document format mean "comfortably viewable on most systems" rather than "yeah you can view it but it's gonna suck and you'll get eye strain"?
I believe this is called "responsive design", a useful but differentiated concept.
It's pretty cool how PDFs don't typically load resources from an external website or CDN. They are self-contained, and thus demonstrably portable.
Gross analogy: Have you ever been to a multi-day music festival? A port-o-potty in the dark is disgusting, but still somewhat useable compared the alternative of going to the bathroom in public. PDF artifacts are in the same ballpark.
Also, I think I'd personally dislike a "portable document format" that doesn't look identical on all systems. By making it visually identical everywhere, you of course sacrifice comfort on smaller screens by nature. But to me that's an acceptable tradeoff for knowing I'm looking at the document, as it was intended to be displayed. I don't think of PDFs the way I think of websites. My physical papers don't reflow text.
A few people mentioned they miss his writing, so i thought it was worth pointing out he still writes occasionally: https://dvorak.substack.com/ though it's less technology focused..
The main argument of this article seems to fall into the counterfactual fallacy category. Even if MOND has problems and ends up being wrong, that doesn't make dark matter exist.
Excellent film, to me, it perfectly describes the relationship between the corporate media and politicians in the US. That being said, this film is 25+ years old, and while still very relevant (and great) it generally leaves me feeling apathetic.
One thing I don't get: he is measuring gamma rays, which will go through the wall of the Geiger tube as easily as they'll go through the front window. Why does it matter how the tube is oriented with respect to the source? Seems like the only factor that should affect the count rate is distance.
I recommend you do some basic research on the history of quarantine and the united states as well as colonial america. You'll quickly see your assertion stands on shaky ground. https://www.ushistory.org/laz/history/index.htm
