x=usr(1536)

That is quite the cover. Don't get me wrong - I like it. But it certainly has a style all of its own.

Two photos. Same location, different angles and flash settings. Contact pad is shown on its side; normally, it would be laying flat over the electrical contacts. Note the little bump in the centre of the rubber contact pad between the two contact points. That's where the adhesive needs to go.

Since the question was, "N: NOS, anyone care?", I'd like to register a 'care' vote. Apart from the benefits mentioned above, I like having software in a central location. This helps to keep things on an even footing between machines, makes physical portability much easier, and cuts down on busywork keeping multiple machines in sync.

Which doesn't mean that duties can't be assessed below the $800 limit. All it means is that the limit was revised to $800 from $200.

That only applies to US citizens who leave from and return to the country with goods purchased abroad. For items sent via post, courier, etc. the rules are much different. That's just... Idiotic. How will it be enforced for digital delivery? Tacked on at the time of purchase? If a game is written by a US-based studio but published in Europe (with the data held in the EU), does this still apply? People do not have infinitely deep wallets from which to draw taxes, and it's naïve to believe that measures like these foster home-grown industries or enterprises. For some things, yes, but for others it's just easier to bootleg or smuggle it.

Yes, that is correct. In theory, the USB port could be used as a UPS of sorts, either with a battery or power adapter. However, I don't know how much I'd trust this thing to be powered from both the host computer and an external source simultaneously. Without solid proof to the contrary, it just sounds like a recipe for disaster.

In theory, any item imported into the US is eligible to be dutied unless specifically exempted. In practice, CBP tends to concentrate its efforts more on high-value items (cars) or ones where smuggling is profitable (alcohol, tobacco). As an example: a couple of years ago, my Jeep needed a new thermostat. I ended up having a custom one made in Canada, paid CAN$400 (about US$320 at the time) for it, and awaited its arrival. What I received was a note on my door from UPS telling me that there were nearly $200 in processing fees as well as customs duties to be paid if I wanted my package. The reason for this: UPS automatically collects customs fees and lays its own convenience fees on top for the privilege of doing so. Ditto FedEx, DHL, other major carriers, etc. Had the shop that made it sent it via Canada Post, USPS would have done what they always do when they receive something like this: forget about it for a few days, X-ray it, then send it on its way once it's obvious that it's what it says on the declaration without any customs fees or duties involved. Which is a valid point. I should make clear that the majority of my VAT experience has been in Ireland and the UK, which appears to operate somewhat differently to Sweden. The big scam in Ireland (which taxes everything it can get away with) has been VRT - Vehicle Registration Tax. Because import duties haven't been able to be charged on vehicles (new or used) imported into Ireland from the rest of the EU since 1992, the Irish government came up with VRT. This is a tax that conveniently happens to work out to about what a vehicle would have cost had the Revenue Commissioners been able to duty it at time of entry. Of course, the tax is only applied at the first registration of the vehicle, so it's not an import duty, just a registration tax 🙄

Right, but pre-EU (which is effectively where Brexit has left the UK) VAT wasn't supposed to be charged on items being exported from the UK. For items being imported, HM Customs didn't care about whether or not taxes had been paid on the item at its origin; they just slapped VAT onto it, added their fees and duties, and then added VAT a second time to get the final value. Used to go through this constantly when shipping from the UK to Ireland or vice-versa prior to 1992. It was not a smooth process then, and by all accounts they've found a way to make it even worse now. True, but good luck to HMRC with enforcing that outside of the UK. Unless there's literally millions in fraud taking place with a single shipper, it's not worth their time or effort (or likely to get anywhere with foreign authorities). Which is a very good point. It would also mean that a one-man-shop could conceivably have to register for VAT in any country they sell to if other countries start following the UK's lead. No small business is going to do that; it's just easier for them to say, "sorry, we don't ship to your country." Essentially, there are four levels of taxation in the US: Federal, State, county, and local (city). Sales taxes are not applied at the Federal level, only State and below. A few States have no sales tax, and some cities have no local taxes; it's not completely uniform throughout the country and rates do vary from State to State, county to county, and locale to locale. Sales taxes aren't typically levied when an item is imported or manufactured, but rather when it is first sold. At that point, the taxes are collected by the relevant agencies in whatever proportions they take of the tax as a whole. With imports, there are customs fees and duties that are Federally-levied. Those go straight to Customs & Border Protection (a Federal agency), who subsequently return it to the Federal government. Typically, there would be no further taxation on the item beyond this point unless it fell into certain categories (cars and alcohol being the best examples I can think of). Obviously, there's a lot in there that's been over-simplified, but it should get the gist across. It may sound confusing but in day-to-day life it's really not much of an issue. About the only thing that annoys me about it (apart from having to pay the taxes) is that retail prices of goods on shelves in the US are typically shown without the sales tax added, so you have to mentally recalculate the price to reflect how much you're actually paying.

