Anyone have one or two tapes they'd be willing to part with, or let me
borrow briefly? I've got two of these machines and no tapes to go
with, so I don't have a way to test the drives.
Contact me off-list if you can help out or suggest a source.
Thanks.
- Mike
Semi-OT: I have 13 arcade games in my basement, most non-working when I got them. The video monitors in some of them are mounted "sideways" (long axis of the tube is vertical). These old units (early 1980's) all have the HV generated from the horizontal deflection, naturally. So a thin white line running vertically is actually a loss of *vertical* deflection.
Just to further confuse things :)
-Charles
> For the 7970 tape drive there ARE the full schematics on bitsavers...
the 7970 series was built by HP, the 7879 is was OEM-ed from STC .
I may have an STC manual somewhere, though it will take some digging.
They weren't particularly reliable even when they were new.
fwiw
By the mid 80s, almost none of HP's 'service' manuals had schematics.
> Seems to me back then there was at least one vendor of a
> vector-scanned (as opposed to rasterized) game. Or at least
> the product announcement was made--I don't think I ever saw
> one up close.
>
> Cheers,
> Chuck
Wells-Gardner or some such manufactured a color vector monitor for the
Atari game Tempest. It had problems with some heat and some caps. Most
Tempest games have had their monitors "Re-Cap'd."
Tony wrote:
> > I have, it's a Biomation K100-D. When I first set it up
> > Sunday afternoon,
>
> Amazingly that's what I have... I didn't get the pods with
> mine, but a bit of work and some 10124 TTL-ECL translators
> got the thing useable with TTL level signals
>
> [...]
>
> Be careful!. I have in the back of my mind the idea that the
> 8008 has an internal (8-ish level) return stack and doesn't
> use RAM for this. So you could still have RAM problems.
>
> -tony
Making your own pod...! Again, points earned Tony! Chapeau! :-)
Jim already told me that the 8008 uses an internal stack, but
I am now not so sure that the RAM is OK, so I will connect the
other 8 LA probes to the databus, to see what is taken out of
the RAM to put on the displays.
Yesterday evening was short. Much to do ... but I managed to
look at the matrix signals. It sort-of looks OK, but I admit
that I must make some better measurements to be 100% sure that
it is not there where my problem lies. The outputs of the 8881's
(on page 4, KY11-LB console board) look as described before, and
that is also what I see on the inputs of the 8093 (page KY-3).
But taking samples on the outputs is more work, as that is the
databus (input). So I see a lot of pulses are on those lines, and
it needs more setup work to find out if a stuck bit is messing
things up.
It is not likely a problem of a stuck bit on the address or data
bus, because that would corrupt the program execution of the
ROM code. I still have the feeling that there is no problem with
the RAM, ROM, CPU, 3-state transceiver, and the decoding logic.
This evening I hope to check out (thoroughly) the keypad circuits.
thanks for the input!
- Henk.
This message and attachment(s) are intended solely for the use of the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law.
If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited.
If you have received this communication in error, please notify the sender immediately by telephone and with a "reply" message.
Thank you for your cooperation.
> I'm still nearsighted, but since then, I've also learned double bass and am
> setting my sights on learning viola this year. Just another noise to
> torment the dogs...
Wow, double bass, I'd like to play that one! :)
>
> Are musically-minded people still as commonplace in the computer business
> as they once were?
>
Well yeah, playing bass guitar and piano, composing classical music. Last piece was for orchestra,
the current one I'm writing is for piano and cello.
Didn't somebody say on the list that he plays the cello?
Anyhow, lots of people how are envolved in science/engineering share music as a passion as well.
Regards,
Pierre
__________________________________________________________________________
Erweitern Sie FreeMail zu einem noch leistungsst?rkeren E-Mail-Postfach!
Mehr Infos unter http://freemail.web.de/home/landingpad/?mc=021131
> > Someone should create brief lisings under IBM and Univac catagories
> > stainge that their drives are actually Fujitsu drives and redirecting the
> > reader to the Fujitsu folder.
> And perhaps also the Memorex relabel.
>
Yes, that a nice idea.
> Pierre: Merci and danke! :)
I only contributed the BT3200 documents, not the actual Fujitsu manuals, which certainly are of big help!
Though the full schematics are still missing... will be scanned during next year when I'm getting back to Germany so that the complete set will be online. Tore, you'll have to wait a little bit in case you want to repair your broken drives if it's an electronic problem...
Al, thanks once more for your amazing efforts on maintaining bitsavers!
Regards,
Pierre
__________________________________________________________________________
Erweitern Sie FreeMail zu einem noch leistungsst?rkeren E-Mail-Postfach!
Mehr Infos unter http://freemail.web.de/home/landingpad/?mc=021131
>From: "Chuck Guzis" <cclist at sydex.com>
>
>On 11/8/2005 at 7:36 AM Allison wrote:
>
>>NEC and DEC but never Datapoint.
>
>Darn--I've wondered about a design link between Datapoint and Beehive
>terminals. The Beehive design resembled the Datapoint more than
>trivially--it used no static ram, but rather dynamic shift registers as
>screen and working memory for the 8008. Since that was a pretty formidable
>design for its time, I wondered if Beehive had recruited Datapoint talent
>to do it, since DP would have had the best knowledge of the wiorkings of
>the 8008.
>
>Cheers,
>Chuck
>
Hi
All I know is the Datapoint keyboards were not
easy to use while the Beehive's used the Hall effect
keys from Microswitch.
Dwight
>From: "Allison" <ajp166 at bellatlantic.net>
>
>>
>>Subject: Re: help - 11/34 console problem -- first LA output
>> From: "Chuck Guzis" <cclist at sydex.com>
>> Date: Mon, 07 Nov 2005 20:18:21 -0800
>> To: cctalk at classiccmp.org
>>
>>On 11/7/2005 at 9:31 PM Allison wrote:
>>
>>>Well save for wrap around. The stack on 8008 is strictly address and
>>>as already said 14bits (the 8008 only addresses 16k!!) and 8 levels deep.
>>>It was a challenge programming it to figure out where you came from and
>>>also not blow the stack. Still it beat the design we had before it as
>>>that was around 220 pcs of TTL sequential logic.
>
>Well my 8008 experience predates DEC and the TTL horror was pre 8008!
>
>I'll say it this way. The 8008 was a ground breaking micro. From a
>programmers perspective it wasn't too bad but from a hardware designers
>and debug perspective it was nasty. It was enough to be a micro but as
>feature free as one can get. However for the time it was pushing the
>limit for integration at around 5000 transistors in Pmos.
>
>The number of chips with limited internal stacks would amaze you. The
>8048/9 series is a fairly well known one, TMS1000 4 bitters, NEC uCOM4
>4 bitters, NEC uCOM75 series, National COPs and even the PIC all come
>to mind. And in every one them if you exceed the stack something falls
>off the bottom. Stack red zone hardware is truly a big machine thing.
Hi
I thought I might add that many current day DSP chips also
have internal stacks. Of course the Forth chip, the NC4000
used external stacks but had 3 busses to handle them so that
one could have all being active at one time. Two were stacks
and one was for instruction/data.
The 2100 family DSP by ADI has a limited internal stack as well
but it seems like I remember it would generate an interrupt if
it overflowed.
Most tools for these have a method of indicating if the code
your running has a combination of main flow and interrupts
that would cause an overflow. Although, it doesn't seen so,
the worst case is predictable.
Dwight
>
>>I always wondered why a carry or borrow from the stack pointer couldn't
>>have at least generated a branch to some known location. It may not have
>>exactly told you where your code went bonkers, but it'd be better than
>>letting the program run wild! How many micros used a local stack? The
>>Natoinal PACE is the only other one that comes to mind, but at least it had
>>a "stack about to overflow" interrupt and a way to access the stack
>>directly.
>>
>>Were you a Datapoint employee?
>
>NEC and DEC but never Datapoint.
>
>
>Allison
>
>
>
>Subject: Re: help - 11/34 console problem -- first LA output
> From: "Chuck Guzis" <cclist at sydex.com>
> Date: Tue, 08 Nov 2005 07:20:06 -0800
> To: cctalk at classiccmp.org
>
>On 11/8/2005 at 7:36 AM Allison wrote:
>
>>NEC and DEC but never Datapoint.
>
>Darn--I've wondered about a design link between Datapoint and Beehive
>terminals. The Beehive design resembled the Datapoint more than
>trivially--it used no static ram, but rather dynamic shift registers as
>screen and working memory for the 8008. Since that was a pretty formidable
>design for its time, I wondered if Beehive had recruited Datapoint talent
>to do it, since DP would have had the best knowledge of the wiorkings of
>the 8008.
>
>Cheers,
>Chuck
That was technology of the era. hasiltine H1000 and H2000 terminals
and I think the VT05(hard memory test) did as well. Static rams were
expensive and small and since screen ram was by nature circular as
part of the raster scan it makes sense to keep the whole mess as
shift registers.
Never worked much with terminals printing systems were more my thing.
Allison
