NeXTdimension ROM image

[andreas_g]

Thank you very much for the explanation! Another question has raised, while experimenting with NDromload: Endianness of the ND-board. The processor operates in big endian mode, which means that data is accessed that way, while instructions are still accessed in little endian mode (correct me if I'm wrong).

The NextBus operated in little endian mode. The NBIC of the CPU board converts the big endian data from the m68k board to little endian for the NextBus.

But what happens on the NeXTdimension side? Does the NBIC on the board convert it back to big endian?

e.g.
When I do a 32-bit transfer of 0x10203040 from the CPU board to NeXTdimension memory (at adress "a") will it be stored in big endian or little endian format?

big endian: a = 0x10, a+1 = 0x20, a+2 = 0x30, a+3 = 0x40
little endian: a = 0x40, a+1 = 0x30, a+2 = 0x20, a+3 = 0x10

[M Paquette]

Thank you very much for the explanation! Another question has raised, while experimenting with NDromload: Endianness of the ND-board. The processor operates in big endian mode, which means that data is accessed that way, while instructions are still accessed in little endian mode (correct me if I'm wrong).

The NextBus operated in little endian mode. The NBIC of the CPU board converts the big endian data from the m68k board to little endian for the NextBus.

But what happens on the NeXTdimension side? Does the NBIC on the board convert it back to big endian?

e.g.
When I do a 32-bit transfer of 0x10203040 from the CPU board to NeXTdimension memory (at adress "a") will it be stored in big endian or little endian format?

big endian: a = 0x10, a+1 = 0x20, a+2 = 0x30, a+3 = 0x40
little endian: a = 0x40, a+1 = 0x30, a+2 = 0x20, a+3 = 0x10

The ND board NBIC is set up the same as the CPU board part, and treats the ND board memory as big-endian.

Copying a big-endian data structure from the 68K memory to the ND board memory will store the data structure on the ND board in big-endian format.

This was done to allow data structures (built with 'natural' alignment) to be shared between the boards, along with pixel buffers such as window backing stores.

[andreas_g]

Thank you again for the answer! I'm coming closer to understand this. But there is one more question:

The processor starts in CS8-mode. That means, it fetches instructions using multiple 8-bit access instead of a single instruction word access. What effect does that have on the required byte-order of the ROM?

e.g.
Fetching instruction with opcode 0xA0000000 from address "a":

In normal mode it is fetched as a whole using little endian byte order. That means in memory it is stored as a = 0x00, a+1 = 0x00, a+2 = 0x00, a+3 = 0xA0.

In CS8-mode multiple consecutive 8-bit fetches are performed from address "a". Does that mean the opcode has to be stored in reversed order (a = 0xA0, a+1 = 0x00, a+2 = 0x00, a+3 = 0x00) for CS8-mode?

[ardi]

Very interesting thread! I missed it!! BTW, apart from the i860, I see two Motorola chips in the board, as well as what seems to be an ASIC (with the label VLSI on top of it). What are these chips for? They've the size of a CPU. They look like being able to perform hard work. In such case, maybe they need to be emulated too.

There're also three Philips chips, but they're for video color space conversion and for video input. They're the SAA 7191 WP and the SAA 7192 WP. Their datasheets are available if you search for them.

Anyway, it seems these Philips chips are only used for video I/O, but however maybe you might need to support their instructions codes (even if it's with an empty stub if their functionality isn't needed).

But the two Motorolas and the VLSI chip look larger and make me feel more worried than the Philips ones...

[schubige]

The VLSI chip is the NBIC. A fairly well documented chip even by NeXT standards. The two custom chips produced by Motorola are most likely U52 (datapath, see http://www.nextcomputers.org/NeXTfiles/Docs/Hardware/Schematics/NeXTdimension/ND-04.jpg) and U88 (memctl, see http://www.nextcomputers.org/NeXTfiles/Docs/Hardware/Schematics/NeXTdimension/ND-03.jpg). While having many pins (they basically interconnect the various components on the baord including DRAM and VRAM) their internal logic should not be very complex from an emulator point of view.

[M Paquette]

Thank you again for the answer! I'm coming closer to understand this. But there is one more question:

The processor starts in CS8-mode. That means, it fetches instructions using multiple 8-bit access instead of a single instruction word access. What effect does that have on the required byte-order of the ROM?

e.g.
Fetching instruction with opcode 0xA0000000 from address "a":

In normal mode it is fetched as a whole using little endian byte order. That means in memory it is stored as a = 0x00, a+1 = 0x00, a+2 = 0x00, a+3 = 0xA0.

In CS8-mode multiple consecutive 8-bit fetches are performed from address "a". Does that mean the opcode has to be stored in reversed order (a = 0xA0, a+1 = 0x00, a+2 = 0x00, a+3 = 0x00) for CS8-mode?

Correct.  In addition, the instructions have to be placed on 64 bit boundries, and the packing has to be done in multiples of 64 bits.  The alignment and packing are maintained by the i860 Mach-O toolchain. The following code works on an i860 Mach-O file to re-order the instruction stream to the format to be written to the ROM:

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;
}
}


[schubige]

Happy new year! Good news from the Previous/NeXTdimension front. Together with Andreas I hacked a preliminary emulation of the NeXTdimension board, including the i860 as well as the various peripheral chips. While it runs pretty stable from NS 2.1 to OS 4.2, it still produces some pixel defects. Thus consider it as work in progress. But Andreas and I are both convinced that a full NeXTdimension emulation is within reach. Have a look at this screenshot: http://1drv.ms/1OchfXu

[mikeboss]

wow, just wow! absolutely incredible work   looking forward to the first public release...

regards,
michael

[gtnicol]

Well done!

[itomato]

Is the ND functionality in the r559 branch?

[ardi]

Happy new year! Good news from the Previous/NeXTdimension front. Together with Andreas I hacked a preliminary emulation of the NeXTdimension board, including the i860 as well as the various peripheral chips. While it runs pretty stable from NS 2.1 to OS 4.2, it still produces some pixel defects. Thus consider it as work in progress. But Andreas and I are both convinced that a full NeXTdimension emulation is within reach. Have a look at this screenshot: http://1drv.ms/1OchfXu

A good stress-test, when it's more complete, could be to try to render some demo scenes with accelerated RenderMan. I don't know the details on how to do this, but apparently you don't need a Pixar RenderMan license because the accelerated renderer is included with the ND. It's documented somewhere in some NeXTSTEP document.

[Rob Blessin Black Hole]

Happy new year! Good news from the Previous/NeXTdimension front. Together with Andreas I hacked a preliminary emulation of the NeXTdimension board, including the i860 as well as the various peripheral chips. While it runs pretty stable from NS 2.1 to OS 4.2, it still produces some pixel defects. Thus consider it as work in progress. But Andreas and I are both convinced that a full NeXTdimension emulation is within reach. Have a look at this screenshot: http://1drv.ms/1OchfXu

Where do I find this file?

[schubige]

You find it here https://sourceforge.net/p/previous/code/HEAD/tree/branches/branch_realtime/src/ (dimension_eeprom.bin) along with the other NeXT ROM images.

[Rob Blessin Black Hole]

You find it here https://sourceforge.net/p/previous/code/HEAD/tree/branches/branch_realtime/src/ (dimension_eeprom.bin) along with the other NeXT ROM images.

Thanks its working great, I uploaded the NeXT Dimension file here if anyone else needs it
http://www.nextcomputers.org/NeXTfiles/Software/ROM_Files/