Fred N. van Kempen <Fred.van.Kempen(a)microwalt.nl> wrote:
> When booting the M76 with the VXT (V2.1) load image, nothing happens
> after the load image has been loaded. In other words, it dies when
> started.
>
> [...]
>
> So.. heh. Now, to find out what is happening with the M76...
Well, it's obvious what's happening. The VXT program reads the SID register,
sees the top byte equal to 0B, and doesn't know what the heck to do with it. In
other words, it just doesn't support this machine.
> When loading the M38... _it_works_ !
> The VXT software "detects" a VT1300 with SPX and 16MB, and happily runs.
Good. This is what I expected, but just to make sure. The real VT1300 was AFAIK
a KA42-A (M30, 90 ns cycle time) with GPX video, so you've just built a better
VT1300 with a faster 60 ns cycle time CPU and with SPX video. Given that the
VXT program runs on 3 different CPUs (VS2000 with MV II, KA42/VT1300 with CVAX,
and VXT2000 with SOC), we can safely assume that your faster VT1300 won't cause
any problems later, i.e., the program is very unlikely to time things with CPU
cycles.
MS
All,
Took some fiddling with boards and a firm kick to the monitor,
but... we haveth resulths.
Setup:
Server1: VAXserver 3100, OpenBSD/vax V3.1
Server2: VAX 4000-100, OpenSD/vax V3.1
Client1: VAXstation 3100-M38 [SPX], VR219-D3
Client2: VAXstation 3100-M76 [SPX], VR219-D3
Server2 is the boot server which runs [my version of] MOPD, and which
is the load host here for the VAXlab network. It has no probs booting
the terminal servers, DECnis 600, the VXT2000's and all VAXen I have.
When booting the M76 with the VXT (V2.1) load image, nothing happens
after the load image has been loaded. In other words, it dies when
started.
When loading the M38... _it_works_ !
The VXT software "detects" a VT1300 with SPX and 16MB, and happily runs.
So.. heh. Now, to find out what is happening with the M76...
--fred
I dug the 2001 out of the cupboard the other day - it's reorganise time,
try to get *even more* stuff into exactly the same amount of space as less
(but still lots of) stuff occupied. It never works, but it does give me an
excellent excuse to have a play around with some of them.
Unfortunately, the PET seems to have developed an odd fault: It won't take
a BASIC program, and some keywords seem to be knackered...
It reports 7167 bytes free, as per spec. But if I type:
10 REM blah
or
10 ?"HELLO"
it hangs. If I load a program from tape, it does one of two things:
a) Loads but won't run, typing LIST produces something like this:
10
2
READY.
b) It loads & hangs immediately after the READY. prompt comes up.
I tried to put together a FOR loop (the idea being I could use it to
display chunks of memory at a time, e.g.
FORI=0TO10:?I;:NEXT
Instead, the machine goes into an infinte loop displaying zero on a new
line each time (it's ignored the I variable, and the semicolon after the
PRINT command.
If I replace NEXT with NEXTI, it fails reporting NEXT without FOR.
So.... I figure the BASIC ROM has become slightly corrupted, OR I've got a
flakey memory chip which reads OK but doesn't write properly. The question
is, how to find out?
1) Can the BASIC ROM be swapped with one from, say, a 3032 or 4016? In
fact, which one IS the BASIC ROM?
2) If it's a dodgy memory chip, what's the best way of isolating it? I have
an oscilloscope, but nada skill in this sort of thing.
3) If, as my money is on, it's the BASIC ROM, can it be replaced with an
EPROM - if so, there's a whole gamut of additional questions to follow....
Thanks in advance!
--
Cheers, Ade.
Be where it's at, B-Racing!
http://b-racing.com
On Jan 17, 18:18, Adrian Vickers wrote:
>
> Unfortunately, the PET seems to have developed an odd fault: It won't
take
> a BASIC program, and some keywords seem to be knackered...
> So.... I figure the BASIC ROM has become slightly corrupted, OR I've got
a
> flakey memory chip which reads OK but doesn't write properly. The
question
> is, how to find out?
Swap some of the RAM chips around and see if it makes a difference. If it
does, particularly if it fixes it, swap them back -- it might just be a bad
socket contact. Be careful with the RAM chips: if you have the type of PET
I think you do, they're MOS Technology 6550, aka unobtainium, and unlike
any other RAM chip.
> 1) Can the BASIC ROM be swapped with one from, say, a 3032 or 4016? In
> fact, which one IS the BASIC ROM?
No. BASIC (and also the rest of the code, whether you call it a kernel or
a monitor, or "stuff") is spread over several chips. And in the early
PETs, the ROMs too are MOS Technology specials, and the different versions
of PETs had different ROMs. In fact, there was an upgrade for the
originals, because they didn't handle the IEEE routines properly, which
made it impossible to use disks properly (amongst other things).
> 2) If it's a dodgy memory chip, what's the best way of isolating it? I
have
> an oscilloscope, but nada skill in this sort of thing.
> 3) If, as my money is on, it's the BASIC ROM, can it be replaced with an
> EPROM - if so, there's a whole gamut of additional questions to
follow....
If it's a later unit with 24-pin 2332 mask ROMs, then a TMS2532 EPROM can
be used (not a 2732, nor other 2532s that don't have the TMS prefix). If
it's got 28-pin MOS Technology MPS6540 ROMs, you'd need a carrier to
shuffle some signals, at the very least, and possibly some logic to handle
the multiple select lines. The good news, though, is that I have a
chicklet-keyboard 2001-N as well, and if necessary, I could probably do a
ROM dump for you (though IIRC it used to be on the 'net somewhere). I
wouldn't need to move more than a few hundreweight of stuff to get at it
;-)
--
Pete Peter Turnbull
Network Manager
University of York
I tried with both VR320 and VR19-D3, see next msg on list. This is
driving me nuts.
--fred
> -----Original Message-----
> From: Antonio Carlini [mailto:arcarlini@iee.org]
> Sent: Saturday, January 18, 2003 11:37 PM
> To: cctalk(a)classiccmp.org
> Subject: RE: VXT X terminal question
>
>
> > Although I have both the M38 and M76 set up, I cant get the video
> > part to work - tube (that is on a VXT2000 right now) doesn't
> > seem to sync on either model. The M38 is standard, the M76
> > is the SPX model. Anyone have a clue?
>
> What monitor are you using? These things are synch-on-green,
> which not all monitors support.
>
> Antonio
>
> --
>
> ---------------
> Antonio Carlini arcarlini(a)iee.org
>
>
All,
Although I have both the M38 and M76 set up, I cant get the video
part to work - tube (that is on a VXT2000 right now) doesn't seem
to sync on either model. The M38 is standard, the M76 is the SPX
model. Anyone have a clue?
--fred
Jochen writes:
> Someone on the PUPS / TUHS list has ported 4.3BSD-Tahoe and / or
> 4.3BSD-Reno to the VAX4000-7xx. AFAIK he had some porblems with
> interrupts at autoconfig time, but got it running.
Heh. This is not too hard, but *only* if he used the machine with
a KFQSA (DSSI-to-MSCP) controller, rather than the onboard SHAC.
It'd be a start, though. Michael, was this you?
--fred
Antonio Carlini <arcarlini(a)iee.org> wrote:
> I think the origins of the GPX go back to the QDSS Q-bus
> board set as used in the VAXstation II (the "Dragon" chipset).
I know. I meant that the GPX used in VS3100s originated in VS2K.
> My recollection is that the same GPX board was indeed used on
> the KA410 and KA42s. That was the VS40X-MA.
I thought so too. But what about SPX? Can it go into a pre-M76 VS3100? And what
about VS2K SPX? (It would of course be very silly in practice, but I'm talking
in principle.)
> I *think* that in the KA42 systems, they converted from CDAL
> to EDAL (or whatever) as necessary.
"As necessary"? I thought that except for memory KA42 is 100% EDAL. At least to
system software KA42 is basically a faster KA410. (Well, there are some tweaks,
like the ugly hack to make LANCE address 32 MB instead of 16. On KA410 they
simply got lucky that their system memory size just happened to be what LANCE
can address. Then I recall that the NetBSD folks had discovered that for SCSI
the DMA byte count had to be set off by one between the two or something like
that. I don't remember the details, but the question can probably be settled by
comparing the KA42 SCSI driver in Ultrix sources against the KA410 st driver
and the KA410 TM.)
So I thought that KA42 had one big CDAL-to-EDAL bridge upfront and the rest of
the system except memory was EDAL. But I could be wrong, maybe different
subsystems have their own independent connections to CDAL.
But if KA42 indeed has one big CDAL-to-EDAL bridge upfront, the million dollar
question becomes: why did the VS4000 M90 dev team toil to design their own
CDAL-to-EDAL bridge (CEAC) if there already was one? The only plausible
explanation I could come up with is that perhaps on KA42 the CDAL-to-EDAL
bridge was inseparably integrated with the memory controller.
BTW, I have never found any references to a technical manual for VS3100 (any
model) or for the corresponding early MV3100 models. It looks like one never
existed. Do you have any more info?
> The KA43 was a Rigel chip
> shoe-horned into a CVAX system, so they did something to
> convert the Rigel bus (RDAL?) to CDAL and then left as much
> of the rest of the box alone (I don't have the KA43 stuff
> to hand so I may be misremembering the exact details here).
Does KA43 have memory on CDAL or on RDAL? I once had one in my hands and when I
looked on the board to see what chips it had, I found the P-chip and the F-
chip, but not the G-chip. The G-chip (used on KA670) is a Rigel memory
controller and an RDAL-to-CDAL bridge combined. (The VAX 4500 team got the NCA
idea from it.) I then thought that having no real need for CDAL KA43 went
directly from RDAL to EDAL, perhaps combining the RDAL-to-EDAL bridge with an
RDAL memory controller. But I guess they could have also made a chip like the G
but without the memory controller and then plopped the KA42 memory and I/O on
CDAL. That could explain why KA670 pulls 8.0 VUPs and KA43 only 7.6.
But you are right in that the gap between KA42 and KA43 is much smaller than
between KA410 and KA42.
> In the VS4000-90, the NCA is (IIRC) an NDAL-to-CDAL bridge.
> Then the EDAL hangs off the CDAL to give access to some of the
> internal options that presumably were leveraged from earlier
> CVAX designs (KA42 etc.). But the graphics hang off the CDAL.
> As you note, these are *not* the standard SPX etc. but designs
> that presumably had already been modified from the original
> SPX
Yup.
> to remove the EDAQL interface and use CDAL instead
Yeah, maybe that was the change. (Was that a typo or was EDAQL a chip
converting EDAL to SPX's internal bus?)
> I'm guessing, I
> cannot find the article I'm sure I've read that describes
> the development of the VXT2000).
http://www.research.compaq.com/wrl/DECarchives/DTJ/DTJ402/DTJ402SC.TXT
But it talks about the X aspects of it and says nothing about VXT2000 hardware.
MS
Michael asks:
> This last point makes me think "hmm, it must be fairly generic, I
> wonder what other VAXstations can it run on?"
True, the software set seems to be fairly generic.. I found this out
a while ago by accident; I (net-)booted that image onto the wrong
machine, and dang! wasdat? it *runs* ??? :-)
> Specifically I wonder whether it would run on a KA43 (VS3100 M76).
Most likely not, because the -M76 is an NVAX box similar to the 4000
series machines (MV4 aka 4000/200, the 4000's, the 3100-M76 and -4X
and -8X series.) It might run on the 3100-M38, although I believe
that's a "non" 3100, too. I would assume that they kept the CPU
support library as small as possible, meaning only the generic series
of machines they "sortof" intended the VXT software set for, i.e. the
2000, 3100 and alike systems and their hardware features (as needed.)
> I'm willing to bet that it'll handle the SPX video
Yup, it's basically some "NanoVMS" kernel, with minimal runtime and a
VMS DECwindows subset. Which means (methinks..) that it most likely
wasnt stripped from its GPX and SPX(+) drivers.
Dang! Now you got me curious. I have all three (2000,M38 and M76) so
will set them up tonight or tomorrow and see what they do.
--fred
Fred N. van Kempen <Fred.van.Kempen(a)microwalt.nl> wrote:
> Ugh. Make that V4.20, obviously. Development is done on my V4.5 box..
>
> Shitty thing is, that I probably will also have to run a 4.2 system as
> a second-step system for bootstrapping, and I dont have a 4.2/vax tk50
> or cd set.
Why can't you compile and use the V4.20 kernel on your V4.50 system?
BTW, have you tried booting VXT on different VS3100s? I would really like to
use a KA43 for my own VXT if possible, but I need to know if it is or not.
MS
