Data General microNOVA: Difference between revisions

From Tech Tangents
Jump to navigation Jump to search
No edit summary
No edit summary
Line 291: Line 291:
File:MicroNOVA CPUDebug CS Probes.jpg|Probe points for CS signal origin
File:MicroNOVA CPUDebug CS Probes.jpg|Probe points for CS signal origin
File:MicroNOVA CPUDebug CS PATH.jpg|Probe point readings
File:MicroNOVA CPUDebug CS PATH.jpg|Probe point readings
</gallery>The signal was lost in U20.
</gallery>The signal was lost in U20. After further investigation it was also determined that the chip was behaving incorrectly in other ways as well. The direction pins may not have been responding correctly.
 
A replacement mN634 for U20 was sourced from an unrelated microNOVA RAM board I was able to purchase on ebay before I had started the refurb. Once replaced the CPU board read and wrote to RAM correctly and the machine was fully functional!
|-
|-
! colspan="2" |
! colspan="2" |
Line 306: Line 308:
|-
|-
!
!
=== Refurb Dual 8 Inch Floppy Drive ===
=== Refurb Dual 8 Inch Floppy Drive - DONE ===
!
!
=== Image 8 Inch Boot Disk ===
=== Image 8 Inch Boot Disk - DONE ===
|-
|-
|There is a 6030(?) dual floppy drive unit in the rack. The drive has a monolith PCB that controls both floppy drive mechanisms. The data channel for the drive goes into the chassis and connects to the main board.  
|There is a 6030(?) dual floppy drive unit in the rack. The drive has a monolith PCB that controls both floppy drive mechanisms. The data channel for the drive goes into the chassis and connects to the main board.  
Line 318: Line 320:
* Determine original drive mechanism.
* Determine original drive mechanism.
* Determine the drive's ID for loading with the `L` command in the Debug Console.
* Determine the drive's ID for loading with the `L` command in the Debug Console.
'''DONE:'''
The reform process went smoothly, no shorts were found on the logic board though the total resistance of the logic was lower than I was happy with. The original drive mechs were not inspected due to the requirement of removing the MASSIVE logic board. The drive ID is set via jumpers on the top of the board. The device code is <code>33</code>(octal) for booting from the drives.
NOTE:
The write protect sensor light does not seem to play well with the blocking sticker on the disks I have. I needed to put EMI tape over the notch to fully block light before I could write to it.
|I have one single floppy disk that is labeled "BOOT". Whether it truly is software or not has yet to be determined. The disk needs to be preserved still but this is made difficult by the disk being hard sectored.
|I have one single floppy disk that is labeled "BOOT". Whether it truly is software or not has yet to be determined. The disk needs to be preserved still but this is made difficult by the disk being hard sectored.
I need to find a method for imaging and writing hard sectored disks. I have other non-software hard sectored disks for the microNova that I can test with. I currently have a Kryoflux and Greaseweazle for attempting this. It is also possible that the data encoding scheme of the disks is unknown and a flux image is all that can be done.
I need to find a method for imaging and writing hard sectored disks. I have other non-software hard sectored disks for the microNova that I can test with. I currently have a Kryoflux and Greaseweazle for attempting this. It is also possible that the data encoding scheme of the disks is unknown and a flux image is all that can be done.
Line 326: Line 338:


I have no intention of ''ever'' putting my only original boot disk in the original drive again. There is no way to know what the original drive will do to the disk and if there are low level issues it could potentially erase data. For the sake of ensuring that disks data is never lost I want to duplicate the disk and then use the copy to boot from.
I have no intention of ''ever'' putting my only original boot disk in the original drive again. There is no way to know what the original drive will do to the disk and if there are low level issues it could potentially erase data. For the sake of ensuring that disks data is never lost I want to duplicate the disk and then use the copy to boot from.
'''DONE:'''
The greaseweazle implementation of hard sectors was more advanced than I had found previously and it was able to read and write the hard sectored disks. It cannot decode them though, the encoding scheme for the disks is unlike any other format I can find. But I was still able to duplicate the disk.
|-
|-
! colspan="2" |
! colspan="2" |
Line 334: Line 351:
A bootstrap program for running from the disk will likely be required. The programming manual has such a bootstrap program provided but it may not be suitable for this configuration.
A bootstrap program for running from the disk will likely be required. The programming manual has such a bootstrap program provided but it may not be suitable for this configuration.
Once the machine is booting and running an OS it should be possible for it to act as a gateway to the Nova 4/X for furthering that project.
Once the machine is booting and running an OS it should be possible for it to act as a gateway to the Nova 4/X for furthering that project.
'''2025-03-2:'''
A copy of my one "BOOT" disk was booted on the machine. It seems to most closely resemble DG DOS but is not a complete system. It may just be a utility for either bootstrapping to the HDD or initializing new disks. More research needs to be done outside of what I have by reading the new docs made available by NovasAreForever to determine how to use the system.
|-
|-
! colspan="2" |
! colspan="2" |

