DLT III tapes (TK85-K) and sticky-shed
I've seen plenty of complaints (here and elsewhere) about TK50 cartridges being very difficult to read these days. I'm trying to read TK85-K (DLT III) cartridges and I'm experiencing problems. I've had tapes ripped (although I've found that data elsewhere). So now I'm being particularly careful. If the drive asks for a cleaning tape, I run through a cleaning cycle until it is happy and then I try to load the tape again. However, by the time I've mounted the tape, the drive "Cleaning Required" light is on again. This happens repeatedly, I run a cleaning pass or two and then I get a green light. I might even get as far as loading the tape without and issue, but by the time the tape is mounted, the "Cleaning Required" light is on. So is this likely to be sticky shed? Is the DLT III formulation known to have the same issues? Does baking help? (Not that I'm set up to do that, but I'm in no rush ...) I suppose that it is possible that my cleaning tape is worn out and now past its sell by date. Has anyone cleaned a TZ87 or TZ88 head successfully? It doesn't seem to be terribly accessible, and I'm not sure what I can dismantle without wrecking the alignment. Anyone got any useful suggestions? Antonio -- Antonio Carlini anto...@acarlini.com
Amiga Roots, TRIPOS - Off Topic, was Re: Exploring early GUIs
Forking this thread as we are now way off the original and very cogent topic, which I would like to see continued. (Very valid to ask about good emulations of early GUI systems like Apollo, LispMs, PERQ, Xerox D* etc) Peter’s mentions of TRIPOS (which was used on a Sage IV for Amiga Lorraine bring-up) has me renew my ask: If anyone has media for TRIPOS for the Sage/Stride systems please reach out. > On Sep 22, 2020, at 03:02, Peter Corlett via cctalk > wrote: > > On Mon, Sep 21, 2020 at 11:29:14PM -0500, Richard Pope via cctalk wrote: >> The Amiga 1000 with AmigaDos and Workbench was released in late 1985. >> AmigaDos is based on Unix and Workbench is based on X-windows. > > Er, no. > > The Amiga's operating system is a pre-emptive multitasking microkernel which > uses asynchronous message-passing betwen subsystems, which is not the Unix way > of doing things at all. Unix provide libraries of synchronous procedure calls > which block the caller until the job is done. > > Although "AmigaDOS" appears prominently in the terminal as one boots > Workbench, > that's only the filesystem and command-line shell. Due to time pressure, they > bought in TRIPOS and filed off the serial number. TRIPOS is a fairly clunky > thing written in BCPL that never sat well with the rest of the system, but it > was quite probably the only DOS they could buy in which worked in a concurrent > environment. TRIPOS is the reason why disks were slow on the Amiga. > > The other bit that got reduced from a grander vision was the graphics, which > became blocking libraries rather than device drivers. The window manager ran > as > its own thread which gave the illusion of responsiveness. > > The "X Window System" (not X-windows or other misnomers) is an ordinary[1] > Unix > process which provides low-level primitives for a windowing system. > "Workbench" > is just an ordinary AmigaDOS process which provides a file manager. You can > even quit it to save memory, and the rest of the GUI still works. They are not > the same thing or "based" on each other at all. > > > [1] Well, some implementations are setuid root or have similar elevated >privileges so they can have unfettered access to the bare metal and thus >tantamount to being part of the kernel, but that's basically corner-cutting >by a bunch of cowboys and it is possible to do this sort of thing properly >without introducing a massive security hole. >
Re: PSA to SparcBook 2 Users
No, this applies only to Tadpole Series 2 and potentially Series 1 machines (although I have not observed the latter) Series 3(/3000) are completely different internally. Your SB3000 is safe- at least from this failure mode. > On Sep 22, 2020, at 11:02, Alan Perry via cctalk > wrote: > > You flush electronics with Indian Pale Ale? Too many TLAs. > > This isn't a problem on the model of SparcBook you sold me, is it? > >> On 9/22/20 10:53 AM, Ian Finder via cctalk wrote: >> There is a 1000uf 10v cap on the main logic board just above the Bt display >> controller. >> It is leaking... a lot. (4/4 samples so far) >> Go replace it, flush the area and scrub the with 99.9% IPA.
Re: PSA to SparcBook 2 Users
You flush electronics with Indian Pale Ale? Too many TLAs. This isn't a problem on the model of SparcBook you sold me, is it? On 9/22/20 10:53 AM, Ian Finder via cctalk wrote: There is a 1000uf 10v cap on the main logic board just above the Bt display controller. It is leaking... a lot. (4/4 samples so far) Go replace it, flush the area and scrub the with 99.9% IPA.
PSA to SparcBook 2 Users
There is a 1000uf 10v cap on the main logic board just above the Bt display controller. It is leaking... a lot. (4/4 samples so far) Go replace it, flush the area and scrub the with 99.9% IPA.
Re: Exploring early GUIs
On Mon, Sep 21, 2020 at 11:29:14PM -0500, Richard Pope via cctalk wrote: > The Amiga 1000 with AmigaDos and Workbench was released in late 1985. > AmigaDos is based on Unix and Workbench is based on X-windows. Er, no. The Amiga's operating system is a pre-emptive multitasking microkernel which uses asynchronous message-passing betwen subsystems, which is not the Unix way of doing things at all. Unix provide libraries of synchronous procedure calls which block the caller until the job is done. Although "AmigaDOS" appears prominently in the terminal as one boots Workbench, that's only the filesystem and command-line shell. Due to time pressure, they bought in TRIPOS and filed off the serial number. TRIPOS is a fairly clunky thing written in BCPL that never sat well with the rest of the system, but it was quite probably the only DOS they could buy in which worked in a concurrent environment. TRIPOS is the reason why disks were slow on the Amiga. The other bit that got reduced from a grander vision was the graphics, which became blocking libraries rather than device drivers. The window manager ran as its own thread which gave the illusion of responsiveness. The "X Window System" (not X-windows or other misnomers) is an ordinary[1] Unix process which provides low-level primitives for a windowing system. "Workbench" is just an ordinary AmigaDOS process which provides a file manager. You can even quit it to save memory, and the rest of the GUI still works. They are not the same thing or "based" on each other at all. [1] Well, some implementations are setuid root or have similar elevated privileges so they can have unfettered access to the bare metal and thus tantamount to being part of the kernel, but that's basically corner-cutting by a bunch of cowboys and it is possible to do this sort of thing properly without introducing a massive security hole.
