jamm

I have the 8bitcalssics cable, too. I'm seeing jailbars using either that or the Lotharek cable, so I assume my issue has to do with my UAV upgrade not having gone quite perfectly on my Incognito 800.

That's too bad. I got one of these, too, and they do look very well made on the outside. Anyone have a source for properly-shielded cables?

Thanks for this! Do you have the actual physical copy of the brochure? It'd be great to get a better scan of it. I converted the images you posted into a PDF for easier reading. Infocom - Our Circuits, Ourselves.pdf

We're really focusing on the commercial aspect of this, but I don't think that there are many people who disagree that a.) no one wants to take anyone's rights away, and b.) there isn't a viable commercial market for this product anymore. The real question and point of this thread is whether or not we can get open access to the source code to SpartaDOS, as that would be a benefit the Atari community in a variety of ways.

I don't believe anyone is trying to take anyone's rights away. There's no market to sell SpartaDOS to anyone. If there were, someone would be doing it today. It's just a question of sharing history and information with fellow hobbyists and possibly making it a bit easier to extend the lives of these old computers a few years longer.

Is he still active anywhere? Has he expressed any opinion one way or the other regarding opening up the source?

A few points: There's no where to store a "displayname". We could add that, but keep in mind every new bit of information we add and need keep track of requires changes not only in the Atari code, but in the communication protocol between the Atari and FujiNet (SIO commands) and then in code on FujiNet to store and reload all that from the configuration file. It's not rocket science, but it's also not trivial, so it has to have some pretty good utility value to be worth the effort. Once we get beyond just TNFS and SD, we'll need a way to specify the host "type" or "protocol". Since there will be short number of these, I think it's easier in every way if it's provided as a selection list rather than a free-form type in field. The same way the current "New ATR Disk" sizes are currently presented. Another thing we're having to balance is adding bells-and-whistles to the Atari CONFIG program while keeping the size down so that it doesn't take too long to load every time you want to make changes. The purpose of CONFIG is just to get you set up to actually use the programs you want to use. It should do that as quickly and efficiently as possible so you can get on your way to using the "real" software you're trying to load. CONFIG shouldn't be the end-all and be-all remote storage access program. Don't forget there will be other ways to do things outside of CONFIG. On the Atari side there is the N: handler and all the functionality that brings, and there are a bunch of additional tools @tschak909 has created in the FNC-TOOLS disk. On the FujiNet side we can add functionality on the web interface to handle certain tasks where it makes sense.

So what's the current ownership status of the code? I lost track way back in the original FTE days...

I do find the smaller text actually easier to read.

Also does wonders for keeping most others off your computer!

Since the filtering is actually performed on the TNFSD side, a small change was required to TNFSD. The latest version now does case-insensitive pattern matches and is available both in the GitHub repository and at https://fujinet.online/firmware-dl/

There's been a huge growth of the mechanical keyboard market the last few years. While I would've agreed that quality PS/2 keyboards were the way to go some time ago, that's not really true anymore. Excellent mechanical keyboards exist in a dizzying variety of configurations now, most of them won't wake the neighbors when you're typing, and they're basically all USB. That's not even counting the countless variety of custom keyboards that are being released in small quantities pretty much all the time.

The letters actually don't matter - they're more there for human readability. It's only the number that matters. For example: MST+7 -- This says you're 7 hours west of UTC and you don't observe DST MST7 -- This is the same ABC7 -- This is also the same XYZ7 -- Same... ARIZONA7 -- Same! MST-7 -- You're 7 hours east of UTC, probably somewhere in Russia or Vietnam MST+7MDT -- This says you're 7 hours west of UTC and that you change your time by 1 hour during DST MST7MDT -- This is the same MST7MST -- This is also the same MST7ABC -- Same! ARIZONA7WILDCATS -- SAME! The reality is that time zones, and, more importantly when DST time starts and ends for your particular region, are not only complicated, but they change from year to year and region to region. So there's no reliable way to compute them without a database or rule set that describes them, and that database needs to be updated as things change. "Full size" operating systems will have a database like this from which you can pick a location (e.g. "USA/Phoenix") and the TZ and DST rules for that particular location have been helpfully provided by someone. They'll be out of date (ha!) sooner or later, so unless updates are provided somehow, you'll find the operating system will not switch to DST time on the correct dates. Notice in the examples above we didn't specify when DST starts or stops. There are built-in defaults: if you specify any letters after that number, then you observe daylight savings that changes the time by one hour starting on the first Sunday in April at 2:00AM and ends on the last Sunday in October at 2:00AM. (The specific defaults chosen can change from one operating system to another.) If those defaults don't work for you and you want to provide the correct details, you can do so like this: MST+7MDT+6,M5.1.0/01:30,M9.1.0/1:30 That says you're 7 hours west of UTC during standard time, and you're 6 hours west of UTC during daylight savings. Daylight savings starts on the first Sunday of May at 1:30AM and ends on the first Sunday of September at 1:30AM. The "MST" and "MDT" there are just to give humans something to read. Anyway - I thought that was an interesting diversion... We'll put a drop-down list in the web interface to make it easy to pick something for most people, and you'll be able to override it manually if those options don't meet your needs.

