x=usr(1536)

Unfortunately, there was no change. This was with the latest firmware from https://fujinet.online/firmware-dl/ I have a 410 sitting here as well as a few cassette games. No idea if the media is any good or not, but I'll try to verify that SIO is working on this machine either tonight or tomorrow by seeing if they'll at least start loading. Don't want to have everyone going down rabbit holes that ultimately come back to 'my machine needs <x> to be fixed'. Late edit: have tried the FujiNet both powered from USB and unpowered with the same results.

Having gone back over the suggestions and given getting the FujiNet to boot some more shots, I'm no closer to success. What needs to be done to have it boot successfully? I've tried various combinations of 1200XL first, FujiNet first, pauses of varying length between both, and holding my mouth just right. None seem to be working. I can see the orange card activity LED flash a half-dozen or so times after the 1200XL is switched on, so it does appear to be trying to do something.

Ah, gotcha. I misread '800' as '800XL'. The long-term plan is to have one FujiNet per A8 - tnfsd is running locally, so they'll all be able to share the same (synchronised) resources.

Copy that. I'll take care of the resistor when I have the machine open to deal with the mylar; the 800XL has precedence in that regard, largely because its mylar is already here. Yep, the 600XL's a known quantity; see my signature for details The 800XL boots without the need for external power - it just comes right up.

Unfortunately, that didn't work. Used the same RasPi 2.5A adapter that was powering the 600XL / 800XL and no dice. I did notice that there's a brief squawk when the machine is turned on - it's like the sort of sound you'd hear if a cassette errored out, but lower-pitched and maybe 0.5 seconds in duration. Not sure if that's significant or not, but figured I'd mention it.

Finally getting around to setting up the #FujiNet I received for Christmas, and am having a problem with it booting on my 1200XL. Firmware is today's release (Feb. 6), but this was also happening with the January 24th release. Using the macOS version of the flasher under Big Sur to write it. Basically, plugging the #FujiNet into the 1200XL results in no boot from the #FujiNet. The system starts up, I get the rainbow 'ATARI' graphic, and after that it drops to a blue screen similar to the one used by BASIC, but without the 'READY' prompt. At this point, the machine just sits there, going no further. AFAIK, the 1200XL is completely stock. OS is v10 (no '®' symbol next to the 'ATARI' graphic). PSU is one of Best's NOS 1200XL units that I picked up a month or so ago; it measured out OK at the time. Runs Star Raiders from cartridge like a champ. Only known issue is that the keyboard mylar needs repair / replacement. For giggles, I popped the #FujiNet into my also-stock 800XL. Booted right up without any issue. FWIW, that machine also needs a mylar so I can't do a whole lot with it, but at least it shows that the #FujiNet comes up as expected and sees APs. [For even more giggles, I popped it into my equally-stock 16K 600XL. As expected, it didn't work, though I did get a nice screen full of stripes. The key click sound was still functional, though ] I suspect that the issue is with the 1200XL, not #FujiNet. However, I'd appreciate a sanity check in case I've overlooked something - this is both my first #FujiNet as well as my first 1200XL, so it's entirely possible that I've glossed over something small but important.

I kinda like it - it's slightly reminiscent of bootleg cartridges. Then again, I have a weird affinity for bootlegs, knockoffs, and oddities, so my judgement may be suspect to begin with

I'll confirm this - mine's an A3 85, and Alien Brigade (joystick or light gun) just does not run on it. Seems to be the same thing everyone else is seeing: the hand comes in from the left and starts to draw the title, but never actually draws anything followed by a reset after 2-5 seconds, at which point the process repeats.

€0.50 HERE WE COME!

That's exactly what I was suggesting Point taken re: variation, but 5200 controllers managed to do it at about a 6' distance. Not saying these things wouldn't be issues to watch out for, but it seems like a possibility, at least. Which is fine - pots can stay where they'd normally be. But that leaves a number of pins that could be used for (essentially) multiplexing other controls, if it's feasible to do so. Thanks - just trying to come up with an idea whereby basic controller compatibility can be maintained across the board, while still allowing for extended controls where needed.

