Data General Nova 1200

[Qbus]

Mysterious additional pages, never made any sense to me.

 

[pbirkel@gmail.com]

Thank you Qbus. Original document including instructions and source:

http://www.bitsavers.org/pdf/dg/software/utility/093-000038-00_Debug_I.pdf

 

[Qbus]

Wow, that's way better then my copy! Now if i can only find a copy of Basic for the system. Do not care if its a print of the code being if it were five hundred lines I would still toggle it in. do have a paper tape punch and have to look into finding a way of pushing a batch file thru the com port to have the printer print a tape, know how to read tapes all day long or how to copy tapes but having the ability to compile code into a batch file and push it to the punch is still eluding me.
Remember, I do power systems, drives and racks, not software.

 

[CommodoreZ]

Thank you for providing those scans, Qbus.

Original document including instructions and source:

http://www.bitsavers.org/pdf/dg/software/utility/093-000038-00_Debug_I.pdf

Excellent. I've been compiling a list of programs, resources, and various links to the Nova community at large here: https://www.commodorez.com/novarsc.html




The latest development in my 1200 debug progress has been the fixing of the fault on the front panel. We don't seem to have schematics of a Nova 1200 front panel, the best we've got is a Nixdorf DSS 620, a clone that's close enough to reference when debugging. Initially, unresponsive AC3 Examine, Deposit, and Examine pointed towards U1 and U2 having been damaged by the power fault I had previously uh... encountered. After replacing them, with no operational change noted, this pointed towards the Console Request (/CON RQ) signal itself, which tells the CPU that the front panel has a message for it. The large signal line running across the top gets pulled about a volt lower whenever a momentary switch is pressed, which is then converted into a proper logic level low by the transistor and inverters. However, watching the voltage when AC3 EX, DEP, or EX were pressed, the voltage didn't go low enough to trigger the rest of the logic.

I measured the 5V source at the front panel, and found that it had drooped down to 4.84V or thereabouts. I tweaked the output at the supply to compensate for the droop, and suddenly CON RQ began to respond every time it should. Some of the resistors in that section of the front panel have drifted just enough to be a concern, replacements are on order right now. Either way, the switches that had been acting flaky are now consistently operating, and the power supply voltage isn't too crazy. Remember, the nominal suggested voltages from the factory is closer to 5.25V, and I'm not thrilled about boosting the power supply that high.

Anyway, since then I've been testing out various diagnostic programs. Checkerboard III and IV in particular are of interest, but I'm finding the instruction manuals to be rather vague about what to expect from a working vs. malfunctioning system. I've also yet to get the Nova 1200 Logic Test diagnostic to run in such a way to indicate that it's even trying to run.

At one point, I tried loading the Binary Loader routine over serial, as I had done so many times, and it was encountering errors that prevented the program from successfully loading. Erratic terminal response, failure to halt the Bootstrap Loader routine, that sort of thing. On a whim, I pulled out one of my two core memory boards, and tried again, and magically it worked that time. It's been an essential way of loading up these diagnostic routines, so when that starts failing unexpectedly, it's quite discouraging.

I've also tried loading up BASIC, and it never makes it past the first user response to the initial configuration prompt. Halts the CPU solid.

So, here's what I'm looking for right now:
Nova 1200 Logic Test diagnostic manual
Nova 1200 Technical Manual which will include the first-time startup procedures in order. Thus far, I've been working off of a mix of the 1220 and 800 tech manuals, but they're not precisely tuned for a straight 1200.

I'm also curious what nominal, expected operation of Checkerboard III, IV, and Logic Tests is supposed to look like from someone who has had experience running these pieces of software.

 

[thunter0512]

Thank you Qbus. Original document including instructions and source:

http://www.bitsavers.org/pdf/dg/software/utility/093-000038-00_Debug_I.pdf

Thank you Qbus for discovering and publicizing this debugger in the first place.

Thank you Paul for pointing us to the nice and readable manual with program listing. It may even be convertible to text via OCR.

