jamm

I didn't see this posted:

It's possible, but it would add another layer of complexity and isn't currently planned for. As @tschak909 notes, it would open up a whole new set of issues. For the time being, we're going to let you grab the output from FujiNet's web interface and let your desktop or mobile operating system cope with printing to a physical device and all that entails.

Have you considered asking this question in the 5200 forum? I imagine there are more people with 5200-specific experience there.

How are you determining if there's a difference? HSIO 0 is twice as fast as the default value. If you're only testing against TNFS servers on the Internet, then you may not notice a difference because of Internet latencies. The difference should be pretty obvious if you're loading off a local server or SD card. Also, if you're testing with ATX disk images, the HSIO is always disabled to properly emulate normal disk timing. Try ATR or XEX files for comparison. The best/optimal setting is '0', unless you have problems. SpartDOS won't work at 0, for example.

Thanks very much for the offer! I'll contact you via PM.

Good point - I should've mentioned that I'm in Tucson, Arizona! Thanks - that's great info. I'm assuming Atari BBS's are running on the UDS primarily, but we'll definitely have to get details on the particular model.

We've gotten reports that FujiNet's modem emulation sometimes hangs when communicating with Atari BBS's online. We haven't had luck getting this to happen in other modem tests, and we're assuming these all have a Lantronix servers on the other end. If anyone has one of these that they could spare for a few weeks to test, it'd be greatly appreciated!

A person like that is 100% ego-focused. It wouldn't matter if it cost him his life's savings, he'd still pursue fixing his "reputation". Half the time I think people like that get what they want despite being in the wrong simply because no one else cares nearly as much.

If any part of the firmware isn't building, then obviously there's something fundamentally wrong with the setup. I recommend deleting the project directory entirely and starting with a fresh download of the v0.1.ccbb292f release.

The BOARD_HAS_PSRAM precompiler flag is used in several places in the source code. Since WROOM doesn't have PSRAM, it should not be defined, so it looks correct. The boards/fujinet-wroom.json file is correct in the v0.1.ccbb292f release, so you shouldn't have to do anything other than specify the correct ENV value in your PLATFORMIO.INI. This is well commented in the PLATFORMIO.INI file.

Ouch. What happened to the Vita really breaks my heart. Hardware-wise, it's practically the perfect handheld, with the proprietary storage as the only obvious negative. I have a Switch, and it amazing to me how much better the Vita is in most respects given how much older it is - particularly as a mobile device. I think what happened with Vita is partly due to Sony not supporting it as much as it could have, and, of course, Nintendo having the world's finest first-party video game IP. If Microsoft gets their act together and becomes dominant (if nothing else, they have the cash to simply continue buying development studios until they get there), I hope Sony and Nintendo combine their strengths to create a new generation of devices. Fan-dreaming is fun!

For unrelated reasons, I was just looking at the commenting history attached to my user profile on another forum. It goes back over a decade, which triggered my "oh no, what stupid embarrassing things did I write 10 years ago??" response... Anyway, there was a heated discussion 8 years ago on this Engaget article: "Ouya's success is opportunity missed for Microsoft, Nintendo and Sony" which, to others and myself, seemed like the author was jumping the gun rather significantly given that the Ouya hadn't even been released yet. Sound familiar? It's too bad Engaget seems to have cut out all the old discussions for the articles, because it'd be fun to see what everyone had to say. You can imagine a lot of similar stuff from what's been said regarding this latest incarnation of "Atari". I can't see the comments I was responding to, but here's a couple things I said back then where you can imagine what the original comment was: That last reference to Phantom Entertainment's "Phantom" console was something I'd completely forgotten about. Quote from Wikipedia article regarding the Phantom: "On May 16, 2006, the Securities and Exchange Commission accused Phantom Entertainment founder and former CEO Timothy Roberts of running a "pump and dump" scheme in promoting the Phantom console in 2004." I expect we'll continue to recreate this amazing new "low end, PC-based console for everyone else" every few years and everyone will think it's a fresh new idea.

That's amazing. I had no idea the cloners could build the stuff that much cheaper.

I'm not saying I condone it - I'm just saying I understand the motivation. At least when we're talking a once-$70 game that is now going for $300 or whatever.

At least there I understand where the prices are out of control. I don't think there's anything like that going on with A8 hardware mods.

