test-drb

test-drb@ccmp.vtda.org

101090 discussions

by dm561＠torfree.net

Message: 12 Date: Fri, 12 Feb 2010 08:44:40 -0800 From: "Chuck Guzis" <cclist at sydex.com> Subject: Re: Hacking a typewriter into a teletype To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Message-ID: <4B7514F8.19394.8B6F5 at cclist.sydex.com> Content-Type: text/plain; charset=US-ASCII On 12 Feb 2010 at 6:36, Christian Liendo wrote: > I figured some one on this list would find this useful. > > http://numist.net/post/2010/project-typewriter.html Didn't a number of Brother typewriter models have the capability of also serving as printers--without modifications? I also wonder if it might not be better to start with a word-processor type of typewriter. Mr. Obvious on the web page stated: "it also revealed that avr-gcc's code generation is very poorly optimized" --Chuck ----------------Reply: There's a genuine Brother computer>typewriter RO interface for sale right now ($5) on the Vintage Computer auction site. And if anyone wants to convert an Olivetti typewriter, I still have a box full of interfaces for several models from the days when I was involved in their sales and support. mike

16 years, 2 months

cctech Digest, Vol 78, Issue 3

by jonas＠otter.se

On Mon, 1 Feb 2010 , ard at p850ug1.demon.co.uk (Tony Duell) wrote: > >That sounds more like the Intel 8251 USART. IIRC on that chip you have to >send the reset command 3 times to ensure it's treated as a command and >not as data to be loadrd into one of the configuration registers. > >-tony > Hmm, I must be getting old. Between about 1983 and about 1990, I wrote a fair amount of software for a communications board which I designed, and which used an 8088, an 8259, an 8253, 8255s, and, for some reason I cannot remember now, I think it used 6850s for the serial ports. We started out with all Motorola peripheral chips but found out that the timer chip wouldn't work properly together with the Intel bus, so we switched to Intel. I do have the distinct impression that we kept the 6850s for some reason, probably price, and, I think, simplicity. We had no need for synchronous communications so that would have been a reason. We had an earlier all-Motorola design (6809-based) we got ideas from (I had never designed any microprocessor circuitry before), and IIRC, I started out sending a single reset command, which didn't work, and then I looked at the other design and saw that their software sent 3 resets, which I then understood the reason for. I may be wrong, as this was 27 years ago, but it would be easy to test. I can't, as I have nothing to test on. And Charlie C, had you asked me 27 years ago I could have told you exactly what to do ;-) Whatever it was I did, it worked well, because we sold a number of those boards, each of which used 4 serial interfaces. It annoys me that I can't be sure whether we kept the ACIAs or changed to Intel. Wh?t I do remember is that the Motorola chips were simple and elegant compared to the Intel chips. /Jonas

16 years, 2 months

Dave's walls (was: Selling Calcomp 565 plotter)

by ken＠seefried.com

"Chuck Guzis" <cclist at sydex.com> wrote: > >Fur critters, huh? I'm fighting a running battle with some nutria >that keep invading my pond, but they are definitely not "cute". > They are, however, reasonably tasty when properly prepared, so there's a way to deal with that situation. KJ

16 years, 2 months

OT: Datasheet for Motorola MCM62940 32K X 9 SRAM?

by trag＠io.com

Anyone have a datasheet for the MCM62940 (MCM62940AFN14) static RAM? It's not strictly off topic, as it's from the 256K level 2 cache of a computer >from the mid-90s (NuBus PPC Macintoshes). The usual web searches have failed me. I thought I had downloaded it years ago, but it turns out I only collected the datasheet for the TAG SRAM and not for the cache chips. This is particularly interesting because one can get 4000 of the chips (soldered to boards) for about $50. <http://eshop.macsales.com/item/Motorola/CACHE256M500PK/> I have a couple of projects in mind where they might be useful. On the other hand, they do take up a lot of board real estate (about .75" square). Jeff Walther

16 years, 2 months

Fwd: [comp.sys.dec] BASIC-Plus-2

by legalize＠xmission.com

This message has been forwarded from Usenet. To reply to the original author, use the email address from the forwarded message. Date: Fri, 12 Feb 2010 15:18:22 -0500 Groups: comp.sys.dec From: "Tom Lake" <tlake at twcny.rr.com> Org: albasani.net Subject: BASIC-Plus-2 Id: <hl4d6a$4vt$1 at news.albasani.net> ======== I'm running RSTS/E on the SIMH PDP-11 emulator and it works fine. It only has BASIC-Plus, though. Is there somewhere I can get a disk or tape image of BASIC-Plus-2? Me ntec was swallowed up and the new owners don't want to know from PDP-11. TIA Tom Lake

16 years, 2 months

S-100 home brew PCB projects

by lynchaj＠yahoo.com

Hi! John Monahan and I are making some S-100 home brew PCB projects. The S-100 backplane, S-100 prototyping board, and S-100 buffered prototyping board projects are essentially done. I am gathering up those who would like any of those boards and when there is sufficient interest I'll make a manufactured PCB order. We nearly done with the S-100 IDE and S-100 keyboard projects. Both projects have been prototyped, manufactured PCBs made, and are demonstrated working. However, there are a few minor issues we'd like to clear up on both projects and are considering respins of those PCBs. If anyone is interested in those projects please let me know so I can make an order. The PCBs typically are in the $20-$30 range depending on quantity. There is an S-100 SRAM/EPROM prototype PCB in the build and test phase and an S-100 Front Panel in design phase. No estimate on when either of those will be done but it will be quite a while since we are making local prototype PCBs first before ordering manufactured PCBs. Thanks and have a nice day! Andrew Lynch