Absolutely. Caveat to that, however: While this is definitely a situation in which a WiFi SD card would be useful, the issues that I was running into with this specific card are card-specific, not application-specific. Moving the card to another machine will just bring those issues along with it. Having said that, I do like the concept and am certainly looking forward to seeing what batari comes up with in his design. He makes good stuff 😁

Nope, just the contacts on the PCB. However: Around 65% of them fell out of their own accord when I separated the PCB from the keyboard. Watched them fall and initially thought I'd found evidence of a past insect infestation, then realised what had come loose. Yep. They haven't been touched at this point; I'm basically in a holding pattern until I can figure out a fix for them.

All of which are certainly possibilities, and initial testing was performed with the Bigtreetech adapter connected to a USB 3 hub which was providing power to the adapter. The issues I noted earlier were seen with it receiving power from either the hub or the Concerto cartridge, so external power hasn't appeared to have an effect on reliability. If the problems only started once the adapter was in the Concerto I'd be more inclined to see this as a power issue, but I suspect it's just the design of the adapter.

Opened up my 800XL to replace the keyboard mylar only to discover that it has the Mitsumi (Type 5 in this post) keyboard that doesn't use a membrane. Gave the pcb a good cleaning, and am ready to reassemble everything. However, the adhesive on the little rubber contact pads used to generate keypresses has given up. This is making reassembly next to impossible. Can anyone recommend an adhesive that could be used to hold them in place that will actually bond with the PCB without attacking the rubber? I tried Gorilla Clear-Grip Contact Adhesive, which claimed to be usable with rubber on the package. Naturally, it adhered just fine to the PCB but not the contact pads 🤪 Any suggestions for what to use? I'd rather not spin the Wheel of Adhesives and try things that may be unproven to be safe for use with rubber.

TL;DR: I like the ideas behind what devices like this offer, but the implementation sucks. Save your money and just keep manually popping SD cards in and out as they require updates. After playing around with the adapter for a good chunk of the afternoon, I've come to the conclusion that it is not a practical way to enhance SD cartridge capabilities. There are applications that it may be more suited to, but practical considerations rule it out for console usage. On the plus side, it's cheap and more or less does the things that it claims to do - at least, when it feels like it. Here's a bulletpoint list of the cons: It's slow. About the best sustained transfer rate I can get out of it is around 128Kb (yes, small 'b') per second at a distance of six feet from the AP on the wall in my office. It's unstable. Trying to move more than about 144KB of data to it at one time (single or multiple files) results in it crashing more often that not. Suspect there's an undersized buffer somewhere that can't empty itself to the SD card fast enough to do its job properly. It doesn't always want to boot. There's been a lot of use of the reset button to eventually get it to come up fully after powering up. Practical consideration: the only way to transfer files to it is via WebDAV. This means mounting the device as a network drive on a PC. Fine, but consoles are typically powered off to change games - at which point the network share on the PC is lost and has to be remounted. Connections are in the clear - i.e., unencrypted. Didn't expect encryption at this price point, but it is good to have just on general principles. The default username of 'guest' (no password) used to access the share cannot be changed. Also expected, but again is something that would be a plus if implemented. Hostname is 'WiFi-SD-Card-3DPrinter' with no way to change it that I could figure out. Documentation is terrible. Again, not a huge surprise, but having to rely on it, plus github issues, plus external commentary in order to get it up and running sucks. WiFi is 2.4GHz only. Not a huge deal to me, but may be a problem for some. The previously-mentioned SSID-can't-contain-whitespaces issue and 50-character limit on WPA2 keys. If you're going to make a device intended to connect to WiFi, at least make the basics work, folks. Probably not going to look into this any further. The limitation of losing the network share to the device when the console is power-cycled is one that can't really be worked around, and unfortunately greatly limits its utility. It also limits the utility of any similar device using WebDAV or other networked filesystem protocol that involves having to mount it as a share. FTP or (even better) scp would be vastly preferable, but it's doubtful this will ever happen.

