FISK – It's a floppy disk fax machine
twitter.com
twitter.com
I believe there is one in the NSA museum as we did a version where the serial link between the modem and UART was broken out to the back so an encryption unit could be plugged in (I seem to recall it was used to send details of PoWs during the Bosnian conflicts)
One odd major use area was for sending disks with patterns for knitting machines around the world.
Oh and for those with a Sinclair fetish the case was designed by the Sinclair designer Rick Dickinson.
I've been looking for a DiskFax machine for a long while, in fact I think it was my searches for that that ended up finding this one (on ebay).
That was a few years before the FISK, right? (FISK was ~1993). What was it internally? Something like a 6502/Z80 ?
Memory was 128K of Intel flash with 8K fixed boot partition and 64K of RAM.
Z8530 for the UART, Rockwell chipset for the fax portion. I seem to remember lots of messing around getting the parameters correct for the filters to detect dial tone for various european telco approvals. There was also a pass through port to allow plugging a fax machine in the back (can't remember how that worked though)
I can't remember what we used for the floppy disc controller (I seem to recall we supported single density floppies so we didn't use a multi-IO chip) and later models used a IDE drive with a 16->8 bit converter card.
Somewhere I probably still have the schematics.
I'd love to see those schematics if you can find them!
More loosely, it's also reminiscent of the Commodore disk drives that had their own 6502-class CPU and a software interface to upload code. Some developers used this to create "fast loaders" that bypass the slow stock communication routines.
Yet it was so astonishingly slow, it was a laughing stock among junior high school kids.
Total garbage compared to the Apple II drives designed by Woz, which were just dumb hardware, combined with a logic state sequencer" on the circuit card and registers for step motor control.
That's why there were so many products for the c64 to fix it: Epyx Fast Load cartridges, for example. And plenty of games worked by having you first load a very simple file that just installed faster disk IO code and then used that code to load the rest of the game.
That's basically what Disk II drives did on the Apple II, just for EVERY (bootable) DISK instead of only some of them: The first bootloader is encoded in a simplified method so that they can save firmware space, but the first bootloader is just better disk IO routines to load the rest of the disk.
It sucks, but it's nice that the computer could patch the disk drive at run-time and have it run some more sophisticated software for a speed boost. For example, the Action Replay 6 comes with a "fast loader" that performs some 18 times better than the kernal loader and stock 1541 firmware on normal CBM formatted disks. Still not as quick as Woz' Disk II...
It got even worse when Commodore shat C128D out its engineering hole. 3 CPUs for the low low price of 3 CPUs, two doing nothing 99.999% of the time, all in all 85% of Amiga 500 price, 100% of Atari 520ST price, at 10% the power.
Nintendo made consoles cheaply enough to make a profit, because they weren't designed to be powerful enough for the games that would be released at the end of the console's lifecycle, only the games that would be released near the beginning. But they managed to release games as if the console was more powerful anyway. It was basically because the cartridge was a black box, and could contain anything up-to-and-including its own replacement console. Early-in-lifecycle, game cartridges were just a board with plain ROM chips on it, containing instructions to run on the base hardware; but late-in-lifecycle cartridges included all sorts of other chips. (A game released late in the life of the SNES included a full ARM core, several times more powerful than the SNES's own CPU! Though it only used it to draw a few vector animations in a couple scenes of the game...)
The Famicom Disk System and 64DD were "just" cartridges as well, from their host-console's perspective. And I don't mean that there was a complex dance where the FDS/64DD were running a DOS on the host-console's CPU that sent disk commands back to the drive; that logic was all internal to the drive itself, running on their on-board CPUs. It went even deeper than a memory-mapped IO port or an drive-command wire protocol; the console just didn't direct the drive at all. Rather, the firmware executing on the drive detected when the console would want new data, and DMAed in the required data itself, so that, from the console's perspective, the data was just "there" to see. (A bit like the NES's memory-mapper chips, but for full ROM banks rather than little word-sized windows.)
The closest comparison I can think of to how those devices worked, would be to using one of those aux-to-tape adapters—from the tape reader's perspective, the right data is "just there" when it goes to read it, as if it was a regular tape. In this case, the right data was "just there" in response to bus reads of ROM parts of the memory-space on the cartridge port. These devices were, effectively, the original "flash carts."
This design paradigm has culminated in some pretty ridiculous things embedded into a Nintendo cartridge, actually. There is a Nintendo DS flash cart that embeds a full GBA-compatible CPU core within it. Since it's in the wrong port to deliver GBA games directly to the DS's own GBA-compatible CPU core, it just "brings its own" CPU to emulate them on instead.
I can't find that much information but you're either talking about the Supercard or the CycloDS - both look like they were running emulators. Almost makes me want to find out if it's possible to put an ESP8266 in a cart.
Edit: Ok, I read a bit more about the thing that you sent and it looks like it does actually fulfil that particular need. Very interesting!
This is a nice one, throw it up there and they give you a link, link works once.
2: Select File>New, or "Create new torrent", or whatever.
3: Pick the desired source file.
4: Create the torrent (and open it and make sure the source file is in the destination folder if your client didn't do that on it's own (you want "download finished, seeding to 0 peers")).
5: Right click>copy magnet link, then paste into whereever.
6: Other person downloads the file just like with any other magnet link.
It's obnoxiously unergonomic and rather slow (especially if your clients have to track down each other's IP addresses via DHT), but it's not actually hard.
I'd love to see LGR or Techmoan do a video on this thing.
-> just got the most secure 2 peer communication device.
Probably you can fit it on a usb stick with a slot for a SIM.
Actually not a bad idea for a startup. Who's in? :)
I'm not affiliated with them, I just think it's a good match.
There are three patents: https://patents.google.com/?assignee=Fisk+Communications+Inc
Somewhere in a box I still have a 802.11b wifi router with a built in 33.6kb dial up modem, which was the perfect thing at the time.
They got this wrong.
In the days when FAX was used for things like sending purchase orders, what was needed was a means of putting a file on a floppy, walking to the FAX machine, then sending off a 'PDF' from there, removing the need to print out the form first.
Faxes were still sent a decade ago for this type of task, however, in a big office you had just the one physical FAX machine rather than everyone having a MODEM at their desk. It would take a little while to get things printed and shoved through the FAX machine, saving to disk would have cut down on the paper and enabled clearer documents to be sent.
For regulatory compliance reasons these systems are still in place in large banks, insurance firms, and law firms.
I'm planning to videoify it in the future, if that's more your style.
[1] https://threadreaderapp.com/thread/1050258171317510144.html
With its very own horrible rap video with Flight Simulator in the background.