Revision as of 01:58, 3 March 2025

Data General microNOVA
General Info
Manufacturer Data General
Condition Working
QR Code
(Click for Asset Tag)


Official Documentation

Bitsavers

Power

Power Connector: https://www.mouser.com/ProductDetail/538-50-84-1120

Fuses
Current Rating Diameter Length
120 VAC 5A 6.3mm 32mm
240 VAC 3A 6.3mm 32mm

Cards

Slot # Card Number Card Type Card Photos
9
8
7 107 000648 03 Serial
6 107 000648 06 Serial
5 107 000759 01 Memory
4 107 000759 01 Memory
3 107 000624 01 Memory
2 107 000624 01 Memory
1 107 000533 03 CPU

Card Views

CPU (Slot 1)

Frontlit Backlit

MEM (Slot 2)

Frontlit Backlit

MEM (Slot 3)

Frontlit Backlit

Memory (Slot 4)

Frontlit Backlit

Memory (Slot 5)

Frontlit Backlit

Async and Console (Slot 6)

Frontlit Backlit

Async (Slot 7)

Frontlit Backlit

CPU Card Jumpers


Addressable Locations

Note: This is a 4-bit bitslice machine that uses octal notation, not hex. Digit values range from 0 to 7.

Internal CPU Cells (Not in Memory Map)
Address (Octal) Description
0 Accumulator 0
1 Accumulator 1
2 Accumulator 2
3 Accumulator 3
4 The program counter of the interrupted program.
5 Stack Pointer
6 Frame Pointer
7 CPU and console controller (TTO) status where:

Bits 0-12 are reserved for future use.

Bit 13 is status of the carry bit when the console debug option received control.

Bit 14 is status of Interrupt On flag when the console debug option received control

Bit 15 is status of TTO Done flag when the console debug option received control

10 Address of a location in the first 256 words of main memory that can be used by the console debug option for breakpoint transfers.
11 Address of the most recent breakpoint
12 User instruction at the address of the most recent breakpoint
17 Contents of memory location 0775778
Memory Locations
Address (Octal) Description
2-36 30 word bootstrap loader storage
100 Programmed I/O bootstrap loader start location
377 NIOS instruction loop location for booting from data channel device
077400-077777 The console debug option consists of a program contained in 256 locations of read-only memory (ROM) that respond to addresses 077400-077777

Project Roadmap

In order to fully bring up the machine and ensure everything is running correctly I need to go through certain procedures on each component.

Memory Write Access & Startup Inconsistency - DONE

On the first day of attempting to use the MicroNova after bringing up the PSU with Usagi Electric it behaved inconsistently when being fully rebooted and would not always present the Debug Console (Memory Monitor). After some contemplating and manual reading I think there are three avenues to troubleshoot for a potential cause for this:
  1. There is a memory issue with one of the four RAM cards that is preventing the system from operating correctly
  2. The previously extremely dirty backplane needs more cleaning to have consistent contact
  3. The powerfail option I removed the batteries from is behaving oddly on poweroff and some CPU/RAM state may be held by the giant caps
  4. The card bus has differential connectors that need to be terminated. The external drives share the differential signals and are daisy chained, the last drive in the chain has the terminator on it.[1]
  5. It's possible the Debug Console is locked out of modifying RAM because it is waiting to load a program from an external drive? It's getting to the grasping at straws point here.
  6. The RAM was much colder compared to the rest of the logic indicating it is somehow disabled. More investigation needs to be done to figure out why.

Option 3 is the most recent theory based on reading through the manual ( 015-000050-00_microNOVA_Programmers_Reference_197602.pdf ) and reading the description of the powerfail option.

Option 4 didn't solve the issue with termination on the backplane.


DONE

The problem was U20 which is an nm634, after suspecting RAM the chips were probed.The chip select line never changes in the reading when it should be needed. The path for it from the RAM was followed back up to the CPUThe signal was lost in U20. After further investigation it was also determined that the chip was behaving incorrectly in other ways as well. The direction pins may not have been responding correctly.

