test-drb

test-drb@ccmp.vtda.org

101090 discussions

CyberVision 2000

by menadeau＠comcast.net

It was sold by Montgomery Ward, and I believe it is a repackaged RCA system (uses the 1802). I have scans of literature if you want more info. ----- Original Message ----- From: "Bill Sudbrink" <wh.sudbrink at verizon.net> To: <cctalk at classiccmp.org> Sent: Saturday, November 06, 2010 6:03 PM Subject: CyberVision 2000 > Hi, > > > > Anyone know anything about this computer? Google reveals almost nothing. > > According to an email I just received, it was sold in the mid 1970's in > department > > stores around Washington, DC. Email claims before the TRS-80 and Apple > II. > > > > Thanks, > > Bill > >

15 years, 5 months

CyberVision 2000

by wh.sudbrink＠verizon.net

Hi, Anyone know anything about this computer? Google reveals almost nothing. According to an email I just received, it was sold in the mid 1970's in department stores around Washington, DC. Email claims before the TRS-80 and Apple II. Thanks, Bill

15 years, 5 months

DiscFerret: First working hardware, firmware and microcode!

by classiccmp＠philpem.me.uk

Hi guys, I have -- just this second -- got the standalone, single-board DiscFerret hardware ("0I06") to image a disc. First, the proof: Scatter plot: http://www.discferret.com/temp/dat.scatter.png Histogram: http://www.discferret.com/temp/dat.histogram.png Raw transition data, gzipped space-separated format. First column is array index, second column is the timing value: http://www.discferret.com/temp/dat.gz Rawbinary track dump, gzipped. Most significant bit of each byte is the status of the INDEX sensor (1=index detected). If (x&0x7f) = 0, then a counter carry occurred -- the next byte should have 128 added to it. Repeated counter-carries are allowed.: http://www.discferret.com/temp/dat.bin.gz MagScan analyser output for dat.bin: http://www.discferret.com/temp/dat.magscan.txt For those of you who have a copy of the sources to my Magdecode decoder engine (I know I sent it to at least one person on-list...), the Rawbinary dump should load straight into Magdecode. The space-separated data can be loaded straight into Gnuplot (which is what I used to produce the plots), and I suspect MATLAB and Octave can probably load it too. The image file was created from an old coverdisc from "PC Zone" magazine, and is completely undated on the label. The volume label is "PCZ_OCT_3" which suggests it's from October, with last-modified dates in February and August 1993. It only covers Track Zero, which (if memory serves) is the MBR, FAT and Root Directory. The disc is 720K DOS format, sampled at 40MHz. Other things to note: - The hardware works fine at 80MHz, and possibly faster than that. It should be possible to sample with enough resolution to image a 5Mbps MFM hard disc. - There are plenty of spare registers. The new PIC uses 8-bit multiplexed addressing, which gives 256 register addresses. Only 16 are in use at the moment (!) - Write support isn't enabled yet. I need to port this across from DiscRW and test it (and no doubt rewrite parts of it, as I did with the reader engine). Surprisingly, there are only a few minor issues on the 0I06 PCBs: - C6 is missing a polarity marker. This is a non-issue, as one end connects to the ground plane and the other quite obviously connects to +5V. - Some of the component pads are rather small (notably the inductors and Schottky diodes in the power supply). This makes it hard to heat both the pad and the component pin at the same time, and thus makes the parts a bit of a pig to solder. I worked around this with a hot-air gun, preheater and solder paste... later boards will have bigger pads. - The power supply chip is a QFN with pads under the chip. The only way to solder it down is to use a hot-air gun... unfortunately TI don't make this chip in a more accessible package, and the only viable alternative would have nearly doubled the size of the power supply. Despite these issues, it's perfectly possible to assemble a 0I06 and have it work perfectly, without any "green-wire" fixes. I'm impressed: usually a first-spin board needs at least one track-cut and a couple of green-wires :) Now here's where you guys come in. I really don't want to have boxes and boxes of unused boards and parts hanging around, so I need to know how many people would like to buy a DiscFerret. These would be available as: - PCB only - PCB with the power supply section assembled and tested - Fully assembled and tested PCB - Some other form -- feel free to make suggestions! I'd appreciate it if anyone interested in buying a DiscFerret could email me at philpem at philpem.me.uk, with one of the following in the subject line (start, end, on its own, uppercase, lowercase -- anything will do, my procmail rule is pretty lenient): - "I want a PCB on its own" -- DISCFERRETBARE - "I want a PCB with the PSU built and tested" -- DISCFERRETPSU - "I want the whole thing ready-built" -- DISCFERRETBUILT - "I want a DiscFerret in some other form" -- DISCFERRETOTHER Thanks to everyone who has supported the project thus far -- your thoughts, ideas, comments and criticisms have been very useful! Now to get my reflow oven working and build some prototypes... :) Thanks! -- Phil. classiccmp at philpem.me.uk http://www.philpem.me.uk/

15 years, 5 months

TRS-80 Model II Manuals

by nathan＠nathanpralle.com

Thanks to the ever-useful JP Hindin, I've obtained a set of TRS-DOS disks and other application disks for my TRS-80 Model II system, which is the entire setup pictured here, plus a bit more: http://oldcomputers.net/pics/TRS-80-II_table.JPG It's been sitting, covered, pretty much since I obtained it, but now I can try reviving it and actually seeing what it can do. I'm going to tear into it and clean the drives and so forth, document what it has, etc. and then boot 'er up and see what we can see. I'm looking for a copy of the Technical Ref manual for it; despite finding scans of the covers and so forth online, I'm unable to actually locate one. In addition to that, if someone has a Shugart 8" Service Manual, that might come in damned handy for making sure those are up to speed as well. Many thanks, Nathan -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nathan Pralle, Computer Geek Email: nathan at nathanpralle.com Web: http://www.nathanpralle.com Blog: http://www.philosyphia.com Twitter: http://twitter.com/NathanPralle -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

15 years, 5 months

FF: 2 Maxspeed MaxStations

by g＠kurico.com

Anyone interested in two MaxSpeed MaxStations? One is a SVGA MaxStation and the other a VGA MaxStation. The SVGA version uses a PS2 kb connector, the VGA version an AT kb connector. Sorry, no power supplies. These are free, I'd prefer not to ship, but if I have no local takers then the buyer to pay shipping costs. I'm in Austin TX. These will go to Goodwill if no one is interested. I'm in the very very early stages of shedding the majority of my collection and this is just the start.

15 years, 5 months

Virtual memory

by bqt＠softjar.se

On 2010-11-01 00:02, "Chuck Guzis"<cclist at sydex.com> wrote: > On 31 Oct 2010 at 11:37, Johnny Billquist wrote: > >> > The important question here - are the programs aware of the RA >> > register, and can they change it? And can they address the full range >> > of memory addresses as perceived by the program. > No they aren't. Their memory exists from 0 to whatever the field > length is, physically and continously. If they need more, a system > request can expand their field length provided the system has > sufficient physical memory to accommodate them. There is no way > (absent perhaps a system request to get that information) for a > program to know its real physical base address. Ok. So, a program would think it addressed a memory space, which was it's own, and the addresses it used would in no way related to the actual physical memory it ended up referring to. I'd call that virtual memory. Although, having to map the whole virtual memory as one chunk to physical memory makes it a little more work, end less flexible than having pages. And it pretty much prevents you from ever being able to share memory in a reasonable way between processes. >> > Another word for swapping in and out? > But much older and specific to the architecture and not done in > pieces as a tranditional VM swap file would be. Hmm. I don't think swapping is considered to be done in pieces today either, although swapping is also a term that seems to be defined differently depending on which OS we're talking about. Unix systems can both page and swap. Swapping is throwing everything out to disk, including some kernel structures for the process. Don't happen that often nowadays... Paging is normally enough. > I'll take the coward's way out and use the dictionary here: > > "1. Existing or resulting in essence or effect though not in actual > fact, form, or name" > > So my definiton of "fooling the user into thinking he has more > physical memory than he actually has" is certainly valid. > > And the VAX sense is also true, but only if one takes along with it > the ability to over-commit memory space such that the amount of > addressable memory (i.e. the sum of all users' memory) is greater > than the physical memory present. > > A single task running on a VAX with at least as much physical memory > as addressing space would not be using the virtual memory facility-- > every bit is reflected in the presence of real memory. > > But then, we fall on marshy ground again, when we consider the old > "roll/swap" multiuser situation. I can run 8 jobs, each requiring > 65K of memory on a system with 128K physical memory, simply by > selecting when I give each a time slice and swapping/rolling them out > as needed. So is that virtual? Indeed. I remember (not so fondly) running on a PDP-11/70 back in the 80s. The machine was running RSTS/E V7, and the system allows max 63 jobs. We were at times actually 63 users running on that machine, and it only have 1.5M of memory. It was swapping a lot, and things sometimes went slow, but it worked perfectly fine. Seeing a machine today with over 60 users is not common, and I'm not sure it would feel a single bit more pleasant than the RSTS/E system I used back then... And I'd still claim that the memory used by each process was definitely virtual. And I'm willing to continue to fight for that view. Besides, for the PDP-11, that is what DEC called it. :-) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

15 years, 5 months

PDP 11 Core Memory

by pontus＠update.uu.se

2010-11-05 23:42, Tom Gardner skrev: > > Good eyes! > > When I look more closely, it seems that the X and Y lines are under > the center sections but no cores, ergo, 16 core mats. I'd like to see > a real one to confirm. > > Tom > The reason I noticed is that I looked at a core memory board for a PDP-10 just the other day, it had one half section with missing core. I could take a picture if you like. /P

15 years, 5 months

Tek 4051 in Austin

by swtpc6800＠comcast.net

The TEK 4051 is a Graphics Terminal with BASIC in ROM, It used the Motorola 6800 microprocessor. I did a Wikipedia article on the MC6800 and illustrated it with several old advertisements including the first M6800 ad and a Tektronix 4051 ad. Here is the article http://en.wikipedia.org/wiki/Motorola_6800 And here is the TEK 4051 ad. http://commons.wikimedia.org/wiki/File:Tektronix_4051_ad_April_1976.jpg Michael Holley -----Original Message----- From: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org] On Behalf Of steve shumaker Sent: Friday, November 05, 2010 2:37 PM To: On-Topic and Off-Topic Posts Subject: Tek 4051 in Austin Tektronix 4051 functioning system??? Austin C/L #2043597225 looks in fair shape.? supposedly working...?? wants $150 cash and? pick up only steve

15 years, 6 months

HP9845 design article in EDN

by cclist＠sydex.com

No one seemed to notice this, but I thought I'd post it for Tony's edification. It's a story in the October 7 EDN from the "Tales from the Cube" back section and deals with solving a problem with the I/O board of the HP9845: http://bit.ly/cNwokC (it's a PDF) Enjoy, Chuck

15 years, 6 months

MFM and ESDI SCSI bridge boards (was Re: SCSI emulator)

by ethan.dicks＠gmail.com

On 11/5/10, Jules Richardson <jules.richardson99 at gmail.com> wrote: > Dave McGuire wrote: >> On 11/5/10 2:00 PM, Jules Richardson wrote: >>> It's a bit more murky than that (albeit a related issue) because a lot >>> of the bridge boards expect a vendor-specific command to tell them the >>> drive geometry of the attached drive... >> >> MFM- or ESDI-to-SCSI bridge boards (Adaptec ACB-4000, Emulex MD21 if >> memory serves) are weird to begin with... > > I think the Adaptec was one of the most sane boards out there I do have some experience with a couple of them, primarily the ACB-4000 > IIRC it stores > the drive geometry on block zero of the drive at format time, then at > power-on fetches that block back and initialises itself with the loaded geometry. That sounds somewhat familiar to me, but I wouldn't have been able to have said that's what it did without looking it up first. > I can't remember if it just hides the first block from the user, or hides the > whole track. I really can't remember that detail - been way too long, but if I had to guess, I'd guess "block" since I have a fuzzy memory about some detail about moving, say, an ST225 on and off an ACB-4000 and a different kind of controller (an XT MFM card most likely, possibly a WD WX-1 or Everex clone). > I think the board responds to Inquiry, too (although it just returns "ACB > 4000" rather than anything to do with the geometry of the attached drives) That also sounds familiar (having played at the low-level back in my early Amiga days). > I've not played with the Emulex boards - I think the only ones I have are > tape bridges rather than disk. I have a couple of the Emulex bridging boards from the Sun-3/early Sun-4 days, but I never had to set them up - they were black (beige, really ;-) boxes to me. I just stuck them on a Sun box and don't remember any special fiddling. > The Xebec and Omti boards seemed reliable, but their SCSI implementations > were > a little lacking (one of them I think had the option of a user-supplied ROM > with the expected disk geometry encoded into it, but it still wasn't "SCSI > enough" to work with a modern system) I think I tried to fiddle with an Omti board once but didn't achieve enough success to use it. One reason I tried was it was a combo hard-drive/floppy drive model. It would have been handy, but alas no. It's likely I was running into one of those "almost-SCSI" problems and lacked sufficient documentation. Since I moved from PETs and C-64s and small DEC machines first to Amigas and Macs, then much later to PCs, I was very happy when embedded SCSI drives displaced all the Adaptec and Emulex and Xebec and Omti boards - much easier to set up and move from environment to environment. -ethan

15 years, 6 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