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
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.'
PAL will be gone as soon as the analog systems TV systems are switched
off and digital takes over.
-----Original Message-----
From: cctech-bounces at classiccmp.org
[mailto:cctech-bounces at classiccmp.org] On Behalf Of John Foust
Sent: 27 November 2007 14:44
To: cctalk at classiccmp.org
Subject: Re: Amiga TV Out
At 11:46 PM 11/26/2007, Rod Smallwood wrote:
> I'm sure that I heard that some Commodore systems could do TV out
>and were in fact used to produce CGI stuff for 'Babylon Five"
>Does anybody know which ones and could they do PAL or just NTSC?
Special effects makers strove for higher quality as the job demanded.
Part of the appeal of the Amiga for special effects was the price of the
32-bit hardware and software. SGI hardware and software was an order of
magnitude more expensive. NewTek's Lightwave was used by the Babylon 5
special effects group. I know they also used an early 3D Studio on a PC
for some of the modeling. (And they used some of my software to convert
between 3D file formats; as I recall, the spun shape of the original
station was made that way.)
Yes, the Amiga had the horsepower to play back animations of useful
color depths in real-time. Depending on the image and the requirements,
some special effects might even look OK with the straight TV-out. For
example, the typical synthetic "computer display" in a cheesy sci-fi
show. When you're filming an actor in front of an animation playing on
a monitor, low-res is OK.
More often for serious output, as in Babylon 5's case, they laid their
bitmaps to an 8mm Exabyte tape as data files, then imported into an
Abekas framebuffer that could play them back in real time.
High quality, no generational loss every time you made an edit or copy.
Straight TV-out wasn't a high-quality method of exporting video, though.
In the early days, some people used single-frame video recorders to lay
down a sequence of animation. This worked reasonably well, within NTSC
generational limits. Later, some NewTek Video Toaster-based animators
used its higher-quality framebuffer as the output to single-frame
recordings.
- John
-------------Original Message:
Date: Tue, 27 Nov 2007 16:53:03 -0000
From: "Rod Smallwood" <RodSmallwood at mail.ediconsulting.co.uk>
Subject: RE: Amiga TV Out
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.'
PAL will be gone as soon as the analog systems TV systems are switched
off and digital takes over.
-------------Reply:
FWIW, if it doesn't have to be an Amiga I think some PC Video cards also
could output PAL as well as NTSC.
m
I've got some stuff I need to find a new home for:
MicroVAX 3300, working, spec unknown
LA36, big box of paper and ribbons
Altos 386
RL02, believed to be working but I haven't tried it.
They're in Glasgow. I'd prefer it if you collect, but can deliver at least
part of the way.
Gordon