I am not a fan of toggling in more than say twenty 16 bit values because I am guaranteed to make mistakes.
I have upgraded my Nova 2 with the "Program Load" feature, so I prefer to type in the source code from a listing once and then assemble once and load with the Binary Loader forever, rather than toggle in 16 bit octal values over and over. But maybe that is just me being weird.

Tom

 

[thunter0512]

While we are finding interesting things for the Nova, has anybody come across a working chess program for the Nova 2 or Nova 1200?

Even the "lowly" PDP-8 has Checkmo II which is surprising good. The more capable Nova is bound to have a decent chess program.

Tom

 

[dustyzebra]

So by the time I found out about this, a lot of the stuff had been parted out and some of it scrapped. Apparently the original owners had been trying to work with several hobbyists and amateur radio operators for like, two years or something, and had gotten a lot of "definitely interested, will be by to pay and pick up" type of replies that resulted in no action, and had gotten tired of it.

Most of the DG and Computer Automation stuff was connected to typesetting machines, there were two Kurzweil OCR systems but they were the later integrated packages, not the big early boxes with a full-fledged Nova attached. The Kurzweil stuff may have an OEMed Nova or Nova-compatible board in it, too. I believe they'd told me the Fairchild 2300 (TRW 130, AN/UYK-1...originally a 1950s nuclear sub satellite nav computer) was also hooked up to a typesetter.

We ended up making a second trip up to pick up some other large things that weren't really shippable -- the remains of at least a dozen Kaypros, the guts out of two Linotron 202s that had gotten scrapped, misc. cables and other bits that had been found since the original pick-up, and a box of board scrap that had come from some of the equipment.

I suspect CommodoreZ's Nova 1200 was indeed connected to that Teletype at one point, though the Teletype may have shared service between several computers, such as the Fairchild 2300, which also has current loop output. Don't know what the Nova 1200 in particular was doing, though.

Here's some pictures of the stuff, unloaded in the new building (not everything is from the same lot, in the second picture):





It pretty well filled the back of the 24-foot Mack box truck:



There was a bunch of Sun stuff too, which was one of the big reasons I was interested in the stuff (still support it for my day-job). TangentDelta has been working on a lot of the Computer Automation Naked Mini stuff.

Nice collection!

 

[Qbus]

Maybe it’s a form of brain damage or something else, don’t know but I am drawn to that AN/UYK-1 system. I collect old military radios, teletype and computers and that has to be the oldest system I have seen outside of a museum and would be a great project to get up and running. Am assuming that the TRW had a lot of architecture in common with the Nova being 16 bit and four accumulators but that’s just a guess.

In the last couple years have been running teletype using vintage military equipment on forty meters, 7.087 MHz, 850 Hz shift 45.5 baud at 9:00 AM EST on Saturdays, there is a small group of us all running hardware that’s all over forty or fifty years old , lot of model 28 machines and the like. Been thinking of building up a message buffer for transmitting stored messages using the Rolm 1602 military Nova but that AN/UYK would be way more of a challenge!

 

[Chuck(G)]

Baudot code, right?

 

[Qbus]

Yes, five bit uppercase only! have a YouTube video of the net at:

 

[Chuck(G)]

I used to have a Model 14 and lots of reels of the message tape. LTRS and FIGS.

 

[pbirkel@gmail.com]

Thank you Qbus for discovering and publicizing this debugger in the first place.

Thank you Paul for pointing us to the nice and readable manual with program listing. It may even be convertible to text via OCR.

I am not a fan of toggling in more than say twenty 16 bit values because I am guaranteed to make mistakes.
I have upgraded my Nova 2 with the "Program Load" feature, so I prefer to type in the source code from a listing once and then assemble once and load with the Binary Loader forever, rather than toggle in 16 bit octal values over and over. But maybe that is just me being weird.

Tom

Have you pursued the OCR conversion?

 

[thunter0512]

Have you pursued the OCR conversion?

I did, but the OCR conversion quality was very poor. I used ABBYY FineReader 14 for the conversion attempt.
I think it will be easier to just type in the source code from scratch, assemble it and manually compare the assembly listing with the PDF.
Fixing up the OCR conversion is more work than typing in the original. Here is the first page as text:

007300 .LOC 7300
07300014555 A: DSZ BPSWT ;START HERE
07301 040406 STA 0,ACS JSAVE ACS
O/^oo 004466 STA 1 ,ACS+1
O73C3 050466 STA 2,ACS+2
07304 054466 STA 3,ACS+3
07305 020470 LDA 0# INST J5ETOP FREAK INSTRUCTION
07306 040470 STA 0,PIN5I
07307 020465 LDA O,BADDR 1SET PROOFED ADDRESS DO
07310 C40550 STA O,PADDR .BREAK FAY BE CHANGED.
7311 158660 5UBCR 2,2 .SAVE CARRY
07312 fr?577 SKPEZ CPU JftBYEYBER STATE OF
07313 151400 INC 2,2 ‘INTERRUPT FLOP.
07314 060277 C77l NIOC CPU .TURN OF INTERRUPT-
07315 050456 STA 2,AC5+4 JCARRY SAVE
7316 06351 1 SKPBZ TTO IRF.MBER THE STATE OF
07317 000777 JHR .-1 JTTO DONE FLAG.
07380 063711 SKPDZ TTO
07381 158000 ADC 2,2
07322 050540 STA 2,TFLAG
07323 024451 LDA 1,BADDR MP ENTERED VIA
07324 010531 1ST BFSWT JBREAK POINT TYPE THE
07325004502 AAAI JSR POCT JBREAK POINT ADDRESS.
07386 020537 LDA 0,C15
07327 004521 JSR TYPE IECHO CARRIAGE RETURN.
07330 020534 AAl LDA 0,02 JTYPE LINE FEED
O7J31 004517 JSR TYPE
07332 040531 STA O,OPEN .REGISTER OPEN/CLOSE
07333 152400 SUB 2,2
07334 050521 STA 2,BPSWT .BREAK POINT SWITCH.
07335 050524 STA 2,DIN JDATA TYPED SWITCH
07336 063610 SKPDN TTI
07337 000777 JYP .-I
07340 060610 DI AC O,TTI MNPU! A CHAR
07341 00450? BBs JSR TYPE J ECHO
07342 034575 LDA 3,0 77
07343 163^00 AND 3,0 INASKPARITY
07344 034513 LDA 3>C7O ICHECR FOR A DIGIT
07345 116032 ADCZ# 0,3,SZC
07346 034525 LDA 3,CF60
07347 117046 ADDO 0,3, SEP
07350 004410 JSR SERH INOT ADIGIT 0-7
07351 010510 CCl 1ST DIN ’ DIGIT SWITCH
07352 15H20 KOVEL 2,2 JASSE^BLE DIGITS
07353 153120 AODZL 2,2
07354 173003 ADD 3,2,SNC ISKIP IF EXTRA DIGIT.
07355 000761 JW BB-3
07356 02073*6 GOOFi LDA 0,C77 I OPERATOR ERROR.
0735? 000750 JMP Aft*1

 

[pbirkel@gmail.com]

Sigh. IMO this tends to be a two-person job -- one to read/decipher and one to format/enter corresponding text into a file. It seems to me that with all of this highfalutin tech we have these days that a workable solution would be:

1. A "syntax aware" speech-to-text capability that can handle "space", "tab" and "newline" words as text-format commands and otherwise expects single digits or characters. It would be used to transcribe the running interpretation of the source reader.

2. A corresponding text-to-speech capability that can read back the file while interpreting the three allowable "positioning" possibilities into the corresponding phrases. It would be used to proof-check the file against the source.

The resulting capability would enable a maximally efficient one-person job, at least for those of us who don't accurately and efficiently touch-type.

Is anyone doing this?

 

[CommodoreZ]

Like a zombie, this thread lives. I got rather demoralized by the project, with what felt like constant steps forward, and then backward immediately after. I would think that my front panel was working, and then the next time I used it, it would fail again. I'd run a serial test that would work, only for it to fail mid-test, or the next time I ran it. It was discouraging. However, recently, between Tech Tangents working on his microNOVA, Usagi Electric working on his Nova 1210, and Forgotten Machines making progress on creating dedicated debugging test jigs for Nova parts, I felt encouraged to dig back into the process.

First things first, I took the cards out of their sockets, and gave them a cleaning and a fresh set of deoxit (as the massive DG boards are difficult to socket without some sort of lubricant). When it came to actual technical debugging work, I wasn't sure precisely where to start with the process over again as it had been so long.



Tests of the front panel showed it would work sometimes, and fail other times. Digging into the logic, the /CONRQ line was not triggering sometimes, as the voltage threshold on the analog OR gate was insufficient. It took some time to determine that the 5V rail drooping too low for the logic to work right. I cleaned the card-edge connectors on the PSU and resistor board again to ensure there wasn't any voltage drop from dirty contacts. Then I boosted the voltage on the Meanwell PSU, but this comes with a consequence: if 5V goes up, so do the 12V and -5V rails. I was able to find a suitable adjustment where 5V was nominal at the front panel and on the CPU logic board's far edges, but the 12V rail climbed to 13.5V -- yikes! Now, no regular Nova PSU has 12V, but mine does as it's being used to feed the VLAMP bus and the chassis fans. The VLAMP rail on a Nova can be anywhere between 11V and 17V depending on the system (though 13-15V is pretty common). The bulbs will tolerate plenty of voltages, and I prefer to under-volt mine for the sake of longevity. However, the 12V fans won't like 13.5V, and will likely cook themselves to death before too long. I added in a pair of large diodes to drop the voltage to just under 12V for just the fans. That fixed the front panel logic's inconsistencies.

The next problems were found in basic serial tests, printing all ASCII characters or echoing characters from the terminal. I found failed chips on both the Cassette I/O board and the CPU board, specifically ones that handled the /DS5 signal having incorrect levels when signalling between the boards. With that, simple serial tests seem to work fine again.

Then the big problem, which took alot of work to diagnose and fix...
I tried running the 095-000036-01__Nova_1200_Logic_Test__1970-1974.ab diagnostic tape, and was getting very confusing responses from it. I figured it was supposed to tell me over serial what was wrong, but it wasn't giving me anything. It was getting stuck in one of a few places, mostly related to it trying and failing to report errors via serial. The trick was to single-step through the program until we hit a test that didn't pass: the auto-incrementing addresses.


On a Nova, addresses 00020 thru 00027 auto-increment values when accessed. Meanwhile, addresses 00030 thru 00037 auto-decrement values when accessed. These functions worked, but unfortunately they were being activated on addresses 00120 thru 00137 which is not right at all. It took days of tests, writing custom tests derived from the Logic Test diagnostics mentioned above, and lots of oscilloscope captures before it was finally found. Within the circuitry that handles the auto-inc/dec flag, the N8859A quad-input NAND gate that is part of the address decode logic was ignoring the /MBO13 and /MBO14 signals. That part has been replaced with a 74LS20 (despite technically requiring a 7440, Fairchild 9009, or the aforementioned Signetics part, which has no datasheet) -- it's fine, the LS part has enough fanout for the other circuit it's wired into. So, that problem finally got solved, but it was a pain to nail down why it was happening because it's only using a single 4-input NAND gate to decode a 16-bit value for a 15-bit address. DG pulled this off by cycling through one nibble of the instruction at a time, synced with the four Processor Time Groups (PTGs).


Anyway, that took alot to figure out, and it still doesn't work completely yet, but that's like 3 to 5 problems fixed in the span of a week, so I'd say that's pretty good progress. I'd call that a fruitful week!

What's next is a mix of single stepping that Logic Test more, and making sure it passes all CPU operations, followed by digging into the Cassette I/O board.

 

[CommodoreZ]

Good news! Without a Cassette I/O board installed, the CPU now passes the Nova 1200 Logic Test diagnostic routine!

The bad news: when the Cassette I/O board is installed, it fails on test C53:

Right now I'm running down the logic that drives /INTR line for the serial interface on the Cassette I/O board to signal to the CPU. Seems like it's stuck triggering all the time and should not be, which is no bueno.

But hey, progress.

 

[CommodoreZ]

The fault was initially traced back to the interrupt generator circuitry on the Cassette I/O board, but my hypothesis is that it's not being set or disabled properly by the CPU. I/O devices' ability to trigger an interrupt is generated by a circuit matching the following from the "How To Use The Nova Computers" manual.


I don't even think that interrupt disable signal is ever reaching the Cassette I/O board, and sure enough, pin 11 was not changing to follow 12 and 13. Thus the /MSKO signal wasn't being generated properly on the CPU board. The chip in question is not a flavor of 7402. but rather a Signetics N8885A which is not pin compatible. The first input pin and the output pin are switched for each gate, and I don't keep many spare Signetics parts on hand.



So a temporary replacement for the N8885A was fashioned with a chip carrier, a 74LS02, and some wires (which sadly hasn't fixed the issue).



For some reason ever since this temporary chip replacement tower was constructed, the /DATOB signal isn't being generated, so I can't even see it the effects of /MSKO possibly being fixed.

The process continues.

 

[CommodoreZ]

Testing continued, ended up chasing down the rabbit of where that interrupt was coming from on the Cassette I/O board. /INTR jumped around a few times, though I'm convinced that might have been from me getting mixed up on gates as I was working. The Clock Interrupt was the one in particular that wouldn't go away. Note the cyan and magenta signals coming out of U117 CLK DONE. They should be mirrored perfectly and they aren't. I also noted that pin 3 never changed, and yet, even with that /CLK BUSY signal at a 1 all the time, CLK DONE was always set. You would think that the /RESET pulse (yellow trace, pin 4) would clear it and keep it cleared, but it kept setting again at the conclusion of that pulse.



So, a bit of desoldering later, and U117 is out, and replaced with a new LS series part. Since there is no pull-up or driving logic on pin 1 (one of the /PRESET lines), I added in a pull-up resistor. Original 7474's don't need those, hence why DG doesn't have one.


Sure enough, the original is dead, and fails testing, where other non-LS 7474's pass.



New logic chip installed, and I run the 1200 Logic Test diagnostic again, which passes. In fact, it passes over 8000 times (it keeps count in address 00121)



So, let's go for the big kahuna and try running Single User BASIC again. It's been failing for a long time, always after the prompt that checks the comma width preference.

As you can imagine I was surprised and delighted to see the fantastic response of a working prompt after entering Y. Gave it a BASIC program and... it runs! IT RUNS!



I want to express my thanks to Usagi Electric for his assistance in the debugging process. It's nice to have the machine operational again.

I've installed a second 8K core plane, bringing me to a working 16K total so far. Next steps involve diagnosing my other two 8K core planes, followed by testing my quad multiplexer.

 

[Steve Toner]

Since there is no pull-up or driving logic on pin 1 (one of the /PRESET lines), I added in a pull-up resistor. Original 7474's don't need those, hence why DG doesn't have one.

Although pullups are always a good idea and required for with CMOS inputs, I don't think they are necessary with 74LS logic.

From the TTL Data Book:

you can see that pulling up the PRESET (or CLEAR) input merely reverse-biases the input diodes. There is nowhere for current to flow unless the input is at least a diode drop below the voltage that those base/collector junctions are floating at. The pullup improves noise immunity. So I wonder if DG did not include a pullup because (as stated) it wasn't necessary (engineering decision), or because they really were that cheap (bean counter decision).

We now return you to your regularly scheduled program.

 

[CommodoreZ]

The Nova 1200 made it less than week before it broke again.

The good news is that serial echo routines and ASCII loop routines work okay. However, something failed so badly that I can't even get the bootstrap program to correctly pull in a the binary loader to bring in the full Nova 1200 Logic Test diagnostic tape. Great.

My approach for the moment (beyond checking the basics) has been to hand-toggle the instructions for the aforementioned diagnostic routine by hand. Ideal? Not in the slightest, but so far it's shown me some avenues to explore. The first was test A20:

The second is test A11:


ION circuitry seemed okay at first glance, I'm not seeing that flipflop set, which is good. Right now the initial suspect is U11, so that's going to be replaced soon since it doesn't appear to be flopping right.