x=usr(1536)

UAV. Extremely happy with the one in my 2-port.

From my perspective, it's not on my radar. Never owned one growing up, having been an Atari kid. However, I have had a couple as an adult. Good systems, and I can appreciate them for what they are now much better than I ever did as an adolescent ST user. They're also one of the things I had to let go of when I realised that my collecting habits were well and truly out of hand. Three storage units (mostly filled with arcade games) and an apartment full of computer and video game stuff was where the line in the sand was drawn.

Now that you mention it, that does sound familiar. Haven't been in there in years.

@guppy: this isn't particularly directed at you - it's just that your response happened to raise the general point, so this seemed like a good time to mention a few things in relation to it as well as a couple I just want to get off of my chest. This is likely to be more stream-of-consciousness than anything else as a result. One distinction that seems to be missing in discussions of how AA relates to any iteration of Atari is that, from observation, most folks seem to regard it as the spiritual successor to 1996 Atari, not a continuation of the company itself. There is no doubt in my mind that from that point up to today, the community here has been the main driving force behind keeping these systems fresh and relevant, whether that came from administering the forums, developing new software, selling Atari-related games and peripherals (including upgrades), collecting for the various platforms, or being an enthusiast who just enjoys using them. Because the community has been able to be that driving force for the past 27 years, some incredible things have happened. Look at the panoply of devices we now have to enhance our systems with: the AtariVox+, QuadTari, UAV, U1MB, FujiNet, and many, many others. At the same time, software libraries have expanded tremendously across the board. The 5200 and 7800 were once dead systems; now they both enjoy active development scenes. Ditto the A8 and ST ranges. Now, all of the things mentioned above are ones that don't necessarily make sense to produce from a corporate standpoint. There is no mass market for them, but the market that does exist is both enthusiastic and appreciative. This is why I believe that the community has a solid future: we're the people who will continue to build and do things that simply can't be done effectively in any other environment. In this regard, the community holds the best position in terms of being able to fulfill the community's niche interests. As this relates to last Thursday's announcement of Atari acquiring AtariAge: what's done is done, and the genie isn't going back into the bottle anytime soon. Regardless of one's personal feelings regarding either entity, this is how things are going to be. This does not mean that you should be oblivious to the potential for down-the-road changes, or that you need to like or dislike any of the parties involved. By all means hold both parties to their word in regard to the promises they've made; they should also be held to the maxim that actions speak louder than words. But it's absolutely not a reason to decide that the community is somehow permanently and irretrievably tainted or altered. That hasn't happened, at least not in the last five days, and would take a lot longer to accomplish than that. There's no glossing over the fact that trust is going to have to be rebuilt between the community and Atari. There's also no glossing over the fact that that trust was minimal to begin with. Building that trust, however, is a two-way street and both sides need to work at it - what desire or incentive would anyone have to trust someone who doesn't trust them, or considers them to be the enemy? There's a lot of historical baggage to overcome, and this applies on both sides of the fence. By no means am I suggesting that any past events which have shaped negative opinion or eroded trust be forgotten or swept under the carpet, but rather that those events should not be the guiding memory behind every interaction. TL;DR: don't assume bad faith. By all means hold someone accountable if they fail to keep or act on their word, but not assuming that this will be the default when interacting with them should be the default. A meeting of the minds regarding culture both within the community and within Atari needs to happen. This doesn't mean that anyone has to change theirs, but rather that both learn how to not do something inadvertently-appalling to the other at the dinner table. We're the high-strung prima donnas; the company consists of faceless suits who don't know the slightest thing about how the sausage is made, let alone appreciate the sausage for its tastiness but they'll certainly stick a price tag on it. If this is inducing a sense of déjà vu, that's because it should. It's nothing new, and to one degree or another both sides have engaged in it at various times. And, just to make my own position clear: I have no opinion or expectations one way or the other regarding Atari's acquisition of AtariAge. It's not something in which I have any sort of business- or administration-related role, so cannot see a point in becoming emotionally-invested in it. What I do have opinions on, however, are the survival of this community and its continued growth. Those are very much important to me, and are not things that should be allowed to decline or disappear regardless of internal or external changes or pressures. For the long run, I will do what I can to prevent that from happening through my participation here, and hope that others will do the same.

