NeXTdimension ROM image

[andreas_g]

Hello all,

I'm looking for an image of the NeXTdimension ROM. Has anyone been able to obtain this from a NeXTdimension board?

Regards,

Andreas

[barcher174]

Hi Andreas,

I'm not sure where the ROM is stored on board. There certainly isn't a ROM chip like on the logic board.  My understanding is that the board requests a stripped down kernel from the main OS at boot from which all configuration is done. I've been meaning to do a recap on mine, so when I do I'll do some digging around if no one gets to it first.

--
Brian

[andreas_g]

Hello Brian,

i'm also not 100% sure where the ROM is located. From what i know it is an EEPROM, so it is re-writeable. I think its location is at address 0xfXf10000 (X = SlotID: 2, 4 or 6). The size is most likely 128 kB.
You might be right about the ROM being supplied by the driver of the main OS. That would be good news. I'll try to find out, if that is really true.

Andreas

[mikeboss]

I'm pretty sure that there's a ROM chip on the NeXTdimension:



I still have a PAL dimension in my NeXT collection. so if there's a simple command to type into the terminal which would extract the content of the ROM I'll try it...

[M Paquette]

There is a ROM on the board, specifically, an EEPROM.  It contains the boot code that runs the board's power-on selftest, the mini-monitor used to boot code loaded over the NeXTbus, and the P-code read by the main CPU's kernel and ROM NeXTbus P-machine interpreter that handles the boot animation, ROM monitor display, and NMI display when the NeXTDimension board is the main display.

NDromcheck will generate a checksum and sanity test of the ROM against it's encoded checksum.  The ND device driver in the kernel driver space does the dirty work.
https://www.dropbox.com/s/nq3mesv7xtilttl/NDromcheck?dl=0

NDromcheck.zip

NDromload will load the ROM image and p-code image to the ND board.  If you have multiple boards, use the -slot argument to specify the slot.  The ROM image is in the program, in the __i860 section, __bootcode segment.  The p-code is in the __i860 section, __pcode segment.
https://www.dropbox.com/s/xj9zjfgo8x4naui/NDromload?dl=0

NDromload.zip

[barcher174]

Someone get this man an FTP!  :lol:

[jroark]