I added a couple of font files that probably put things over the edge on WROOM boards. If you remove the two TTF files in the /DATA/WWW folder you should be fine and it won't affect operation.

The N64 and GameCube were underpowered compared to the competition. The difference is, by the time the Wii came around, it was clear that Nintendo had made a conscious decision to not try to fight Sony and Microsoft on the hardware front. You might say the same thing about the GameCube, but I think with N64 it was just a case of underestimating how Sony was going to shake up the market. The N64 was released in mid-1996, while the PlayStation was out late-1995. It couldn't be designed to be "on par" with PlayStation because there was not enough time to make significant changes to the N64 and the PlayStation represented a new direction for console gaming. Edit: I got the date wrong on the PS release - it was out in late 1994 in Japan. So I don't know what Nintendo's excuse was for not doing better than they did with the N64 other than they were the undefeatable market leader at the time. (Though you could still argue that they didn't have a lot of time to react to PS.)

Just to add to what @tschak909 said above and maybe elaborate on what I said before that: TNFSD does no enforcement of security itself. Therefore, all the security enforcement must come from your operating system's file security settings in the folders you've given TNFSD access to and the rights it has by virtue of what user context it's running in. Obviously you don't want to run TNFSD as root or Administrator...

A foretold by the prophecies, the next firmware update will provide a simple mechanism for changing FujiNet's HSIO index setting via the web interface. This will, of course, make its way to the Atari config program later on.

Please do not put anything on TNFSD that you don't have backed up elsewhere. Little to no effort has been put into securing that code (either by the original author 10 years ago or us in our recent additions), so assume any folders you expose via TNFSD are public and may be destroyed/altered. Professionals get this stuff wrong even when they're trying, and we're not even trying...

I'm curious how long that would take to print on a real 1020, but I'm not willing to sacrifice one to find out...

I have to admit, it's kind of a kick that you guys are able to share Atari files directly now. ?

Think of all the money you saved by not wearing those little pens down to even smaller nubs.

We talked about this on a side channel, but for the benefit of everyone else: the problem only presents itself at POKEY/6, which is currently the high speed mode FujiNet defaults to in order to maintain compatibility with SpartaDOS. POKEY/0, and probably other high speed modes, don't seem to be a problem. This will be addressed indirectly when FujiNet gives you the ability to change the high speed divisor setting manually. Coming Soon™

All the details, including the XEX in question, are just a couple of messages above this one. I don’t know enough about what’s happening in Yoomp’s loading routines to say what’s happening, but it clearly behaves differently when different SIO speeds are in play.

Well, I'm pretty glad you raised it. I wasn't aware of that particular behavior in some software, so it's good to know for next time someone asks. Plus, we know your WiFi is solid. And it's good to know someone's actually testing things out. We honestly need more of that. This also raises the issue of allowing you to change the SIO speed dynamically via the web page. Something we talked about a while back but hadn't gotten around to yet.

And I just tested with RespeQt. It also fails and freezes at POKEY/6 and works at POKEY/0. FujiNet is the only one that seems to handle switching back and forth between normal and high speed SIO properly when the latter fails. At least in Yoomp. Here's RespeQt's output at POKEY/6: Serial port speed set to 68522. [AutoBoot] Get status. [AutoBoot] Read sector 1 (128 bytes). [AutoBoot] Read sector 2 (128 bytes). [AutoBoot] Get chunk 0 (287 bytes). [AutoBoot] Get chunk 1 (2 bytes). [AutoBoot] Get chunk 2 (352 bytes). [AutoBoot] Get chunk 3 (256 bytes). [AutoBoot] Get chunk 4 (128 bytes). [AutoBoot] Get chunk 5 (422 bytes). [AutoBoot] Get chunk 6 (2 bytes). [AutoBoot] Get chunk 7 (61 bytes). Serial port speed set to 19200. [AutoBoot] Get chunk 7 (61 bytes). Serial port speed set to 68522. [AutoBoot] Get chunk 8 (123 bytes). Serial port speed set to 19200. [AutoBoot] Get chunk 8 (123 bytes). [x5]