Oh, that wasn't smugness. It's not really in my repertoire. I'd classify it more as mild sarcasm with a hint of self-effacing delivery. Sure, those two things could be considered to be odds with each other to one extent or another, but such is the nature of humour. In any event, buying properties (or the rights to them) that are going to sit unused just ties up capital that could be used for other things. For an organisation the size of, say, Warner Bros., this isn't a big deal, but at Atari's scale it doesn't make sense. One thing I do wonder about is how well an Atari-manufactured VIC20 / C64 / Amiga mini or similar would be received by both the Commodore and Atari camps. Somehow, I suspect that it would make the discussion around the modern VCS look like Shakespeare's sonnets by comparison.

That's what we refer to as a 'poor business decision'. Companies generally try to avoid making those if they're concerned for their long-term viability. While we're at it, I want a pony. @TrogdarRobusto: will the 2600+ have pony support? If so, I think I've found the USP that might just persuade me into a preorder.

Not to mention that architectural similarities between the two systems eventually encouraged lazy ports, something that affected both platforms and in some ways started a race to the bottom in terms of software quality later on in the systems' lives. How do you propose to overcome the issues behind licensing them? The majority of software for the ST was third-party, like pretty much every other system in existence. Personally, I'm not really itching to play the ST versions of Star Raiders, Moon Patrol, Super Breakout, etc. Thing is, those are the ones most likely to see a first-party release since they were first-party titles to begin with. Everything else has a (possibly significant) cost attached to it just to get it to market.

Memos to self for future testing: Gigantic images (e.g., 1MB+) Mount an atrfs filesystem via FujiNet Show atrfs mounts in Finder sidebar (may be macFUSE limitation) Loopback atrfs

So far, I've been able to create a blank image, mount it, and both write to and read from it. File deletion also works, as does renaming. 'Open in Terminal' even works properly from Finder's context menu, which is huge for my typical workflow. Here's what I'm seeing: 1536@lolbox A8 % atrfs --create --name=blank.atr /Volumes/blank 1536@lolbox A8 % The image is successfully created and mounted at /Volumes/blank with the following files: 1536@lolbox blank % ls -al total 5 drwxr-xr-x@ 2 1536 staff 1024 Sep 11 21:05 . drwxr-xr-x 7 root wheel 224 Sep 11 21:05 .. -r--r--r-- 1 1536 staff 302 Sep 11 21:05 .bootinfo -r--r--r-- 1 1536 staff 384 Sep 11 21:05 .bootsectors -r--r--r-- 1 1536 staff 135 Sep 11 21:05 .fsinfo 1536@lolbox blank % And the contents of .bootinfo and .fsinfo are: 1536@lolbox blank % cat .bootinfo Boot information Boot sectors: 3 Load boot sectors at $0700-$087f Init with JMP $0714 Run after load at: $1540 Max open files: 3 [default] (DOS 2 and compatible only) Number of drives supported: 2 [DOS 2 default] (DOS 2 and compatible only) DOS 2 flag for DOS.SYS: $00 DOS 2 DOS.SYS starting sector: 4 1536@lolbox blank % 1536@lolbox blank % cat .fsinfo File system information Sectors: 720 Sector size: 128 File system type: Atari DOS 2.0s Total data sectors: 707 Free sectors: 707 1536@lolbox blank % Trying to do things the FS doesn't support (non-8.3 filenames, extended characters, etc.) are trapped properly with error -43. I'll need to do some further testing with other than the default images, but so far this looks great! Thanks again!

Good news: it builds! Thank you! I'm working on getting macFUSE to recognise and use atrfs. This is being based off of the way that the sshfs package does it, which is to place the binary in /usr/local/bin/, set it 755 / root:staff, and install the man page to /usr/local/share/man/man1/sshfs.1, 644 / root:staff (no ACLs or extended attributes, etc. on either one). Granted, mentioning the man page right now is getting ahead of things a bit, but figured I'd note it just so it's there.

At which point you (and the kid) are basically confined to that hotel, because Vegas doesn't cease being Vegas based on where you stay.

Sweet, it's the Barbara Feldon release!