This has me wondering about something: Is each non-pot pin on the standard D-sub 9-pin joystick connector only capable of being read as high / low, or is it possible to send different values over those pins? My thinking is that if this just a limitation of the OS, design the additional controls so that ones that need to be are on a matrix similar to a 5200 keypad (or DTMF keypad). Depending on which column and row a button sits on, a different value is created and sent over <insert pin here>. As long as everyone can agree on what those values need to be, the code to read those inputs would be more or less the same from program to program.

Thank you. Those are some interesting perceptions.

Out of curiosity, how do you define "the way this board would like to see it run"? I am genuinely curious about this, because I've seen the phrase (or near enough as doesn't matter) used several times by multiple posters, yet no-one has really explained what they believe it to represent.

Maybe, but scout them out carefully first. TV repair these days is largely-similar to cellphone repair - replace backlights, screens, and PCBs as a unit rather than going down to a component level. Not saying these are bad ideas, but that there are gotchas with them.

I'd recommend filing those type of shops' soldering ability under 'questionable'. The majority of their business tends to be screen replacements, which are typically just parts swaps; the same applies to PCB-level problems. It's rare for them to do actual work at a component level.

Thank you for doing this. I tested it in Atari800MacX shortly before pawing through the cartridge dump, and got the same result. Didn't want to use it as an example, though, due to possible differences between emulated and physical hardware.

It would be the same on a repurposed A8 cartridge PCB. The 5200 version is the A8 version; they share the same codebase. For differences, see the following: http://www.ataricompendium.com/game_library/easter_eggs/5200/52ballblazer.html Right, but whether you, or I, or anyone else with a 16K machine is interested doesn't matter. Doing this conversion would be wasted effort because we're an incredibly small pool. Since we're speculating, let me set odds on that now: 50:1 against. You're in for a long wait. In the meantime, you may want to refer to p.59 of the following issue: http://www.atarimania.com/mags/pdf/analog_no_15.pdf It might give you some ideas of things to do with the interstitial time.

Keep in mind that I'm also the owner of an unmodified 16K 600XL when I say the following: There is going to be literally zero interest in converting Ballblazer on the 5200 to run on an A8 of any memory capacity below 48K. For giggles, I decided to take a look at the cartridge dump of Ballblazer currently on Atarimania (here) and compare it to the 5200 dump (here) that they also have. Basically, the A8 dump is 64KB in size, but there's 24KB of unused space in the middle of it at $2000 through $7FFF. This gives an overall game size of 40KB. On the 5200, the dump is 32KB, which makes sense since that's what a standard 5200 cartridge maxes out at. This is already 8KB smaller than the A8 version, so expect that things have been removed to make it fit. There also don't appear to be any unused blocks of null or $FF values to clear out, so 32KB is what it takes. There really isn't any benefit to converting a cut-down version of Ballblazer to run on a platform that already has a version with more features. I get that you want it to run on a 16K system, but memory expansions for 600XLs have been the norm since the mid-'80s. It's not realistic to expect someone to convert a game in order to run it on what's essentially an edge-case machine these days.

Doubtful. The game already exists on the A8 natively, so no conversion is necessary. If you want to find out if your 600XL is capable of running Ballblazer, grab the ROM of (specifically) the A8 cartridge version and load it in an emulator with the system memory set to 16K. If that works, track down the cartridge on eBay or similar, or burn one from your ROM image.

That's what I was thinking of; completely forgot that it was a U1MB. Appreciate the memory jog.

Yep, and I could've sworn that there was another one that cropped up recently (like, since about Christmas). Very clearly remember seeing it, but cannot find the details for the life of me. Want to say it was being designed by folks in Poland.

They were sold in the US, and there's one on eBay right now, CIB, with a $250 opening bid and a $1500 BIN. As for easy to find, no. See my signature; I've been looking for one for some time. Most expedient route: the 2-chip upgrade that @DrVenkman described. I just hate having more desk space and an empty PBI slot, so am holding out for one to turn up.

Oh, snap. This just cropped up in my YouTube subscriptions. And also: https://retrohax.net/the-mouster-project-is-here/ This device is probably 80% of the way there. Need to figure out if it can (or eventually will) handle analogue controller inputs, but it seems to have figured out the USB-to-Atari interface for the most part.