Sure, and that's understood. But this brings us back to the point that MAME has no performance target as a build consideration. I understand that people want to run MAME on their older hardware, and that's certainly their prerogative. But anyone doing that also needs to accept that they're doing something that is inherently contrary to the nature of not just MAME's development, but hardware and software development in general. To my mind, it's not reasonable to expect the project to adapt itself to what are corner-case desires in relation to its stated goals. Correct - there are electromechanical devices, calcuators, and others that it emulates. But remember that its scope has evolved over time, and that MAME is, as stated on the front page of mamedev.org, "...a multi-purpose emulation framework." It's no longer just an arcade video game or home computer / game console emulator, and hasn't been for quite some time. That's part of the evolution of the project. Anyone is free to contribute whatever they may that is relevant, much as anyone is free to improve any included driver. There is no requirement to submit a 'working' driver - and even 'working' in this case is a somewhat nebulous term. There are games that are playable, but have the wrong colours, or sound. Are those working, or imperfect, or broken? I realise that that question opens up a serious rabbit hole, and it's not one I really intend to go down. But sometimes, for the sake of documentation and preservation, it's necessary to submit and include drivers that are quasi-to-non-functional. If that didn't happen, there would be no opportunity for anyone looking at the project to contribute to them. Again, unwieldy is a matter of perspective. There have been significant rewrites to major components of MAME over the years - video, audio, discrete component handling, driver structure, the UI, etc. all serve as examples. By and large, these (and other) changes have all brought definite improvements over the years. The reality is that if it was unwieldy, nobody would want to contribute to it because nobody wants to have to slug it out with the software that they're developing just to make those (voluntary) contributions. Which is a good point, and one worth mentioning. MAME has only three official build targets: Windows, Linux, and macOS. Windows and macOS are pretty self-explanatory, but Linux opens up an interesting set of cases due to the source's high portability between hardware architectures: the same source that builds on x64 will also build on ARM, RISC, and others. This has led to a lot of complaints about MAME's performance on low-end hardware, which overlooks the 'just because you can doesn't mean you should' aspect of running on those platforms. macOS user here, and I also build from source. This is something I do mainly to ensure that the libraries MAME is linking against match the ones on my system - it's an old habit, and probably no longer necessary, but old habits die hard. Thing is, you and I are in the minority: most end users just want to download a binary and go. Believe me, I get the long build times. On a recent-ish (3 years old) MacBook Pro, just an arcade build takes around 45 minutes; can't really say how long a full build takes as I don't use the MESS side of things for computer / console emulation. But that's the tradeoff for emulating a broad swathe of machines. This is one reason why using low-end hardware doesn't make sense from a development point of view Understood. I'm mainly just sharing my perspective as someone who has contributed financially and materially to the project for quite some time, and has a certain degree of insight into it as a result. And no, my views are not ones officially endorsed by the MAME project, its developers, contributors, or users. It's just my opinion based on what I've seen over the years.