Using the new Makefile: 1536@lolbox atrfs % make cc -g -O0 -W -Wall -DFUSE_USE_VERSION=25 "-DFUSE_INCLUDE=<fuse.h>" -D_FILE_OFFSET_BITS=64 -c atrfs.c atrfs.c:365:97: warning: format specifies type 'unsigned long' but the argument has type 'off_t' (aka 'long long') [-Wformat] if ( options.debug ) fprintf(stderr,"DEBUG: %s %s %ld bytes at %lu\n",__FUNCTION__,path,size,offset); ~~~ ^~~~~~ %lld 1 warning generated. cc -g -O0 -W -Wall -DFUSE_USE_VERSION=25 "-DFUSE_INCLUDE=<fuse.h>" -D_FILE_OFFSET_BITS=64 -c special.c cc -g -O0 -W -Wall -DFUSE_USE_VERSION=25 "-DFUSE_INCLUDE=<fuse.h>" -D_FILE_OFFSET_BITS=64 -c info.c cc -g -O0 -W -Wall -DFUSE_USE_VERSION=25 "-DFUSE_INCLUDE=<fuse.h>" -D_FILE_OFFSET_BITS=64 -c mydos.c mydos.c:1402:97: warning: format specifies type 'unsigned long' but the argument has type 'unsigned long long' [-Wformat] if ( options.debug ) fprintf(stderr,"DEBUG: %s %s extend file %lu bytes\n",__FUNCTION__,path,size+offset); ~~~ ^~~~~~~~~~~ %llu mydos.c:1674:26: error: use of undeclared identifier 'RENAME_NOREPLACE' if ( r==0 && (flags & RENAME_NOREPLACE) ) return -EEXIST; ^ 1 warning and 1 error generated. make: *** [mydos.o] Error 1 1536@lolbox atrfs %

Don't forget the mutual breakup. All things Margolis are now in the rear-view mirror, disappearing into an ever-shrinking dot on the horizon to the rear. The future looks only like this:

In a market where producing and selling 500 copies of a title is a smash hit, expecting any major retailer to give up shelf space for that is just unrealistic. Boutique shops selling 5 or 10 copies apiece, sure, that's workable. But not Wal-Mart, Target, or Kohl's. Something that people seem to gloss over is that the days of million-plus-selling cartridges are over. A thousand units would be phenomenal in this day and age, and the economies of scale at that level just aren't there to make it practical to carry them outside of niche distributors. And, like it or not, we're also in an era of streaming and downloadable content. While I don't want to get into the usual ownership arguments that discussion of those delivery methods tend to devolve into, it is worth noting that physical media (and not just games) is on the decline. It's not dead yet, but the signs are there that it's on the out. One thing that would make for an interesting device would be a flash-based multicart, programmable from the device it's used with. Load it up with downloadable ROMs, flip through them at your leisure, take it with you to friends or relatives with the same device to play with / against them, and also enable features like saving high scores and game progress, etc., on the cart.

Well, blowing up the older hotels and replacing them with new ones over a period of a couple of decades did refresh the Strip somewhat. I'll give it that. The main thing is that, well, it's Vegas. Take away the gambling, booze, and hookers and you're left with Salt Lake City only with three times the population. Nothing against SLC (or even Utah in general), but vice is Vegas' USP. Without it, it's just a moderately-sized desert city.

We were there last month for a conference. The image change is... Superficial. I wouldn't exactly call it a 'kid zone' by any stretch of the imagination. If you're staying on (or near to) the Strip, after you check in at your hotel you will have to walk through part of the casino to get to your room. I can't think of a single property in that area where this isn't the case. As part of walking through the casino, you also get to walk past the bars. This is great for watching some really inexplicably bad behaviour. If you're really lucky, you'll get to see hotel security dragging someone out who couldn't abide by the rules after getting drunk. Vegas has a massive homeless population, along with drug problems, aggressive panhandling, and petty crime. The Strip isn't as sanitised by Vegas Metro (police) as it used to be. Needles on the sidewalks and in the gutters are not uncommon. Don't forget the somewhat-clothed strippers and hookers. They're still out on the strip, drumming up business. Oh, and the city's running out of water. Again.

So relieved to see these circular discussions rehashed yet again. The thread was way too on-topic there for a minute.

