x=usr(1536)

True. But that really only applies to the US scenario, and it's easily worked around. Locate offshore somewhere in neutral datacentres, redirect customers in regulatorily-sensitive countries to a, 'we're sorry, but the government in your territory says you can't use our online gambling service', then offer a low-monthly-cost VPN/proxy service to run those customers' traffic through to your neutral datacentres - just install the appropriate app from the Ataribox App Store. It's another tier for them to make money at, and given that it would facilitate opening up the customer base for the gambling service, worth investing in since that's where the real money is.

Agreed, but given that it's possible to buy both blockchain mining and blockchain management as a service, they could conceivably contract with a third party to provide this. I still think their business model looks like this, however: Throw buzzwords around like you know what you're talking about ??? PROFIT! But having said that, the potential for the gambling / Tacocoin business model is also there. It wouldn't surprise me, though, if the 'Ataribox mines bitcoins while you sleep' was also a definite possibility.

I'm wondering if it may not have been a US model that was retrofitted with a PAL TIA, modulator, etc. from a later PAL 2600. Do you have any photos of the inside (including the PCB)?

Had to say it: every time I see this game mentioned, I think of this: (Excellent game, BTW!)

I'll admit that I was stretching things a bit with the example I described, but it's one possibly-workable way I can see for them to potentially have a business model surrounding the Ataribox, their gambling software, and their Tacocoin. Having said that, I am entirely willing to admit that it's far more likely that they're just throwing buzzwords out there to see who throws money back at them in return.

I hate to say this, but... This might actually work in the marketplace - at least, in certain circumstances. Hear me out. If they pitch this as a box capable of online gambling and use Tacocoin as a method of holding and paying out gambling funds, this may get around regulation in certain territories where online gambling is either heavily-regulated or illegal. Think of it this way: you play <insert gambling game here> and win Tacocoin, not cash. But you can spend Tacocoin in the Atariboxcorp, Inc. online store - and one of the items you can 'purchase' is gift cards loaded with the dollar / pound / Euro / other local currency value of Tacocoin you happen to have amassed in the gambling games. Minus an exchange fee, of course. It's actually kind of smart - they get to keep the players' losses as well as hit them with an exchange fee for pulling their winnings out of the ecosystem. And given that cryptocurrencies are low on regulation at the moment, it sidesteps a bunch of nasty legal encumberances involving the transfer and movement of real money. If this is what they actually end up doing, I will have to give them some credit.

I'm from a couple of hops to the West of Belgium I live in the US now, though. Growing up, I had family who worked in the entertainment industry. We had multiscan TVs and VCRs in our home as a result, because they needed to be able to play back videotapes that would be sent to them from the US and elsewhere. I was probably the only 10-year-old in the country who knew that the US' NTSC standard ran at 3.58MHz, while Japan's version ran at 4.43MHz. One side effect of this is that we used to be sent movies that had already been released months prior in the US but that hadn't made it to the cinema in Europe yet. The Internet has kinda killed that, though

Belgium used PAL, IIRC. For what it's worth, we used to be able to pick up SECAM transmissions occasionally if the conditions were exactly right. They'd usually drift in and out, and the combination of distance weakening the signal, interference, and differences in the color fields made for some rather eerie visuals by the time they were showing on the PAL TV.

We've been through this before: tacos > Ataribox. Don't worry about the 'why', just sit back and marvel at how well we do it! But whatever you do, don't stop for a moment to think about the common denominator in all of your failed and / or contentious relationships. It couldn't possibly be that.

True, but your original question asked about SECAM 2600s using a PAL TV connector instead of SCART. We had SCART in PAL countries, too The connection type had nothing to do with the TV scan the 2600 would output.

Point taken, but remember that SCART didn't always exist The PAL TV connector that you're talking about was pretty much standard across transmission formats in Europe. It didn't matter if the country was PAL or SECAM, it just fed the signal from the 2600 into the TV. Anyway, to answer your question: as far as I know, France only received SECAM models.

Or practically anywhere in Europe. https://en.wikipedia.org/wiki/Teletext Granted, teletext wasn't interactive in the sense of it allowing two-way communication, but it was ubiquitous. I miss it; it was really useful. Shame it never caught on in North America.