It's amazing to me that there's enough of a market out there for this stuff to make cloning worth the effort. It's also amazing to me that, knowing the problem exists, people in the community - in whatever country - are willing to bypass official sellers to get things cheaper. Are the clones able to make working devices cheap enough to make it worth it for the buyer and still make a profit?

Mnemonic IDs make sense to me. Since these are unlikely to have a purpose in real-time use (i.e. change the behavior of an ATX reader) and are more for tracking down potential bugs, IMO, why not use the already-established "Data Record" structure of ATX files and either create a new "Creator" data record or use the existing "Hots Data" record? That strikes me as more consistent than adding an extra block of metadata at the end of the file. True enough, although I do think it'd still be useful from the software preservation aspect. I think the calculation would only be interesting in the case where an archiving program is creating an image from its source. Any modifications after that don't necessarily have to be documented by a flag or such, since it'd be evident there was a change from the hash mismatch. The hash doesn't make much sense for programs that simply create an ATX as another form of "blank Atari disk image" in lieu of ATR (I believe RespeQt is able to do this), so those might simply leave it blank. Let's take inventory of what current metadata falls into that category: Creator code MD5 hash (potentially) I can't think of anything else, really. Although there's other metadata in the file, one would expect those other values to change as needed (e.g. if the sector count or density were to change, etc.) I can't think of any cases where a "MODIFIER ID" would be useful. For simplicity's sake, I would argue that if a program modifies an ATX file, it should change the CREATOR ID to it's own value, and then optionally change the MD5 hash if that were also included. It could also leave the MD5 alone: just the fact that it no longer matches is indication enough that we no longer have the original file. In that usage, the MD5 becomes "The hash value when the image was created from the source media", rather than "The currently correct hash value". In that sense, it works a bit more as the currently-unused "IMAGE ID/IMAGE VERSION" header fields. Again, I'm assuming that no one is really going to care about any hash value except for cases of software preservation where they want to make sure they have the original or same disk image as was originally created. If the MD5 doesn't match, then who modified it and why seems unimportant - they're going to keep looking for the original/correct one. Or it could be even simpler and leave all that out...

I like the idea of knowing if the file has been modified, but I don't know that knowing it's been modified X times is useful. I think it'd be of more practical use to have an MD5 hash stored when the original ATX is created and then have a second MD5 hash stored when/if the ATX is updated along with an ATX creator ID for that second value. That would give us verification that the file has not been corrupted and that it's been modified. Of course, that would require either an extra header value, or use of some of the reserved bits, or a separate ATX record.

I get the feeling that people who are genuinely excited about the Atari VCS are a bit or a lot out of touch with what's been going in in gaming from the days of the Ouya release to today. The only thing new thing the Atari VCS is bringing to the table is a logo. And that's old, too - just revered. Much of the same "I don't care if it doesn't do the latest games, at least I'll have a cool, all-in-one media box" arguments where also flying fast and loose about Ouya. Also the "I want a box I can emulate old games on", and "people want the 2D gaming experience but with modern games." That device was created by a lot of people who really wanted it to succeed, cared about gaming, contacted and made deals with real (mostly indie) developers, and supported it as well as they could. The VCS doesn't have any of that.

Has there been any news on the source code situation? Does Julian need to keep it closed, or is it being made available somewhere? I'm dreaming of a cross-platform networked MULE.....

Don't worry - this doorstop will address any current and future problems through the power of BLOCKCHAIN! It's the magic technology that does it all!

You need a PC TNFS client. I'm not aware of one that exists. I've been meaning to write one, but just haven't had the time. It's a simple enough project that really anyone should be able to take on. There's both decent documentation and sample code in the Spectranet project that TNFS comes from.

This isn't meant for hard-core doorstop users.

"Atari never said they were going to deliver an actual door stop - just the idea of a door stop with an Atari logo on it. And that's all I ever wanted, so I'm thrilled with my purchase!"

FN doesn't have the kind of hardware control over the Atari that cartridge-based additions do, so what you're describing isn't really possible. "Safe reset" (AKA "shutdown and restart") using a long press on button B is a good practice to get into if you ever start opening ATRs in read/write mode. If you simply turn off the FN, it doesn't have the opportunity to properly close ATRs in read/write mode, which might lead to corruption or loss of recently written data. Same as turning off any modern computer without performing a proper shutdown.