Forgot to mention: due to current weather conditions, our local Post Office is closed. This means I likely can't get shipping costs figured out for a day or two until they reopen. It's Wednesday today; I'm hoping they'll be back up and running either Friday or Saturday, but it may drag into next week. Also: PM received.

From the 'should've looked before I ordered' department, I've ended up with a 600XL / 800XL keyboard mylar that is of no use with the keyboard in my 800XL. It has been opened, but is otherwise unused and in as-new condition. $25 plus postage, or willing to trade / part-trade for other stuff. Looking for a working condition 1010 tape drive in particular.

Well, it really hasn't changed a whole lot over the years. Basically, playability is secondary to documentation and preservation. Not saying that to be glib or dismissive - that's just what it has pretty much always been. Based on that, what are the areas that aren't making sense to you? This is something I'd really like to help to clarify if I can. Sort of. Nicola Salmoria wrote a couple of standalone emulators for (IIRC) Pac-Man and Ms. Pac-Man. That led to combining them into the Multi-Pac emulator, which also supported other versions on similar hardware. From there, MAME sprang up, adding support for Space Invaders and Phoenix. It all snowballed from there. Good question. More: Potentially, yes. However, MAME's current architecture really isn't designed to handle things in that way. Starting over from scratch to implement the 'pluggable' architecture being proposed would pretty much be necessary. One thing that is important to understand, though, is that doing so really only reduces MAME's memory footprint. The amount that it's reduced by could likely be significant, but that doesn't necessarily equate to performance gains in emulation since those are tied to the underlying hardware. A monolithic MAME build will run at the same speed as a pluggable one, given the same cores, ROMs, drivers, etc. The last arcade-only build of MAME that I compiled on this machine (which, being completely honest, was probably from last November - updating has been low-priority for the past couple of months) shows a file size of 233516340 bytes; let's call it 233MB for easy reckoning. That's not even a quarter of a gigabyte in an era where even the lowest of low-end PCs can be had with 4GB of RAM. Could a pluggable architecture reduce that? Sure, but for what return? Convincing a dev or devs of the benefits is going to be a difficult task when there's no clear overall benefit to the project as a whole. In terms of original game and/or driver code, I'm willing to bet that very little to none is the answer. But what is definitely shared between machines is emulated hardware. Cores, discrete components, controller types, and so on and so forth. Sure, we can go back to the pluggable architecture idea, but that also comes down to a cost/benefit analysis as to whether or not it's worth implementing. Points taken, but should MAME have just frozen in time, never branching out in other directions? There was a time when something pretty close to that idea was guiding the project, and it didn't work well for a number of reasons. It all comes back to the earlier question of what does and does not bear inclusion, and who makes that call. As regards MESS, it follows the MAME philosophy of documenting the hardware as far as is possible so that someone with the inclination to improve emulation can do so. I'd argue that that's not bloat; it's providing a starting point to continue from. Opinions may differ, but again it comes back to the question of who decides what counts and doesn't. OK, those are fair points. Taking them in order: Regarding 1) above: how would you propose re-architecting the existing emulator to accommodate that change? WRT 2) above: is this meant to be something that an end user can build, or that is part of an official release? I ask because the majority of users aren't rolling their own, and what an average user may or may not need is different from person to person. Finally, what is the cost/benefit analysis on both of the above as regards overall improvement to the project? Note that I'm not asking the above to be difficult or combative - it's just that these are the terms that need to be considered when some pretty massive changes are being proposed.

Card is in hand, along with some setup issues. Long story short, I've been piecing together how to configure it from a combination of sources: the official documentation (such as it is), the issue tracker in the github repository for the device, and various random Internet commentators. So far I have managed to a) update the firmware and b) find out that it doesn't support SSIDs with whitespace in them, or WPA2 keys over 50 characters in length. You read that right: someone set the WPA2 key size to 50 bytes when the spec calls for 64. Smart! b) above is problematic, since all of my existing SSIDs fail on key length. Unfortunately, I'm also maxed out on the number of SSIDs (four) that my WiFi gear can handle. I can migrate stuff from one SSID to another and fix the key length problem, but frankly I'm just not up for it this evening. I'll deal with it tomorrow when I hopefully have mor enthusiasm for doing so 😜 On the plus side, the device is communicating properly over serial, so I'm at least hopeful that progress can be made once it's networked.