Out of curiosity, is libbsd required to build atrfs? The macOS defines are definitely present in the header files, but here's what I'm seeing: 1536@lolbox atrfs % make cc -g -O0 -W -Wall -DFUSE_USE_VERSION=25 "-DFUSE_INCLUDE=<fuse.h>" -D_FILE_OFFSET_BITS=64 -c atrfs.c atrfs.c:365:97: warning: format specifies type 'unsigned long' but the argument has type 'off_t' (aka 'long long') [-Wformat] if ( options.debug ) fprintf(stderr,"DEBUG: %s %s %ld bytes at %lu\n",__FUNCTION__,path,size,offset); ~~~ ^~~~~~ %lld 1 warning generated. cc -g -O0 -W -Wall -DFUSE_USE_VERSION=25 "-DFUSE_INCLUDE=<fuse.h>" -D_FILE_OFFSET_BITS=64 -c special.c cc -g -O0 -W -Wall -DFUSE_USE_VERSION=25 "-DFUSE_INCLUDE=<fuse.h>" -D_FILE_OFFSET_BITS=64 -c info.c cc -g -O0 -W -Wall -DFUSE_USE_VERSION=25 "-DFUSE_INCLUDE=<fuse.h>" -D_FILE_OFFSET_BITS=64 -c mydos.c mydos.c:20:10: fatal error: 'linux/fs.h' file not found #include <linux/fs.h> // RENAME_NOREPLACE ^~~~~~~~~~~~ 1 error generated. make: *** [mydos.o] Error 1 1536@lolbox atrfs % Which makes sense, since the linux/fs.h header file doesn't exist on macOS.

I'd need to double-check which light gun titles were marked as compatible, but IIRC some of them had a joystick mode. It's possible that those were the versions that were tested.

Unfortunately, it still errors out. FWIW, this is with the Makefile that was checked in about 5 hours ago and use_modern_fuse=yes commented out. 1536@lolbox atrfs % make cc -g -O0 -W -Wall -DFUSE_USE_VERSION=25 "-DFUSE_INCLUDE=<fuse.h>" -D_FILE_OFFSET_BITS=64 -c atrfs.c atrfs.c:289:11: error: no member named 'st_atim' in 'struct stat' stbuf->st_atim = atrfs.atrstat.st_atim; ~~~~~ ^ atrfs.c:289:35: error: no member named 'st_atim' in 'struct stat' stbuf->st_atim = atrfs.atrstat.st_atim; ~~~~~~~~~~~~~ ^ atrfs.c:290:11: error: no member named 'st_mtim' in 'struct stat' stbuf->st_mtim = atrfs.atrstat.st_mtim; ~~~~~ ^ atrfs.c:290:35: error: no member named 'st_mtim' in 'struct stat' stbuf->st_mtim = atrfs.atrstat.st_mtim; ~~~~~~~~~~~~~ ^ atrfs.c:291:11: error: no member named 'st_ctim' in 'struct stat' stbuf->st_ctim = atrfs.atrstat.st_ctim; ~~~~~ ^ atrfs.c:291:35: error: no member named 'st_ctim' in 'struct stat' stbuf->st_ctim = atrfs.atrstat.st_ctim; ~~~~~~~~~~~~~ ^ atrfs.c:365:97: warning: format specifies type 'unsigned long' but the argument has type 'off_t' (aka 'long long') [-Wformat] if ( options.debug ) fprintf(stderr,"DEBUG: %s %s %ld bytes at %lu\n",__FUNCTION__,path,size,offset); ~~~ ^~~~~~ %lld 1 warning and 6 errors generated. make: *** [atrfs.o] Error 1 1536@lolbox atrfs %

Forgot to show how the plastic retaining tabs for the keypad / fire button PCB was repaired despite having already taken photos of it Cut a thin strip (approx. 4mm wide) of aluminium from a 1/16" x 1" strip. That strip was cut in half, and the two resulting pieces were bent into an 'L' shape. This was then adhered to the rear of the plastic retaining tabs and the underside of the case with E6000 adhesive after cleaning all surfaces with rubbing alcohol. Seems to be pretty solid so far. May do the same on the other side as preventative maintenance.

Regarding macOS: this may just be an issue of making sure that the makefile knows where the FUSE libraries, etc. reside. So far, I've done a fair bit of work with manually pointing includes to where those are, but I get a significant number of build errors after that point. I'll post (in a spoiler) the output of that build a bit later on. The 'Installing macFUSE' part is easy: Download the current version of macFUSE from https://osxfuse.github.io/ and install, or: Install via brew with `brew install macfuse', or: Install via Macports with `port install macfuse'. Any of those three methods should install all necessary components and create a preference pane in System Preferences for macFUSE. Don't install osxfuse; it's deprecated. macFUSE is its replacement and is what should be used. As for the build instructions: have the current version of the XCode commandline tools installed. That's about as far as I've got with it since I can't get it to build successfully

Ugh. I hope it's not.

Understood, and you are correct. Apologies for the misunderstanding to anyone who may have read my post earlier.