Modern printers with CP/M

[Eudimorphodon]

A go-tech is even tough to swallow, though necessary. But if I can run a Diablo 630 emulation on an rPI connected to my Kaypro serial port, that's a fair solution.

If it helps rationalize these things at all, there was a fighting chance all the way into the 1990’s that a peripheral you bought for your computer would have a more powerful CPU in it than the one you were running your word processor on.

(For instance, even the original HP LaserJet had an 8Mhz 68000 in it, when there was a good chance the computer it was going to be used with was a 4.77 mhz 8088. Postscript started an absolute arms race for ramping up CPU speeds in printers, if you had a RISC CPU on your desk before 1995 there was probably a better than 90% chance it was in your printer.)

 

[Istarian]

I am not fond of "just network everything, put a modern computer in the middle, doing all the heavy lifting". To me, a physical 8080 machine with a 160 MHz frontend (for network downloads) and a 700 MHz backend (for processing and rendering) is wasting a perfectly good machine. Trying to sell it as "my Altair 8800 can surf the modern internet, look" feels like lying, not retro or vintage computing.

I share the general sentiment about not reducing the retro computer to being an veneer, but what you describe is inevitably the easier route and depends more on software approaches than on really understanding fundamental principles of electronics and low-level details of hardware.

The only alternatives that come readily to mind are:
- asking the retro hardware to work really hard at gettingthe job done slowly
- design and build/implement an interface box/unit of some sort that does at least some of the work without involving an entire operating system and significant compute resources
- connecting to a "remote system" and uploading the documents you want printed OR accessing a retro computing appropriate view of some of the internet

Realistically it's just easier and cheaper these days to just throw a much more powerful computer at the problem. We're swimming in options these days.

 

[whartung]

I share the general sentiment about not reducing the retro computer to being an veneer, but what you describe is inevitably the easier route and depends more on software approaches than on really understanding fundamental principles of electronics and low-level details of hardware.

It's mostly an issue if you wish to bring the retro machine in any way into the modern age of connectivity. Such as trying to connect to a modern printer. The moat around modern hardware is deep and wide for retro machines to cross.

Logging in to a "server", much like we used to do to get access to applications and databases, is an "authentic" way of doing so, but it's not quite as fulfilling (at least to me). I'm sure I'm not alone in having created local applications that uploaded their data to a server for further processing. In my case it was a remote data entry and we'd get a floppy disk every few days with data, we'd upload to the VAX with Crosstalk.

I like the idea of a "super i/o" processor. Something that would give 8-bits access to USB (host and client), which can open up, well, everything. But also higher level access to networking, storage, even help with SIP and I2C. (Bit banging SIP is easy, and really slow).

Even though I know that the I/O processor is vastly more capable than the host CPU, I like to look at it more like a really nice UART or SCSI controller, or even a graphics adapter. When you can get a 150MHz uController for cheaper than a 7 segment LED decoder, you know that the world has changed.

Heck, this is exactly what the Atari and C64 do with their disk interfaces -- it's a serial cable to a completely different CPU.

But I appreciate that its a delicate issue.

 

[Istarian]

A big part of what's changed about the world is what is being produced and in what volume. With significant production volume, it's possible to sell cheap and still make some profit.

-----

My understanding is that the Atari and C64 disk drives use a 6502-derivative processor, so it's more like having a second computer of comparable power to manage the disk drive.

I.e it's similar to having a second Atari or C64 nearby that is dedicated to managing storage instead of being for interactive use by a person interactive.

Rather different than having a much more powerful system to do that, imho.

As @durgadas311 was saying in a previous post, it's a little more palatable when you have an accessory device external to the retro computer which performs a specific purpose anc communucates via a period appropriate mechanism. --- Which is to say that it doesn't alter the experience of retrocomputing to the same degree. A printer is still just a printer in that respect even if it's a supercomputer under the hood.

 

[Thorbjørn Ravn Andersen]

