MAME is now emulating LCD handheld games, which is weird and kind of amazing. The sort of games that had little light-up chunks of the "moving" portions on top of a printed background, like an old digital watch. Here's a thread describing the extraction process:The first step is identification. They're usually microcontrollers, but can someitmes (rarely, even) be pure state machines in the form of an ASIC. This does happen, though, and if they're not an MCU, it makes it a lot harder to emulate.
To identify the MCU, the circuit board (which is usually simple, with just a handful of passive components other than the chip itself) is traced out, and "Sean Riddle" of the Bannister forums tries to match the pinout against any known pinouts.
In the event that it matches an MCU model for which there's a known method for dumping the internal ROM, Sean breaks out one of several test jigs and pulls out the data, then wires up the LCD and photographs the segments to be vectorized.
Since the chips themselves usually have all identifying markings scrubbed, this is about the only way to do it in a safe manner. It also assumes the chip is in a normal plastic or ceramic package. If it's unidentifiable or is "globbed" with an epoxy dot, the real fun begins!
In that case, the chip is removed from the board in any way possible, and the whole shebang is dissolved in fuming nitric acid until the silicon die itself is exposed. The silicon die is then cleaned in Whink and put under a microscope.
Multiple photos are taken of the exposed die, then stitched together. At this point, it would be a good time for a small digression about "mask programmed" versus "electrically programmed" silicon chips.
Hand-waving away certain details, the vast majority of modern chips are electrically programmed. The chip starts out blank, and has its program uploaded at the time of manufacturing, usually via pogo pins against the wafer itself, or a custom jig after the chip is packaged.
But, for chips that are going to have a lot of them made, this step costs too much time and money. In these cases, the ROM bits are literally a part of the photolithographic mask used to manufacture the silicon chip itself. So yes, bits in this case are actual physical objects.
The bright side to this is twofold: First, after photographing, the bits can be pulled out of the images however. Computer vision, some unfortunate fellow sitting and manually plugging 0/1 into an editor, whatever method results in the least number of errors.
Second, and most importantly, it means that the actual ROM bits are usually the absolute last thing to break. So, in the event that you have a partly-functioning or non-functioning LCD handheld that you'd like to see dumped, take heart and send me a DM! :-)
He's looking for donations to help him buy a big auction of old handhelds to de-cap and extract.
I understand that MAME can also emulate Pong now, and I'm not even really sure what that means, because Pong was arguably not a computer. It didn't have "code". It didn't have a CPU. It was wire-wrapped out of discrete analog components: a state machine and signal generator made out of relays as big as your thumbnail.
Previously, previously, previously, previously, previously, previously, previously, previously, previously, previously, previously, previously, previously, previously, previously, previously, previously.
Testing a hypothesis about the site cache
So yeah, comments do re-write the individual post's file in the cache, including the "Recent Posts" sidebar.
What surprised me is that it seems to rewrite several other pages' caches as well, which might explain why the comment seemed to take so long to post.
Something like https://www.jwz.org/blog/2017/12/this-is-fine-2/ didn't get the Recent Posts updated, though, possibly because its comment section is locked down.
Hmm, no, I'm wrong—the post at https://www.jwz.org/blog/2017/12/this-is-fine-2/ seems to update its Recent Posts as well, but not in all browsers for me.
Ohhh. Maybe it's that because I'm "logged in" now and sending cookie headers, I'm getting fresh content each time, but anonymous browsers are getting heavily-cached content. Not sure.
I think WP Super Cache bypasses the cache if you are logged in, or if the URL has query args. I don't know if you are "logged in" or if only I am, as the admin.
Good point! It does seem like just getting an I-have-commented cookie is enough to bust the cache; I had read the description of the plugin and forgotten it:
The interesting thing about the very old posts I'm seeing in an incognito browser is that they all seem to have "Recent Posts" as of more than 24 hours ago. I noticed that your site returns a
Cache-Control: max-age=14400header, and I wondered if the plugin might be using that 4-hour value for caching, but it looks like it's doing 24 hours instead, maybe?24 hours doesn't match any of the settings you mentioned previously, though.
Two decent workarounds, though: Incognito browser / clear cookies, or just leave a comment on a page.
Looks like I'm wrong about 24 hours; I had visited https://www.jwz.org/blog/2017/12/this-is-fine-2/ at
Fri Dec 22 13:23:48 PST 2017and got the same shasum I'm getting now, so it's something less than 24 hours. I'll keep an eye on it and see if I can discern what the cache timeout is.My hope is that if I can determine what the cache timeout is, I can figure out which setting needs tweaking.
...I think I meant "more than 24 hours" in that last comment. This is what I get for troubleshooting caching while fighting a cold.
tl;dr: I think there's probably something wrong with the scheduled garbage collection. Either wp-cron isn't triggering the garbage collection, or the garbage collection is broken; the next steps to troubleshoot the problem are probably to confirm that all the necessary Apache modules are installed, and then check whether wp-cron is triggering successfully.
Long, poorly-edited version:
I realized it's better to look at the timestamp on the top item under "Recent Comments" showing up at an older page like https://www.jwz.org/blog/2017/12/this-is-fine-2/ — it currently shows this comment from 8:47am PST. The next comment after that was at 11:57 am, so the cached version of this-is-fine-2 was created sometime before that, and is still cached now. My guess is that you cleared out the cache this morning after folks had commented on the cache problem, and possibly did a preload that caused all old posts to get recached with the same sidebar.
Reading through the documentation, the settings jwz mentioned here seem correct to me. "Cache Timeout" has the same name in the documentation, while "Timer" seems to refer to the "Scheduler" feature mentioned in the documentation.
The documentation mentions problems with wp-cron, referencing this blogpost, which suggests an
/etc/hostsupdate would be required to get it working. I guess it does some sort of API call to the blog itself in order to run?The other bit in the documentation that sounds similar to the behavior we're seeing is this:
This only seems relevant if wp-super-cache is configured to use the "Expert" option described in the documentation, but I'm not 100% certain of that.
The Developers documentation has a couple options that bypass wp-cron, if that's attractive at all (spoiler alert: it's probably not attractive):
Note that this just performs the cache cleanup on each request; if there are no files to be cleaned up, presumably it would run fairly quickly. Given how much history this blog has, though, it'd probably be sluggish under load.
Alternatively:
...I was thinking that new blogposts (or comments) could trigger the cache clear, but that's probably too much effort and too much risk of breaking something else that's more vital.
I think that's all the troubleshooting I can do from my end without seeing the admin interface or server filesystem. I'll try to check in again tomorrow to see if my incognito tabs have updated their cache at all, but at this point I suspect the problem is in the garbage collection, and only your manually clearing the cache works for cookie-free visitors.
Looks like the cached pages got updated overnight, so some process is getting them updated. There are different timestamps on each of the cached pages I found, so either they didn't all update at the same time, suggesting garbage collection is working as intended, or else some sort of site-wide preload was run that just took a while to complete, and a comment happened during that period.
The sampling of pages I checked, along with the timestamps I found on the top Recent Comment, include:
1) https://www.jwz.org/blog/2015/ 9 hours ago at 5:21 pm (so around 2am)
2) https://www.jwz.org/blog/2011/ 14 hours ago at 11:57 am (also near 2am)
3) https://www.jwz.org/blog/2017/12/this-is-fine-2/ 1 hour ago at 12:55 am (near 2am again)
I have no idea why there'd be such variability in the cached Recent Comments, but at least the timestamps all seem to be around the same time, suggesting a preload triggering of some kind.
Well I wanted to see if wp-cron was running at all so I added this to my theme's functions.php, and nothing is showing up in my error log, so that's weird:
So now I'm loading "https://www.jwz.org/blog/wp-cron.php?doing_wp_cron" once a minute from real-cron, and I'm still not seeing a message in my error_log.
Beats me if wp-cron is functional, or how to tell.
I got all excited, thinking I'd triggered a cache update by hitting https://www.jwz.org/blog/wp-cron.php?doing_wp_cron, but it turns out you'd posted something new around the same time. It's kinda looking like some page that you visit is triggering the cache updates, or else you're manually clearing out the cache, perhaps?
Regarding monitoring wp-cron, the wp-super-cache readme.txt suggests that you use the cron-view plugin:
Trigger failures in wp-cron seem the likely source of the problem, though I wonder if Apache caching might confound the site's behavior. Have you ruled that out yet?
Looks like https://wordpress.org/plugins/wp-crontrol/ is better-supported than Cron View when it comes to wp-cron admin plugins.
Huh. After installing WP Crontrol, it looks like the "my_schedule_hook" thing I tried got scheduled a thousand times and then never actually ran. So that's weird. I deleted them manually.
But it looks like wp_cache_gc_cron() is in fact running about once a minute, and wp_cache_gc_watcher() is running about once an hour. At least, the "Next Run" column keeps updating.
I've never done anything to clear the cache manually. I don't have any Apache-level caching turned on (except in that WP Super Cache works by using mod_rewrite.)
Okay cool, sounds like wp-cron is working okay, so it's either a weird config option somewhere in WordPress preventing deletions, or something weird in Apache.
I'm assuming you're using the "Expert" option listed at https://wordpress.org/plugins/wp-super-cache/, wherein Apache just serves files off of disk via mod_rewrite.
I'm also assuming that you've confirmed that mod_mime, mod_headers and mod_expires are all installed as recommended at that link.
Assuming all three of those modules are active, the next thing I'd take a look at is the cache files on disk.
(If this were my own site, I'd probably just set up a cron to delete any files in the cache directory older than a certain age, but that might be more hacky than you'd like to try.)
If the files on disk aren't getting deleted, then it would seem the problem is with the deletion mechanism, and it's probably something in the WordPress configuration. If the cache files are getting deleted regularly, then I would try to blame Apache, but it looks like mod_rewrite is just serving up the files, so I am highly suspicious that the files are actually being deleted.
Since you're not manually clearing the cache, it appears there's a page you visit that clears the cache. I've been tracking the content on this-is-fine-2 and it seems to update right before you comment or post to the blog. (I assume it's before because the page often won't have the very last blogpost, so the cache refresh seems to happen before then.) I saw a cache update between
Sat Dec 23 18:38:12 PST 2017andSat Dec 23 21:57:13 PST 2017, and an update betweenSun Dec 24 11:37:15 PST 2017andSun Dec 24 11:57:18 PST 2017— weirdly, that second update includes a comment that's timestamped with "18 seconds ago at 12:39 pm", which is actually after when I saw the timestamp update.(If this ends up being a timezone configuration issue, I will laugh and laugh and laugh and cry.)
Since my last comment shows a timestamp of "3 seconds ago at 4:14 pm", which matches when I posted it in PST, it doesn't seem like a timezone issue.
I looked into the disparity in timestamps that I mentioned, and it appears the method I'm using for checking the shasum of this-is-fine-2 gets a different cache result than I get when I hit it in my incognito web browser, and the shasum version has a comment timestamped as "15 minutes ago at 10:58 am", which makes sense for that cache hit. Looks like the difference in content is due to
Accept-Encoding:gzip, so Apache's probably storing gzipped and uncompressed versions of the file separately.Unrelated, while I was checking request headers, I noticed Chrome complaining about the SSL certificate:
Oh hey, is "Preload Mode" enabled in the wp-super-cache settings? This sounds very similar to the behavior we're seeing:
Preload Mode was on. I just turned it off. Maybe that was the problem? I'm not entirely clear on what it was intending to do.
Kinda seems like that fixed things? Commenting to confirm.
Nice, yeah, that seems to've fixed it. Thank you!
From what I can tell, Preload Mode is a feature you can enable to pre-cache your entire site. It's probably useful for sites that have a lot of pages before the plugin is installed, but few enough visits that pages won't be cached very frequently.
For a site like yours that gets a lot of hits, but also has frequently-updating sidebars, it's not very useful except to turn on overly-aggressive caching. If you were CPU constrained on your server, it might be worth enabling, but it doesn't seem like you are.
Thanks for sticking with me through this; it probably would've bugged me if we'd never found a fix.
Well, I have a lot of pages and I'm CPU-constrained, in that things go badly if I have to render the same page hundreds of times a minute... so I guess I still don't see the use case of Preload. But whatever.
Thanks for figuring this out!
So now you should be seeing 60-90 sec latency on pages updating, worst case?
And I guess if you are seeing better latency than that when not logged in, then that means I'm re-rendering pages more frequently than I'd like.
Yeah, I was just wondering myself if there's maybe a use case where you'd want to re-enable Preload Mode, and I can think of situations (that I won't describe here) where you'd want to turn it back on to keep the site running under heavy load. Most of the time, though, I think you could just adjust the Cache Timeout value higher so that cached copies are retained longer, and that would work fine.
Since your Apache is returning
Cache-Control: max-age=14400, I'm occasionally seeing some more-than-90-second caching, but when I ignore the Cache-Control header I am indeed seeing roughly 60-90 seconds of cache persistence currently with cookie-free requests. It seems to be working as intended now!Huh. Deletion of that "I commented" cookie could be my main culprit. I have a cookies-get-killed policy that flushes them 60 sec after I "leave" a domain. That means my "I commented" cookie goes away and, magically, aggressive caching reappears on my next visit. That makes sense.
jwz.org is now white listed to prevent this over-cache-behavior.
Wow, the Magnavox Odyssey was amazing -- discrete analogue and modular. Maybe MAME will have to include SPICE eventually!
However, from what I can make out, Atari Pong (inspired by the Odyssey and apparently by a PDP-1 game) was built from digital components: 74-series logic, so they "merely" need a digital simulator, unless there was fancy stuff in the analogue bits.
Well, we have a rather good dual digital/analog simulator. The pong driver is essentially a description of all the components and wiring. The real one, because schematics are always wrong..,
Oh very good -- I was just looking at the project Github and see you already have lots of 74-series logic simulated at bit level. There must be many interesting shortcuts you can take in the analogue simulation compared to SPICE.
I know this is gonna come off like gratuitous internet pedantry. But look, your "wire wrap" link leads to a page containing zero wire wrap (and zero relays). It's a gaffe on par with emphatically calling C source a "script".
Here's Atari's wire-wrapped digital Pong prototype, from before the design was refactored onto PCBs for commercial release just like those Magnavox Odyssey modules.
http://www.atarimuseum.com/videogames/dedicated/homepong.html