At 12:28 PM 4/12/98 +0000, you wrote:
>> I promise that we CAN. I didn't say anything about willing to. However,
>> should I come across one, you'll be the first to know.
>> Tim D. Hotze
>> >Is this a promise?
>> >
>> > I'm sure that we could find a TRS-80 model 1 CASE
>> >> somewhere for you.
But if you did, would you want to risk your own reputation by sending it to
him? Goodness knows, it might not have the right serial number or
something, and then you'd be branded a con man for life! 8^)
--------------------------------------------------------------------- O-
Uncle Roger "There is pleasure pure in being mad
roger(a)sinasohn.com that none but madmen know."
Roger Louis Sinasohn & Associates
San Francisco, California http://www.sinasohn.com/
J. Maynard Gelinas wrote:
> OK, This is mildly on topic. My monitor is an HP 1097C, making
> it at least 10 years old. However, I am using it with a modern PC, so
> that's where the 'on topic' issue gets a little iffy. I'm sure there
> are plenty of people here who can answer this question. A pointer to
> a FAQ would be most welcome.
Here's one interesting URL:
http://rugmd0.chem.rug.nl/~everdij/hitachi.html
I've seen others as well but that was the one I made a bookmark to. :-)
> These old monitors are Fixed frequency, unlike our modern
> monitors which multisync. The 1097C supports only a 78.125 khz
> Horizontal Scan Rate and a 72hz Vertical Refresh Rate. Now a couple
> of years ago I foolishly bought one of those cards by Mirage
> (www.mirage-mmc.com) which is supposed to be a 'fixed freq video
> card'. Actually, it's an OEM Diamond card, basically an S3/968 video
> processor with an IBM 52x RAMDAC - ala Diamond Stealth VRAM. The
> fixed Freq hacks are basically a resistor (and a jumper selection) to
> drive sync over green, and a homebrew PROM to skew the VESA
> frequencies for several video and text modes.
Hmmm, interesting. Photon also makes fixed-freq. boards, and I was tempted to
get one for an old SuperMac monitor I have. I also once attempted to fix a
batch of Moniterm monitors that had various problems, and the one board I
found to use with them in Windows was a Vermont Microsystems model that cost
way too much to begin with, and is now no longer made. There was also no
driver later than Windows 3.1, so my dad has it now since he still has a slow
486. Anyhow, I thought Photon's boards were probably better than Mirage's, I
forget why. They are at www.photonweb.com I think, but I can't seem to get
there at the moment.
> It works, but Mirage hasn't been too helpful with getting a
> variety of XFree86 modelines, even though they claim to support Linux
Darn, shame on them.
> and XFree86. They give out _one_ modeline for 1280 x 1024, which they
Well at least it works eh? Can you at least upgrade the VRAM to get more
colors, or did you want low-res for some other reason?
> swiped from the XFree86 distribution in 'Monitors.txt'. For Windows
> and Dos, they give out a video driver which seems to work just fine.
> It will even display 320x200 full screen (Quake works great in DOS!),
> and boots to a functional 80x24 col text mode. How the hell do they
> do this?
>
> Here is how I'm calculating my video modes based in the
> XFree86VideoModes HOWTO (found in every Redhat 5 distribution):
You understood what they said, that your horizontal line includes enough
"dots" to allow time for the gun to sweep back to the beginning of the next
line? So to get 1280 dots across, you might need to allow 1350-1400ish
dot-clock-periods per line (or maybe even more).
(dots/sec) / (dots/line) = lines/sec = lines/frame * frames/sec
For example:
if you want 1024 lines, allow around 1150 total lines (to allow time to sweep
back to top-left between frames); so
1150 lines/frame * 72 frames/sec = (x dots/sec) / (1350 dots/line)
now solve for x to get the dot clock, and to double check the formula, make
sure that all the units cancel out.
x dots/sec = 1150 lines/frame * 72 frames/sec * 1350 dots/line
yep, line / line * frame / frame * dots / sec = dots / sec
and you need a dot clock of 111,780,000 dots/sec
>
> Dot Clock Per Second
> Total Horizontal Pixels Per Line = --------------------------
> Horizontal Scanning Rate
This is right, dots / line * line / sec = dots/sec
>
> Since my refresh rate must be at 72hz to sync with the HP1097C:
>
> Dot Clock
> Refresh Rate = -------------------------------------------------
> Horizontal Frame Length * Vertical Frame Length
frames / sec = (dots / sec) / (dots / line * lines / frame)
= (dots / sec) / (dots / frame)
= frames / sec
yep
>
> So, it's really more constructive to think of this as how many
> pixels _total_ do I need to display in order to get a 72 hz vertical
> scan rate with any arbitrary dot clock? In this case I need
>
> Dot Clock
> Total Pixels Per Frame (HFLxVFL) = -------------
> Refresh Rate
You did algebra on above, correct
>
> Since I know my Horizontal Pixels Per Line, I can use this to
> determine the number of vertical lines which will support a 72 hz
> refresh rate.... hmmm, this is where things get sticky. We'll start
> with a DCL of 10Mhz...
Why? That is too slow a dot clock to be useful. You should work backwards -
figure out what resolution you want, find the corresponding dot clock, pick
the closest supported dot clock to the one you calculated, and then calculate
forward again to figure out what resolution you can actually get. You can
also play with the blanking intervals, because the monitor has a minimum time
that it takes for the gun to scan back to the beginning of the next line (or
next frame), but no maximum time. If your supported dot clock is a little too
slow, you can waste the time in the blanking interval to keep a standard
resolution, or else optimize the resolution to use up all the available
time/line. But with a fixed frequency monitor, you must also keep the
horizontal and vertical scan rates in "range" - however wide that happens to
be. So really, with those two constraints plus your quantized available dot
clocks, that's why "fixed frequency" also means "fixed resolution". If the
monitor was designed for 1280 x 1024, the card must output about that many
dots in each frame and at the correct frame rate. You could output half the
dots per line, and also halve the dot clock, and halve all the other values
(front porch, back porch, vertical blanking interval, etc.) but if you tried
to also cut the vertical resolution in half, you'd violate the line rate
constraint. So as you say below, line doubling makes a lot of sense; you
could simulate 640 x 480 on a 1280 x 960 screen by halving the dot clock and
line-doubling each line. Text mode can be simulated by custom programming on
the graphics chip, so that it actually produces dot data at 640 x 480.
Keep in mind the monitor will have "total bandwidth" limitations too - it
might not be able to accept too fast a dot clock even if you don't exceed the
horizontal scan rate or frame rate.
<second message>
> BTW: no one responded to this message, so I guess no one
I'm sorry, I must have missed it. Normally that subject would catch my eye.
:-)
> knew the answer. I received a responce to a USENET post about
> this and thought there might be some interest in the group.
> The VGA spec supports 'doublescan' mode for low resolution
> compatability with CGA apps. This essentially forces the card
Cool, makes sense, I didn't know that was a standard.
I used to have a DOS CGA simulator for the Hercules card, several years ago,
that
must have worked this way also; simulating 640 x 200 on a 720 x 400-something
display. The displayable area was smaller too, so evidently they only used
640 of the available 720 dots across. It was very useful for playing old CGA
games on my mono card anyhow.
> to draw each horizontal line twice, thus doubling the refresh
> rate (or your vertical resolution in half at the same refresh
> rate) at any arbitrary horizontal scan rate. Well, some
> chipsets (like the 968, Matrox Millenium, and most ATI
> chipsets), allow for tripplescanning which does exactly what
> one would expect... it scans each horizontal line three times
> before skipping down to the next line, thus allowing one to
> drop down to a third of the vertical resolution at the same
> refresh rate (same horizontal rate always, of course).
Hmmm, so 1024 / 3 = 341, 960 / 3 = 320, I don't see how that would be very
useful since there aren't many (any?) modes that have vertical res. in the
320-340ish range. Maybe it could be stretched a little to get 640 x 400.
Quad-scan would be useful for doing 320 x 200, or they could just be wasteful
with memory and do 4 pixels in VRAM for every pixel and get 640 x 400 out of
it.
800 x 600 would just be plain nasty. :-)
>
> OK. XFree86 and SVGAlib don't support tripplescan mode, but
> they do support doublescan mode because it's part of the VGA
> spec. Tripplescan is vendor specific, and so thus is enabled
> in different ways for each chipset. I'm attempting to hack
> svgalib to support tripplescan for the S3/968... waiting for
XFree you mean, or svgalib?
> the 968 docs to arrive so I can find the register and register
> values to set for my adapter. The rest seems fairly easy, just
> hack in parsing for 'tripplescan' on the modeline and such.
>
> Why does this matter to you? Well, if you have an Hitachi
> HM-4119, HP1097C, or somesuch fixed freq monitor, getting it to
> work under Linux is pretty easy once you know the trick. Why
> buy a $1500 monitor when you've got a perfectly fine one
> sitting on your VaxStation 3100? Well, for the purposes of
> this list, why not just use the 3100 as the xterm... but that
> defeats the purpose of this message. ;-)
Yep, I've been wanting to do this for years. I did it briefly with that
Vermont card (and kept the hercules card also, for text mode, because the
Vermont card made no attempt to support any standard modes at all; it was
really intended to be a secondary display for CAD) but couldn't do any newer
Windows or X with it. It also had an interesting high-level proprietary
command language for drawing the primitives; I got the impression from its
sketchy docs that you could actually send textual commands to its I/O port and
it would interpret them in real-time. That and being an ISA card made it
kindof slow. And it only had enough VRAM to do 16 colors, and Vermont wanted
an arm and a leg to upgrade to 256 colors.
My SuperMac monitor worked fine with my ATI All-in-Wonder, but only in Windows
95, for which there is a nice driver that lets you tweak every parameter.
Tweaking similarly might be possible, if harder, in X, but I haven't tried it
yet. Unfortunately the Win95 ATI driver won't tell me the numbers to plug
into X modelines; I wish it would, but there are just these arrow buttons on
the screen to adjust position, size, etc. My experience has been, if you are
in the ballpark and the monitor is behaving itself, you can tweak it a little
bit to adjust size and position; but then all of a sudden it will just go
bonkers, and to get back to where you were right before that, you have to
overshoot and then edge your way back (not moving the mouse, because
you can't see the on-screen button anymore!) So reproducing the same results
with xvidtune's tricky interface would be difficult.
Someday, maybe somebody will produce a video card with a video-scaling chip
built-in, so that you can multiply dots by something other than a whole
number. This is the sort of thing that's already being done for LCD video
projectors, video digitizers that can put the image into an arbitrarily-sized
window (like my All-in-Wonder), the digital HDTVs now being designed, and
maybe even some of the better laptop displays. I don't see why if they can do
it for TV input they can't do it on the output signal as well. As the dot
clock asks for each output dot, the chip would just have to take into account
the colors of the adjacent dots, and blend smoothly; so to avoid having to
read VRAM at, say, 9x dot clock, it would have to have some fast registers to
store the values of the adjacent dots temporarily, and it could then read VRAM
at a mere 3x dot clock. Or, it could store 3 lines in its fast memory and
read the line past the next one during each horizontal blanking interval.
Maybe the need for fast VRAM is the limiting factor; no, because actually
scanning at 1280 x 960 requires 4x the speed of scanning at 640 x 480, whereas
simulating 640 x 480 at a dot clock to achieve 1280 x 960 only requires
reading VRAM at 3x the rate. So I don't know why this hasn't been done.
Maybe Photon does this, I'm not sure.
I think I'm going to post this on a newsgroup or two and see if we get any
better answers.
--
_______ KB7PWD @ KC7Y.AZ.US.NOAM ecloud(a)bigfoot.com
(_ | |_) Shawn T. Rutledge http://www.goodnet.com/~ecloud
__) | | \_____________________________________________________________
<today at goodwill I found a Advance Micro Device AM2900 Evaluation &
<Learning Kit in the it's box (very nice design on it) with one worksheet
<the unit was only $5.
I must be looking in all the wrong places. That's only my list for SBCs,
next time.
Allison
I have had too many 3.5" disks go bad, some my own, some not, not
to ask why. I mean, is it just a property of 3.5" disks to be
unreliable, or is something else? Are there any "industrial quality"
drives/disks that are reasonably reliable?
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
On Apr 13, 23:19, Tony Duell wrote:
> Seriously, I think you can justtify owning several of the same machine if
> the machines have expansion slots (like the Apple ][ or the PDP11) and
> you've got a lot of cards you want to play with. I'm pretty sure I've got
> far too many unibus cards (even with DB11 bus repeaters) for a single
> machine. And I wonder how useful 2 DX11's (I do mean DX11, not RX11) are
> on the same machine.
Isn't a DX11 an IBM channel interface? Originally a big cabinet with a lot of
flip chips and lamps? I've seen two, working.
--
Pete Peter Turnbull
Dept. of Computer Science
University of York
> Wasn't there a Dennis Kitz speedup mod published in an old
> 80 Micro article? He wrote a _bunch_ of articles containing
> useful mods to the model 1... really an amazing guy. I wonder
> what happened to him.
Dennis is alive and well and may be contacted at bathory(a)maltedmedia.com.
Hello everyone,
Just a quick "Rescue Needed" announcement.
There is a VAX 11/750 available at WeirdStuff Warehouse in Sunnyvale,
CA. Most of you Bay Area classic computer enthusiasts probably know
where this place is. If not, visit http://www.weirdstuff.com/.
The 11/750 doesn't have any paripherals, nor any disk, but it does
appear to be fully populated with cards. Be the first one on your
block to own a classic, proper VAX!
Anyway, it's up for auction there. If I had infinite space and lots
of time, I'd go get it myself, but I don't :)
-Seth
Even if I had the room and time to pick up every machine that was
headed for the dump, what can I do with several dozen PC clones?
Same goes for other systems. It's interesting to have maybe a
couple, but not the "8 PDP 11/34, 22 Atari ST, 15 Apple ][" I hear.
>Well, not all of us have the time to work on every single system we get
>our hands on. There are only so many hours in the day left over after
>life stuff (ie. job, pets, family...) and this is just a side hobby for
>me. My concern first is to at least get the computers to prevent them
>from being disposed of and worry about getting them running later.
>
>> I collect for many reasons, amongst them :
>> 1) The fun and mental challenge of restoring/repairing them. Fault
>> finding can be interesting, you know
>
>I do it for the joy of being surrounded by such an ecclectic and
expansive
>collection of computers that span the innovation of two decades. When
I
>make enough money to relax for a couple months, I'll have fun restoring
>and repairing them.
>
>> 2) Finding out what the machines I grew up dreaming of were really
like.
>> And the machines that came before them. I could never afford them
when
>> new, now I can play with them
>
>Same here.
>
>> 4) Tracing the history of certain features. To take a trivial
example,
>> IOBYTE at location 3 on CP/M can be traced back to the Intellec
MCS8i. It
>> was at location 3 on that machine (with the same format of 4 2-bit
>> fields) as locations 0-2 were reserved for the reset jump
instruction, so
>> this was the first free RAM location.
>
>This is not only fun, but in my view, relevant. These are the sorts of
>tidbits that, in my nerdy opion, would make a fascinating book: where
all
>the standards came from.
>
>> I won't claim I run all my 150+ machines all the time. I have a few
that
>> I run quite often (the PDP11/45, the PDP8/e, the PERQ 2, a TRS-80 M4,
>> this PC/AT, etc). Others I only run from time to time when I need
them.
>> But I do try to have all my machines operational if at all possible.
>
>That's commendable, but there's not a lot of need on my end to have
>everything running. There's a desire, but not a need. When my
collection
>goes on display, it will be desirable to have at least one of
everything
>in the collection working with usable software so that people studying
the
>artifact can get a better understanding of it.
>
>Sam Alternate e-mail:
dastar(a)siconic.com
>-------------------------------------------------------------------------------
>Don't blame me...I voted for Satan.
>
> Coming in September...Vintage Computer Festival 2.0
> See http://www.siconic.com/vcf for details!
> [Last web page update: 04/08/98]
>
>
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
<backplane. It's missing box/PSU and floppy, though, so it's not terribl
<functional ATM. I'm sure someone has built something even smaller with
<Falcon or similar.
I've seen a 11/23, RQDX3, 512k ram, dlv11j(4 serial) and a mrv11 in a
custom box using a RX50 and a 3.5"MFM 40meg disk that was quite small!
The backplane was 6 dual slots. Smaller than than a PC minitower.
Qbus PDP-11 systems can be quite small if non dec boxes are used.
Allison