An 8080/Z80 can rasterize or generate PostScript itself, it's just going to be a bit slow. The problem is that WordStar 3.x printer drivers are too limited, so you'd need to either use a separate program or implement the functionality as an RSX or BIOS extension. Or, as on the fZ80 or similar systems, you could do it outside the emulated environment.

I am not fond of "just network everything, put a modern computer in the middle, doing all the heavy lifting". To me, a physical 8080 machine with a 160 MHz frontend (for network downloads) and a 700 MHz backend (for processing and rendering) is wasting a perfectly good machine. Trying to sell it as "my Altair 8800 can surf the modern internet, look" feels like lying, not retro or vintage computing.

I surfed the net with text browsers back in the day. First lynx and then links over the serial port (modem to a unix host fully on the university internet).

These days everything is so heavily infested with Javascript that I think it will remind us too much how hard it is to be blind in a seeing world

But what's wrong with adding modern technology to make old, slow computers usable and useful to us again?

 

[Thorbjørn Ravn Andersen]

If it helps rationalize these things at all, there was a fighting chance all the way into the 1990’s that a peripheral you bought for your computer would have a more powerful CPU in it than the one you were running your word processor on.

(For instance, even the original HP LaserJet had an 8Mhz 68000 in it, when there was a good chance the computer it was going to be used with was a 4.77 mhz 8088. Postscript started an absolute arms race for ramping up CPU speeds in printers, if you had a RISC CPU on your desk before 1995 there was probably a better than 90% chance it was in your printer.)

We got some NeXT machines at our university which everybody loved because of the tooling. But also the printer was astonishingly fast - the NeXT rendered the bitmap and sent over so we easily got the speeds we are used to today. That was quite a difference from the laserprinters connected with 9600 baud to the secretaries machines shipping TeX files.. One of my first tasks as a student programmer back then was lifting the speed to 38400 baud

 

[Eudimorphodon]

Rather different than having a much more powerful system to do that, imho.

Personally I'm willing to fudge this a bit precisely because the costs associated with "more powerful" have decreased at the same time. I mean:

A go-tech is even tough to swallow, though necessary.

