cathrynm

Will this card work with DMA, specifically the Drive Turbo card? Or will it also have the same limitation that the AppleSqueezer has? It would be nice to have the ability to work with DMA, even if at reduced speed.

The C compiler does make the Atari side easier relative to old days where everything had to be in Assembler. Showing the image previews would require some Atari specific knowledge, but doing it with text, maybe you could figure out if you have basic programming ability.

My view is that the problem with Atari wasn't that 'CPUs weren't fast enough.' The reason why Mac and PC became dominant is because they kept backwards compatibility in mind, generally. Eventually the very old stuff got abandoned with Apple, but Macs generally could run the previous generation's software. DOS software was still running pretty late in with Windows. Tramiel's went from PET, to Vic20 to C64, to Plus4, to ST, to TT, to Falcon -- all of these platforms had compatibility issues with previous platform. In the early 80's you could get away with this, but going into late 1980's and 90's, this just wasn't going to stand anymore. Users had money invested in their software, and they weren't going to throw that all away for a slightly faster PC. The hint of this should have been failure of Apple 3. Apple backtracked and went to the IIe that was backwards compatible. Radio Shack went down a similar path of making a handful of platforms where compatibility was confusing, I remember looking at catalogs and not really understanding this. This was a dead end. I believe now, looking backwards in time, the key to survival was backwards compatibility, and a quality GUI. Both of these things are hard engineering problems for the time. It's much easier to start clean. For Atari to survive out of the 1990's, they had to solve both of these. I don't see too much evidence they actually cared that much about either.

That Alan Alda wasn't lying when he pitched the Atariwriter on TV. I still have my cart. When we did 'Electronic Novels' at Synapse, we put all the writers on Atariwriter.

I suppose it might be possible on 2E/2GS to plugin a card, that remaps pr#1 to the printer, though I'm not sure if that's the spirit of the thing or not here. I'm not sure what that 'slots' menu on the GS settings does exactly. I believe that remaps the ROM in those slots, but I have no idea what the hardware is capable of, if it can map this to RAM and custom code or not. The stuff the FujiApple guys are doing with SmartPart is next level Apple Oscura. It's kind of makes the device interesting, though maybe not at its full potential yet, I suppose.

I guess he made more off of Necromancer, I'm pretty sure Alley Cat was later. Basically at Synapse the games that made money were the ones that came out early. What happened at the end was the music driver had a bug that broke the games on Atari 1200XL/800XE, stores just returned them all in large quantities, and then the stores all ordered Zaxxon for C64 in exchange. He might have gotten caught up in that.

I guess it's not possible, right? Though I don't know. Fujinet Printer is some kind of SmartPort character device -- which I never even knew existed until Fujinet. That's not, a PR#1 type thing, I think. I've been poking around with it, and have had no luck so far. I did get the Modem working fine from the program on the website.

Really? I saw the same quote on Google, but I had no idea. I made quite a bit more than that with Shamus.

I agree with all this. Old pre-Warner, maybe going into Warner-era Atari had some pretty sharp guys working over there, if they hadn't been idiots, they might have been a contender with Apple even, but by the time of the crash and the Tramiel era, all the software and UI brains had left the building. MacOS and the UI was the heart of why Apple became Apple and it's what mattered. I don't think the Tramiels had it in them to build this kind of software product.

For game systems, SNES was on 65816, Sega Genesis was on 68000, and I don't think it really made that much difference. Both systems had exactly the same games, sometimes, obviously built with the same art, probably from the same source code to both platforms. SNES was a hint, that chip was available cheap in large quantities, but yeah, I don't think Antic/GTIA was on the path to evolving to take on something like Sega Genesis. On the PC side, pre-VGA, games were getting built from C rather than assembly, so anything with 16-color, 320x200, probably might have gotten a conversion if there were enough units out there. It would have fit more in the Tandy 1000 category, I suppose. An upgraded 8-bit with ST-level graphics would have obliterated ST completely, kind of my take. That basic the same games, but people can still plugin their old floppy drives. Would have been a natural upgrade path to all those XEGS buyers, and old 8-bit people. Atari would have hobbled together a GUI of some point, but GEM wasn't that great either. The problem is that it'd have taken slightly longer to design, and that delay might have been a deal killer. On the applications side, Atari was just doomed because of Gem, is my take. The UI was sloppy, the rules for programming a compatible game that would survive upgrades were unclear. They had 68000 just like Mac but they never made the jump to the next CPU, not really. When Atari went to 68030 too much stuff broke and those platforms all failed pretty hard. Tramiels never cared much about backwards compatibility, but by the late 80's and 90's, it mattered. I don't think they got that, and that's why they failed.

I just did a quick google. I'm not an expert on this, but it's just what comes up first. HDMI isn't free to use. https://www.symmetryelectronics.com/blog/what-are-the-licensing-costs-associated-with-hdmi/

C128 was hackish, but it did the job. To me, the logical progression from Atari 8-bit maybe would have been more like the Apple 2GS than the C128. Compatibility with old 8-bit chips built into a single chip, but then a 16-bit 65816 mode with ST-ish/VGA-ish video modes and a SCSI port for hard drive, maybe a blitter. I do think Atari ST had basically a lot of the right decisions for features for the time. Just GEM was a sloppy mess compared to MacOS, and Tramiel had burned a few too many bridges.

