gnu@hoptoad.uucp (John Gilmore) (10/29/88)
casseres@Apple.COM (David Casseres) wrote: > At best, the 1.8 meg would be "free" in the 8 meg total > system, and since the I/O to the printer from RAM is DMA, the applications > would be totally unaffected. Nice. I don't recall the transfer rate (it's > in the Byte article) but it's about what you'd need to hose that 1.8 meg > out to the printer within the 6 seconds or so that the printer allows... I'm not sure what he means by "free" but the RAM is certainly there to be "used"; that's what RAM is for. However, just having DMA between memory and the printer does not guarantee that "applications would be totally unaffected". The interface to a print engine looks a lot like video going to a monitor; you send each scan line as bits on a serial line. The Byte article quotes 3.2M bits/sec, or about 300 ns per bit. If they can fetch 128 bits (16 bytes) from main memory in 9 cycles, that's 128 bits/360ns, (at 25MHz, a cycle is 40ns), so the printer interface, when running, burns about 1/100th of the memory bandwidth, which is not bad; applications would not notice. But don't forget the CPU time burned by the PostScript interpreter. We sell one, we know; high quality imaging of 1.8MB of bits in an interpreted language definitely runs the CPU at peak for a while. The point of the NeXT design is that the CPU subsystem now has enough resources that when printing, it can spare a significant chunk of them to drive the printer (and with dense gate arrays, the interface to the printer can come standard because it's close to free). So all you have to pay for is the print engine and software. This was not an option on a 512K Mac with a slowly clocked 68000 controlled by PALs, so they had to put the 12.5MHz 68000 and 1.5MB inside the printer. Of course, if the original Mac had had a bus, they could've put the extra 1.5MB and the fast 68K on the bus, so when the printer was idle you could use it for your applications! But that's design by hindsight. -- John Gilmore {sun,pacbell,uunet,pyramid,amdahl}!hoptoad!gnu gnu@toad.com Noriega-Bush in '88 -- a *crack* team. Let's put the white powder (CIA = Cocaine Import Agency) in the white house!
casseres@Apple.COM (David Casseres) (11/01/88)
In article <5784@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >casseres@Apple.COM (David Casseres) wrote: >> At best, the 1.8 meg would be "free" in the 8 meg total >> system, and since the I/O to the printer from RAM is DMA, the applications >> would be totally unaffected. Nice. I don't recall the transfer rate (it's >> in the Byte article) but it's about what you'd need to hose that 1.8 meg >> out to the printer within the 6 seconds or so that the printer allows... > >I'm not sure what he means by "free" but the RAM is certainly there to >be "used"; that's what RAM is for. I just meant that in the best case, the space could be allocated without having to swap anything else out. >... However, just having DMA between >memory and the printer does not guarantee that "applications would be >totally unaffected". Correct; I should have said virtually unaffected, and I should have added "by the I/O requirements." >But don't forget the CPU time burned by the PostScript interpreter. >We sell one, we know; high quality imaging of 1.8MB of bits in an >interpreted language definitely runs the CPU at peak for a while. I don't think this will have a very large impact on applications running on the same machine. We know their implementation of Display PostScript can paint the NeXT screen fast enough for a whizzy interface, and that screen is a million pixels X 2 bits/pixel = 2 megabits or about 0.25 MB. To draw a page of about 2 MB would take about 8 screen times, which just doesn't sound to me like a big hit. David Casseres