A gotek drive emulator has an ARM CPU in it that runs at... 70-something Mhz in the most basic version, faster in some later versions? (Gotek swaps out the MCU in those things all the time depending on what's cheap.) So sure, I suppose if you want to get irked by the fact that the CPU core in that could run rings around most personal computers built before the 1990's there's not a lot to do about that, but... on the flip side, it's a part that's built to fulfill the same role that dirt-cheap microcontrollers like a Z8 or Intel MCS-48 did from the mid-70's. (FWIW, even some of those rinky-dink MCUs could actually in terms of sheer integer ops per second outrank general purpose CPUs, but at the cost of having weird harvard architectures/unexpandable memory/etc.) So far as the host computer goes it's a black box, so... why worry about it?

If you're using a Raspberry Pi or Beaglebone to emulate an unobtanium hard disk or translate print jobs for you you can at least just reasonably *pretend* you're living in the world the computer came from. Personally where I draw the emotional line is "upgrades" that effectively turn your old computer into skin suit being worn by an emulator. (PiStorm for Amiga, for example.) Those are just literally emulation with unnecessary extra steps.

 

[durgadas311]

...
Personally where I draw the emotional line is "upgrades" that effectively turn your old computer into skin suit being worn by an emulator. (PiStorm for Amiga, for example.) Those are just literally emulation with unnecessary extra steps.

Yeah, FujiNet is another of those - or appears to be. Early versions, at least, would basically take over the system bus and do whatever it wanted.

 

[Thorbjørn Ravn Andersen]

Personally I'm willing to fudge this a bit precisely because the costs associated with "more powerful" have decreased at the same time. I mean:



A gotek drive emulator has an ARM CPU in it that runs at... 70-something Mhz in the most basic version, faster in some later versions? (Gotek swaps out the MCU in those things all the time depending on what's cheap.) So sure, I suppose if you want to get irked by the fact that the CPU core in that could run rings around most personal computers built before the 1990's there's not a lot to do about that, but... on the flip side, it's a part that's built to fulfill the same role that dirt-cheap microcontrollers like a Z8 or Intel MCS-48 did from the mid-70's. (FWIW, even some of those rinky-dink MCUs could actually in terms of sheer integer ops per second outrank general purpose CPUs, but at the cost of having weird harvard architectures/unexpandable memory/etc.) So far as the host computer goes it's a black box, so... why worry about it?

In the old days, where the C64 diskette drive was as powerful a computer as the C64 itself, programmers found out how to offload software to it.

It would have been perfect if somebody made a fantastic demo by offloading heavy work to the cpu inside the gotek.

 

[Eudimorphodon]

In the old days, where the C64 diskette drive was as powerful a computer as the C64 itself, programmers found out how to offload software to it.

FWIW, "As powerful" comes with a pretty big asterisk, it only has 2K of RAM. There were some useful things they figured out how to do with it (a cute one I recall was an auto-copy program you could stick on two 1541's and then just let them perpetually pirate software in a corner at the users group meeting without needing a C64 attached to them once started), but mostly it was stupid pet tricks.

(Speaking of "Pets", the old IEEE disk drives for those actually had *two* CPUs in them, one running the DOS and the other running the drive mechanism. They weren't 6502s, they were smaller address space versions similar to the 6507 in an Atari 2600, but they were, strictly speaking, "as powerful".)

It would have been perfect if somebody made a fantastic demo by offloading heavy work to the cpu inside the gotek.

There's nothing stopping anyone from using it as more than a dumb floppy. For instance, the HxC alternative firmware (not flashfloppy, yet, as far as I'm aware of) supports a "direct access" mode that instead of simulating the mechanics of a real floppy drive with an image file it lets you, via commands sent through the floppy controller, do high-level access to the plugged-in flash memory. Here's an application for the Atari ST that uses it to fake a hard drive, albeit one limited to floppy speeds because of the method of connection. If you wanted to patch Flashfloppy to let you run sandboxed programs on the GoTek CPU that you communicated with in a similar way it's 100% doable. The only real problem is that goteks use a variety of MCUs, and some of them have barely adequate RAM to do their floppy emulation job, let alone run anything else that interesting.

(I guess a fun stupid pet trick-level application might be a way to put custom messages or pictures up on the screen of a Gotek that's been modified with one of those OLED displays?)

 

[Istarian]

@Eudimorphodon I would tend to treat emulation of an MFM/RLL drive a little differently than some other use cases, precisely because it's not wrapped in layers like most ATA/IDE/EIDE drives.

My impressions was that you have to actually emulate the drive hardware in a way that is close enough for an existing controller to think it's dealing with a real drive.

You don't have emulate any hardware at all for an "IDE" drive, because all of the real hardware and drive electronics are hidden behind an interface. So you can get away with nearly and kind of storage backing as long as you comply with the interface standards. And with LBA you don't even have to do the C-H-S math to determine where on your virtual drive the data would be stored to /retrieved from.

 

[Eudimorphodon]

@Eudimorphodon I would tend to treat emulation of an MFM/RLL drive a little differently than some other use cases, precisely because it's not wrapped in layers like most ATA/IDE/EIDE drives.

... so... what is the point? How does that have any bearing on whether you should care if the CPU in your "modern replacement for old-time-y peripheral" is "powerful" or not?

Even many MFM/RLL drives have a "CPU" on them, albeit a pretty minimal one (like a Z8 or something) to handle the housekeeping of handling the mechanical parts of the drive. (So do many newer floppy drives, for that matter, simply because by even the late 70's slapping a CPU and a bit of ROM into a board was cheaper than a discrete state machine to do the same job. By the second half of the 80's you could start embedding small MCU cores directly into ASICs, so it might not even be immediately obvious if a thing had a "CPU" or not.) Yes, this CPU is not directly in the data path, but on the other side of the cable tothe board you stuck in the computer, the "controller", lurks a thing on that might as well be a CPU, even if it's not *strictly speaking* a Turing-complete general purpose computer. That there dingus takes high-level commands and acts on them completely independently of the host machine; even an old-timey floppy controller like an WDC 1770 has enough complexity inside it it's of similar scale to a CPU like a 6502, and many winchester controllers *do* outright have a CPU on them. It's this controller chip that presents the "API" to the host CPU, and although it might as well be a magic box so far at the user is concerned it is still a powerful state engine that does many things very fast.(*)

(* It's not unusual for drives to have secret diagnostic/manufacturing APIs that theortically might go so far as letting you run "code" on them, although they're certainly not going to tell you the details.)

Anyway, all an IDE drive is is an RLL drive glued permanently to the controller. Thus all the REALLY NASTY parts of talking to a mechanical device with a wickedly high-speed time-critical bitstream firehosing out of it are hidden behind the curtain so *all* the user needs to deal with is that neat and tidy API-presenting ASIC that's hanging off their computer's bus. Which is why you can build an ATA adapter for something like an 8-bit ISA bus with three completely dumb TTL logic chips, there's no *visible* additional computer chip at all... but if its our job here to pretend to be upset that there's now a CPU core in the box that runs anachronistically fast for the era the host computer is from we've already lost this battle, because we all know that it doesn't matter if you've interfaced a modern (can we still call them those?) ATA spinning rust drive or a flash device it's going to have a RISC core embedded in it that, if you could pry it out, would completely blow your XT's head to the back of the auditorium.

So again... what's the point? A Gotek is technically doing the same thing as an MFM/RLL drive emulator is doing, in the sense that it's not a "high level" replacement for a complete old subsystem that has the "luxury" of just having to keep up with a well-specified computer bus, it has to deal with the nasy semi-analog firehose that the controller has to control a mechanical dingus in the first place. This firehose doesn't include the concept of "wait states", it's strictly real time, and that is why they needed an MCU that could run at 70mhz; that's fast enough to keep up with the 500Kbps of a floppy interface without needing a bunch of accessory state machine bits. MFM *hard drive* emulators need to be another order of magnitude faster, which is why they also usually include some CPLD/FPGA glue. But... I'm still baffled. If you look at a really high-end IDE drive the CPU built into that is actually probably pretty close to this; sure, it's going to have ASIC support for driving the read-write heads and *probably* some help for voice-coil positioning, but I imagine a *lot* of that *is* actually done in software, plus that CPU is going to be really busy doing things like cache management (modern drives of course have large and intelligent cache memories). So it's not really going to be that much different when it comes to this philosophical hangup.

In short, if you don't want a CPU core faster than what was available when your vintage computer was built touching it then you're restricted to buying peripherals that were manufactured when your computer was, full stop. If you take your 386 from 1990 and plop a 2002 vintage PATA hard disk in it (you'll be needing a ROM upgrade or overlay software for this, of course, but let's ignore that) you are probably getting a Turing-complete processor a few magnitudes faster than your main CPU as part of the deal, whether you can see it or not.

 

[Quagmire]

Hmm. Park the PATA's and use a CF card or a SSD. I've been doing it for years on Tandy 1000's and other PCs on up. HDs are getting fairly long in the tooth anyway. Sooner or later 'pop goes the weasel'.

 

[Eudimorphodon]

Hmm. Park the PATA's and use a CF card or a SSD. I've been doing it for years on Tandy 1000's and other PCs on up. HDs are getting fairly long in the tooth anyway. Sooner or later 'pop goes the weasel'.

But those have embedded CPUs in their flash control chips that would also be a bazillionty-times faster than an 8088 if you could pry them out to run code on. (How else would they handle things like cache management and wear leveling?) There’s no way to hide!

 

[Svenska]

A go-tech is even tough to swallow, though necessary. But if I can run a Diablo 630 emulation on an rPI connected to my Kaypro serial port, that's a fair solution.

A Gotek cannot replace a full Kaypro or PC or Amiga, but an rPI can. Stuff the rPI into a separate box, connect it through a pre-defined interface and make it pretend to be a hard drive or printer, and it turns into a distinct peripheral.

I don't really mind that, especially since such a peripheral can be used with many different computers. And the Kaypro still meaningfully contributes to the task (word processing) in the same way it was designed to. It is not sidelined.

My understanding is that the Atari and C64 disk drives use a 6502-derivative processor, so it's more like having a second computer of comparable power to manage the disk drive.

I.e it's similar to having a second Atari or C64 nearby that is dedicated to managing storage instead of being for interactive use by a person interactive.

It is not. These are smart peripherals, not base system replacements masquerading. Neither drive can be turned into a replacement for the Atari or C64 without a complete redesign, and even if you did that redesign, you would no longer have a disk drive.

The C64 and its 1541 disk drive have distinct roles, and both meaningfully contribute to the whole system.

But what's wrong with adding modern technology to make old, slow computers usable and useful to us again?

Strongly depends on how the modern technology is used. If you take away the old, slow computer's purpose, you should just replace it instead.

It's similar to putting people into the driver's seat on automous trains or cars, but disallow them from actually taking decisions. They are not the drivers, do not pretend they are. Do not waste them.

 

[tomjennings]

We're all trying to navigate a path through all the complexities of meddling with half century old hardware and software. I wanted the operational feel of using old software that hews to it's inherent limits but without today's expense and difficulty of vintage hardware. I understand it doesn't please everyone, YMMV, etc.

The new LX-350 printer I have very well may have more CPU etc than the CPU. I choose not to look : - ) But it does retain the parallel port and tractor feed paper and so "feels like" and old system minus the problems. ANd I get the zing-zing of dot matrix.

Yeah, FujiNet is another of those - or appears to be. Early versions, at least, would basically take over the system bus and do whatever it wanted.

I've got Phil Karn's CP/M version of NOS (KA9Q) compiling. I've used the DOS version a lot (we ran an ISP with it!). It contains the basic clients in-built as well as the TCP/IP and DNS and other stuff necessary.

I follow the Fujinet guy on the fediverse. Lots of people love it, and have integrated it into things like the C64, in a way that "looks like" the C64 has those features innately. I'm a bit mixed about it (for myself; more power to 'em I say): I don't want to pretend my CP/M machine is on the internet. But younger people who grew up with the internet already mature when they were kids have a totally different set of assumptions about things.

Back to the thread: my ideal solution was the new old-fashioned Epson LX-350. To me it's the perfect bridge. It's a narrow path, finding new products like that.

 

[KE6JAG]

The new LX-350 printer I have very well may have more CPU etc than the CPU. I choose not to look : - ) But it does retain the parallel port and tractor feed paper and so "feels like" and old system minus the problems. ANd I get the zing-zing of dot matrix.

A bit pricey, but basically its an old style epson printer with drivers for windows. It still uses ESC/P so CP/M and WS can use it. I like that it has parallel, serial, and USB ports. Is the parallel the same as the one on the fz80?

 

[tomjennings]

Yeah, 300+ buckola's... but what's a good running CP/M machine cost these days? lol. And it is more generally useful than many.

Yes, I'm using a generic "Centronics parallel" cable from feePay to connect to fZ80. Works right off.

 

[KE6JAG]

Yeah, 300+ buckola's... but what's a good running CP/M machine cost these days? lol. And it is more generally useful than many.

Yes, I'm using a generic "Centronics parallel" cable from feePay to connect to fZ80. Works right off.

So it has Centronics, USB, and DB9?

 

[tomjennings]

So it has Centronics, USB, and DB9?

Yes it does, all three. Takes tractor feed or single sheet paper. Factory ribbons are 6 bucks, 4 million characters. It's a lovely thing.

I wonder what happens when you connect two computers to one printer...