Having run across this thread earlier, it occurred to me that there might be some interest in a project that I've been fiddling with on and off in my spare time for the last few months. Some background: about four years ago, it became necessary to have an actual fax machine at home. Our printer already had the capability, but we didn't want to have to pay for a landline in order to be able to use it. In searching for a solution to this, I ran across Obihai, who make devices that can bridge Google Voice service to analogue phones - or faxes, or pretty much anything else capable of making use of dialtone and an RJ-11 connector. As it turned out, this worked surprisingly well, and also proved that usably passing data over VoIP was at least possible. But it left me wondering if it was possible to run a BBS or other modem-based dial-in service over VoIP, a thought which I didn't put any real effort into at the time. Eventually, however, some free time fell into my lap and I decided to put something together to test the idea. The environment that was built used the following: A pair of Google Voice accounts (one for testing, one to dedicate to the BBS) An Obihai 202 Google Voice to analogue telephony adapter A pair of TrendNet TFM-561U USB 56Kbps modems (one for the BBS, one for the machine I'm testing dialup to the BBS with) A V-Tech CD1103WH analogue phone for testing purposes ($6 at Wal-Mart) The VMWare ESXi hypervisor A rotating cast of virtual machines running under VMWare ESXi. The first thing to do was to get dialtone to both the phone jack in my office and the BBS' modem. Configuring the Obihai for both Google Voice accounts, one of its phone ports was dedicated to the test number with the other phone port dedicated to the BBS number. The test number port was plugged directly into one of the house's disused phone jacks, which conveniently brought dialtone to the phone jack in my office; the BBS' modem was cabled directly to its phone port on the Obihai. One of the TrendNet USB modems was installed on the machine on my desk; the other was attached to the VMWare server that the BBS would reside on. The Wal-Mart phone was used to test that calls could be made from the test number's modem to the BBS number and vice-versa. With that out of the way, it was time to build the proof-of-concept. This went through a number of iterations. Frankly, I wasn't happy with any of them, and still haven't settled on a final configuration. For now, however, it's a Windows XP (more on that further down) virtual machine running a mix of SEXPOTS, the NSSM service manager, the ncat general-purpose network connector, and fortune for Windows. It's cobbled together so that the following happens (and all network connections are made on the loopback address): At boot, SEXPOTS starts as a service on its own; NSSM starts ncat as a service. ncat listens on TCP/17. SEXPOTS redirects dial-in sessions from the modem to TCP/17. When ncat sees a session come in on TCP/17, it runs fortune and sends its output over TCP/17 to SEXPOTS. SEXPOTS takes the data it received on TCP/17 and crams it back down the modem to the dial-in session. The person who dialled in sees the fortune printed on their terminal and the session is automatically disconnected. Some notes on why this particular arrangement was chosen follow. Apologies for any gaps in the explanations; I've almost certainly forgotten things since this was initially configured. Windows XP was chosen for compatibility reasons with older BBS software. Yes, XP is an unsupported security nightmare these days, but the VM it runs under is configured without the network adapter connected to a vswitch. Even if it did get 0wned, there wouldn't be much that could be done with it that would be useful since it has no connectivity beyond the modem. TCP/17 is being used for the ncat listener because that's the same port as was originally allocated to QOTD (Quote of the Day). Since this part of the PoC basically replicates QOTD's functionality, I decided to be anal about things and use its port. RFC compliance is Serious Business in an undertaking like this. If I hadn't wanted to use TCP/17 and had instead stuck with the default port of 23 (telnet) that SEXPOTS uses, NSSM and ncat could have been eliminated and Net2BBS used instead. NSSM, ncat, and Net2BBS can all coexist without stepping on each other. This opens up the possibility of having Net2BBS handle connections to the BBS under normal conditions while ncat handles connections to, say, a message informing callers that the BBS is down for maintenance, etc. Just repoint SEXPOTS to the appropriate TCP port that ncat is listening on, restart the SEXPOTS service, and callers get a 'try again later' message when attempting to connect; flip it back over to pointing at Net2BBS to resume normal service. Doing this under Linux by way of mgetty is also a possibility - and, indeed, the original plan had been to do this on a Raspberry Pi. However, the BBS software options weren't exactly what I was looking for under Linux, so it ended up running on Windows. There are some batch files that glue various small but significant things together. In a nutshell, that's how it does it. Now for the 'why'. The more I thought about it, the more I was entertained by the idea of using a (mostly) modern technology stack to replicate the functionality of a communications method and medium that are largely considered to be obsolete - and ones that are particularly relevant to the career path I later took. There was also the 'can it be done?' aspect: this almost certainly wasn't the first time that someone had tried it, but there wasn't any clear record of anyone else having done so. One other thing was appealing in all of this: finding a practical use for old software. There is a surprising amount of BBS software still available, with many packages still being maintained and developed. All they really need is a modem to be useful, and those are easy to get. There are plans to make some changes - a USRobotics Courier 56Kbps Business Modem (which are practically constructed to withstand harsher environments than cockroaches can endure) fell into my lap on Friday, and will probably end up being the BBS modem. This will pull a digital / analogue conversion stage out of the VoIP environment that's introduced by the USB modem, which may help with data rates. Or not, and it will just look completely proper. There is one other thing I want to do with this, but I'm not certain that it can be accomplished in the way that I'd like it to be. But that's for later on