A replacement mN634 for U20 was sourced from an unrelated microNOVA RAM board I was able to purchase on ebay before I had started the refurb. Once replaced the CPU board read and wrote to RAM correctly and the machine was fully functional!

Serial Interfacing

Software: https://github.com/AkBKukU/DG-ConsoleDebugInterface/blob/main/dg-con.py

I want to be able to use a modern computer for reading and writing serial data from the computer to have a automated method of controlling it. This will make it possible to dump memory contents and load programs from a modern computer. This may become crucial for backing up the data that is on the hard disks in the future and may end up being the easiest way to preserve any data on the floppy disks if imaging them doesn't work out. If I end up writing ASM for the computer before I get the other drives working this will make it possible to "save" and "load" programs later as well. Requirements:

  • Parse data format of memory reads (ex, input "077400/ " output "077400 025464")
  • Read binary data and send it to machine
  • Handle receiving and transmitting files from a CLI on linux

Refurb Dual 8 Inch Floppy Drive - DONE

Image 8 Inch Boot Disk - DONE

There is a 6030(?) dual floppy drive unit in the rack. The drive has a monolith PCB that controls both floppy drive mechanisms. The data channel for the drive goes into the chassis and connects to the main board.

It needs the following steps done:

  • Capacitors reformed
  • Drives manually cleaned
  • Checked for shorts on main power rails
  • Determine original drive mechanism.
  • Determine the drive's ID for loading with the `L` command in the Debug Console.


DONE:

The reform process went smoothly, no shorts were found on the logic board though the total resistance of the logic was lower than I was happy with. The original drive mechs were not inspected due to the requirement of removing the MASSIVE logic board. The drive ID is set via jumpers on the top of the board. The device code is 33(octal) for booting from the drives.


NOTE:

The write protect sensor light does not seem to play well with the blocking sticker on the disks I have. I needed to put EMI tape over the notch to fully block light before I could write to it.

I have one single floppy disk that is labeled "BOOT". Whether it truly is software or not has yet to be determined. The disk needs to be preserved still but this is made difficult by the disk being hard sectored.

I need to find a method for imaging and writing hard sectored disks. I have other non-software hard sectored disks for the microNova that I can test with. I currently have a Kryoflux and Greaseweazle for attempting this. It is also possible that the data encoding scheme of the disks is unknown and a flux image is all that can be done.

I have no intention of ever putting my only original boot disk in the original drive again. There is no way to know what the original drive will do to the disk and if there are low level issues it could potentially erase data. For the sake of ensuring that disks data is never lost I want to duplicate the disk and then use the copy to boot from.


DONE:

The greaseweazle implementation of hard sectors was more advanced than I had found previously and it was able to read and write the hard sectored disks. It cannot decode them though, the encoding scheme for the disks is unlike any other format I can find. But I was still able to duplicate the disk.

Boot Machine

In a perfect world, it may be possible to just pop the floppy in and boot whatever is on it. The condition and contents of the disk are unknown though, it may not work.

It may be needed to learn how to convert the archived 9 track tape formats available from Wild Hare for use on a machine with floppies. It is possible simH could be used to convert them through emulation, or converting binary formats may be possible. A bootstrap program for running from the disk will likely be required. The programming manual has such a bootstrap program provided but it may not be suitable for this configuration. Once the machine is booting and running an OS it should be possible for it to act as a gateway to the Nova 4/X for furthering that project.


2025-03-2:

A copy of my one "BOOT" disk was booted on the machine. It seems to most closely resemble DG DOS but is not a complete system. It may just be a utility for either bootstrapping to the HDD or initializing new disks. More research needs to be done outside of what I have by reading the new docs made available by NovasAreForever to determine how to use the system.

6095 Removable/Fixed Platter Drive

The rack for the microNOVA has a 6095 removable/fixed platter drive with 5MB disks. The drive's contents are unknown. I have three removable platter pack between both of my systems, one is crashed.

The drive is going to need considerable restoration before any attempts to use it can happen:

  • Basic power checks: Caps, shorts, voltage rails
  • Top head removable pack is crashed. A repair will be attempted.
  • Bottom head conditions are unknown
  • All heads should be checked for blown coils
  • The air filter must be removed, inspected, and cleaned as well as possible.
  • Any dust or debris must be removed from the drive.
  • The solenoid interface connector that loads the heads needs to be found to be able to safely spin the drive platters to flush the system before allowing the heads to be loaded.

Refrences