I have been trying to get a microvax II fully functional over the last few weeks and I seem to have a roadblock. The system used to boot and allow logins, but now after connecting a VCB-02 cable to display, keyboard and mouse, it has become more and more unreliable. It may be possible that some assistance I got from a colleague might have helped to cause this situation, but I think its unlikely. When the system was booting properly, it wouldn't bring up decwindows even when the display, kb, and mouse were attached to the bulkhead cable (bc18z). I was asked to check the WINDOW_SYSTEM variable within sysgen to determine if the current value was anything other than 1. In this case it was 2. He asked me to change the value to 1, and then to write it to current and active, then complete an autoconfigure all. I don't feel this is a factor, because when I boot into conversational mode and set the WINDOW_SYSTEM variable to 0 the system still faults when I perform a @sys$system:startup. In conversational mode, when I launch the startup.com script, the kernel panics as it does when it boots in normal mode. I was hoping to edit the startup.com script (or move it to a safe location and place a partial startup script in its place), but I'm not sure what parts I need to have. If I dont run the startup script, I can't run anal/crash because of protection issues.
At first when connected to a display the system would kernel panic during boot. It would boot WITHOUT the display being connected, however, so I continued using it without the display. Unfortunately, now it appears to panic every boot, and I can't get to a prompt to run any diagnostics such as anal/crash. No user based changes were made to the system between boots. The real brain teaser is that it doesn't always crash during the same process load, I have been trying to get a microvax II fully functional over the last few weeks and I seem to have a roadblock. The system used to boot and allow logins, but now after connecting a VCB-02 cable to display, keyboard and mouse, it has become more and more unreliable. The real brain teaser is that it doesn't always crash during the same process load, sometimes its OPCOM, sometimes its STARTUP, sometimes its DECW$STARTUP as it is below. Anyone have any insight on how to proceed? I'm not a very experienced user. A crash example is below:
KA630-A.V1.3
Performing normal system tests.
7..6..5..4..3..
Tests completed.
>>> boot
2..1..0..
VAX/VMS Version V5.2 Major version id = 1 Minor version id = 0
$! Copyright (c) 1989 Digital Equipment Corporation. All rights reserved.
The VAX/VMS system is now executing the system startup procedure.
**** FATAL BUG CHECK, VERSION = V5.2 MACHINECHK, Machine check while in kernel mode
CRASH CPU: 00 PRIMARY CPU: 00
ACTIVE/AVAILABLE CPU MASKS: 00000001/00000001
CURRENT PROCESS = DECW$STARTUP
REGISTER DUMP
R0 = 00000000
R1 = 7FF38058
R2 = 00000000
R3 = 00000268
R4 = 00000000
R5 = 00000000
R6 = 00004152
R7 = 00000001
R8 = 0000026C
R9 = 00003FDC
R10= 000042DC
R11= 00006CF0
AP = 7FF380FC
FP = 7FF380C0
SP = 803AF1E0
PC = 8028D977
PSL= 04DF0008
KERNEL/INTERRUPT/BOOT STACK
803AF1E8 0000000C
803AF1EC 00000082
803AF1F0 7FF38058
803AF1F4 02000002
803AF1F8 00001534
803AF1FC 03C00001
LOADED IMAGES
[SYSMSG]SYSMSG.EXE 800E0600 8010A400
[SYS$LDR]SYSLDR_DYN.EXE 80195200 80196C00
[SYS$LDR]DDIF$RMS_EXTENSION.EXE 80197000 80198200
[SYS$LDR]RECOVERY_UNIT_SERVICES.EXE 80198200 80198E00
[SYS$LDR]RMS.EXE 8010A400 80130200
SYS$NETWORK_SERVICES.EXE 80130C00 80130E00
SYS$TRANSACTION_SERVICES.EXE 80131400 80131600
CPULOA.EXE 80131C00 80133200
LMF$GROUP_TABLE.EXE 80133C00 80134600
SYSLICENSE.EXE 80134A00 80136000
SYSGETSYI.EXE 80136600 80137C00
SYSDEVICE.EXE 80138000 80139600
MESSAGE_ROUTINES.EXE 80139C00 8013C800
EXCEPTION.EXE 8014CC00 80155400
LOGICAL_NAMES.EXE 80155C00 80157600
SECURITY.EXE 80157C00 80159400
LOCKING.EXE 80159A00 8015C200
PAGE_MANAGEMENT.EXE 8015C800 80164800
WORKING_SET_MANAGEMENT.EXE 80165000 80169600
IMAGE_MANAGEMENT.EXE 8016A000 8016CA00
EVENT_FLAGS_AND_ASTS.EXE 8016D000 8016E400
IO_ROUTINES.EXE 8016EA00 80175C00
PROCESS_MANAGEMENT.EXE 80176200 8017E800
ERRORLOG.EXE 8018BC00 8018C600
PRIMITIVE_IO.EXE 8018CC00 8018DC00
SYSTEM_SYNCHRONIZATION_UNI.EXE 8018E000 8018F600
SYSTEM_PRIMITIVES.EXE 8018FC00 80193000
**** STARTING MEMORY DUMP....
ERROR WRITING 127 BLOCK(S), STARTING AT VBN 5471 - STATUS = 00000054
> Guess what computer I brought back from the dead?
> http://raspberry-python.blogspot.com/2012/10/it-lives-hint-1.html
> I'm thinking somebody on this list has used one and will recognize it.
> Just a simple screenshot to start with...
It's Applesoft, but says "PRESS RESET" at the top, so.... an Apple II (not plus) with Applesoft language card? Or upgraded with Applesoft ROMs?
Personally I like Integer Basic :-)
Tim.
Reposted from comp.os.cpm
by Charles Richmond
I am sorry to report that C.B. "Chuck" Falconer has passed away. He used
to be a regular in alt.folklore.computers, comp.os.cpm, and comp.lang.c.
He had a long and involved history with computers and programming. He was
born in Switzerland on September 13, 1931 and passed away in Damariscotta,
Maine on June 4, 2012. I'm sure most everyone here remembers him and his
posts to Usenet. One of his many accomplishments was writing an article
for an early Dr. Dobbs magazine on implementing floating point on the
Intel 8080 microprocessor.
His resent resume and the downloadable files from a recent web page of
his... can be found at You can a recent resume of his at the ClassicCmp
website:
http://tinyurl.com/8fudn4o
His obituary is at:
http://tinyurl.com/8ahongj
--
David Griffith
dgriffi at cs.csubak.edu
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
> you put in a disk, you get a cursor, but that`s it. Puter won`t give
> disk back. Do I have to take it apart?
The SD-321 drives have a lock mechanism that should release the disk when
the button is in the 'out' position. But it doesn't as the old grease
keeps the lock in place. I have observed this with both the QX10 and the
TF-20 which both use the 1/3 height SD-321 disk drives. So far I managed
to get my disks back by prying the lock upwards (or was it downwards?)
with my fingers (not very pleasant work). Everytime I plan to fix the
drive by replacing the gunked grease, but so far it didn't happen.
Greetings & success,
Fred Jan
and not playing Traveller?
------------------------------
On Wed, Oct 24, 2012 7:37 PM PDT Zane H. Healy wrote:
>At 5:44 PM -0400 10/24/12, Sridhar Ayengar wrote:
>>Zane H. Healy wrote:
>>I've always preferred the following. The key part is how I end line 10
>>with the spaces and the semicolon.
>>
>>10 PRINT "HELLO, WORLD ";
>>20 GOTO 10
>>
>>The first program I ever wrote in BASIC was (drumroll, please):
>>
>>10 GOTO 10
>>
>>Peace... Sridhar
>
>LOL! Well I guess it has the advantage of being 'bug free'. :-) I
>find myself tempted to turn on my Commodore 64 and try it.
>
>BTW, I'm quite happy to report that as part of the project to redo my
>darkroom, I've set my Commodore 64 back up (yes, in the darkroom
>area). In fact part of the time I was supposed to be working on the
>Darkroom last Saturday I was actually playing a game on the C64. :-)
>
>Zane
>
>
>
>--
>| Zane H. Healy | UNIX Systems Administrator |
>| healyzh at aracnet.com | OpenVMS Enthusiast |
>| | Photographer |
>+----------------------------------+----------------------------+
>| My flickr Photostream |
>| http://www.flickr.com/photos/33848088 at N03/ |
>| My Photography Website |
>| http://www.zanesphotography.com |
>
Hey all,
Since I'm stuck in a hotel for the IEEE LCN conference, I had
nothing better to do than look up lots and lots of datasheets in
search for an ideal driver/receiver pair for modern DEC bus
circuits.
Warning: below is a lengthy missive. Ignore it if the subject
line doesn't turn you on (so to speak).
The driver is generally the easy part; there are quite a few FETs
out there that ought to do the job acceptably. You need a total
(driver + receiver) capacitance of 9.35 pf, which is generally
the tallest order, but it's easy enough to limit the slew rate of
the pulldown by putting a series resistor in line with the gate.
I believe Peter Wallace recommended the FDV301N, which seems as
good as any; put one for the driver and one at the source as a
gate for a group of them, and you should have a pretty effective
transceiver. It might take a bit of space, and you'll eat a lot
in assembly if you're not doing it yourself, but as Dave McGuire
pointed out, if your main logic is contained in a micro and/or
CPLD/FPGA, you're going to have plenty of space. And for SOT-23
packages, you can probably get close enough to the density of the
original (quad-gate) DIP devices. The FDV301N claims a Coss of
6 pf, though I haven't done my homework to think about how the
other parasitics affect the input capacitance.
The receiver is a little harder. In the National (now re-branded
by TI, which is hilarious considering the part was obsolete and
long out of production by the time TI acquired them) app note on
the DS3662, they indicate that they essentially just did the
obvious thing and used a comparator for the input. Doing so with
discrete comparators is possible, but generally costly in terms
of both money and board space, and I've found parametric searches
of comparators to be a bit tricky, depending on where you look.
At least looking through what Digi-Key offers (and they're pretty
much the best parametric search I know), there are few quad units
fast enough which don't break the bank.
The MAX9108 is a good candidate, though (quad gate for $4, or $2
in quantity 100, which you'd certainly be looking at for more
than one or two units). It's a TSSOP-14 package, which isn't
exactly tiny, but it's smaller than a DIP in most respects. It
has a dual-element cousin, the MAX9107, which comes in a SOT23-8
package; I believe you could achieve higher density that way,
though you'd end up spending more per gate. The input bias
current is in the sub-uA range, but there's no input capacitance
listed, which bothers me a bit. The outputs are TTL-compatible,
which is generally compatible with 3.3v logic as well; it has a
typical Voh of slightly more than 3.3v, but at 100uA source
current, which is well within the handling range of the built-
in protection diodes of most FPGAs (and it's close enough that
it probably wouldn't trip them).
Another good candidate is the NE521, which has some very nice
logical gating inputs (which would save some external components
if you're using bidirectional lines on the FPGA side). It's
also a dual part, but unfortunately only available as small as
SOIC-14, which doesn't provide for a lot of density (it is
available in DIP, though, which should make some people happy).
Its propagation delay is 12 ns instead of the MAX910x's 25,
though both are still comfortably below the 32 required for DEC
buses. Bias current is a max of 40 uA over temperature range
(DEC max for the receiver unit load is 80 uA). It also does
not provide an input capacitance; I suppose it's common with
comparators? This one is also not as cheap per gate; even in
quantity 100, it's still almost $4 each ($2 per gate), which
probably offsets the convenience of having the enables built
in to the part for most people (especially considering the
larger package size).
In any case, the solution doesn't seem as infeasible as I
previously thought. Anyone want to go in on a few test boards
together to split the costs? It seems like it would be prudent
to make a few short (2 inches, maybe) dual-width boards to test
input and output capacitance/waveforms before we try making
whole boards, and if someone has a UNIBUS machine they're
willing (and able) to test out on, that would be handy since I
definitely do not. Also, are there major flaws in the above
analysis? Am I totally smoking crack?
The app note I referenced is here:
http://www.ti.com/lit/an/snla139/snla139.pdf
There's another interesting related one here:
http://www.ti.com/lit/an/snla134/snla134.pdf
- Dave
I'm a newbie here so I apologize in advance if I am not doing this
right! Anyways, I am a collector of vintage soundcards and I'm looking
for a Creative Sound Blaster CT1320A or CT1320C as well as a Roland
LAPC-I ISA sound card. Thanks!!
Steve
On 10/25/2012 2:30 AM, cctalk-request at classiccmp.org wrote:
> Send cctalk mailing list submissions to
> cctalk at classiccmp.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.classiccmp.org/mailman/listinfo/cctalk
> or, via email, send a message with subject or body 'help' to
> cctalk-request at classiccmp.org
>
> You can reach the person managing the list at
> cctalk-owner at classiccmp.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cctalk digest..."
>
>
> Today's Topics:
>
> 1. Re: Blue screen of Basic (Zane H. Healy)
> 2. Re: VMS newbie with sick VAXstation (mc68010)
> 3. Re: Superbrain schematics (Anthony Wallach)
> 4. Re: pdp 14/30 chassis on ebay (Jochen Kunz)
> 5. Re: Another Apple 1 for sale? (barythrin at gmail.com)
> 6. Re: Blue screen of Basic (Sridhar Ayengar)
> 7. Re: Surplus DE9F to 8P8C adapters available (Philip Pemberton)
> 8. Re: PERQ monitor problem (was HP 9845 power supply
> diagnostics) (Tony Duell)
> 9. Re: Blue screen of Basic (Chris Tofu)
> 10. Re: Surplus DE9F to 8P8C adapters available (Pete Turnbull)
> 11. Re: Surplus DE9F to 8P8C adapters available (Tothwolf)
> 12. Re: Blue screen of Basic (Francois Dion)
> 13. Re: Blue screen of Basic (Zane H. Healy)
> 14. QBUS/UNIBUS transceivers (again) (David Riley)
> 15. Re: Blue screen of Basic (Chris Tofu)
> 16. Re: QBUS/UNIBUS transceivers (again) (Dave McGuire)
> 17. Re: QBUS/UNIBUS transceivers (again) (Guy Sotomayor)
> 18. Re: QBUS/UNIBUS transceivers (again) (Dave McGuire)
> 19. Re: Another Apple 1 for sale? (mc68010)
> 20. Microvax II won't boot, hardware error? (Kevin Reynolds)
> 21. Re: This is a VT180 right ? (Dave McGuire)
> 22. Re: Surplus DE9F to 8P8C adapters available (Pete Turnbull)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 24 Oct 2012 10:35:09 -0700
> From: "Zane H. Healy" <healyzh at aracnet.com>
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Subject: Re: Blue screen of Basic
> Message-ID: <p0624081accadd679caef(a)[192.168.1.199]>
> Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
>
> I've always preferred the following. The key
> part is how I end line 10 with the spaces and the
> semicolon.
>
> 10 PRINT "HELLO, WORLD ";
> 20 GOTO 10
>
> Zane
>
>
>
> At 10:56 AM -0400 10/24/12, Francois Dion wrote:
>> On the last guessing thread (it lives! about the
>> CES apple clone), William said:
>> "Make it PRINT "HELLO" and then GOTO 10 for me
>> one more time, won't you please?"
>>
>> And the C64 fans were also left in want, so I present to you the Blue
>> Screen Of Basic:
>>
>> http://raspberry-python.blogspot.com/2012/10/blue-screen-of-basic.html
>>
>> I'm sure quite a few people already know what it is... The follow up
>> post wont be a clue but simply a detailed post on this modern retro
>> computer.
>>
>>
>> Fran?ois
>>
>> --
>> solarisdesktop.blogspot.com - raspberry-python.blogspot.com
>
In case you missed it on one of the web postings I would like to mention
that Andrew Lynch and I have just completed a prototype of a new 80386
Master/Slave CPU S-100 bus board. This exciting board is capable of reaching
up to12MHz in an S-100 system with an active terminated bus.
This is an ongoing project. It utilizes the 16 bit mode of the 80386 to
address the 16MG of RAM the S-100 bus is capable of addressing. A second
daughter board system with an overhead ribbon cable connector is planned to
for daughter board(s) to enlarge the RAM space up to the 4GB the CPU is
capable of addressing (using high density static and DRAM chips).
If you would like to read about this board please look here:-
http://s100computers.com/My%20System%20Pages/80386%20Board/80386%20CPU%20Boa
rd.htm
It is too early to accept "orders" for this board, but if you would like to
be kept in the loop as this board evolves keep an eye on the above page.
John Monahan Ph.D
e-mail: <mailto:monahan at vitasoft.org> monahan at vitasoft.org
Text: <mailto:monahan at txt.att.net> monahan at txt.att.net