jamm

I don't know what to tell you. If you can justify this thing for your extremely niche use case, then go for it. Personally, if "daughter who wants to run PC games with mods" was the use case I was trying to fill, I'd spent a few more dollars for a SFF PC that she's unlikely to outgrow for a couple of years and could use for more than the bare-minimum PC games. Meanwhile, the new Xbox Series S will be out for $300 and in people's hands long before you see an Atari Box in the flesh. New and used PS4's will be cheaper than ever as people upgrade. The world will move on.

Add one more data point to the list: Atari 800 w/Incognito + UAV (NTSC) S-video to RetroTINK to HDMI to recent LCD monitor Obvious jailbars with both the Lotharek and 8-bit Classics monitor cables. Jailbars completely gone with Hercules Workshop monitor cable.

Is there a significant market for parents who can't afford a decent laptop for their kids but can afford a low spec games console for $400? Wouldn't that theoretical market be better served by any of the vastly more powerful consoles out there that have a ton of actual games and are also cheaper? It never ceases to amaze me the lengths to which people go to try and justify this thing's existence.

Damn it. I sprained my eyeballs when they rolled so hard at seeing that story. ?

I don't think @tschak909 was suggesting that this would only be in the N: device. He said "this would be made available to the WiFi Modem and the N: network device". "WiFi Modem" = 850/R: emulation

I don't know that I'd call it a "risk" since nothing bad will happen if you do it. It's been in there since the beginning, so if it was something that you'd easily trigger it would've happened to you already. If you do happen to accidentally fall asleep on the button, all you have to do is hold down the button for a couple of seconds again to undo it.

FYI: A new, somewhat cheaper version of the RetroTINK is now available: https://www.retrotink.com/post/2x-minis-in-stock

This hasn't been updated in almost two years, so progress is pretty slow. The author did post a little update in February that's interesting, though: https://www.lsdwa.com/blog/2020/02/20/fractalus-1-0-progress/

Here is the relevant page from the help file:

I can't be the only person who learned that saying, "a different kettle of fish", from Gilligan's Island... ?

I think you're misconstruing FPGA configuration/write cycles, which can be limited depending on the type of FPGA, with lifespan of the device in general use. If you're not frequently re-configuring the device, then FPGA lifespan shouldn't really be a concern. For example, the popular Altera Cyclone V used in MiSTer has been stress tested to the equivalent of over 250 years without failure.

I keep forgetting that there was a time before this stuff was documented.

Are there many disks that use this type of protection? If the number is small, then the potential impact on older devices is also minimal, and I'd vote for the more straightforward (inline) implementation for the sake of simplicity. As phaeron points out, there are always mitigation mechanisms in those cases anyway. (I'm wondering: since sector data is indicated as an offset to the data chunk, it's hard to imagine an implementation that wouldn't simply ignore/skip the additional data.) You mean by the Extended Sector chunk, right? Is it safe to assume that the actual size of the physical sector will be one of the values currently defined (128, 256, 512, 1024), or might they be an arbitrary size?

I took a look at Synology's build tools. It wouldn't be terribly hard to build TNFSD for it, but their build chain is old and their documentation not great and also obviously out of date, so it would take some work. Different Synology devices use different CPU architectures, so you'd need to set up a build chain for at least a couple of architectures. (e.g. the DS413 uses Motorola/Freescale while the DS412+ uses Intel, which is why they don't support Docker on both.) After all that work you'd have have a TNFSD that would work for some Synology devices but would also be a pain to update/maintain, and it would do nothing for people with QNAP or other NAS devices. I think the way to go with this is for someone who's decent with Python to take the existing TNFSD C sources and re-write it in Python. It would take a little time, but the result would work on almost every device out there and would be relatively easy to maintain.

And you should consider adding multiplayer via networking on FujiNet! You know - to spice things up even more! ?

If everyone is an outlier doesn’t that make no one an outlier...? ?

Gopher is really well suited for this, but the big down side is that it would require setting up custom (Gopher) servers for the purpose and the result wouldn't be compatible with modern clients (not without adding a gopher client front end, of course). Maybe that wouldn't be a big deal, however. I think ideally the protocol would allow for Atari-specific features (colors, images, etc.).

