All,
As I try and rationalise some of my collection, I have a SGI that I
can see that I will never really have a use for and would like to give
to a good home.
I have the keyboard, screen and mouse to go with it. The machine is
complete and worked last time I powered it up - about 12 months ago or
there abouts. It is currently running some version of Irix. I don't
know how much memory or the size of the HDD, but I seem to remember
the HDD was somewhere between 200MB and 1GB - so not exactly huge.
>From the part numbers, it has an old 8 bit frame buffer and the CPU
is, "R4600PC -100mhz Primary Cache only".
Ideally, I would like it to be collected from Cheltenham UK. However I
work in Witney and I am up in the Milton Keynes area on weekends and
can deliver to these areas, or on my way to / from Cheltenham.
Bristol, Swindon and London are also deliverable when I am next in
those areas.
Thanks.
Simon
--
------------------------------------------------------------------------
"Well, an engineer is not concerned with the truth; that is left to
philosophers and theologians: the prime concern of an engineer is
the utility of the final product."
Lectures on the Electrical Properties of Materials, L.Solymar, D.Walsh
Hello,
a few interesting items in the U.K. have recently popped up here - and the VCFe (which usually attracts some visitors from North of the Channel) is getting closer, so I figured I might try organizing a transport once again.
I'm still in the process of contacting the current owners as I wanted to inform myself beforehand whether I can arrange transportation. Items may be coming from:
-Glasgow
-East London
-Dorset (this one is fairly critical, would have to be collected before Christmas)
and would have to be transported to southern Germany (Nuremberg area) for some compensation (meal, fuel money, etc).
Offers and suggestions welcome.
Thanks in advance, yours sincerely,
Arno Kletzander
--
Psssst! Schon vom neuen GMX MultiMessenger geh?rt?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
"Roy J. Tellason" <rtellason at verizon.net> wrote:
> On Friday 23 November 2007 22:23, Chuck Guzis wrote:
> > There are many kinds of mechanical memory. In particular, I recall
> > an early TTY device that used a large rotating drum with cams
> > embedded in the surface. One could flip a cam one way or the other
> > and then read them out. I'm trying to remember what sort of machine
> > this was used on and its application, but my memory sadly fails me.
>
> This stirs a vague recollection of an old mechanical adding machine I
> once had, the kind that had a big rectangular array of buttons instead
> of just a "10-key" set of numbers. I have *no* idea how it stored a
> number in there, though.
Hmm, like, say, an old cash register? This design is called "Volltastaturmaschine" in German (would translate to "complete keyboard machine"). They have a latching mechanism that holds in one button per column of keys (0-9, representing one digit of a number). When a calculation is initiated, the protruding shaft of the latched key acts as a stop for a toothed rack or similar device which is used to advance the wheels of the accumulator register by as many teeth as the corresponding digit says. There are also designs which involve an arrangement of levers positioning an intermediate gear along the axis of a stepped drum, for example the Badenia VA-17/VARE-17.
The big advantage is that zeros need not be entered (to enter 100.00, you just press the "1" button in the fifth column from the right) and that operators could learn to "touch-type" on these keyboards, effectively entering all digits of a number in parallel and greatly reducing cycle times. Also, correction of mistypes is very fast and easy because you just have to latch the correct key in the respective column. I have a Diehl EVM series machine of that type, unfortunately the mechanism is about completely gummed up from old grease.
Most mechanical and electromechanical ten-key adders contain a "pin carriage", which essentially is such a keyboard in miniature. A set of push rods connected to the ten keys is suspended above this construction; upon entry of a digit, the corresponding pin (sticking out through the top of the carriage after a clear) is pushed through (now sticking out at the bottom) and the carriage is advanced one position by an escapement mechanism.
> Going back even earlier, I had the occasional chance to play with some
> mechanical calculators. These were about the size of an old typewriter,
> and there were a couple of different sets of readouts that consisted of
> digits that showed through small windows on the front of the machine.
> It had a "carriage" of sorts that would shift back and forth at times,
> though my fuzzy recollection isn't clear on when it did that. And when
> you told it to multiply, it'd really take off! :-)
Ah...I suppose these were Odhner / Facit electromechanical pinwheel calculators, or at least a similar construction. I got one of those not very long ago and I'm very fond of it! A wealth of information about them is to be found on James Redin's Facit Page, http://www.xnumber.com/xnumber/cmisc_facit_page.htm
The input register on those is a bank (or "drum") of pinwheel mechanisms which are actuated by the input keys - gears with an adjustable number of teeth, so to say. The "pins" are extended or retracted by rotating two parts of the gear against each other. For the calculation cycle, the adjustment is locked and the whole drum turns once, advancing the adjacent intermediate wheels (and thus the accumulator wheels) by the number of pins set.
Machines with keyboard entry had to use a "split pinwheel" design in order to reduce the key travel needed, involving four pins and a sector with five more. 1 - 4 steps UP from the zero position extended 1 - 4 pins; 1 - 5 steps DOWN extended the sector AND 0 - 4 pins. Mechanical Bi-Quinary.
Once a digit is set, the drum is advanced one step to the left and the next unset wheel is positioned in front of the setting mechanism.
So long,
--
Arno Kletzander
www.iser.uni-erlangen.de
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
Hi, all,
In the past, I've run real Amigas (from my 1986 A1000 to my 1997 A4000), and
I've run plenty of Amiga emulation ("Amiga Forever", etc.). Can anyone
recommend a good URL for running Amiga apps under my present platform of
MacOS 10.4?
I have apps, I have ROMs, etc. I just need a good Intel-Mac-based Amiga engine.
Thanks,
-ethan
--
Ethan Dicks, A-333-S Current South Pole Weather at 29-Nov-2007 at 10:50 Z
South Pole Station
PSC 468 Box 400 Temp -29.0 F (-33.9 C) Windchill -44.3 F (-42.4 C)
APO AP 96598 Wind 4.2 kts Grid 112 Barometer 682.8 mb (10523 ft)
Ethan.Dicks at usap.govhttp://penguincentral.com/penguincentral.html
-------------Original Messages:
Date: Thu, 29 Nov 2007 15:30:51 -0800 (PST)
From: Fred Cisin <cisin at xenosoft.com>
Subject: Re: Teaching kids about computers...
> > Here's a question - what
> > 8-bitters (or defunct 16-bitters, Atari, Amiga, you
> > know, the common stuff) had COBOL available?
> > What was SNOBOL? What about COBAL? I think I > have COBAL for the TI PC.
For a while, I had a binder on one of my office bookshelves labelled
"COBAL", due only to having a temporary worker who couldn't spell COBOL.
What is the model number for the EAM card interpreter?
At the college, I had a plugboard from one of them specifically set up for
putting the relevant fields of COBOL source files in handy locations on
the card (the interpreter did 60 columns of text, so it did not line up
with the columns on cards). That particular plugboard was clearly
labelled "COBOL Interpreter". So, yes, there was a COBOL interpreter :-)
--
Grumpy Ol' Fred cisin at xenosoft.com
-----------Reply:
LOL!
There were several different models - see:
http://en.wikipedia.org/wiki/List_of_IBM_products
We did have one, but I don't recall which one (probably a 557 or 548);
machines that printed card contents on the card were indeed called
"interpreters."
They were used mainly for utility bills, etc. which were often printed on
punched cards to be returned with your payment for processing. We
didn't do that sort of work very often, and when the cards had to be easily
human-readable (such as your COBOL cards) they'd be punched on a
printing keypunch (026) in the first place.
BTW we also had a somewhat rare 047, which was a printing keypunch
that could also read (and convert) paper tape.
m
> I know you can program on the Amiga using the following languages:
> Assembler
> Amiga BASIC
> AMOS BASIC
> Blitz BASIC
> Rexx
> Arexx
> C
> Machine Code
> I don't think I missed any.
Ada, Smalltalk, Forth, Fortran, Pascal, Lua, Lisp, BCPL, Prolog,
Comal, C++, HeliOS, Intercal, J, Java, Visual Pascal, Brainfuck,
Logo, Malbolge, Cobol, Perl, Pilot, Scheme, Python, Perl, SML, Y
and many variations of same. And those are just the free ones.
For more go look here ..
http://aminet.net/search?f=2&path=dev/lang
Lee.
.
Hello,
I exhibited some of my Sage and Stride computers, manuals, datasheets, newsletters and software at the Vintage Computer Festival 10.0. It was an exciting and rewarding event and I'm looking forward to the next one. I took some pictures and video. I've uploaded the pictures, the video will follow soon.
VCF 10.0 pictures:
http://entertainment.webshots.com/album/561582429RvEsQG?vhost=entertainment
One of the Sage Computer Technology founders, Rod Coleman, gave a talk about the early days of Sage Computer Technology and some of the Stride Micro story. Sellam let me add one of his computers to my exhibit, a Stride 440 (http://www.sageandstride.org/html/stride_440.html). During the show a really interesting guy came to visit my exhibit and he told me about his experiences with Sage and Stride computers. He still has the original systems he used for development in the 80's. More on that interesting story later ...
He has a couple Sage IV's (in beautiful condition) and a Stride 460 tower!! (http://www.sageandstride.org/html/stride_460.html) I've been looking for a Stride tower for quite a while. Recently, he let me get my grubby hands on the Stride 460 tower and I've been restoring it. It was not in the best condition when I picked up the pieces. I've documented the process with tons of pictures that I've uploaded for others to enjoy. I'm not finished with the project. I'm hoping to get the system fully operational and then retrieve the data from the hard drive. I've pulled the hard drive from the system and substituted another MFM drive until I've figured out the safest method for retrieving the old data. I'll be asking for advice on that topic soon. I think the original drive has Idris installed.
Here are links to the pictures of the Stride 460 system:
Disassembly:
http://entertainment.webshots.com/album/561576298tAcFSb?vhost=entertainment
Cleaning:
http://entertainment.webshots.com/album/561577961QEgBvM?vhost=entertainment
Reassembly:
http://entertainment.webshots.com/album/561575340kcreuM?vhost=entertainment
Booting:
http://entertainment.webshots.com/album/561575350zNSULy?vhost=entertainment
Stride 460 datasheet:
http://www.sageandstride.org/html/stride_460.html
Any suggestions on how to carefully check if an old MFM drive is still operational, without damaging it, are appreciated. The drive has some oxidation on the exterior and it appears to have been stored in an occasionally damp location.
Regards,
david.
- - - - - - - - - - - - - - - - - -
David W. Erhart
daviderhart at hotmail.com
daviderhart at oldzonian.comhttp://www.sageandstride.org
Hi,
I am working to restore an old Vector Graphic machine. I think it is a VG 5
series machine but sort of an odd hybrid. It has a VG 1 case repainted and
relabeled as a "No Name Computer" with all VG 5 components inside.
Seriously, it is called NNC and that is not a joke. It is a very strange
name.
It contains a ZCB (Z80 CPU board), 64K RAM, Flashwriter II (video and
parallel ASCII keyboard interface), and integrated FD/HD controller (aka
VEDMCS).
After working on this machine for weeks, I finally got it to boot CP/M 2.2
with a 56K TPA! YAHOO!
I am very happy and thought I would share the good news with the folks on
the VG and CCTALK mailing lists.
If anyone needs or wants a VG 5 series CP/M boot disk to restore their
machine, please send me an email and I will make you one. If you are
interested in discussing Vector Graphic, feel free to join us on the VG
mailing list.
Thanks!
Andrew Lynch
PS, Here is all the info on the mailing list:
http://h-net.msu.edu/cgi-bin/wa?A0=VECTOR-GRAPHIC
To post (send a message to all subscribers), address your e-mail to
vector-graphic at h-net.msu.edu. To unsubscribe, send the command
"unsub vector-graphic", without the quotes, in the BODY of the message, to
listserv at h-net.msu.edu. For other help, e-mail Dennis Boone <drb at msu.edu>.
I've finally acquired enough of the missing boards to try for a console
prompt. But I want to do this carefully. I don't want to fry any of these
modules if my power supplies are not on spec.
I'm still waiting for a power key that's in transit (graciously copied by
another classiccmp'er), but I figured I could just set the power controller to
local and crank it up.
So, after cleaning and reforming the removable capacitors[1], I figured
that I wanted to apply power to the system with all the loads removed, and
confirm proper voltages on the outputs.
I left the backplane completely empty of boards, and I disconnected the
power cable to the TU58 controller, just to be safe. I get a good AC
indication on the controller when I plug into the main AC supply circuit.
Switching the breaker on and the control switch from OFF to LOCAL gives
good air from the (loud!) blower, but...
What I see on the power controller indicators is the '+2.5 FAIL' and 'REG
FAIL' LEDs both light up, then several seconds elapse and the 'OVER
VOLTAGE' LED will flick on and the REG FAIL flicks off for about 1/2
second, then the whole sequence repeats. Each cycle takes about 8
seconds. A couple of photos of this can be found at:
http://www.rogerwilco.org/VAX11-750/psfault
I admit that I've never dealt with such a complex power system before,
and I've just spent the last hour or so reading through the 'VAX 11/750
H7104 Power System Technical Description' document that I found on
vt100.net. Trying to get my brain around what's going on, I came across
the fault isolation section and it seems that what I'm seeing on the Power
Controller LEDs maybe indicates a "Fault in the CPU backplane".
Of course, there is no CPU installed yet. Could this indication be normal
when no boards are installed?
I'm hesitant to install any of my precious boards until I'm convinced that
the power supplies are good, but maybe I have to install one (or more)
boards to actually close the loop on something.
Further reading tells me that there is a +2.5V-at-the-backplane monitoring
function in the +2.5V power supply. I haven't yet looked at this particular
issue up close, but maybe the monitor circuit is not complete without the
proper board in the backplane. Is this a sensible explanation? I just want
to be sure that putting one or more boards into the backplane is a safe
next step.
Thanks!
- Jared
[1] System hasn't been powered since 1994. I went through the motions,
but I don't think the caps needed any help; the readings during the
reforming process seemed to show them in good shape from the start.
Hi,
I've got a pair of AlphaServer 1000A systems available for free to whoever
wants them. I need the space.
These were previously rack-mounted, include memory and disk, and
were working last time I powered them on.
I'm near Plymouth Meeting, PA, USA, about five minutes from the PA
turnpike exit.
Please email me if interested.
Mark
--
Mark G. Thomas (Mark at Misty.com)
http://mail-cleaner.com/
Regular drill bits will work fine as long as you go slow and easy -
especially when you are about to "break" through the other side. Dull
bits work better. The bit the salesman was trying to get you to buy was
actually a bit designed to scrape the plastic instead of cutting it.
The angles are different on the bits.
Also, when using screws to join your pieces together be sure to drill
your holes slightly larger than your screws. This allows for some
movement of the plastic and prevents breakage at the stress point.
--- Michael Lee <mikelee at tdh.com> wrote:
> I just received an old-ish (1990) Toshiba T1000LE
> laptop and it wouldn't
> boot, so I took a look at the hard drive and there
> seems to be some type
> of goo oozing out of it. It's a Conner hard drive,
> nothing too abnormal.
>
> I didn't think a hard drive contained anything that
> could ooze out. Any
> idea what it could be and does that mean the drive
> is pretty much
> toast? Let the magic goo out?
-------------
I've had that problem with a Conner drive in an Ogivar laptop; it was
the gasket between the housing and cover decomposing the same
way as drive rollers etc. My drive was still working though and, after
removing the goo and wrapping a layer of tape around the perimeter,
still is (at least so far).
m
> is it likely that I'll
> be able to read it on the programmer like a standard PROM/EEPROM?
Most likely. You will need to verify on the schematic that they didn't
use the extra lines to control programming as chip selects, though.
From: Richard <legalize at xmission.com>
In article <474E0308.2010901 at atarimuseum.com>,
"Curt @ Atari Museum" <curt at atarimuseum.com> writes:
> There was an urban myth back in the late 80's and early 90's that there
> was a virus going around that could alter the scan rate of a video
> adapter so that it would blow out the monitor. Never saw any such
> damage to a monitor in person, so I don't know if it was just a myth or
> actually existed.
Its not an urban legend. The issue was that there was a sync register
(horizontal sync, I think) for which you could poke in a zero value.
Wasn't the issue with a MONO monitor rather than CGA? ISTR that the horizontal
frequency would get altered overheating the flyback with the resultant loss of
the magic smoke.
Hi Tony and all
>Why do you suspect that the CRT has failed? Have yoy actually tested it
>(e.g is the heater open-circuit?)
K, here's the story. The machine is about a thousand km from here. It was
sent to the Motorola agents (1600 km from here :) where the technician
diagnosed a faulty CRT. He also swapped his test CRT in, proving that the
problem is with the CRT, but he's not prepared to part with the CRT he has.
> >
> > I don't even know if it's vector or raster, I'd suspect vector?
>
>There is no such thing as a 'vactor CRT'. Any CRT can be used in either
>mod. Although it's common for raster displayes to use
>magnetically-deflected CRTs and vector displays to use
>electrostatically-deflected CRTs
That's pretty much what I meant, yes. A vector display would imply an
oscilloscope type CRT while a raster display would imply deflection coils
and the like. And yes, there are exceptions I'm sure :-)
>Is it more like TV CRT ot a 'socpe one?
That's what I meant :)
OK, so I have
>CRT is marked with the following numbers :
>
>P/N95-P09122T001
>P/N96/80396A98
>AEG396512
>D/14/390GH it could also be D/14/390GHB
>
>(None of these pop up on google).
>
>The size of the CRT is as follows;
>L: 360mm
>W: 100mm
>H: 125mm
A length of 360 yells "oscilloscope" to me... no?
I'm trying to get a picture of this animal, but since they can't fix it,
maybe I should suggest they ship it to my side of the world, then I can
count the pins on the base etc.
I'm thinking that if it's a 'scope tube almost anything will work?
Thanks
W
I'm unsure how many readers are local to
Elizabeth (central) NJ but I'm being forced to
"downsize" my holdings
so I'm offering things for free if picked up:
- hundreds of new and slightly used floppy disks, both 3.5" and 5.25"
- floppy drives: 3.5" and 5.25"
- salvaged PC power supplies: about 9 PC-AT and 2: PC-ATX
- EISA motherboards and cards (SCSI, network)
- token ring cards, hub
- crates of CD plastic "jewel cases"
If you /absolutely positively/ require something
and cannot pick it up, we'll see about shipping.
-- Jeff Jonas jeffj-at-panix-dot-com
"Jerome H. Fine" <jhfinedp3k at compsys.to> skrev:
>> Johnny Billquist wrote:
>
>>>>> Jerome Fine replies:
>>>>> Obviously, a SYSTEM request avoids all of the problems at a
>>>>> heavy cost in overhead estimated at between 50 and 500 times
>>>>> the above two examples.
>>>>>
>>>>> That was sort of what I was thinking about when I asked if
>>>>> there was an "fast method (only a few instructions)" to
>>>>> access an IOPAGE register.
>>>
>>> Well, in RSX, you have a rather high overhead to set up the
>>> mappping to the I/O page, unless it's already mapped in when the
>>> task starts. But from there on, there is no overhead at all. It's
>>> located somewhere in your 16-bit address space. (Note that you
>>> really don't have to map the I/O page at APR7 in RSX. You can get
>>> it mapped anywhere if you use the CRAW$/MAP$ or TKB options.)
>>>
>
> That is helpful information. There might be times when APR7 should
> not be used.
Might be, but I can't figure out when. But I guess if you wanted to map
something else into memory as well (such as a shared library), which
wasn't position independent, and which expected to be at APR7...
I just mentioned it since it's technically no difference between any of
the APRs for a user program.
Anyway, the overhead of mapping in the I/O page is a one time cost.
>> However, with normal privileged programs, the I/O page is always
>> present at APR7 even if you don't do anything.
> Also VERY helpful. However, if so, then would there be any reason
> why APR7 could not be mapped to user memory in the normal manner so
> that the user program has a full 65536 bytes of address space, but
> then the PREVIOUS DATA space is mapped to KERNEL providing the user
> with complete access to the IOPAGE registers via that 2 instruction
> example that I gave at the beginning? I can't see that there would
> be any greater loss of security since being able to change the IOPAGE
> registers either directly or indirectly is just as damaging!
>
> Please comment?
You can have a privileged program that isn't mapped to the I/O page. The
problem is that the kernel sets the PSW at various times for you, so you
cannot expect to be able to keep control of the previous mode field of
the PSW from your program. RSX is multitasking. Things can change
between one instruction and the next in your task. One typical mistake
people might do is to manipulate the APR registers themself, just
because they are accessible, and the program is privileged. This won't
work, since a contect switch can occur at any time, and the APR
registers are not preserved between context switches. Instead, they are
recreated from scratch, based on your mapping context every time the
task is selected to run.
So in that case, it fails not because of security considerations, but
because of system design. You need to have the I/O page mapped in properly.
Put another way: RSX makes sure the previous mode field is set to user
at every occasion the system have executed in kernel mode and goes back
to user mode. That is a security design. To make this different for
privileged programs would incur extra costs everywhere, whithout any
real gain. Privileged programs can get around this "problem" anyway, but
not by running in user mode and expecting the previous mode field to be
set to kernel.
>>>>>>>>> RSX had a bit more flexibility (opportunity) in this
>>>>>>>>> regard. I believe you can set up a CRAW$ (create
>>>>>>>>> address window) directive in either Macro or Fortran
>>>>>>>>> to achieve the desired result.
>>>>>>>
>>>>>>> Yes with reservation. CRAW$ (create address window) is as
>>>>>>> a part of doing dynamic remapping of your address space.
>>>>>>> However, CRAW$ always required a named memory partition.
>>>>>>> You cannot create an address window to an arbitrary
>>>>>>> memory address. Also, the memory partitions have
>>>>>>> protections and ownership associated with them.
>>>>>>>
>>>>>>> On most systems, CRAW$ cannot get you access to the I/O
>>>>>>> page, simply because normally you don't have an address
>>>>>>> space and a partition associated with the I/O page.
>>>>>>>
>>>>>>> But if such a partition is created, then CRAW$, in
>>>>>>> combination with MAP$ would allow you to access the I/O
>>>>>>> page.
>>>>>>>
>>>>>>> The same thing can also be achieved even without
>>>>>>> CRAW$/MAP$, since you can specify mapping that your task
>>>>>>> should have already at task build time, with the COMMON
>>>>>>> and RESCOM options to TKB.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>> This seems to be the answer if it is allowed. Obviously it
>>>>> does require giving up that 8192 bytes the have APR7 mapped
>>>>> to user space.
>>>
>>> Correct.
>
> But unnecessary if privileged jobs already have access to the IOPAGE.
>
>
> Please comment?
True, but that already implies that one APR is used.
>>>>> There is also another option with E11 that I will make use of
>>>>> when I have finished with the HD(X).SYS device driver for
>>>>> RT-11. It turns out that if the memory is being accessed
>>>>> sequentially, the average time to reference a single 16 bit
>>>>> value in the file under: MOUNT HD: FOOBAR.DSK is actually
>>>>> less than the time to get/store a single value under EMEM.DLL
>>>>> when as few as 8 blocks (2048 words at a time) are being
>>>>> referenced. Consequently, setting up a small 4096 byte buffer
>>>>> and the associated code to handle to calls to the HD: device
>>>>> driver (all standard calls to .ReadF and .WritF in RT-11) is
>>>>> actually more efficient since after the values are in the
>>>>> buffer inside the program, the values can be referenced and
>>>>> modified at "emulated PDP-11" memory speeds.
>>>
>>> You mean that using a device driver, and a device that can access
>>> the "normal" memory instead is better. Well, I'm not surprised.
>>> What this essentially turns into, is that you're emulating DMA.
>
> Actually, under E11, it is almost identical in principle to the VM:
> device driver which accesses "emulated normal PDP-11 extended
> memory". The E11 command: MOUNT HD: RAM:/SIZE:number-of-blocks
> makes HD: into a Virtual Memory device which directly uses PC memory.
"Ram disk" is probably the word I'd use.
> However, the average transfer rate per word for even a few blocks
> (or a few thousand words) from/into emulated user memory is a small
> fraction of > a normal memory access time.
True.
> In addition, if an operating system caches the blocks in a file, the
> same speed is achieved.
Not really. By using a ram disk, you don't need to run through the
various layers of the operating system to deal with the system call and
the device handling, even if that ends up just accessing a disk cache.
>>>>> Of course, the above solution for sequential references does
>>>>> not work when the references are random or when references
>>>>> are at regular but very large intervals (thousands and even
>>>>> millions of successive values). For this latter situation,
>>>>> it may be possible to modify EMEM.DLL so that a single
>>>>> reference to the IOPAGE register modifies all of the
>>>>> specified values (over a range of up to many billions of
>>>>> values).
>>>
>>> Can't comment much, since I don't know exactly what you're trying
>>> to do. But speedwise, if you really want something to act like
>>> fast disk, writing something that behaves like proper DMA is the
>>> best. You give the device a memory address, a length, and a
>>> destination address on the device, and let it process the data as
>>> fast as it can, without involving the PDP-11 after that point.
>
> It is just a bit more complicated since the memory address can be
> anywhere in the 4 MB of emulated PDP-11 memory. So 22 bit address is
> required > - which can be determined during initialization. The even
> better aspect is that the code (only about a dozen instructions which
> set up the 6 IOPAGE registers) can be in user space which avoids the
> overhead of a system call.
Why limit yourself to 4 MB?
If you have a device that gives you the storage, you can basically let
if be of any size you want to.
Johnny
Broadcast PAL as defined by the IBA (Independent Broadcasing Authority)
'Specification of Television Standards for 625-line System I
Transmissions'
(September 1972)
The IBA were the governing body for TV in the UK at the time.
-----Original Message-----
From: cctech-bounces at classiccmp.org
[mailto:cctech-bounces at classiccmp.org] On Behalf Of Jim Leonard
Sent: 28 November 2007 18:29
To: General at icky.berkhirt.com; On-Topic and Off-Topic Posts
Subject: Re: Amiga TV Out
Rod Smallwood wrote:
> My requirement is much less demanding.
> I only need to show test cards,static pictures and the like.
> Whats most important is that the output is as close to the full PAL
> standard as possible.
> So to widen the scope the question becomes:
> 'Where can I get an old system that will do broadcast standard PAL TV
> out.'
I'm not sure that question can be answered, since I have never ever seen
a system that does "broadcast" PAL output. You have to define what you
mean by "broadcast":
- If you mean "broadcast as circa 1990 and before", then composite video
qualifies, but I have never seen a system with a composite output
without an unacceptable level of noise.
- If you mean "broadcast as circa 1991 and later", you'd need a system
with a bare minimum of Y/C ("s-video") output and I don't know of any,
unless you stick a later-model genlock onto an Amiga.
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
------------Original Messages:
Date: Tue, 27 Nov 2007 22:22:09 +0000 (GMT)
From: ard at p850ug1.demon.co.uk (Tony Duell)
Subject: Re: IBM 5271 (PC3270) host interface options
<snip>
> What was special about slot 8?
In a true-blue IBM PC/XT (5160) or PortablePC (5155), and AFAIK very few, if
any clones, the data bus on slot 8 is wired to the opposite side of a bus
buffer to the data bus to the other 7 sltos. For that reason, the card in
slot 8 has to assert (pull low) one pin on the conenctor on read cycles
to that board (I forget the exact pin, I can look it up if you need it).
The IBM Async card (RS232 card) was one card that could do this (jumper
selected). I have heard that one reason such a card was included with
every PC/XT was that it was bout the only thing that could go in slot 8,
and by putting it there at the factory it avoided too many calls from
customers 'Why doesn't the XYZ card work properly in my new XT?'
<snip>
-tony
------------Reply:
Wasn't it used (and intended) for the expansion chassis card?
m
Esteemed listmembers;
I am restoring a ca. 1985 IBM 5271---the so-called 3270 PC. I
received it intact, with a full complement of cards, cables, etc. It
looks very much like it was shut down, removed from its original
office installation, and then apparently left somewhere the squirrels
could get to it (thus, "restoring"). I've vacuumed about forty pounds
of sunflower seed hulls out of it. Blessedly, I haven't found any
other signs of animal inhabitation.
Anyway, my irrational fear of contracting hantavirus aside, I am
wondering if somebody could tell me about what I suspect is the host
interface adapter. All card slots are occupied:
1 - Async Adapter
2 - 5271 Graphics Adapter APA option
3 - 5271 Graphics Adapter
4 - 64-256KB Memory expansion card
5 - 5160 ST412 controller
6 - 5160 floppy controller
7 - the card I need help identifying
8 - 5271 Keyboard Adapter
As there is no 3270 coax card and no open slot to have once held one,
I suspect that the 3270 host interface is the unknown card in slot 7.
I own IBM SDLC and Bisync adapter cards, and this one doesn't look
like either.
Physical characteristics:
* 8-bit, short card.
* One DB25F on the bulkhead.
* 9x Oki M37S64-20; apparently 64Kx1 memories.
* 34 pin .100" header, vertically, at back end of card (J2)
* one 4-pos DIP switch at top right.
* Pretty much everything else on the card is 74LS-series TTL or passive.
It's built like IBM made it, but I can't find any obvious IBM-style
part number on it, unless it's 2683541. Google is silent on this
number. (update: I just noticed 6320999 in the etch, but that hasn't
gotten me any closer to an answer).
Anybody have any guesses? What other host attachment options were
available for the 5271, besides 3270 coax?
Thanks!
ok
bear