I'm truly not understanding how HMRC thinks it can require VAT registration in territories outside of the UK which are shipping to the UK. This is the complete opposite of how I've seen it work my entire life, and am concerned that they believe that they have the power to do so. Of course they can enact whatever they want and simply say, "if you don't like it, tough," and seize or return untaxed shipments. But UK taxation can't be enforced outside of the UK's borders. Confusing, to say the least. Oddly enough, there's some bit of historical precendent for this sort of thing not going over well. Can't remember exactly what it was; perhaps an example may be found in one of the (now ex-) colonies 😜 Might not be a bad idea to start organising group buys. Bump up over the £135 limit and bundle orders for cheaper shipping. Just a thought...

Ehhh... We may be getting into hair-splitting territory on this one. I'd argue that it does qualify as an emulator, just one where the machine being emulated can be defined by its driver rather than the emulator as whole. Think LKMs vs. monolithic kernels as a parallel. Still, I get what you're saying. Part of that is just down to the fact that it now supports over 35000 different machines - and that's an arcade-only build. But that brings us back to the question of, "what is bloat?", which still needs a decent answer before trying to see if there's a problem that needs to or can be solved. I don't know that there's necessarily a good answer to that question simply because 'bloat' may mean something different to different people: one may consider the UI wasteful, or another advocates ripping out support for all of the mahjongg, hanafuda, and fruit machines. To someone else, it may be an inefficient or redundant routine in <insert emulator element here>. 🤷‍♂️

The point that seems to be being overlooked is that MAME doesn't target a specific performance goal. If a system has the beef to run a particular game at 100%, great, but if it can't, it'll need to be upgraded and/or stand by for driver improvements. And while everyone talks about 'bloat', the reality is that nobody (in the wider picture, not specifically here) has defined that term in such a way as it would permit a solution to the perceived problem being forumlated - yet the emulator continues to work in its present state just fine on not-up-to-date hardware. Additionally, one of the problems with specifically targetting low-end hardware is that it makes it difficult to break with the past. MAME running on a 486 is an excellent example of this, and one that I have experience with so can remember how well it performed. But that was at a time when the demands of the drivers were much lower due to the far lesser complexity of the emulated systems: there was a time when Galaga was believed to be unemulatable because it had - *gasp* - two Z-80s. There were also a lot of inaccuracies not just in drivers, but also in things like CPU cores and discrete audio, and improving accuracy over time in some cases required more cycles. There's a reason why 32-bit builds are no longer distributed and are generally discouraged.

Got it, and thanks. It seemed close, but I couldn't find a BOM that matched up 100% with what I was seeing, so wasn't totally certain.

I want to say that they go back as far as 2000; apparently, the rationale is that these versions perform better on low-end hardware. Unfortunately, this eliminates 21 years of improvements to drivers, backports newer drivers into older builds (thus causing problems related to that), and in some cases breaks the licenses of the respective versions of MAME being used. Not to mention that it means maintaining multiple ROM sets, sample sets, etc. for each of the versions in use. Given that even today's low-end hardware is capable of running some reasonably demanding games, the argument in favour of doing this really doesn't hold water. Granted, not everything may run at 60fps with 100% CPU speed - but that applies to pretty much any hardware running the emulator.

Ditto Three Stooges and Krull for me, but never Q*Bert's Qubes - and we were nowhere close to Chicago at the time. A lot of games achieved popularity after emulation made them available to a wider audience. That may be distorting what's popular vs. what was popular due to availability BITD.

Only ever saw one of these on location in a supermarket, and agreed - in the actual cabinet, the gameplay is fantastic. Production run was definitely small - I want to say over 1200 but under 1500 machines is rattling around in my head.