Time for a FujiNet XL (as in "extra large") board! Or maybe a FujiNet expansion board...

Since the A8 version of Print Shop doesn't have color printing capabilities, all you're going to get out of this is very expensive black and white dot matrix printer output (unless you're planning on running multiple passes per print). Is the Okimate 10 the only Atari-compatible printer you have access to?

We've talked about possibilities for this. I don't think there's a reason to create a new standard, necessarily. It could simply be a minimal subset of current HTML - that would automatically make it compatible with current systems. It could also be something that already exists: WML was used for mobile devices in the 90's before they got powerful enough to render plain HTML. The advantage with that is that there is code out there that could be re-used/re-purposed. The possibilities are endless, but someone with some free time will have to take on the task...

The conductive contact (dark circles and lines) on the membrane oxidizes over time - at least it had in my case. I very lightly scraped the top surface of those conductive contacts and my keyboard has been working perfectly all year so far (knock on wood...)

Oh, I see - I'll try that out, thanks. Thanks for the clarification!

Thanks for the replies, @ijor - I assumed many of these were due to old/early versions of programs generating different output. Since these ATX files are in a "preservation" archive, I thought it'd be useful to document cases where we might want to re-archive those particular entries if possible. I did check, and none of the tracks have the MFM flag set. Out of curiosity, I went ahead and did a quick check of the ATR files in the archive, too. Here are a couple of issues I found: Napoleon in Russia (1988)(Datasoft)(US)[!].atr This is actually an ATX file. Silicon Dreams (1986)(Firebird)(GB)[!][req 64K].atr The number of paragraphs is wrong in the header (it's recorded as 0x1680 but it should be 0x2080). The similarly-named "Silicon Dreams (1986)(Rainbird)(GB)[!][req 64K].atr" is actually identical to this file, except it has the correct number of paragraphs in the header.

