Many years ago I was involved in a product called DiskFax which was similar. Used a fax modem which gave 9600bps even over crappy links like satellite.
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.
8088 internally with a custom ASIC for the board support (no DMA). I think it launched in 1990.
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.
Very neat! That sounds like it's pretty similar to this one then. I wonder if the FISK was directly inspired by the DiskFax? I'm hoping to get in touch with the designer so I may have some answers soon.
I'd love to see those schematics if you can find them!
I used to hang out with a British guy who invested in the DiskFax product and was also the distributor for Singapore and the APAC region, in the early 90s. Was a flop, though he sold a few to media/ad agencies that needed a simple way to transfer Mac DTP files to their various offices. This was before the advent of email, and sending files via modem between computers was a chore.
The "oh look, this disk drive is actually a whole PC" aspect reminds me of the "Mr. Backup Z64" copier for Nintendo 64. It had a 386-class embedded PC running a ROM-based DOS system to operate the internal Zip drive. Since the Zip drive sat on a standard ATA interface being driven by DOS, it could be replaced with a hard drive or CompactFlash slot.
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.
"This disk drive is actually a whole PC" was basically Nintendo's entire Unique Selling Proposition for a long while.
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.
>There is a Nintendo DS flash cart that embeds a full GBA-compatible CPU core
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.
Apparently they initially intended for it to have a fast parallel connection which would have meant a huge gain in speed, but they ended up with a serial bus on the C64 to be compatible with VIC-20 disk drives. This was supposed to be offset by hardware that could maintain a high serial speed, but the design ended up half broken, which they had to amend with the slow software routines before release.
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...
The drive itself was actually very powerful and capable, it just was very limited by having to talk to the C64 using the Vic20-compatible interface, which had issues.
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.
In 1983 C64 was $300, 1541 was $300, 180K Tandon TM100-1 PC floppy drive was $189. Why sell cheap floppy drive when you can sell one for the full price of your computer and double the profit? Commodore was manufacturing all mayor chips inside it after all ;-/
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.
In 2018, transferring large files over the internet is still not exactly straightforward. Few years ago Skype was excellent for P2P transfers of very large files, but since then they removed this feature, and today Skype's file transfer limits are ridiculously low. Using Dropbox or Google Drive for that requires a pre-paid amount of cloud storage space: you can't really stream anything directly with any well-known widely available layman tool.
I think OP means sending files to someone over the internet. Like, if I wanted to send you, a complete stranger, something over the internet, then the options we could use are very limited. There's pretty much nothing that works on p2p basis, I'd have to upload it to something like google drive or mega first.
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!
I never thought of something like this existing but it seems obvious now and I'm surprised I haven't seen one before. The fact that PCs had these capabilities built in was I guess enough to kill it, but that didn't stop actual fax machines from clinging on to life for far too long - I suppose they had momentum.
I'd love to see LGR or Techmoan do a video on this thing.
I'm always surprised that cheap satellite text messaging has never become a thing. All these new cheaper satellites, you would think it would be the ideal low bandwidth application. But lower the prices and greater abundance never quite happened.
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.
This product seems to be more about sending a file to another FAX machine that accepts files, presumably so you didn't have to own a MODEM.
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.
In Some places 'eFAX' is still a thing, where the staff members can email a PDF (or Word doc etc.) to <number>@<faxmachine.local> and it gets sent out of the building as a FAX over POTS. For incoming FAXs, users register their email address against a phone number or extension, and get incoming faxes as PDFs in their inboxes.
For regulatory compliance reasons these systems are still in place in large banks, insurance firms, and law firms.
A few people have mentioned that! I'm keeping my eye out for a second one, so if I find one (or I figure out a way to talk to off-the-shelf hardware with this one) I'll send it his way and we can exchange disks.
There are definitely services that just do a basic stitching so that it reads like a giant paragraph but it would be neat to see it truely translate from a tweet thread to a blog format beyond just a basic concatenation