x=usr(1536)

@Allan is the only one who can give a definitive answer to that question.

❤️

You're being held to your word, and thank you for giving it. Moving on: which version of the firmware are you currently running?

Before I or anyone else helps you, I'm going to be completely up-front about one thing: pimp your YouTube channel or website here even once, and the help ends right there, right then. Keep it personal and focussed on the issues you're dealing with, and it'll all be OK. Deal?

PM me your preferred shipping address and I will send you the following: These are fire button PCBs for a CX24 Proline joystick. They were removed from my CX24s when I did an upgrade to Best Electronics' kit, and are no longer needed. Rather than toss them out, I'd like to see them go to someone who can use them. They are used, but still have the proper springiness to them. Shoot me a PM with where you want them to go and I'll send them your way.

Could this be posted as a Google Doc or similar? It would be extremely useful for testing.

Is there a good way to identify a PAL 7800 release solely from a ROM image of the cartridge? This is a long shot, but what I'm hoping for is a unique but repeatable hex pattern that effectively says, "yep, I'm a PAL cartridge." I'm aware that this can be pulled from the 'TV Type' field in an .a78 header, but would prefer a method that can be used on a straight dump of the cartridge without the headers added. Thinking about it, being able to positively identify a dump as NTSC would be just as useful.

OK, ended up making a purchase. Went with the Bigtreetech SD Cloud, which, at $10.25 shipped from China, seemed like the best get-your-feet-wet route. ESP12S-based wifi, takes Micro SD cards, fits a full-sized SD card slot, and is serial-programmable / configurable. Figure it'll be here in a couple of weeks. We'll see how it goes then.

Oh, I'm counting on issues But, yep, those are certainly valid concerns. As it happens, I've already run up against the first couple of issues: finding a card that works as a client, not an AP; additionally, finding one that supports any file format you throw at it, not just image / audio / video files. There are a couple that make vague claims about being able to do one or the other of these things, but nothing I really want to play Amazon return roulette with just yet. What I'm giving serious consideration to is the FYSETC SD-WIFI with Card-Reader Module. This is the one that sent me down this rabbit hole last night, and it seems to have the greatest overall flexibility. I do like that it's serial-configurable, too.

I'd never heard of them before last night, either: they cropped up tangentally while looking into some 3D printer stuff. Turns out they're a popular option for avoiding having to run Octoprint or a similar print server. There evidently are ribbon cable adapters to allow a micro SD port access to a full-sized SD card. Given that they should just be an electrical passthrough, I can't imagine them not working in tandem with the wifi SD cards with the possible exception of physical space restrictions. https://www.amazon.com/s?k=micro+sd+adapter+cable

Does anyone have any experience with wifi-enabled SD cards in any of the current SD carts such as the Concerto, Harmony, or Atarimax? They've hit a $20-ish price point on Amazon, which is where they're starting to look attractive to me. I like the idea of being able to leave the SD card plugged in and manage the files on it remotely; being able to be lazy and productive has its appeal https://www.amazon.com/s?k=wifi+sd+card

Yours and mine may have been made on the same day:

Had some time this afternoon to take another look. Unfortunately, I didn't make any significant progress: it's still not powering up fully. Changes since the last update: replaced the power switch with a new one, installed the RF modulator that -^CrossBow^- sent me a while back, and replaced C45 with a fresh capacitor just in case. Just for grins, tried three power supplies other than the one I had purchased; no dice. Bridging emitter to collector or collector to base on Q7 still gets the power LED on solid, but that seems to be the only way to make that happen. Other than shotgunning all of the transistors, I'm out of ideas. If anyone has any, I'm all ears.

Registering interest.

Huh. I'll be damned. Never heard of this before, and am slightly surprised I never thought to try it until now. Worked like a charm, at least on the capacitor I just freed from its surly hot-glued bonds. Definitely keeping this in mind for future use.

No worries 😁 Might want to go at it with an X-Acto knife or similar first - if it's soft enough to cut with a blade, start there and see how far you get. Far less risk of accidentally damaging something you'd rather not.

Epoxy is generally solid to the touch, though that depends on the formulation of the epoxy. It looks like it's probably hot glue, but I wouldn't want to swear to that from a distance.

If that's hot glue (and I really hope for your sake that it is), there's enough of it on there that you might be able to take a Dremel with a cutting wheel through the middle of it before attempting to heat and remove it. If this allows you to separate either the RAM upgrade or UAV board from the main PCB before tackling the adhesive, your cleanup job will be a lot easier.

True, but Tramiel Atari at least understood what was involved with product design, engineering, and marketing. Not always successfully, but more often than not, at least. They weren't viewing lawsuits as a revenue stream.

Because their business model revolves mostly around being an IP holder who sues people for printing Atari T-shirts.

The impression I've had regarding this is that they expected it to be hacked in the, "tee hee, I added a blue power LED," sense of the term, not the, "lol, clownshoes security, pwnt" one that they actually got. Possibly, but I really don't believe that they realised exactly what was going to happen. Other OSes were meant to be sandboxed from the main OS, but, in the end, turned out to not even be a necessary vector of attack for everything else that's been prised wide open on the device so far. At this point I'm just waiting to see how much imitation of a legitimate system can be done with the OS running on non-native hardware (including virtualisation). That talks to the store and other payment processors, and is where a lot of truly malicious shit can happen. If it does, it'll be an utter disaster for both the platform and company.

I remember that issue - the controller was one of two things from that magazine that I built, the other being the speech synthesiser that plugged into the joystick ports. From what I recall, at the least one of them needed supplementary notes from a subsequent issue to get working properly. There's a ton of (110V) X10 stuff I've collected over the years that I really should clear out. It's still great equipment, but I've moved on to newer home automation protocols.

Rather than parsing the filename from the header, why not have the ability to have fields in the header akin to ID3 tags in MP3s? Use it for metadata that describes the actual software content (name, publisher, year, etc.) separately from what's in the filename. N.B.: I'm aware of how much agreement and coordination it would take for this to be workable, but it could conceivably fix a number of issues with software identification and cataloguing.