As part of the work done to add ATX support to FujiNet, I wrote a little ATX parser/analyzer program. Source for this is available here: https://github.com/kaelef/Atari-ATX-Parser I'm providing some notes below based on what I found in the ATX files included in the January 25, 2020 version of the Atari 8bit Preserved Software archive. All my notes are based on the documentation provided at http://www.a8preservation.com/#/guides/atx which I assume is the most accurate source of documentation available on the ATX format. Also, can someone provide a list of what programs are responsible for each of the "creator" codes found in the ATX headers? Here's the list I have, including both what's documented and not, based on results of files in the archive: $01 TX_CR_FX7 $02 ATX_CR_FX8 $03 ATX_CR_ATR $10 ATX_CR_WH2PC $74 UNKNOWN There are several cases where the UNKNOWN_SKEW (0x0100) flag is set on tracks. What does this really indicate (i.e. how should that be handled, if at all)? Ignoring it seems to have no negative repercussions. ATX Header End Field and Host Records Creator 0x10 (ATX_CR_WH2PC) adds a HOST record at the end of every file. The contents of this record are undefined in the documentation. The size of the record (8 record header bytes + 40 bytes of data) is not included in the ATX header "end" value. Whether or not this is a bug is debatable since the "end" value isn't clearly defined, but it seems to me like it should be included. In all other cases, the ATX header "end" value is equal to the size of the ATX file itself, so it serves as a nice verification that the whole file is present. ATX Header End Field Incorrect There are a couple of instances of images with creator ID 0x01 (ATX_CR_FX8) where the ATX 'end' field off by 8 bytes. In all other cases, the 'end' value correctly matches the size of the entire image file. Examples: Colonial Conquest v1.1 (1985)(SSI)(US).atx (8 bytes short) Metric and Problem Solving v1.2 (1982)(APX)(US)[f][BASIC].atx (8 bytes over) Action Classics - Volume I (1987)(Activision)(US)[!].atx This is not an ATX file - it has an ATR header. Bad Angular Position Values There are several instances of images with creator ID 0x01 (ATX_CR_FX8) where the angular position of a sector is greater than the expected maximum of 26041. Interestingly, with only a couple of exceptions (see below), this only happens 17 sectors into the table. Examples: Adventure on a Boat! (1981)(subLOGIC)(US)[f][BASIC].atx Tracks 13, 27; sector index 17 Blue Max - 2001 (1984)(Synapse Software)(US)[f].atx Tracks 10, 13; sector index 17 Drelbs (1983)(Synapse Software)(US)[f][OS-B].atx Track 2, 5, 6, 10, 14, 17, 22, 23, 26, 31; sector index 17 Laser Hawk (1986)(Red Rat Software)(GB)[f].atx Tracks 1, 11, 13, 37; sector index 17 Pac-Man (1984)(Datasoft)(US)[f][!].atx Tracks 2, 7; sector index 17 Tracks 5, 10; sector index 18 Print Shop Graphics Library 1 (1985)(Broderbund Software)(US)[f][!].atx Tracks 0, 4, 10, 11, 13, 16, 22, 26, 28, 32; sector index 17 S.A.G.A. #06 - Strange Odyssey v5.0-119 (1982)(Adventure International)(US)(Side B)[!].atx Track 0; sector index 15 Track 7; sector index 17 Spaceport (1983)(Umbrella Software)(CA)[f].atx Tracks 1, 4, 12, 15, 18, 24, 27, 30; sector index 17 Spy vs. Spy Vol. II - The Island Caper (1985)(Databyte)(PAL)(GB)[XL-OS].atx Tracks 1; sector index 17 Zeppelin (1983)(Synapse Software)(US)[f][810 only].atx Tracks 0, 1, 6, 15, 20, 21, 23, 30; sector index 17 Undocumented Sector Flag There are several instances of images with creator ID 0x01 (ATX_CR_FX8) where sectors are marked with bit #2 (0x02). The function of this flag is not documented, and it doesn't get set by any other creators. This only seems to happen in cases where the CRC_ERROR (0x08) and LOSTDATA_ERROR (0x04) flags are also set. Examples: Boulder Dash II (1985)(Databyte)(PAL)(GB)[XL-OS].atx Track #37: Sectors that also set the CRC_ERROR and LOSTDATA_ERROR flags Mr. Robot and His Robot Factory (1986)(Databyte)(PAL)(GB)[!][XL-OS].atx Track #37: Sectors that also set the CRC_ERROR and LOSTDATA_ERROR flags Spy vs. Spy Vol. II - The Island Caper (1985)(Databyte)(PAL)(GB)[XL-OS].atx Track #37: Sectors that also set the CRC_ERROR and LOSTDATA_ERROR flags Random Angular Position Values There are several instances of images with creator ID 0x10 (ATX_CR_WH2PC) where the angular position for most of the sectors seems completely random and often greater than the expected maximum of 26041. Throwing the values out and replacing them with '0' allows the game to load. Examples: Crisis Mountain (1982)(Synergistic Software)(US).atx Galactic Chase (1981)(Spectrum Computers)(US).atx Lords of Karma (1981)(Avalon Hill)(US).atx Invalid Sector Numbers There are a couple of instances of images with creator ID 0x01 (ATX_CR_FX8) where sectors have an invalid sector number. These are marked as single density disk images, however, several tracks include sector numbers greater than 18. Since the invalid sector numbers only go up to 26, it seems like the individual track is MEDIUM/ENHANCED density, although it doesn't have the expected MFM flag (0x02) if that was the intention. Examples: Max + Magic World (1997)(Sikor Soft)(PL)(Side B)(Magic Word).atx Track 37: Sector numbers between 19 and 26 Track 38: Sector numbers between 19 and 26 Moscow 1993 (1994)(Sikor Soft)(PL)[!].atx Most tracks have sector numbers greater than 18. Maybe this one simply has the wrong density header value and should be marked as "ENHANCED DENSITY". I tried changing just the density header value, but it still wouldn't load in Altirra.

By the way - the Altirra Performance Analyzer is amazing! I'm embarrassed to admit that I had know that incredible feature was hiding in the menus...