16 years, 2 months

IMSAI / SOL-20 / Northstar + much other for sale

by gmeanie＠gmail.com

Any of those old computers left?

16 years, 2 months

Dave's walls (was: Selling Calcomp 565 plotter)

by dm561＠torfree.net

*************Original Message: Date: Wed, 10 Feb 2010 01:36:01 -0500 From: Dave McGuire <mcguire at neurotica.com> Subject: Re: Selling Calcomp 565 plotter <snippage> I work at home, and one very large room in my house is my office. An entire wall of my office, and most of another wall, is a row of racks: http://www.neurotica.com/misc/wall-o-pdp.jpg There's more behind where I was standing when I took the picture, but you get the idea. <more snippage> -Dave Dave McGuire Port Charlotte, FL ************Reply: Is that a prayer rug on the floor? Or just there to mop up spilled bits? m *******************************************************************************

16 years, 2 months

Manual Needed

by jthecman＠netscape.net

Hello Does anyone have a copy of the hp Draftmaster II manual for loan, sale, can make a copy of it? Thanks, John K

16 years, 2 months

The value of assembler language programmers [was RE: Algol vs Fortran was RE: VHDL vs Verilog]

by roger.holmes＠microspot.co.uk

>> >>> *Every* generation of programmers has *always* looked down on their successors >>> as using tools that waste too much computer time to do too little. Of course, >>> *my* generation (started programming in 1969 on a 1401) is right. ;-) >> >> I certainly agree with you in principle, but I still wonder why even >> non-GUI application bloat has to be as bad as it is. We used to put >> 25-40 users on an 8MB VAX before it would start to swap. Now, still >> using a character based interface (which happens to be ssh vs direct >> serial connect, but that doesn't affect CLI application size), a >> program to tell me what processes are active on the system is 8MB by >> itself, vs a few dozen K bytes (I should go back and dig out one of >> those programs from the old days and port it to a modern machine to >> compare library bloat vs application bloat. Fortunately, I have my >> backups from 25 years ago). > ICBW, but I think a lot of the bloat is caused by the layer upon layer > upon layer upon layer of application interface code. My theory is that > all those layers arose because of inadequate or incompetent design in > the first place. Then too, I think we have a lot of "features" that are > rarely used and that we would be better off without, to say nothing of > all the changes for no apparent reason other than to just be different. > I also suspect that some of those spurious features are the root cause > of a lot of the security holes. Too, your "non-GUI" application is > probably actually running inside a system GUI which only emulates the > non-GUI user interface you think you're using. :-) I too started programming in 1969 but on a 7094, though as a schoolboy sending off cards one week to get results the next week. Yes of course we're right :-) I agree there are far too many levels of interface code, many with bugs in them which sometime get corrected in a different level. Take text on the Mac, there was a simple technology for drawing text in QuickDraw on Lisa, it did proportional fonts, different size text, handle descent, ascent and leading. On Mac they added a Text Editing manager. Then they had to allow for internationalized for non left to right languages, then they added kerning etc then they tried to replace the Text Editing manager with the Multi-Lingual Text Editing manager, then along came Unicode and we got ATSUI (The Apple Type Services for Unicode Imaging) and so it went on, all the old levels are still available, though deprecated and unavailable to 64 bit Apps. Trying to get a Carbon application to get Unicode text to appear at the right size on a non 72dpi screen AND print properly is somewhat of a nightmare. I would like to discuss Moore's law and how it seems to have broken down in recent years. Processor speeds are still increasing but not at the expected rate, but I wonder if the real problem is RAM speed, which does not seemed to have kept up, and no longer seems to be quoted when you buy a computer, or at least a Mac. Of course on chip and level 2 cache has made tight loops of small pieces of data acceptably fast but real world programs don't do that. Think about rotating a 12 mega pixel image for instance, yes the code is a tight loop but the data isn't. Think about rendering a 3D scene with many textured objects with accurate shadows and per pixel shading and anti-aliasing ready for printing on a A0 (about 34 inch by 44 inch) printer and complex enough not to fit the capabilities of the graphics processor so it has to be done in the main processor cores. The data being processed is far too big to fit in the caches and the output pixel maps are too, though I admit it only processes one pixel at a time. Oh and while you are at it, think about error diffusing the output. I know on the PowerPC the rotation or a one bit per pixel actually ran quicker if I turned the cache off because for every bit I fetched it loaded the cache with four words of data. Does something similar happen on Intel? By the way I spent three hours this morning showing a BBC regional news crew my 1962 mainframe, apparently it will be condensed down to three minutes. I don't have a transmission date, it didn't go out today and probably will only shown in the south east area of England but should be on the BBC web site. Oh and a couple of weeks ago I posted an old video of it on U-Tube if anyone is interested the URL is http://www.youtube.com/watch?v=VsBPuUJPvKg or just Google ICT 1301 and select video. I hope to post a better one later in the year. Roger Holmes

16 years, 2 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb