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
>
>
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
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/
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
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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.
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
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
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
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
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