Very cool, modern tools on OSX 10.10.3 parse the Mach-O (mostly, the CPU type doesn't make sense , should be I860, right?)

Code Select Expand


$ otool -s __i860 __bootcode  NDromload | tail -n+3 | xxd -r | tail -c +40961 > bootcode.bin
$  otool -vh bootcode.bin
bootcode.bin:
Mach header
     magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
  MH_MAGIC    I386          1  0x00     PRELOAD     6       1028   NOUNDEFS


[M Paquette]

Very cool, modern tools on OSX 10.10.3 parse the Mach-O (mostly, the CPU type doesn't make sense , should be I860, right?)

Code Select Expand


$ otool -s __i860 __bootcode  NDromload | tail -n+3 | xxd -r | tail -c +40961 > bootcode.bin
$  otool -vh bootcode.bin
bootcode.bin:
Mach header
     magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
  MH_MAGIC    I386          1  0x00     PRELOAD     6       1028   NOUNDEFS


The Mach-O format folks reshuffled the CPUTYPE codes in the mid-90s.  The value NeXT had gotten for the i860 was re-used.

[andreas_g]

Thank you for all the information! Just to make sure i understand this correctly:
If the NeXTdimension board has for some reason no valid ROM, the driver will automatically load a ROM image to the board?

I'm interested in emulating the NeXTdimension as an extension for "Previous".

Unfortunately there is almost no documentation availabe about the NeXTdimension board. That makes it difficult.

[M Paquette]

Thank you for all the information! Just to make sure i understand this correctly:
If the NeXTdimension board has for some reason no valid ROM, the driver will automatically load a ROM image to the board?

I'm interested in emulating the NeXTdimension as an extension for "Previous".

Unfortunately there is almost no documentation availabe about the NeXTdimension board. That makes it difficult.

The ND EEPROM was loaded at the factory.  The kernel does not automatically load a ROM image.  For factory, service, and internal engineering use, the NDromload and NDromcheck programs communicated with real-time EEPROM programming code in the loaded ND device driver to find ND boards, and load or read back the EEPROM content.  The ND device driver just contains the code that understands how to erase or write the EEPROM byte by byte, and read the device back.

The ND board, like other NeXTbus boards, identifies itself with a four byte ID read from the NBIC chip.  The ND device driver and support programs know how to check for the ID code for a NeXTdimension board.  The ID is in the most significant byte of specific slot ID addresses in the slot physical address space for each board.

Caution: Evil code from the Dawn of Time, when ints were ints, and always used an honest 32 bits of space.

Code Select Expand


#define ND_BOARD_ID 0xC0000001
#define ND_id_msb_register(s) ((unsigned int *)(ND_var[(s)].slot_addr + 8))
#define ND_id_byte2_register(s) ((unsigned int *)(ND_var[(s)].slot_addr + 12))
#define ND_id_byte1_register(s) ((unsigned int *)(ND_var[(s)].slot_addr + 16))
#define ND_id_lsb_register(s) ((unsigned int *)(ND_var[(s)].slot_addr + 20))


The stuff loaded into the NeXTdimension board for normal use would be non-trivial to implement.  It would involve emulating the Desplay PostScript back end from the scan-trap layer down, all the Porter-Duff compositing logic, and the entire Quick Renderman implementation from Renderman Interface Binary (RIB) stream handling down to the pixels.

Display PostScript and the NeXTdimension board

   The Display PostScript system can be (very broadly) broken into two pieces, the PostScript interpreter and the device.  The interpreter processes the language, and passes marking, imaging, and (in the NeXT version) compositing directions to the device layer.

   The device layer takes the high level marking, imaging, and compositing operations and (eventually) converts these to bitmap level operations.  The Display PostScript system spends the majority of it's time down here.

   In the case of the NeXTdimension board, the device layer is implemented on the NeXTdimension board.  Marking, imaging, and compositing operations are asynchronously transmitted to the NeXTdimension for processing while additional PostScript is interpreted on the 68K processor.  A good degree of parallelism is achieved in normal operation.  The NXPing() AppKit call is interpreted by the Display PostScript system as a request to synchronize the NeXTdimension, PostScript interpreter, and app, and will not return until PostScript rendering is complete on the NeXTdimension.

Quick Renderman and the NeXTdimension board

   Renderman uses a similar architecture.  The 3DKit and RI C binding reside on the m68k (otherwise you couldn't link with them).  Depending on the setup of the Renderman context, a RIB stream can be spooled to Photorealistic Renderman running on the host CPU (the m68K for black hardware), or to a Quick Renderman implementation loaded on demand into the Window Server.  The Quick Renderman implementation in the Window Server may then, if the target window is on a NeXTdimension, forward the rendering operations to a Quick Renderman context running on the NeXTdimension board.

   The NeXTdimension board performs all rendering operations for windows displayed by the board.  Everything from high level geometry tesselation on down to marking the pixels is done on the NeXTdimension.

[andreas_g]

The ND EEPROM was loaded at the factory.  The kernel does not automatically load a ROM image.  For factory, service, and internal engineering use, the NDromload and NDromcheck programs communicated with real-time EEPROM programming code in the loaded ND device driver to find ND boards, and load or read back the EEPROM content.  The ND device driver just contains the code that understands how to erase or write the EEPROM byte by byte, and read the device back.

Can these programs be used to read the raw content of the ROM to a file? Or is there a different way for reading raw memory contents from the NeXTdimension board?

The ND board, like other NeXTbus boards, identifies itself with a four byte ID read from the NBIC chip.  The ND device driver and support programs know how to check for the ID code for a NeXTdimension board.  The ID is in the most significant byte of specific slot ID addresses in the slot physical address space for each board.

I already made some progress on the NeXTbus and NeXTdimension memory map. The system running on the emulated machine sees the board, but stops after telling it is unable to reset it. Nevertheless it seems to program the RAMDAC and writes something the NeXTdimension RAM.

The stuff loaded into the NeXTdimension board for normal use would be non-trivial to implement.  It would involve emulating the Desplay PostScript back end from the scan-trap layer down, all the Porter-Duff compositing logic, and the entire Quick Renderman implementation from Renderman Interface Binary (RIB) stream handling down to the pixels.

I was thinking of two possible ways to emulate the NeXTdimension. The first is emulating it at a higher level, as you described. I agree that this might get too complex if one is not an expert for that kind of stuff.
The other way is to emulate it a the low level. This would involve emulating the i860 microprocessor and other components of the board. This will only be possibly if there is somewhere a complete and working i860XR emulator available.

[M Paquette]

Can these programs be used to read the raw content of the ROM to a file? Or is there a different way for reading raw memory contents from the NeXTdimension board?

NDromload -S

This should dump the ROM image in EXORMAX S-record format.  That's what went into a factory EEPROM programmer.  Note that I haven't tested this functionality since about 1990...

I'm not sure how useful this will be.  The ROM code for the board is pretty odd.  For example, there really isn't a data segment.  The ROM includes code that generates the data tables and whatnot that will eventually be loaded onto the IIC bus and RAMDAC on the fly.  This is done because of the odd way the i860 boots, in a mode (CS8 in the memory controller) where it fetches all instructions on a single 8 bit path (bytelane) from ROM, and the contents of the ROM being swizzled about to work with this.  Oh, did I mention the ROM content is swizzled about?  

Oh, and the S-records have their own funkiness from being munged to match the way the old Data I/O programmer wanted to see the addresses.

Code Select Expand


//
// The i860 text segment must be byte and word swapped before packing into the ROM.
// The text must be on a 64 bit boundry, and must be a multiple of 64 bits in length.
//
// The byte sequence to be written for each pair of words is as shown:
// 3 2 1 0 7 6 5 4
// |- - - -|- - - -|
static void
MungeText( unsigned char *src, unsigned char *dst, unsigned data_len)
{
struct munge{
unsigned char byte[4];
} munge;
struct munge *msrc;
struct munge *mdst;
int i;

msrc = (struct munge *)src;
mdst = (struct munge *)dst;
while ( data_len )
{
for ( i = 0; i < 4; ++i )
munge.byte[ 3 - i ] = msrc->byte[ i ];
*mdst = munge;
++msrc;
++mdst;
data_len -= 4;
}
}

/*
* Munge the ROM image into a format suitable for dumping an S-record
* for the ROM physical address sequence used by the Data I/O programmer.
*
* The address munging consists of extracting bits 0 and 1 from the ROM
* address, shifting the address right by two, shifting the extracted 2 bits
* up to bits 15 and 16, and ORing the two shifted fields together.
*/
static void
MungeV1MC( unsigned char *src, unsigned char *dst, int length )
{
unsigned int dstoff;
unsigned int srcoff;

for( srcoff = 0; srcoff < length; ++srcoff )
{
dstoff = srcoff >> 2;
dstoff |= (srcoff & 3) << 15;

dst[dstoff] = src[srcoff];
}
}


I should probably mention that getting this board running had certain side effects, including synesthesia and related experiences.   I'm better now.

I was thinking of two possible ways to emulate the NeXTdimension. The first is emulating it at a higher level, as you described. I agree that this might get too complex if one is not an expert for that kind of stuff.
The other way is to emulate it a the low level. This would involve emulating the i860 microprocessor and other components of the board. This will only be possibly if there is somewhere a complete and working i860XR emulator available.

Oof.  Intel did have an N10 emulator early on, running on their '286 based N10 development systems.  They updated this with an actual N10 PC-AT form card, as the emulator didn't emulate the various chip behaviors that needed to be actually coded for.  Any emulator would have to support running in big-endian mode for data (instruction space was always little-endian), and would have to support fiddly details like dual-instruction mode, and the the crazy pipeline dump and restore sequences that had to be done around interrupts (several hundred bytes of state, and something like 400 instructions in code).

It would be a great challenge project, but probably wouldn't be the best possible emulation experience for users.

You would get better performance for color output by just concentrating on the NeXTStation Color implementation, where the framebuffer is just a physical memory address range that's even cacheable.  The usual emulation trick is to play 'spot the blitter' and drop into a native code piece rather than emulate the blit or compositing loop.[/code]

[andreas_g]

NDromload -S

This should dump the ROM image in EXORMAX S-record format.  That's what went into a factory EEPROM programmer.  Note that I haven't tested this functionality since about 1990...

I don't think that will be useful. I really need the bits and bytes as they are stored in the EEPROM. I now think the EEPROM starts at 0xFFFE0000 with a size of 0x00020000 (128 kB). Reading this address range to a file without any conversion should do the job. But I don't know how this can be done. Through NeXTbus we should see it starting at 0x?FFE0000 (? = slot ID, for example 2 --> 0x2FFE0000).

You would get better performance for color output by just concentrating on the NeXTStation Color implementation, where the framebuffer is just a physical memory address range that's even cacheable.  The usual emulation trick is to play 'spot the blitter' and drop into a native code piece rather than emulate the blit or compositing loop.

Previous already includes support for the NeXTstation Color with its 4096 color output.

Using the low level emulation approach we should not need to care about all these strange features and data formats. If there is somewhere a complete i860 emulator, it will do all these things for us. We only need to provide it the memory map including a valid ROM and the devices, of which are not too many on the NeXTdimension board. The i860 will then do its work on the data it is provided with and write the result to the video memory. All we need to do then is blitting the pixel data from the video memory to the host screen.

I might be wrong, but this is the way the NeXT emulator Previous works, just with the m68k and with lots of devices.

I am trying to contact Jason Eckhardt, who seems to have written an almost complete i860 emulator. A stripped down version of it is in MAME: http://git.redump.net/mame/plain/src/emu/cpu/i860/i860dec.inc

[cubist]

I am trying to contact Jason Eckhardt, who seems to have written an almost complete i860 emulator. A stripped down version of it is in MAME: http://git.redump.net/mame/plain/src/emu/cpu/i860/i860dec.inc

Stardent.  There's another name from the past...

[pentium]

Rip the sticker off and see what kind of chip it is. If it's something common enough you can make a PLCC adapter and dump it a generic EEPROM machine.