On Scanning
This may be a good place to mention a text I began writing some while ago: On Scanning. http://everist.org/temp/__On_scanning.htm Meant to be a 'how to' about scanning and post-processing techniques, written as I explored that myself. It's not finished because I was working on a solution to the 'screened images with overlaid sharp text' post-processing problem, when sidetracked. As often happens with me. Also that project diverged into the whole text encoding thing. Which I can't discuss, but I *can* discuss scanning issues. Anyway, any comments, corrections and suggestions for extra material are welcome. Oh, and those with an interest in Apple history may find this amusing: http://everist.org/NobLog/20181001_missing_wave.htm Guy
Re: Happy New Year!
At 06:48 AM 1/01/2019 +, you wrote: > >Happy New Year to all! >Ed# > >Sent from AOL Mobile Mail So, no new year's resolution about not typing extra spaces after words, Ed? Well maybe next year? Best wishes to all, and hopefully 2019 will bring everyone lots of interesting classic computers (that work!), and fewer 'interesting' political dramas. Guy
Re: PDP-11/45 RSTS/E boot problem
> On Dec 31, 2018, at 11:43 PM, Noel Chiappa via cctalk
> wrote:
>
>> From: Paul Koning
>
>>> On Dec 31, 2018, at 6:32 PM, Henk Gooijen via cctalk >> classiccmp.org> wrote:
>>> ...
>>> There are one or two bits in a register of the RK11 that have a
>>> different meaning/function, depending on the controller being a -C or
>>> -D.
>
>> If someone can point me to the description of the differences I should
>> be able to say what RSTS will do with them.
>
> AFAIK, the only difference (in programming terms) between the -C and -D is
> that the -D has dropped the maintainance register.
>
> Although I cheerfully admit I haven't sat down with -C and -D manuals and
> done a bit-by-bit compare. I just did that (I used the "RK11-C Moving Head
> Disk Drive Controller Manual", DEC-11-HRKA-D, and the 1976 "Peripherals
> Handbook"), and found in the following:
>
> In the RKDS: bit 7 has changed the definition slightly ("Drive Ready" to
> "R/W/S Ready"), but seems to be basically the same.
You mean bit 6? Bit 7 is "drive ready" in both. I'm using the 1972
peripherals handbook for the RK11-C. Bit 6 has a different name in the two
descriptions but the meaning appears to be the same.
It would be interesting to see the output from "hardware list" in INIT.
On overlapped seek: that is only ever useful if you have more than one drive,
and then only if there is enough load on the drives to keep more than one head
moving at a given time. The INIT drivers are the plain (not overlapped seek)
ones so if that works it is worth trying the plain drivers in RSTS as well to
see if that cures the issue. I'm still not sure why things break, though. You
could load monitor ODT (ODT option in the memory layout settings in DEFAULT)
and set a breakpoint at LOG$DK, that's the error logging entry point of the
driver. Then you could display the RK11 CSRs and we can see if we can figure
out why it's unhappy.
paul
Re: Motorola M88K books & user manuals (looking for)
RISC was never just about compiler and hardware simplification for improved performance of the most frequently-executed instructions. It's also been front-and-center in low-power (e.g., mobile) and embedded (now including Internet of Things) applications, which each far outpace the number of devices produced for traditional desktop and top-end computing (high-performance computing, originally aka supercomputers). It's a big reason why no one is using Windows Phones, or IoT components based on x86/x64 hardware today. Microsoft and Intel made big bets on their accumulated legacy code and hardware bases being shoehorned into everything imaginable, with what should have been obviously poor results for most of the application areas pursued. Anyone remember trying to run Excel on a Windows Phone with largely the same mess of menus, submenus, subsubmenu items, dialogues, etc., as on the desktop version? IoT devices like door locks don't need scads of registers, instructions, caches, etc., and can you imagine an Apple or Galaxy Watch with cell capability running on a multicore x64 processor with a battery smaller than that for a vehicle? A Blue Screen of Death is truly fatal for a product that depends on an embedded device, like an ATM in the middle of dispensing over half a grand in cash, a DVR in a satellite TV receiver that requires upwards of ten minutes to restart and get back to where the viewer was (minus the permanently lost live recorded cache), or a self-driving vehicle at any speed above zero. Yes, BSoDs continue to happen when memory runs out before users run out of things they want to do all at one time. Windows systems can still routinely get to the point where it becomes impossible to dismiss a modal dialog, close a tab or window, bring up the Start menu or Task Manager, or other critical user interface element actions that should always be instantly accessible. This lack of attention to user experience is endemic to the Wintel way of doing things, going back deep in the estimated ~100 million lines in their code base. The x86/x64 instruction set complexity hasn't been helpful in reducing the security vulnerability of software running on those architectures, either. The multiple parallel pipelines that make possible speculative execution of a number of branches before associated decisions are computed, have resulted in the whole new class of security vulnerabilities such as Meltdown, Foreshadow, and Spectre. This isn't limited to x86/x64, however, as the most recent multicore ARM processors have also fallen victim to such issues, they've just been late to the game as the most advanced (and complex) features have been pursued (somewhat for me-too marketing purposes), so fewer families/generations have been affected.
Re: Motorola M88K books & user manuals (looking for)
On 1/1/19 7:17 PM, Jim Manley via cctalk wrote: > RISC was never just about compiler and hardware simplification for improved > performance of the most frequently-executed instructions. John Cocke is rolling over in his grave.
Re: Motorola M88K books & user manuals (looking for)
On 1/1/2019 8:58 AM, Carlo Pisani via cctalk wrote: hi on DTB we are designing a RISC-ish CPU, code name "Arise-v2"(1). We are using the MIPS R2K and the RISC-V as the reference. In the end, it will be implemented in HDL -> FPGA. The page on DTB is related to a software emulator (written in C) for the whole system. CPU + RAM + ROM + UART, etc. so we can test and our ISA more comfortably. As a second reference, I'd like to consider the first Motorola RISC: 88K, which is very elegant and neat ISA; unfortunately, I have difficulties at finding user manuals and books about it. If someone wants to sell me a copy, it will be appreciated! Thanks and happy new year! I was never a fan of RISC architecture as does not fit the standard high level language model. Everybody wants a 1 pass compiler, thus the RISC model. If you are doing your own RISC model, you might consider a model that supports Effective addressing better since we have got the point where fetching the data is taking longer than processing it. The other thought is the pipeline seems has too high speed of a clock, what is the use a fast clock, if you got one or two gates of logic between your clocks. Gate and line driving speed ratios remind me of the Vacuum tube era of computing. I have FPGA card here, as using it to develop a NICE 20 bit TTL computer.I just ordered a few 7437's from the Ukraine, so this might be the last year to stock up needed 74XXX spares. Good luck with your design. Ben.
Re: Motorola M88K books & user manuals (looking for)
> On Jan 1, 2019, at 2:35 PM, Carlo Pisani via cctalk > wrote: > >> I was never a fan of RISC architecture as does not fit the standard high >> level language model. Everybody wants a 1 pass compiler, thus the RISC >> model. If you are doing your own RISC model, you might consider a model >> that supports Effective addressing better since we have got the point >> where fetching the data is taking longer than processing it. > > yup. I am a 68k programmer so I know what you mean. > the 68k is more comfortable to be programmed in assembly, and even the > EA modes (especially in the 68020 and CPU32) help a lot. > > unfortunately, the 68K is very complex to be designed, and the first > 68020 used microcode, which is a no-go for modern designs. Umm. Says who? Intel x86 CPUs makes *heavy* use of microcode. So do a number of other processors (IBM S/370, et al). The ISAs may be old but I would argue that in both examples, the underlying designs are *very* modern. TTFN - Guy
Re: music dec tapes? (paper)
On Tue, Jan 1, 2019, 15:18 Adrian Stoness via cctalk anyone seen these music tapes before i grabed this trays for the oddnes of > the content of these tapes? also apears to have the software to play them? > > > https://www.ebay.ca/itm/Lot-of-15-digital-decus-Paper-Tapes-w-Case/273628629483?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m2749.l2649 > > > https://www.ebay.ca/itm/Lot-of-8-digital-decus-Paper-Tapes-w-Case/273628539210?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m2749.l2649 > > would this be some weird synthy type thing? > control points for the sound boaerd used for automation on some fancy desk? > or somthing els? > Vince has a listing for some version of DECUS 8-152 on his website ( http://svn.so-much-stuff.com/svn/trunk/pdp8/src/decus/8-152/decus-8-152-lst.pdf). I have reverse engineered it enough to have his version play a few songs. However, it seems like there's a difference between the music tapes I have and the listing he has. I don't know what hardware was required of this software, but I suspect it to be a DAC responding on address 055. This seems to match with an AA01 option. Did you end up buying these tapes? I have digitized the music tapes I bought from the seller and will post them soon. It would be excellent if the buyer of this lot would do the same. Musically, Kyle >
Re: Motorola M88K books & user manuals (looking for)
> On Jan 1, 2019, at 2:00 PM, ben via cctalk wrote: > > On 1/1/2019 8:58 AM, Carlo Pisani via cctalk wrote: >> hi >> on DTB we are designing a RISC-ish CPU, code name "Arise-v2"(1). >> We are using the MIPS R2K and the RISC-V as the reference. >> In the end, it will be implemented in HDL -> FPGA. >> The page on DTB is related to a software emulator (written in C) for >> the whole system. CPU + RAM + ROM + UART, etc. so we can test and our >> ISA more comfortably. >> As a second reference, I'd like to consider the first Motorola RISC: >> 88K, which is very elegant and neat ISA; unfortunately, I have >> difficulties at finding user manuals and books about it. >> If someone wants to sell me a copy, it will be appreciated! >> Thanks and happy new year! > > I was never a fan of RISC architecture as does not fit the standard high > level language model. Everybody wants a 1 pass compiler, thus the RISC model. > If you are doing your own RISC model, you might consider a model > that supports Effective addressing better since we have got the point > where fetching the data is taking longer than processing it. Huh? I don’t understand the 1 pass compiler statement requiring RISC. I was doing 1 pass compilers in the mid-to-late 70’s (well before RISC). So I’m not sure what you’re talking about. It also depends upon what you mean by “1 pass”. Most compilers nowadays make only one pass over the source but will make multiple passes over the intermediate form before finally generating code (even then it may make another pass over the resulting generated code for peep-hole optimizations. RISC is actually nice for a compiler because it’s simple and fairly regular (hard to actually generate code automatically for complex instructions) and RISC has a large number of registers. However, modern CPUs are all out-of-order execution with register renaming with ridiculous numbers of registers (I think current Intel Core x CPUs have 192+ registers for register renaming where the visible number of registers is 8). It also allows for speculative execution (following multiple paths through the code until the data required for the various decision points is finally available). > > The other thought is the pipeline seems has too high speed of a clock, > what is the use a fast clock, if you got one or two gates of logic between > your clocks. Gate and line driving speed ratios remind me of the Vacuum tube > era of computing. Deep pipelines are needed to get clock speeds up so that timing can be met. The problem with deep pipelines is that when any sort of exception (interrupts, etc) happen, there’s a lot of state that gets flushed and then restarted when the exception handling completes. Pipelines (especially if they’re not fixed depth for all operations) means that simple operations (those that require a minimum number of pipeline stages) can be completed quickly where as complex operations that require either a lot of logic or time to complete can be broken up in to multiple stages. This allows a higher clock rate and allows for the simple operations to be completed more quickly than if there was a very shallow pipeline. TTFN - Guy
Re: PDP-11/45 RSTS/E boot problem
> On Dec 31, 2018, at 8:43 PM, Noel Chiappa via cctalk
> wrote:
>
> In the RKDS: bit 7 has changed the definition slightly ("Drive Ready" to
> "R/W/S Ready"), but seems to be basically the same. In the RKCS, bit 9 is
> "Read/Write All" in the -C, and unused in the -D; bit 12 is "Maint" in the
> -C, unused in the -D.
Thanks for digging that out, Noel. I didn’t know that the RK11-D didn’t have
“all” mode — its actually pretty handy for recovering slightly corrupted
sectors. Also, the older RK11 static MAINDEC actually does quite a lot with
maintenance mode, without needing a working drive attached. I suppose that
test coverage is lost with the RK11-D?
--FritzM.
Re: music dec tapes? (paper)
I have these, plays music over the radio b On Tue, Jan 1, 2019 at 4:18 PM Adrian Stoness via cctalk < cctalk@classiccmp.org> wrote: > anyone seen these music tapes before i grabed this trays for the oddnes of > the content of these tapes? also apears to have the software to play them? > > > https://www.ebay.ca/itm/Lot-of-15-digital-decus-Paper-Tapes-w-Case/273628629483?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m2749.l2649 > > > https://www.ebay.ca/itm/Lot-of-8-digital-decus-Paper-Tapes-w-Case/273628539210?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m2749.l2649 > > would this be some weird synthy type thing? > control points for the sound boaerd used for automation on some fancy desk? > or somthing els? >
Re: music dec tapes? (paper)
On Tue, Jan 1, 2019, 18:23 Bill Degnan via cctalk I have these, plays music over the radio > b > Bill, which of these tapes do you have exactly? I've checked and it would appear DECUS 8-152 is not intended to play over the radio, but rather with a DAC (or two). I'm still working on fully understanding it, but that's my conclusion thus far. Thanks, Kyle >
Re: Motorola M88K books & user manuals (looking for)
On Tue, Jan 1, 2019 at 7:18 PM Jim Manley via cctalk wrote: > RISC was never just about compiler and hardware simplification for improved > performance of the most frequently-executed instructions. It's also been > front-and-center in low-power (e.g., mobile) and embedded (now including > Internet of Things) applications, which each far outpace the number of > devices produced for traditional desktop and top-end computing > (high-performance computing, originally aka supercomputers). It's a big > reason why no one is using Windows Phones, or IoT components based on > x86/x64 hardware today. > Windows Phones were almost entirely (if not completely) based on MIPS and ARM processors. > > Microsoft and Intel made big bets on their accumulated legacy code and > hardware bases being shoehorned into everything imaginable, with what > should have been obviously poor results for most of the application areas > pursued. OK... what does this have to do with RISC? > Anyone remember trying to run Excel on a Windows Phone with > largely the same mess of menus, submenus, subsubmenu items, dialogues, > etc., as on the desktop version? Yep. That sure was a thing that existed. > IoT devices like door locks don't need > scads of registers, instructions, caches, etc., and can you imagine an > Apple or Galaxy Watch with cell capability running on a multicore x64 > processor with a battery smaller than that for a vehicle? > So should I be running Excel on an IoT door lock, then? I'm confused. Were we talking about RISC? > > A Blue Screen of Death is truly fatal for a product that depends on an > embedded device, like an ATM in the middle of dispensing over half a grand > in cash, a DVR in a satellite TV receiver that requires upwards of ten > minutes to restart and get back to where the viewer was (minus the > permanently lost live recorded cache), or a self-driving vehicle at any > speed above zero. Yes, BSoDs continue to happen when memory runs out > before users run out of things they want to do all at one time. Windows > systems can still routinely get to the point where it becomes impossible to > dismiss a modal dialog, close a tab or window, bring up the Start menu or > Task Manager, or other critical user interface element actions that should > always be instantly accessible. This lack of attention to user experience > is endemic to the Wintel way of doing things, going back deep in the > estimated ~100 million lines in their code base. > Good thing RISC solves all of these... uh, problems, then. You should probably send this mail to Microsoft so they can change their ways. > > The x86/x64 instruction set complexity hasn't been helpful in reducing the > security vulnerability of software running on those architectures, either. > The multiple parallel pipelines that make possible speculative execution of > a number of branches before associated decisions are computed, have > resulted in the whole new class of security vulnerabilities such as > Meltdown, Foreshadow, and Spectre. This isn't limited to x86/x64, however, > as the most recent multicore ARM processors have also fallen victim to such > issues, they've just been late to the game as the most advanced (and > complex) features have been pursued (somewhat for me-too marketing > purposes), so fewer families/generations have been affected. > Yes, as you say this is in no way a problem specific to any given architecture, it's endemic across many processor implementations that involve speculative execution. What exactly is your point? - Josh
Re: wanted back issues IEEE ANNALS OF THE HISTORY OF COMPUTING bound or unbound... dtop us a line off list please.
On 1/1/19 8:03 AM, Noel Chiappa via cctalk wrote: > I thought Shustek was a person?) CHM Shustek Center in Fremont, where software and text is stored, and where I have my lab and office. Named for CHM's Chairman (Len Shustek)
Re: Motorola M88K books & user manuals (looking for)
I am looking for original printed copy Il giorno mar 1 gen 2019 alle ore 18:31 Josh Dersch via cctalk ha scritto: > > There are these things called "printers." > > - Josh > > On 1/1/2019 9:13 AM, Carlo Pisani via cctalk wrote: > > yes, but I prefer a printed copy > > > > Il giorno mar 1 gen 2019 alle ore 18:08 Al Kossow via cctalk > > ha scritto: > >> > >> > >> On 1/1/19 7:58 AM, Carlo Pisani via cctalk wrote: > >>> hi > >>> As a second reference, I'd like to consider the first Motorola RISC: > >>> 88K, which is very elegant and neat ISA; unfortunately, I have > >>> difficulties at finding user manuals and books about it. > >>> > >> http://bitsavers.org/components/motorola/88000 > >>
Re: Motorola M88K books & user manuals (looking for)
On Tue, 1 Jan 2019, Josh Dersch via cctalk wrote: There are these things called "printers." A lot of them are getting on in years and getting kinda cranky. There has been a decline in their business due to copy machines for small to medium volume, and overseas competition. But some of them would gladly help newcomers learn how to operate a press. Oh. Maybe you meant computer printers. There are little ones, such as the Centronics 101 (RS232, or a parallel data interface using a 36 pin Blue-ribbon connector), that will fit on a sturdy table. Recommend the 101A; 9x7 matrix is nicer than 5x7 http://bitsavers.trailing-edge.com/pdf/centronics/37400020G_Centronics_Model_101A_Printer_Technical_Manual_Dec1974.pdf Some of the new fancy computer printers even have lower case! Although excruciatingly slow (14.8 CPS, and do NOT exceed that!), the I/O Selectric is versatile. In many offices, newbies will be welcomed by somebody putting in the APL typeball.
music dec tapes? (paper)
anyone seen these music tapes before i grabed this trays for the oddnes of the content of these tapes? also apears to have the software to play them? https://www.ebay.ca/itm/Lot-of-15-digital-decus-Paper-Tapes-w-Case/273628629483?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m2749.l2649 https://www.ebay.ca/itm/Lot-of-8-digital-decus-Paper-Tapes-w-Case/273628539210?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m2749.l2649 would this be some weird synthy type thing? control points for the sound boaerd used for automation on some fancy desk? or somthing els?
Re: wanted back issues IEEE ANNALS OF THE HISTORY OF COMPUTING bound or unbound... dtop us a line off list please.
On Tue, Jan 1, 2019, 4:16 AM Guy Dunphy via cctalk At 09:44 AM 31/12/2018 -0800, you wrote: > > > > > >On 12/30/18 5:04 PM, Paul Koning wrote: > > > >> It might be helpful to state the policy (or choice, if any) explicitly > so people know what to expect. > >> > > > >I will return documents if requested. > > > >Originals may or may not be donated to CHM for archiving, depending on > >if they are duplicative or are of duplicative scope. > > > >I do not archive any paper myself. > > > >Currently, I am being asked to reduce my backlog inside of Shustek > >and am making some hard choices. > > > Hopefully those hard choices don't involve dumpstering anything? > > Would they be less hard, if you mentioned here what your storage > difficulties > involve, and asked if anyone could help with that? Pretty sure you'd find > willing helpers. Who love silverfish. > Don't be like ManualsPlus: "Oh my gosh we have 300,000 manuals and one week > before they have to go to the bin. Err, maybe we should ask for help now." > > > Reading between your lines above, I gather that once you've scanned > manuals, > if CHM don't want them and the donor didn't ask for their return, they are > disposed of? > > Respectfully, I suggest there are better alternatives. Such as offering > them for > sale or giveaway. And that you could probably find volunteers to provide > all > the required work and temporary storage. > > > > > > Guy > I have a lot of ACM SIGPLAN Notice, event proceedings and "Communications" in my document library. Also some DECUS proceedings. Not too much from the IEEE. There is an older website registry of computer preservation hobbyists out there, listed by interest and location but I don't it's actively managed. It could be assumed to include document preservation for thise looking for a home for their docs. This site has been around since 90's but has been updated a few times since launch http://www.cs.unc.edu/~yakowenk/classiccmp/ccrs_list.html Someone should probably mirror this page or even take it over. Another possibility ... On the bitsavers website it might be nice to add a section where people can see what docs are available for pick up/rescue opportunities. Personally I limit my doc storage to what I can store in proper conditions. No silverfish. I will even bathe moldy docs under florescent light as needed, to help control mold. Too much light hurts the paper so only what is needed to restabilize. Personally I am looking for ComputerWorld newspapers from the 60's and early 70's, People's Computer Company newspapers, and early SIG club docs... should anyone be looking for a home for these. Bill >
Re: On Scanning
Very nice book scanner!There is probably a second career out there for you if you chose to make them!Ed# In a message dated 1/1/2019 11:01:31 AM US Mountain Standard Time, cctalk@classiccmp.org writes: On Tue, 1 Jan 2019, Guy Dunphy via cctalk wrote: > This may be a good place to mention a text I began writing some while ago: > > On Scanning. > http://everist.org/temp/__On_scanning.htm > > Meant to be a 'how to' about scanning and post-processing techniques, written > as I > explored that myself. It's not finished because I was working on a solution > to the > 'screened images with overlaid sharp text' post-processing problem, when > sidetracked. > As often happens with me. Also that project diverged into the whole text > encoding > thing. Which I can't discuss, but I *can* discuss scanning issues. > > Anyway, any comments, corrections and suggestions for extra material are > welcome. > Here's a video on a diy book scanner I built in order to scan all the Crescent Software documentation I got. Seems relevant to this. :) https://www.youtube.com/watch?v=niwLAbgRpDE (Crescent Software archive is here: http://annex.retroarchive.org/crescent) g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://scarlet.deltasoft.com - Get it _today_!
Re: Motorola M88K books & user manuals (looking for)
Well as it turns out I have several boxes of databooks that I need to get catalogued and listed. (My decluttering task was supposed to be finished *last* year ...) Here we have: MC88100 RISC Microprocessor User's Manual MC88200 Cache/Memory Management Unit User's Manual Please pay shipping from Texas 78746. Whatever else you want to pay on top of that will be used exclusively to buy more high-quality beer :-) mcl
Re: Motorola M88K books & user manuals (looking for)
There are these things called "printers." - Josh On 1/1/2019 9:13 AM, Carlo Pisani via cctalk wrote: yes, but I prefer a printed copy Il giorno mar 1 gen 2019 alle ore 18:08 Al Kossow via cctalk ha scritto: On 1/1/19 7:58 AM, Carlo Pisani via cctalk wrote: hi As a second reference, I'd like to consider the first Motorola RISC: 88K, which is very elegant and neat ISA; unfortunately, I have difficulties at finding user manuals and books about it. http://bitsavers.org/components/motorola/88000
Re: Motorola M88K books & user manuals (looking for)
On 1/1/19 7:58 AM, Carlo Pisani via cctalk wrote: > hi > As a second reference, I'd like to consider the first Motorola RISC: > 88K, which is very elegant and neat ISA; unfortunately, I have > difficulties at finding user manuals and books about it. > http://bitsavers.org/components/motorola/88000
Re: On Scanning
On Tue, 1 Jan 2019, Guy Dunphy via cctalk wrote: This may be a good place to mention a text I began writing some while ago: On Scanning. http://everist.org/temp/__On_scanning.htm Meant to be a 'how to' about scanning and post-processing techniques, written as I explored that myself. It's not finished because I was working on a solution to the 'screened images with overlaid sharp text' post-processing problem, when sidetracked. As often happens with me. Also that project diverged into the whole text encoding thing. Which I can't discuss, but I *can* discuss scanning issues. Anyway, any comments, corrections and suggestions for extra material are welcome. Here's a video on a diy book scanner I built in order to scan all the Crescent Software documentation I got. Seems relevant to this. :) https://www.youtube.com/watch?v=niwLAbgRpDE (Crescent Software archive is here: http://annex.retroarchive.org/crescent) g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://scarlet.deltasoft.com - Get it _today_!
RE: On Scanning
On another forum, a JW Early did a lot of magazine scans. I'll look to see if I saved any of his descriptions. My memory, he scanned twice, once for line and text, and again for images. Original message From: Guy Dunphy via cctalk Date: 01/01/2019 01:29 (GMT-08:00) To: "General Discussion: On-Topic and Off-Topic Posts" Subject: On Scanning This may be a good place to mention a text I began writing some while ago: On Scanning. http://everist.org/temp/__On_scanning.htm Meant to be a 'how to' about scanning and post-processing techniques, written as I explored that myself. It's not finished because I was working on a solution to the 'screened images with overlaid sharp text' post-processing problem, when sidetracked. As often happens with me. Also that project diverged into the whole text encoding thing. Which I can't discuss, but I *can* discuss scanning issues. Anyway, any comments, corrections and suggestions for extra material are welcome. Oh, and those with an interest in Apple history may find this amusing: http://everist.org/NobLog/20181001_missing_wave.htm Guy Y
Re: wanted back issues IEEE ANNALS OF THE HISTORY OF COMPUTING bound or unbound... dtop us a line off list please.
> From: Al Kossow > I do not archive any paper myself. There are quite a few silver-dish lovers; you might be able to raise some funds by listing stuff on eBait (although I can easily see that maybe it would be more hassle than it's worth). > Currently, I am being asked to reduce my backlog inside of Shustek and > am making some hard choices. Can you say anything about this (it sounds troubling)? Can we help in any way? (And the "inside of Shustek" is puzzling - I thought Shustek was a person?) Noel
Re: Motorola M88K books & user manuals (looking for)
yes, but I prefer a printed copy Il giorno mar 1 gen 2019 alle ore 18:08 Al Kossow via cctalk ha scritto: > > > > On 1/1/19 7:58 AM, Carlo Pisani via cctalk wrote: > > hi > > > As a second reference, I'd like to consider the first Motorola RISC: > > 88K, which is very elegant and neat ISA; unfortunately, I have > > difficulties at finding user manuals and books about it. > > > http://bitsavers.org/components/motorola/88000 >
Re: Motorola M88K books & user manuals (looking for)
Any chance of getting the list to add 'monthly digest' format? 12 doses of this a year would be about right. On 1/1/19 9:13 AM, Carlo Pissant wrote: > yes, but I prefer a printed copy > >> I have difficulties at finding user manuals and books about it. >>> >> http://bitsavers.org/components/motorola/88000 >>
Re: Motorola M88K books & user manuals (looking for)
On 2019-01-01 1:08 PM, Fred Cisin via cctalk wrote: > On Tue, 1 Jan 2019, Josh Dersch via cctalk wrote: >> There are these things called "printers." > > A lot of them are getting on in years and getting kinda cranky. Speaking of which, it's a new year, can we not prolong this thread into a 100 post monster. Book was requested, book was offered, all poster's options are covered, surely, by now. --T
Re: Motorola M88K books & user manuals (looking for)
There are these things called "printers." - Josh On 1/1/2019 9:13 AM, Carlo Pisani via cctalk wrote: yes, but I prefer a printed copy Il giorno mar 1 gen 2019 alle ore 18:08 Al Kossow via cctalk ha scritto: On 1/1/19 7:58 AM, Carlo Pisani via cctalk wrote: hi As a second reference, I'd like to consider the first Motorola RISC: 88K, which is very elegant and neat ISA; unfortunately, I have difficulties at finding user manuals and books about it. http://bitsavers.org/components/motorola/88000