That sounds really good as is. That sounds total plausible, that GSOS is spending all its time copying to video memory, I wonder now if emulators simulate this aspect accurately. I like the idea of a real 65816, though I might pick up an applesqueezer too if that shows up on the market. (I'm mostly commenting just so when this gets released I get notified, as I recently picked up a GS and have no acceleration at all.)

And really, Atari 8-bit doesn't need ADC for audio input. It would be enough just to mix audio input with your audio output to handle everything the physical hardware does.

Sounds like you're pretty far along then. Maybe just ship it, or do what you can to turn it into a proper shippable project, cheap and reliable as possible. Account for users unplugging and plugging in cartridges a lot, make sure this doesn't break anything. Maybe ask for help with your noise issue.

I think I prefer 'by publisher'. That otherwise there are too many games, it's that paradox of choice. Too many options makes it less attractive. But, say, if Activision released some weird games that's more interesting because it's part of the story of the company. PUBLISHER->YEAR->GAME,GAME,GAME -- like that. Maybe there are some ambiguous ones that make this a pain, I know Mame has Publisher sorting and it's a little messy with all various mashups of companies.

SIO including cassette tape and audio input, real cartridge port. I don't think anyone has ever had both of these on an FPGA device yet, have they?

My view, most of the company destroying mistakes were on the console side. What they might have done is hire top management who 'actually played the games.' If this had been the case, someone might have noticed that the 5200 joysticks made Pacman, which would have been the killer app for 5200, not quite what it should have been. This was the start of the end. All the pieces were there, but no. I did work with someone awhile back who had worked at Atari around that time, and the project he was on was the "Mindlink joystick." Somehow you were going to strap sensors on your brain and control games with your mind. We knew about this at Synapse because we were doing something simlar with 'Relax' -- so we knew what was going on. This was never going to work for games, but according to the guy I talked to they had huge hopes the Mindlink controller would be the next big thing, but no, it was dumb and I suspect nobody was willing to say anything. The final company destroying blunder was not releasing the 7800 when they had it. It might have saved the company. Basically 7800 + a Pokey chip would have been a perfect successor to the 2600. The system had decent graphics, it had 2600 compatibility, but no, they sat on it. I guess they just didn't know what they had.

Does Fujinet on Apple 2 support Modem emulation? I guess not, I don't see a connector for serial ports coming out of the box. (Not sure if there are pins left for this or not.)

This would be less janky then my bash script. Maybe we could call it 'tcups' -- like tnfs but for cups.

Not in a straightforward way. What makes this work is having a Linux install with a printer configuration that works with your printer. Fujinet isn't Linux. Might work with something like a Raspberry Pi? Maybe a Pi 0?

#!/bin/bash nextfujiprint=$(curl -s -I -X GET http://fujinet/print | grep "^Content-Disposition" | cut -d '"' -f 2) echo -n "$nextfujiprint" > /tmp/.fujiprint while : do fujiprint=$(cat /tmp/.fujiprint) nextfujiprint=$(curl -s -I -X GET http://fujinet/print | grep "^Content-Disposition" | cut -d '"' -f 2) if [[ "$nextfujiprint" != "$fujiprint" ]]; then if [[ ! -z "$nextfujiprint" ]]; then echo Printing "$nextfujiprint" wget http://fujinet/print -O "/tmp/$nextfujiprint" lp -o Duplex=DuplexNoDumble -o PageSize=A4 -o portrait "/tmp/$nextfujiprint" fi fi echo -n "$nextfujiprint" > /tmp/.fujiprint sleep 1 done I know nobody asked for this, but I got tired of downloading PDFs. For me, seems to work on my linux box. I print to fujinet, and this pull pdf files from Fujinet (named fujinet on the network) and send them to my printer. I did get PrintShop to work, not sure why, but the one on tnfs just soft locked at the start, but an ATX I found on archive does work perfectly -- just it's really really slow. Not really fun. I'm trying to remember, didn't these printers have ATASCII graphic characters on them? Thought it might be amusing to just print out some ATASCII art, but for some reason on #fujinet, all my control characters are coming up empty. I swore the Atari 820 and 822 had ATASCII, but it's been a long time. EDIT:Oop, and I google this, and no, it looks like none of these old printers had ATASCII, far as I can tell.

Oh, nice. The CPM, in particular, is a pain to tinker with because it can only have files on SD: and SD: is just a pain to do anything with. Looking forward to seeing this get merged.

I'm sure it's possible, someone just has to do it. (And I have a job still, so not much time for hobby stuff,) I'm just puzzling all this out myself this weekend. It is confusing but it possible to copy files to SD: using fcopy. fhost 1 SD fhost 3 atari-apps.irata.online fcopy 3 Atari_8-bit/n-handler.atr 1 n-handler.atr works What N Device has is the ability to copy from TNFS to/from ATR disks, physical floppies or Incognito hard drive mounts. I can get a file from TNFS to SD using fcopy, but to edit a file on Atari and copy it to SD requires ncopy to TNFS and then fcopy to SD, which works but isn't great. If you don't have a local TNFS server, I'm not sure how you do it.

And this is total unrelated, but I don't want to spam too many topics here. But there's no way to ncd to the SD: card on the Fujinet, I think. NCD N1:TNFS://SD/ NDIR doesn't work. I guess SD isn't a tnfs device but is something slightly different.