If you're just interested in doing some BBSing, then yes, it's absolutely doable. If you want to avoid service or long-distance charges, here's what I recommend: Sign up for a Google Voice account. Buy an Obihai 202. Configure the Obihai 202 with your Google Voice account. Connect your modem to the Obihai's line (phone) port and go to town. This is the setup I have an experimental BBS running on, and it's very reliable. VoIP doesn't give the greatest data rates, but 9600bps is fairly standard with the odd fluke connection at 14.4Kbps. For most dialup BBSes, that should be fine.

The one other arcade emulator that sticks in my mind from that timeframe was the standalone Xevious emulator that the author (think he may have been Austrian) was trying to get people to pay money for. Didn't really work out for him, and especially not once MAME supported Xevious. There were also the standalone Stern / Konami game emulators from the same guys who eventually merged them into RAGE. Retrocade was kinda interesting, but fizzled out after a while. Definitely agreed that 1995-1996 was where it really started taking off. By '97 or '98 it was pretty much commonplace.

Retro Gaming Design is whatever you want it to be! Just use the power of your imagination! (The secret ingredient is love. And by 'love' I mean 'desperation'.)

I had an HX-20 aeons ago, complete with printer and microcassette drive. Unfortunately, it's long-gone, but here're my recollections of it: They're a neat machine from an historical perspective, but overall practicality is somewhat limited. There's almost no original software available for them. The keyboard is better to use than it might at first look with a nicely-readable non-backlit LCD. BASIC is built-in and is a variant of Microsoft BASIC, IIRC. I think there may also have been a monitor mode akin to the one in the Apple ][, but that may be my memory playing tricks on me. They're really a product of their time - and by that I mean that they're representative of trying to figure out what usable mobile computers would look and act like. That's not to knock them, but if you're interested in them I'd recommend asking yourself if you want it because of its place in the history of computing, or because you want something to use and enjoy regularly. If your answer is the former, you'll probably be better off in the long run than if it's the latter.

Five point fifty-one Cheating for little reward And watching has none

Lacking any pithy Ataribox comments to contribute right now, I thought I'd mention that we found a couple more varieties of El Yucateco hot sauces (the Caribbean and Chipotle) at the semi-local supermercado last night. The Caribbean is... Kinda meh. Not bad, but also just not anything really outstanding. It's far more vinegary than their other sauces, and the slight carrot flavour doesn't really stand out as anything special. It might work well as a cooking sauce, though. We'll keep it around and eventually finish it off, but it's definitely not a go-to. As for the Chipotle, it's pretty good. Doesn't have the heat of their habanero sauces (to be expected), but the spice is pretty reasonable. Not vinegary, which is a plus. Nice smoky flavour to it with definite chipotle taste. Pours thinner than their other sauces, but not in a watery way like Tabasco. The only one of theirs we haven't tried at this point is the jalapeño. It looks as though the same supermercado may carry it but was out; will check again in a few days. Lol penny stocks, etc.

There's always the potential for a Donkey Kong killscreen at Funspot, if you want to see one.

Isometric shooter, similar to Zaxxon in its use of perspective. 'Shooter' is generic enough that the type of player (person, anthropomorphic figure, vehicle, etc.) doesn't really matter in relation to the description, IMHO.

The only hockey that matters is this hockey.

One possibility: there used to be VCRs on the market that would play back NTSC videotapes on PAL TVs without requiring any intermediate conversion. You might be able to find one and use that; if it works, the advantage would be that you could potentially use it with multiple NTSC devices should you end up buying others. There is a caveat to that, though: some VCRs would only convert playback from tape, not signals received via RF or SCART, S-Video, etc. To figure out which models do and don't do that, you'll need to do some research. A number of modern LCD televisions will also play back NTSC (or PAL, or SECAM) natively. However, you'll need to do your own research on that as well since I don't have specific model numbers to hand. However, the cheaper ones generally seem to be more likely to do this than more expensive ones.

In my case, it was probably the Atari 1020 plotter. When I finally received one as a birthday present, I was thrilled. For about a week, I used it to draw all kinds of interesting things. Then I got tired of having to use glue sticks to paste its output down into the things I was continuing to print off on the Epson FX-80 because the 1020's text output was so damned slow. Then the pens started to run out of ink. No matter how many tubes of replacement pens I ordered, at least one pen would have a damaged ball point (one of which tore through the paper) or no or dried-out ink. Then the paper became a pain to obtain. By then I was over it and wanted space back on my desk for the ST that had ended up next to the 800XL. I seem to recall trading it for a couple of cartridges. Something tells me that I made out best on that deal.