10 Feb
2009
10 Feb
'09
1:12 a.m.
Inherited a Tektronix 4051 this afternoon (really, really cool old
machine - 6800 CPU, vector storage-tube display) and after cleaning it
out and reseating the socketed chips it appears to work almost
correctly. (Even the tape drive works after cleaning the head... amazed
that the pinch roller hasn't turned to goo.)
The one issue is that "long" vectors do not get drawn as straight lines
-- they end up curving in the direction of the destination. I've taken
a photo to demonstrate:
http://yahozna.dyndns.org/computers/tek4051/unvector.jpg
The above is _supposed_ to be drawing a line from 0,0 to 100,100 and
back, but as you can see, it's not really doing a very good job.
Short vectors seem to draw OK, as do perfectly vertical and horizontal
ones. Text gets drawn fine. I have the schematics but I've never dealt
with a vector-based display before (only other vector display I have is
in my Vectrex, and I haven't had to tweak that one yet.) Any ideas
where to start? I figure the D/A converters on the CPU board are
working correctly since text positioning works, and the endpoints of the
vectors seem to be correct. Bitsavers has the schematics at:
http://www.bitsavers.org/pdf/tektronix/405x/070-2286-00_4051_Service_Vol2_M…,
(see page 92 for the start of the display schematics.)
And a higher-level overview of the functionality at:
http://www.bitsavers.org/pdf/tektronix/405x/070-2065-00_4051_Service_Vol1_M…
(See page 147 for the start of the display overview.)
Thanks!
Josh
10 Feb
10 Feb
2:37 a.m.
Josh Dersch wrote:
Short vectors seem to draw OK, as do perfectly
vertical and horizontal
ones. Text gets drawn fine. I have the schematics but I've never dealt
with a vector-based display before (only other vector display I have is
in my Vectrex, and I haven't had to tweak that one yet.) Any ideas
where to start? I figure the D/A converters on the CPU board are
working correctly since text positioning works, and the endpoints of the
vectors seem to be correct.
If the endpoints are correct, then the DACs are probably OK. That leaves the
deflection system, and the two filters (one X, one Y).
Take a look at 2-12 (#81 of 228) from service manual volume 2.
To rule out deflection, I'd get an oscilloscope (a Tek 454 or similar should
be more than enough), set it to X-Y (Lissajous) mode, and wire it up to the X
and Y signal outputs from the filters -- there are two test points shown on
the schematic for this (TP X and TP Y).
If the display on your scope is still non-linear, go looking for faults in the
display filters.
If the display looks good on the scope, I'd start looking for issues in the
CRT deflection circuitry.
If you're going to hook it up to a scope, I'd try and get it to produce an
alignment pattern that checks 45-degree lines drawn "both ways" so to speak.
Either something like the Atari Asteroids self-test pattern, or even just a
cross inside a square. Maybe something like this?
110 MOVE 0,0
# draw square forwds
120 DRAW 0,100
130 DRAW 100,100
140 DRAW 100,0
150 DRAW 0,0
# X forward-slash
160 DRAW 100,100
170 DRAW 0,0
# X back-slash
180 MOVE 0,100
190 DRAW 100,0
200 DRAW 0,100
# draw square backwards
210 DRAW 0,0
220 DRAW 100,0
230 DRAW 100,100
240 DRAW 0,100
# back to the start
250 GO TO 110
That's assuming the syntax of the DRAW command is "DRAW x,y", 0,0 is the
bottom-left co-ordinate, and 100,100 is the top-right...
The idea of this is that you can tell at-a-glance if the vectors are
converging properly in both directions in all axes.
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
7:38 p.m.
Philip Pemberton wrote:
Josh Dersch wrote:
Thanks for the suggestion! Made two discoveries:
1) The schematics on Bitsavers do not correspond to the revision of the
machine I have (mine appears to be earlier). I have a printed set of
them, so I'm OK (I mistakenly assumed both were the same). There are no
X/Y test points on my Tek's display board, but it was easy enough to
hook up to the X/Y connector (J55, for those playing along at home).
2) Having done so, it looks like the display filters are at fault. The
oscilloscope display is distorted in exactly the same way as it is on
the Tek's display.
Now to start debugging from here... (and maybe I should get these
schematics to Al for archiving...) would dried up capacitors be a likely
culprit?
Thanks,
Josh
Short vectors seem to draw OK, as do perfectly
vertical and
horizontal ones. Text gets drawn fine. I have the schematics but
I've never dealt with a vector-based display before (only other
vector display I have is in my Vectrex, and I haven't had to tweak
that one yet.) Any ideas where to start? I figure the D/A
converters on the CPU board are working correctly since text
positioning works, and the endpoints of the vectors seem to be correct.
If the endpoints are correct, then the DACs are probably OK. That
leaves the deflection system, and the two filters (one X, one Y).
Take a look at 2-12 (#81 of 228) from service manual volume 2.
To rule out deflection, I'd get an oscilloscope (a Tek 454 or similar
should be more than enough), set it to X-Y (Lissajous) mode, and wire
it up to the X and Y signal outputs from the filters -- there are two
test points shown on the schematic for this (TP X and TP Y).
If the display on your scope is still non-linear, go looking for
faults in the display filters.
If the display looks good on the scope, I'd start looking for issues
in the CRT deflection circuitry.
8:36 p.m.
Ha, whoops -- disregard #1 below... I was looking at the wrong section
:). Some days...
Josh
Josh Dersch wrote:
Philip Pemberton wrote:
Josh Dersch wrote:
Thanks for the suggestion! Made two
discoveries:
1) The schematics on Bitsavers do not correspond to the revision of
the machine I have (mine appears to be earlier). I have a printed set
of them, so I'm OK (I mistakenly assumed both were the same). There
are no X/Y test points on my Tek's display board, but it was easy
enough to hook up to the X/Y connector (J55, for those playing along
at home).
2) Having done so, it looks like the display filters are at fault.
The oscilloscope display is distorted in exactly the same way as it is
on the Tek's display.
Now to start debugging from here... (and maybe I should get these
schematics to Al for archiving...) would dried up capacitors be a
likely culprit?
Thanks,
Josh
Short vectors seem to draw OK, as do perfectly
vertical and
horizontal ones. Text gets drawn fine. I have the schematics but
I've never dealt with a vector-based display before (only other
vector display I have is in my Vectrex, and I haven't had to tweak
that one yet.) Any ideas where to start? I figure the D/A
converters on the CPU board are working correctly since text
positioning works, and the endpoints of the vectors seem to be correct.
If the endpoints are correct, then the DACs are probably OK. That
leaves the deflection system, and the two filters (one X, one Y).
Take a look at 2-12 (#81 of 228) from service manual volume 2.
To rule out deflection, I'd get an oscilloscope (a Tek 454 or similar
should be more than enough), set it to X-Y (Lissajous) mode, and wire
it up to the X and Y signal outputs from the filters -- there are two
test points shown on the schematic for this (TP X and TP Y).
If the display on your scope is still non-linear, go looking for
faults in the display filters.
If the display looks good on the scope, I'd start looking for issues
in the CRT deflection circuitry. 
8:49 p.m.
In article <49924848.1080601 at mail.msu.edu>,
Josh Dersch <derschjo at mail.msu.edu> writes:
Now to start debugging from here... (and maybe I
should get these
schematics to Al for archiving...) would dried up capacitors be a likely
culprit?
That's what I immediately expected as soon as you described the
problem. They seem to be the "usual suspect" for flakey vintage
electronics.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
11 Feb
11 Feb
9:27 a.m.
Josh Dersch wrote:
Thanks for the suggestion! Made two discoveries:
1) The schematics on Bitsavers do not correspond to the revision of the
machine I have (mine appears to be earlier). I have a printed set of
them, so I'm OK (I mistakenly assumed both were the same). There are no
X/Y test points on my Tek's display board, but it was easy enough to
hook up to the X/Y connector (J55, for those playing along at home).
Good call with the X/Y connector. They might have pulled them off the board
layouts and not updated the schematics... Not a very Tek thing to do, but that
sort of thing can happen.
2) Having done so, it looks like the display filters
are at fault. The
oscilloscope display is distorted in exactly the same way as it is on
the Tek's display.
Divide-and-conquer's great, isn't it? :)
Which leaves you -- as you quite rightly said -- the path between the DACs and
the deflection system, which is basically the filters.
Now to start debugging from here... (and maybe I
should get these
schematics to Al for archiving...) would dried up capacitors be a likely
culprit?
It'd be worth looking into, and the first thing I'd check.
The schematic (Vol2, p.2-12) shows no electrolytics in that path other than
two pairs of 1uf decouplers on the opamps -- C853, C854, C871, and C872. I'd
ignore those for now, unless the power supply is abnormally noisy.
That part of the circuit is basically all 'dry' capacitors, i.e. no
electrolyte. You've got two 0u01 (10nf) Paktron "plastic" capacitors per
filter, and a 470pf ceramic. I suspect those are probably good, they don't
usually fail unless overvoltaged or otherwise abused in some way.
The parts manifest suggests that R965 (one of the 39meg resistors) is a
carbon-composition type. Just about anything will make these things change
value, but the main killers are age and (again) voltage stress. They're a
known cause of failure in old kit, and generally the value will increase over
time. That screws the time-constant of the filter, lowering the cutoff frequency.
My plan-of-action would be something along these lines:
1) If you've got a DMM that goes as high as ~40 megohms, desolder one leg of
each of the 39M resistors and check them. If not, desolder the existing
resistors and replace them, but keep the old ones for now in case their
replacement causes problems.
2) Also check R894 and R961 (100R 5% carbon-comp) and their mates in the X
filter. These supply power to the opamps. If these have gone high in value,
the opamp may have trouble sourcing current into the output circuit. This will
reduce the filter's cutoff frequency as well...
3) If that didn't fix it, check the other resistors in the filters. For the Y
filter, that's R962, R963 and R964.
4) If the opamps are socketed, swap them both out. You'll want a Signetics
N5558, which Google tells me crosses to the MC1458. Which is still fairly
common after all these years :)
This wouldn't be my first choice, though. Again, unless overstressed these
don't generally fail.
5) Those plastic and ceramic capacitors are IMO the least likely to fail (but
tied with the opamp in the "chance of failure" stakes).
Let me know how you get on, this is starting to get interesting :)
Cheers,
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
9:17 p.m.
Philip Pemberton wrote:
Divide-and-conquer's great, isn't it? :)
Which leaves you -- as you quite rightly said -- the path between the
DACs and the deflection system, which is basically the filters.
My multimeter doesn't go that high (I
really need to get a good one one
of these days.) I replaced these with two 20M's in series (figured it'd
be close enough to at least see if it changes anything, and I can't find
any place that actually stocks 39M resistors that aren't SMD...) No
change in display behavior.
Now to start debugging from here... (and maybe I
should get these
schematics to Al for archiving...) would dried up capacitors be a
likely culprit?
It'd be worth looking into, and the first thing I'd check.
The schematic (Vol2, p.2-12) shows no electrolytics in that path other
than two pairs of 1uf decouplers on the opamps -- C853, C854, C871,
and C872. I'd ignore those for now, unless the power supply is
abnormally noisy.
That part of the circuit is basically all 'dry' capacitors, i.e. no
electrolyte. You've got two 0u01 (10nf) Paktron "plastic" capacitors
per filter, and a 470pf ceramic. I suspect those are probably good,
they don't usually fail unless overvoltaged or otherwise abused in
some way.
The parts manifest suggests that R965 (one of the 39meg resistors) is
a carbon-composition type. Just about anything will make these things
change value, but the main killers are age and (again) voltage stress.
They're a known cause of failure in old kit, and generally the value
will increase over time. That screws the time-constant of the filter,
lowering the cutoff frequency.
My plan-of-action would be something along these lines:
1) If you've got a DMM that goes as high as ~40 megohms, desolder one
leg of each of the 39M resistors and check them. If not, desolder the
existing resistors and replace them, but keep the old ones for now in
case their replacement causes problems.
2) Also check R894 and R961 (100R 5% carbon-comp) and their mates in
the X filter. These supply power to the opamps. If these have gone
high in value, the opamp may have trouble sourcing current into the
output circuit. This will reduce the filter's cutoff frequency as well...
Checked all these. They tested out fine.
3) If that didn't fix it, check the other resistors in the filters.
For the Y filter, that's R962, R963 and R964.
Ditto for these.
4) If the opamps are socketed, swap them both out. You'll want a
Signetics N5558, which Google tells me crosses to the MC1458. Which is
still fairly common after all these years :)
This wouldn't be my first choice, though. Again, unless overstressed
these don't generally fail.
Found some MC1458P's on Mouser, ordered...
we'll see if this makes any
difference.
5) Those plastic and ceramic capacitors are IMO the least likely to
fail (but tied with the opamp in the "chance of failure" stakes).
Also
ordered, why the heck not :).
Let me know how you get on, this is starting to get interesting :)
Thanks for the
help!
Josh
Cheers,
12 Feb
12 Feb
4:24 p.m.
Josh Dersch wrote:
My multimeter doesn't go that high (I really need
to get a good one one
of these days.)
My Fluke 25 won't go that high either -- max range on that is 32 megohms. I've
got a Solartron 7150plus bench DMM that can read down to one milliohm in the
2K-ohm range (6.5 digits with averaging enabled), but still limits at 20M-ohms
max.
I replaced these with two 20M's in series (figured
it'd
be close enough to at least see if it changes anything, and I can't find
any place that actually stocks 39M resistors that aren't SMD...) No
change in display behavior.
The spec in the parts list was 1%. 1% of 39M is 390k-ohms either way... 40M is
well out of spec.
I'd have used a 20M, a 10M, an 2.2M and a 6.8M in series which gets you 39M
exactly, and if you use 1% resistors you should be within 1% of the final
value (assuming my math is accurate, which it probably isn't). Note that all
of those are E12 values, i.e. standard resistor values.
Found some MC1458P's on Mouser, ordered...
we'll see if this makes any
difference.
Well, based on what you've done, that leaves the capacitors and the opamps (as
you've already said).
There is a note on page 5-26 of volume 1 relating to the test fixture and the
vector display -- specifically:
Don't worry if both directions of vector drawing do not close for the
deflection magnitude may be well out of the linear range of display deflection
parameters.
I've just been (re-)reading Jed Margolin's "Secret Life of Vector
Generators"
article (<http://jmargolin.com/vgens/vgens.htm>). There's a bit in this
article about capacitors in analog vector generators... and how picky the
integrators in AVGs tend to be.....
I'm starting to wonder if some normally-irrelevant parameter of those poly
caps has shifted and fragged the vector generator.
Catch is, because both channels are intended to be matched (there's a bit
about that in the theory of operation for the vector generator in Vol 1, IIRC)
you might have to replace the same parts in both channels to get everything to
match up...
Thanks for the help!
No problem.
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
7:18 p.m.
Philip Pemberton wrote:
Well, it's not the op-amps: I discovered last
night (of course, after
ordering the parts...) that the tape controller board has 3 MC1458's on
it, so I swapped a pair of them with the CPU board. No change, and the
tape drive still works fine, so I think we can rule those out.
I've ordered enough replacement caps to replace them in both the X/Y
channels so we'll see what happens once the parts arrive.
Thanks again,
Josh
Josh Dersch wrote:
Ah, whoops -- thought it was 5% like the others, but you're right.
Well, nothing blew up...
My multimeter doesn't go that high (I really
need to get a good one
one of these days.)
My Fluke 25 won't go that high either -- max range on that is 32
megohms. I've got a Solartron 7150plus bench DMM that can read down to
one milliohm in the 2K-ohm range (6.5 digits with averaging enabled),
but still limits at 20M-ohms max.
I replaced these with two 20M's in series
(figured it'd
be close enough to at least see if it changes anything, and I can't
find any place that actually stocks 39M resistors that aren't
SMD...) No change in display behavior.
The spec in the parts list was 1%. 1% of 39M is 390k-ohms either
way... 40M is well out of spec.
I'd have used a 20M, a 10M, an 2.2M and a 6.8M in series which gets
you 39M exactly, and if you use 1% resistors you should be within 1%
of the final value (assuming my math is accurate, which it probably
isn't). Note that all of those are E12 values, i.e. standard resistor
values. Found some MC1458P's on Mouser, ordered...
we'll see if this makes
any difference.
Well, based on what you've done, that leaves the capacitors and the
opamps (as you've already said).
There is a note on page 5-26 of volume 1 relating to the test fixture
and the vector display -- specifically:
Don't worry if both directions of vector drawing do not close for
the deflection magnitude may be well out of the linear range of
display deflection parameters.
I've just been (re-)reading Jed Margolin's "Secret Life of Vector
Generators" article (<http://jmargolin.com/vgens/vgens.htm>). There's
a bit in this article about capacitors in analog vector generators...
and how picky the integrators in AVGs tend to be.....
I'm starting to wonder if some normally-irrelevant parameter of those
poly caps has shifted and fragged the vector generator.
Catch is, because both channels are intended to be matched (there's a
bit about that in the theory of operation for the vector generator in
Vol 1, IIRC) you might have to replace the same parts in both channels
to get everything to match up... Thanks for the help!
No problem.
19 Feb
19 Feb
9:52 p.m.
Alright! Replaced the four .01uF capacitors in the X/Y filters and it
made a huge difference. It's still not completely perfect, but it's
very close.
http://yahozna.dyndns.org/computers/tek4051/vector.jpg
(compare to before:
http://yahozna.dyndns.org/computers/tek4051/unvector.jpg)
The small remaining imperfection may be due to me accidentally ordering
10% tolerance instead of 1% for these capacitors. But it's very
promising. Thanks, everyone, for the help!
Now if there was only some software archived for this thing :). Guess
I'll have to write something really cool to show off the cool display now...
Thanks again,
Josh
Josh Dersch wrote:
Philip Pemberton wrote:
Well, it's not the op-amps: I
discovered last night (of course, after
ordering the parts...) that the tape controller board has 3 MC1458's
on it, so I swapped a pair of them with the CPU board. No change, and
the tape drive still works fine, so I think we can rule those out.
I've ordered enough replacement caps to replace them in both the X/Y
channels so we'll see what happens once the parts arrive.
Thanks again,
Josh
Josh Dersch wrote:
Ah, whoops -- thought it was 5% like the others, but you're right.
Well, nothing blew up...
My multimeter doesn't go that high (I really
need to get a good one
one of these days.)
My Fluke 25 won't go that high either -- max range on that is 32
megohms. I've got a Solartron 7150plus bench DMM that can read down
to one milliohm in the 2K-ohm range (6.5 digits with averaging
enabled), but still limits at 20M-ohms max.
I replaced these with two 20M's in series
(figured it'd
be close enough to at least see if it changes anything, and I can't
find any place that actually stocks 39M resistors that aren't
SMD...) No change in display behavior.
The spec in the parts list was 1%. 1% of 39M is 390k-ohms either
way... 40M is well out of spec.
I'd have used a 20M, a 10M, an 2.2M and a 6.8M in series which gets
you 39M exactly, and if you use 1% resistors you should be within 1%
of the final value (assuming my math is accurate, which it probably
isn't). Note that all of those are E12 values, i.e. standard resistor
values. Found some MC1458P's on Mouser, ordered...
we'll see if this makes
any difference.
Well, based on what you've done, that leaves the capacitors and the
opamps (as you've already said).
There is a note on page 5-26 of volume 1 relating to the test fixture
and the vector display -- specifically:
Don't worry if both directions of vector drawing do not close for
the deflection magnitude may be well out of the linear range of
display deflection parameters.
I've just been (re-)reading Jed Margolin's "Secret Life of Vector
Generators" article (<http://jmargolin.com/vgens/vgens.htm>). There's
a bit in this article about capacitors in analog vector generators...
and how picky the integrators in AVGs tend to be.....
I'm starting to wonder if some normally-irrelevant parameter of those
poly caps has shifted and fragged the vector generator.
Catch is, because both channels are intended to be matched (there's a
bit about that in the theory of operation for the vector generator in
Vol 1, IIRC) you might have to replace the same parts in both
channels to get everything to match up... Thanks for the help!
No problem.
21 Feb
21 Feb
12:11 p.m.
Now if there was only some software archived for this
thing :). Guess
I'll have to write something really cool to show off the cool display
now...
Oh, but there is. A lot of it is on paper, not electronic, but I did
type in the winning Christmas card program. I've also written some
fractals, and started work on a map projections suite.
I'm not sure how best to get the stuff to you, though. Maybe the best
way is for me to record a tape and post it. (Heavy, though :-( ) I got
my 4052 talking to a Commodore 8050 disk drive, though, so if you can
get hold of one of those, we might be able to exchange stuff on disk.
(Using a 405x with an 8050 is a PAIN. You send all the commands to the
drive to find the file and be ready to load it. You then type OLD at 8 and
what does the machine do? Why, asserts IFC, of course. But there are
ways around this. I wonder if I can find my notes...)
Anyway, let me know if you're interested, and what sort of stuff you'd
like, and I'll see what I can do.
Philip.
22 Feb
22 Feb
10:11 a.m.
In article <49A05FF3.6080704 at axeside.co.uk>,
Philip Belben <philip at axeside.co.uk> writes:
I guess the best way to get data transferred from these systems is to
use the GPIB interface and transfer the programs out of the system and
into the internet. I wonder if the easiest would be to use a
Commodore GPIB compatable floppy drive or something.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Now if there
was only some software archived for this thing :). Guess
I'll have to write something really cool to show off the cool display
now...
Oh, but there is. A lot of it is on paper, not electronic, but I did
type in the winning Christmas card program. I've also written some
fractals, and started work on a map projections suite.
I'm not sure how best to get the stuff to you, though.
11:06 a.m.
Richard wrote:
I guess the best way to get data transferred from these systems is to
use the GPIB interface and transfer the programs out of the system and
into the internet. I wonder if the easiest would be to use a
Commodore GPIB compatable floppy drive or something.
Or over the optional RS-232 expansion (at a whopping 2400bps). I've
been experimenting with this idea for archiving 405x tapes (and Bob
Rosenbloom has offered to lend me a couple of tapes to play with) but
the major catch is that the 4051 appears to _only_ be programmable in
BASIC -- there's no PEEK/POKE or ways to call user 6800 machine code.
This wouldn't be a problem except that it's possible to protect tape
files with the "SECRET" command -- this makes a given file execute-only,
so it appears to be impossible to read the contents of the file using
BASIC commands. I'm guessing that most (if not all) commercial software
tapes are protected in such a manner, but I suppose I'll find out.
I'm looking into whether if it's possible to adapt one of the "backpack"
expansions to take EPROMs instead of MCM6832 ROMs. Anyone done this
before? Given a bit of hacking it'd then be possible to write some 6800
code to do a binary dump of the tapes, bypassing the protection mechanisms.
- Josh
..
Oh, but there is. A lot of it is on paper, not electronic, but I did
type in the winning Christmas card program. I've also written some
fractals, and started work on a map projections suite.
I'm not sure how best to get the stuff to you, though.
2:10 p.m.
In article <49A1A227.10605 at mail.msu.edu>,
Josh Dersch <derschjo at mail.msu.edu> writes:
Or over the optional RS-232 expansion (at a whopping
2400bps). I've
been experimenting with this idea for archiving 405x tapes (and Bob
Rosenbloom has offered to lend me a couple of tapes to play with) but
the major catch is that the 4051 appears to _only_ be programmable in
BASIC -- [...]
I thought an earlier conversation here mentioned that there was a way
of sneaking machine code into a BASIC program? IIRC, the story went
that Tek employees used this to code up some real-time games running
on the 4051. I also found this old message about transferring stuff
to an 8050:
==============
Date: Fri, 9 Nov 2007 18:52:19 +0100 (CET)
From: Christian Corti <cc at corti-net.de>
Subject: Re: Tektronix 4051
Re: <47347D83.9060001 at bitsavers.org>
Id: <Pine.LNX.4.61.0711091842080.8194 at linuxserv.home>
Refs: <47347D83.9060001 at bitsavers.org>
---------
On Fri, 9 Nov 2007, Al Kossow wrote:
> We've got a Tektronix 4051 with the optional
Data Comms Interface and tons
> of tape cartridges. As the belts in the Scotch/3M DC300 tapes are worn out
> or torn I need to copy the contents 1:1 to other media. But how?
I have a box of tapes from Jim Willing that I need to
deal with as well.
There was a GPIB version of the drive used in the 405x that I have. The
service manual goes into more detail than the service manual for the
main unit. I also have a couple of the bare drives and had intended to
hook them up to the same sort of interface that I've been using to deal
with other cassette media.
I think that I've already found the solution. I just write a small program
to copy all the files onto a CMB 8050 drive! How? Well.. the previous
owner (a former high school director) had developed some very fancy
extension ROMs for the 4051 with self-written BASIC extensions in machine
language etc (around 1983). There are instructions to read or write one
physical tape block no matter what type the file is into a string of 256
bytes. The functions are called with CALL "TREAD" and CALL "TWRITE".
And
there are functions to deal with the Commodore GPIB disk drives (like DIR,
SAVE etc.). He even designed a RAM module and corresponding functions to
load/store/call machine programs.
I will try to write a backup program maybe next week. There are lots of
interesting tapes (e.g. games), and I think the ROMs from the cartridges
should be dumped, too.
Christian
==============
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
4:10 p.m.
New subject: Executing Machine Code on the Tektronix 4051
I recall that there was a way to make the 4051 execute machine code. I
don't remember the exact method, but I remember that the bytes of 6800
machine code were encoded into a character string using the CHR$()
function. For example, hex 43 would turn into CHR$(67), or a "C". The
bytes were put into a string with the limit of program size being the
max. size of a character string. The next part is where my memory fails
me -- there was a way to cause the BASIC interpreter to branch to the
first character in the string, executing the code there. It involved
doing the transfer in such a way that it was if the code was branched to
with a "jump to subroutine" call, and when the code was complete, a
"return from subroutine" instruction would be in the code, and that
would cause a branch back to the BASIC interpreter. As I'm writing this,
a statement called EXEC$ or something along those lines pops into my
head.
I don't know if this is any help at all, but I really clearly remember
seeing 4051 programs (I worked at Tektronix from 1977 to 1990, and did a
lot of tinkering with 4051/2/4) that filled character strings with
hand-assembled machine code, and had a means to execute it. Hopefully
someone can find some docs that might substantiate these memories and
solve the mystery.
Rick Bensene
The Old Calculator Museum
http://oldcalculatormuseum.com
5:28 p.m.
New subject: Executing Machine Code on the Tektronix 4051
Looks like your memory is not too bad... the documented method for
calling ROM code (in expansion packs) is via the "CALL" command with a
string that names the function to be called. (i.e. I have the EDITOR
rom, and that's invoked by doing 'CALL "EDITOR"').
Well, I just tried this:
A$="ABCDEF"
CALL "EXEC",A$
And the machine immediately reset and gave me a system error :). So it
seems evident that this was executing the string as machine code (and
crashing horribly).
Further experimentation reveals that the string can only contain
hexadecimal digits (strings containing other characters returns an I/O
error), so I'm wagering that the "EXEC" call does a simple translation
from the hex string to bytecodes, then executes it.
Now to work out various sundry details like calling conventions, where
the code is in memory when it's executed (so I can do jumps) and then
onto more fun things like doing something useful!
Thanks!
Josh
Rick Bensene wrote:
I recall that there was a way to make the 4051 execute
machine code. I
don't remember the exact method, but I remember that the bytes of 6800
machine code were encoded into a character string using the CHR$()
function. For example, hex 43 would turn into CHR$(67), or a "C". The
bytes were put into a string with the limit of program size being the
max. size of a character string. The next part is where my memory fails
me -- there was a way to cause the BASIC interpreter to branch to the
first character in the string, executing the code there. It involved
doing the transfer in such a way that it was if the code was branched to
with a "jump to subroutine" call, and when the code was complete, a
"return from subroutine" instruction would be in the code, and that
would cause a branch back to the BASIC interpreter. As I'm writing this,
a statement called EXEC$ or something along those lines pops into my
head.
I don't know if this is any help at all, but I really clearly remember
seeing 4051 programs (I worked at Tektronix from 1977 to 1990, and did a
lot of tinkering with 4051/2/4) that filled character strings with
hand-assembled machine code, and had a means to execute it. Hopefully
someone can find some docs that might substantiate these memories and
solve the mystery.
Rick Bensene
The Old Calculator Museum
http://oldcalculatormuseum.com
8:19 p.m.
New subject: Executing Machine Code on the Tektronix 4051
Small correction: The string "EXEC" takes does not seem to need to only
hexadecimal digits, the only requirement seems to be that it have a
non-zero, even length.
So I'm unsure of the encoding -- strings on the Tek are limited to 7-bit
ASCII, so using CHR() to build a string directly from 6800 machine codes
isn't going to work. Given that the call requires an even-length
string, clearly two characters are combined somehow to form one machine
code, but how isn't immediately obvious. I've played around with a few
simple combinations with no luck so far.
Josh
Josh Dersch wrote:
Looks like your memory is not too bad... the
documented method for
calling ROM code (in expansion packs) is via the "CALL" command with a
string that names the function to be called. (i.e. I have the EDITOR
rom, and that's invoked by doing 'CALL "EDITOR"').
Well, I just tried this:
A$="ABCDEF"
CALL "EXEC",A$
And the machine immediately reset and gave me a system error :). So
it seems evident that this was executing the string as machine code
(and crashing horribly).
Further experimentation reveals that the string can only contain
hexadecimal digits (strings containing other characters returns an I/O
error), so I'm wagering that the "EXEC" call does a simple translation
from the hex string to bytecodes, then executes it.
Now to work out various sundry details like calling conventions, where
the code is in memory when it's executed (so I can do jumps) and then
onto more fun things like doing something useful!
Thanks!
Josh
Rick Bensene wrote:
I recall that there was a way to make the 4051
execute machine code. I
don't remember the exact method, but I remember that the bytes of 6800
machine code were encoded into a character string using the CHR$()
function. For example, hex 43 would turn into CHR$(67), or a "C". The
bytes were put into a string with the limit of program size being the
max. size of a character string. The next part is where my memory fails
me -- there was a way to cause the BASIC interpreter to branch to the
first character in the string, executing the code there. It involved
doing the transfer in such a way that it was if the code was branched to
with a "jump to subroutine" call, and when the code was complete, a
"return from subroutine" instruction would be in the code, and that
would cause a branch back to the BASIC interpreter. As I'm writing this,
a statement called EXEC$ or something along those lines pops into my
head.
I don't know if this is any help at all, but I really clearly remember
seeing 4051 programs (I worked at Tektronix from 1977 to 1990, and did a
lot of tinkering with 4051/2/4) that filled character strings with
hand-assembled machine code, and had a means to execute it. Hopefully
someone can find some docs that might substantiate these memories and
solve the mystery.
Rick Bensene
The Old Calculator Museum
http://oldcalculatormuseum.com
11:50 p.m.
New subject: Executing Machine Code on the Tektronix 4051
Ok, sorry for continually replying to my own posts, and sorry for
spamming the group with stuff, but I found the answer.
And the answer comes from Rick, c. 1999 :).
http://www.classiccmp.org/pipermail/cctalk/1999-February/120292.html
Looks like, based on that encoding, it's just the lower-nybbles of each
pair of characters forming one machine code byte. Makes sense :). (I
swear I tried this without success earlier, but now I'm having better
luck...)
Now to figure out everything else. Now I wish I had a bitmapped display
to make debugging easier :).
Josh
Josh Dersch wrote:
Small correction: The string "EXEC" takes
does not seem to need to
only hexadecimal digits, the only requirement seems to be that it have
a non-zero, even length.
So I'm unsure of the encoding -- strings on the Tek are limited to
7-bit ASCII, so using CHR() to build a string directly from 6800
machine codes isn't going to work. Given that the call requires an
even-length string, clearly two characters are combined somehow to
form one machine code, but how isn't immediately obvious. I've played
around with a few simple combinations with no luck so far.
Josh
Josh Dersch wrote:
Looks like your memory is not too bad... the
documented method for
calling ROM code (in expansion packs) is via the "CALL" command with
a string that names the function to be called. (i.e. I have the
EDITOR rom, and that's invoked by doing 'CALL "EDITOR"').
Well, I just tried this:
A$="ABCDEF"
CALL "EXEC",A$
And the machine immediately reset and gave me a system error :). So
it seems evident that this was executing the string as machine code
(and crashing horribly).
Further experimentation reveals that the string can only contain
hexadecimal digits (strings containing other characters returns an
I/O error), so I'm wagering that the "EXEC" call does a simple
translation from the hex string to bytecodes, then executes it.
Now to work out various sundry details like calling conventions,
where the code is in memory when it's executed (so I can do jumps)
and then onto more fun things like doing something useful!
Thanks!
Josh
Rick Bensene wrote:
I recall that there was a way to make the 4051
execute machine code. I
don't remember the exact method, but I remember that the bytes of 6800
machine code were encoded into a character string using the CHR$()
function. For example, hex 43 would turn into CHR$(67), or a "C".
The
bytes were put into a string with the limit of program size being the
max. size of a character string. The next part is where my memory
fails
me -- there was a way to cause the BASIC interpreter to branch to the
first character in the string, executing the code there. It involved
doing the transfer in such a way that it was if the code was
branched to
with a "jump to subroutine" call, and when the code was complete, a
"return from subroutine" instruction would be in the code, and that
would cause a branch back to the BASIC interpreter. As I'm writing
this,
a statement called EXEC$ or something along those lines pops into my
head. I don't know if this is any help at all, but I really clearly
remember
seeing 4051 programs (I worked at Tektronix from 1977 to 1990, and
did a
lot of tinkering with 4051/2/4) that filled character strings with
hand-assembled machine code, and had a means to execute it. Hopefully
someone can find some docs that might substantiate these memories and
solve the mystery.
Rick Bensene
The Old Calculator Museum
http://oldcalculatormuseum.com
23 Feb
23 Feb
3:26 a.m.
On Sun, 22 Feb 2009, Josh Dersch wrote:
Richard wrote:
We have several third-party ROM and RAM modules for our 4051. A RAM module
(called BACKRAM) behaves like a ROM module after you have loaded the
contents from tape. There is one module with support for CBM drives,
special I/O routines, assembler and firmware routines.
The documentation (alas German only) for these ROMs can be found at
ftp.informatik.uni-stuttgart.de/pub/cm/tek4051/
BTW it *is* possible to write 6800 programs, it's just not officially
documented. The magic command is
CALL "exec" [,{Var1} [,{Var2} {,...]]], {Loaderstring}
(see exec.txt and ram_loader.prg)
I guess the best way to get data transferred from
these systems is to
use the GPIB interface and transfer the programs out of the system and
into the internet. I wonder if the easiest would be to use a
Commodore GPIB compatable floppy drive or something.
Or over the optional RS-232 expansion (at a whopping 2400bps). I've been
experimenting with this idea for archiving 405x tapes (and Bob Rosenbloom has
offered to lend me a couple of tapes to play with) but the major catch is
that the 4051 appears to _only_ be programmable in BASIC -- there's no
PEEK/POKE or ways to call user 6800 machine code. This wouldn't be a problem
except that it's possible to protect tape files with the "SECRET" command
--
this makes a given file execute-only, so it appears to be impossible to read
the contents of the file using BASIC commands. I'm guessing that most (if
not all) commercial software tapes are protected in such a manner, but I
suppose I'll find out. I'm looking into whether if it's possible to
adapt one of the "backpack"
expansions to take EPROMs instead of MCM6832 ROMs. Anyone done this before?
Given a bit of hacking it'd then be possible to write some 6800 code to do a
binary dump of the tapes, bypassing the protection mechanisms.
I've already written a little BASIC program that uses the special ROM
functions in order to create real tape dumps into a CBM floppy file. These
dumps contain all records etc., and it is possible to create a real tape
from that image. The commands are TREAD and TWRITE.
The file sysrom.txt contains a descriptions of the system ROM entry points
and the function they perform.
And here's how to un-secret a program (see exec.txt):
L$="7?008039"
CALL "exec",L$
Christian
11:35 a.m.
Christian Corti wrote:
We have several third-party ROM and RAM modules for our 4051. A RAM
module (called BACKRAM) behaves like a ROM module after you have
loaded the contents from tape. There is one module with support for
CBM drives, special I/O routines, assembler and firmware routines.
The documentation (alas German only) for these ROMs can be found at
ftp.informatik.uni-stuttgart.de/pub/cm/tek4051/
BTW it *is* possible to write 6800 programs, it's just not officially
documented. The magic command is
CALL "exec" [,{Var1} [,{Var2} {,...]]], {Loaderstring}
(see exec.txt and ram_loader.prg)
Wow, that's awesome! I'd worked out a bit of "exec" but this
will be
very helpful (assuming I can decipher enough of the German text to get
anything useful out of it :). (Google Translate seems to do a pretty
good job -- I'll clean it up and provide an English version when I'm done...
Thanks a ton!
Josh
I'm looking into whether if it's possible
to adapt one of the
"backpack" expansions to take EPROMs instead of MCM6832 ROMs. Anyone
done this before? Given a bit of hacking it'd then be possible to
write some 6800 code to do a binary dump of the tapes, bypassing the
protection mechanisms.
I've already written a little BASIC program that uses the special ROM
functions in order to create real tape dumps into a CBM floppy file.
These dumps contain all records etc., and it is possible to create a
real tape from that image. The commands are TREAD and TWRITE.
The file sysrom.txt contains a descriptions of the system ROM entry
points and the function they perform.
And here's how to un-secret a program (see exec.txt):
L$="7?008039"
CALL "exec",L$
Christian
22 Feb
22 Feb
10:53 a.m.
(Using a 405x with an 8050 is a PAIN. You send all
the commands to the
drive to find the file and be ready to load it. You then type OLD at 8 and
what does the machine do? Why, asserts IFC, of course. But there are
ways around this. I wonder if I can find my notes...)
If this were my system,. I think I'd modify that 8050 to ignore IFC. I
don't have the service manual in front of me, but it's probably jsut a
matter of cutting the trace to the apporpriate pin of the IEEE-488
socket. 8050s are a lot more common that 405x's, adter all, so I'd modify
that end (not to mention the fact that there are times when I'd want to
be able to reset other devices from the 405x.
If you could find an 8250LP, the IEEE-488 connection in that goes through
an intenral cable which would be easy to reversably modify.
-tony
12:32 p.m.
Tony Duell wrote:
If this were my system,. I think I'd modify that
8050 to ignore IFC.
Personally, I'd sooner get a couple of IDC IEEE-488 connectors and some cable,
crimp the connectors on the cable (wired 1-1, 2-2, etc.) then separate the IFC
wire from the rest of the bundle (I'd pick a bit in the middle, say 2in long).
Cut that wire dead in half, continuity-check the cable, then cut the IFC wire
down to a more respectable length once all the checks pass (or solder it back
together if it turns out you cut the wrong wire).
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
23 Feb
23 Feb
12:25 p.m.
Tony Duell wrote:
Ore cerfully seprate the IFC line from the rest of the cable at one end
before crimping the connector on that end amd crimp the remianing 2 bits
(one either side of the IFC wiee) to the connector with a gap between
them. I've done that sort of thing often enough making PC-type floppy
cables, RS232 caels iwth null-modem twists, etc, so I don't see why it
would be any more difficult with microribbon connectors.
-tony
If this were my system,. I think I'd modify
that 8050 to ignore IFC.
Personally, I'd sooner get a couple of IDC IEEE-488 connectors and some cable,
crimp the connectors on the cable (wired 1-1, 2-2, etc.) then separate the IFC
wire from the rest of the bundle (I'd pick a bit in the middle, say 2in long).
Cut that wire dead in half, continuity-check the cable, then cut the IFC wire
down to a more respectable length once all the checks pass (or solder it back
together if it turns out you cut the wrong wire).
22 Feb
22 Feb
12:44 p.m.
Tony Duell wrote:
Tony, you may rest easy. The workaround involves chaining the program
rather than loading it from scratch. This doesn't assert IFC.
As regards an 8250LP, I think I used the disk drive mounted in my 8296
in situ, using the 8296 to check that it was working...
I want a MUPET.
Philip.
(Using a 405x
with an 8050 is a PAIN. You send all the commands to the
drive to find the file and be ready to load it. You then type OLD at 8 and
what does the machine do? Why, asserts IFC, of course. But there are
ways around this. I wonder if I can find my notes...)
If this were my system,. I think I'd modify that 8050 to ignore IFC. I
don't have the service manual in front of me, but it's probably jsut a
matter of cutting the trace to the apporpriate pin of the IEEE-488
socket. 8050s are a lot more common that 405x's, adter all, so I'd modify
that end (not to mention the fact that there are times when I'd want to
be able to reset other devices from the 405x.
If you could find an 8250LP, the IEEE-488 connection in that goes through
an intenral cable which would be easy to reversably modify. 
13 Feb
13 Feb
12:30 a.m.
On Fri, 2009-02-13 at 00:24 +0000, Philip Pemberton wrote:
The spec in the parts list was 1%. 1% of 39M is
390k-ohms either way... 40M is
well out of spec.
Hmm. I'd say it was a *little* out of spec, particularly when you
consider that the 39M resistor may well have headed off into 100M+
territory with age.
Gordon
10:45 a.m.
Josh Dersch wrote:
I have a high voltag insulation tester that would easily measure 39M, but
(a) you'd have to take the resisotrs out of circuit (I don't think the
other bits would like having a few hundred volts across them) and (b) I
am not sure how accurate it is. It would pick up a shorted or open
resistor, sure.
My multimeter doesn't go that high (I really
need to get a good one one
of these days.)
My Fluke 25 won't go that high either -- max range on that is 32
megohms. I've got a Solartron 7150plus bench DMM that can read down
to one milliohm in the
2K-ohm range (6.5 digits with averaging enabled), but still limits at 20M-ohms
max.
Yes, but unless the original resistor has drifted to 40M, then fitting a
40M reisstor in place of it should change the symptoms. It may not be
possible to get to the original spec (strightness of lines, etc) but you
should see some change.
I replaced these with two 20M's in series
(figured it'd
be close enough to at least see if it changes anything, and I can't find
any place that actually stocks 39M resistors that aren't SMD...) No
change in display behavior.
The spec in the parts list was 1%. 1% of 39M is 390k-ohms either way... 40M is
well out of spec. I'm starting to wonder if some normally-irrelevant
parameter of those poly
caps has shifted and fragged the vector generator.
I am wondering if the fault could be further back. What if one or both
of the DACs has 'gone slow', and no longer produces a sharp output change
when you change the digitial inputs?
-tony
17 Feb
17 Feb
1:20 a.m.
New subject: ASR33 as storage medium on PDP 11/05
Hi to all!
My PDP 11/05 came, when it was first sold, with an ASR 33 as the only console and storage
medium.
Later it was modified to a system with RX02 Floppy and one VT Terminal (connected to the
20mA loop
but with 2400 baud instead of 110 as for the ASR).
Now i would like to reconnect the ASR (or another papertape reader/puncher) to the system
without having
to screw up the CPU to reduce the speed of the serial line interface. I don't want the
console-output to
be printed on the ASR but reading/punching papertapes would be fine.
As i remember DEC was selling its high speed reader ( PC11 ?) but only for fanfold tapes.
Maybe this can archived by adding one extra interface to the unibus and a piece of
software.
I'm not sure. The machine runs RT-11 V4.0
Regards
Axel Harten.
--
18 Feb
18 Feb
4:53 a.m.
New subject: ASR33 as storage medium on PDP 11/05
Date: Tue, 17 Feb 2009 10:20:45 +0100
From: harten at injectstar.de
To: cctech at classiccmp.org
CC:
Subject: ASR33 as storage medium on PDP 11/05
Hi to all!
My PDP 11/05 came, when it was first sold, with an ASR 33
as the only console and storage medium.
Later it was modified to a system with RX02 Floppy and
one VT Terminal (connected to the 20mA loop but with 2400
baud instead of 110 as for the ASR).
Now i would like to reconnect the ASR (or another papertape
reader/puncher) to the system without having to screw up
the CPU to reduce the speed of the serial line interface.
I don't want the console-output to be printed on the ASR
but reading/punching papertapes would be fine.
As i remember DEC was selling its high speed reader
( PC11 ?) but only for fanfold tapes.
Maybe this can archived by adding one extra interface to
the unibus and a piece of software.
I'm not sure. The machine runs RT-11 V4.0
Regards
Axel Harten.
Maybe I am overlooking something, but is a simple DL11
interface not all that you need to connect a reader and puncher?
The PC11 interface (M7810) connects to the PC05, but if you have
a "standard" reader / puncher they can have an serial interface
(RS-whatever or current loop). And in that case, you can connect
to the the 11/05 using a simple UNIBUS async serial interface
module like the M7856.
You might want to disable the line time clock on the added SLU.
If the reader/pucher has a (8-bit) parallel interface it also has
a few handshake signals. It is fairly straight-forward to make a
parallel <-> serial interface. With a bit more effort you can
control the handshake lines to control the stepping speed of the
papertape movement. Less effort will cause the tape to move at
the reader/puncher speed, which might not match to a standard
baudrate.
With an SLU, no special software (drivers) are needed, unless
you want more control than simple start at begin of tape and
stop when tape is (completely) read (or all data punched).
Hope this helps (and is correct)
- Henk, PA8PDP
11:12 a.m.
New subject: ASR33 as storage medium on PDP 11/05
As i remember DEC was selling its high speed reader (
PC11 ?) but only
for fanfold tapes.
There were also 3rd-party paper tape punch/reader systems that were
software-compatible with the PC11. I have an interface card in my 11/45
that talks to a Trend HSR700 (700 cps) reader and a Facit 4070 (75 cps)
punch. I am pretty sure Facit sold a Unibus interace card for their
reader too.
Maybe this can archived by adding one extra interface to the unibus
and a piece of software.
AFAIK there is no reason why you can't add another DL11 serial interface
(with a different Unius address and Interrupt vector) to link to your
ASR33. I am not sure about the driver -- the DL11 is somewhat
register-compatible with the PC11, so it might be a very simple
modification of the PC: driver.
-tony
11:15 p.m.
New subject: ASR33 as storage medium on PDP 11/05
In message <m1LZrqb-000IxyC at p850ug1> you wrote:
Adding another DL11 will not be a problem for me. I have already done so
for the TU58 emulator.
Unfortunately I have no experience in modifying a RT-11 PC11 driver.
Axel
--
As i remember
DEC was selling its high speed reader ( PC11 ?) but only
for fanfold tapes.
There were also 3rd-party paper tape punch/reader systems that were
software-compatible with the PC11. I have an interface card in my 11/45
that talks to a Trend HSR700 (700 cps) reader and a Facit 4070 (75 cps)
punch. I am pretty sure Facit sold a Unibus interace card for their
reader too.
Maybe this can archived by adding one extra interface to the unibus
and a piece of software.
AFAIK there is no reason why you can't add another DL11 serial interface
(with a different Unius address and Interrupt vector) to link to your
ASR33. I am not sure about the driver -- the DL11 is somewhat
register-compatible with the PC11, so it might be a very simple
modification of the PC: driver.
-tony
5780
days inactive
5793
days old
29 comments
10 participants
participants (10)
-
ard＠p850ug1.demon.co.uk -
cc＠informatik.uni-stuttgart.de -
classiccmp＠philpem.me.uk -
derschjo＠mail.msu.edu -
gordonjcp＠gjcp.net -
harten＠injectstar.de -
henk.gooijen＠hotmail.com -
legalize＠xmission.com -
philip＠axeside.co.uk -
rickb＠bensene.com