Data General microNOVA

Data General microNOVA

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

Official Documentation

Bitsavers

• 1976 Technical Reference - microNOVA COMPUTER SYSTEMS
• 1977 Technical Reference - microNOVA COMPUTER SYSTEMS
• 1976 Technical Reference - microNOVA INTEGRATED CIRCUITS
• 1977 microNOVA INTEGRATED CIRCUITS DATA MANUAL FOR DESIGN ENGINEERS
• 1976 Users Manual - PROGRAMMERS REFERENCE - microNOVACOMPUTERS

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	Top Bottom Top Backlit Bottom Backlit
5	107 000759 01	Memory
4	107 000759 01	Memory
3	107 000624 01	Memory
2	107 000624 01	Memory	Top Bottom Top Backlit Bottom Backlit
1	107 000533 03	CPU	Top Bottom Top Backlit Bottom Backlit

Card Views

CPU

Expand

Frontlit	Backlit
Left Full Image Right Full Image	Left Full Image Right Full Image

MEM

Expand

Frontlit	Backlit
Left Full Image Right Full Image	Left Full Image Right Full Image

Async

Expand

Frontlit	Backlit
Left Full Image Right Full Image	Left Full Image Right Full Image

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
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: There is a memory issue with one of the four RAM cards that is preventing the system from operating correctly The previously extremely dirty backplane needs more cleaning to have consistent contact 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 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. 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. 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.
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	Image 8 Inch Boot Disk
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.	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. Greaseweazle: Has some initial hard sector support after this commit: https://github.com/keirf/greaseweazle/commit/4d5a8c8543c7a0cdceac2e2b227f4c416cc7f6c1 Kryoflux: Can read disks potentially, but will not write them: https://www.kryoflux.com/download/kryoflux_manual.pdf 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.
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.
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.