NeXT Computers

NeXT Computer, Inc. => NeXTdimension Board => Topic started by: andreas_g on June 19, 2015, 08:50:54 am

Title: NeXTdimension ROM image
Post by: andreas_g on June 19, 2015, 08:50:54 am
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
Title: NeXTdimension ROM image
Post by: barcher174 on June 19, 2015, 08:49:03 pm
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
Title: NeXTdimension ROM image
Post by: andreas_g on June 19, 2015, 09:25:45 pm
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
Title: NeXTdimension ROM image
Post by: mikeboss on June 19, 2015, 10:34:17 pm
I'm pretty sure that there's a ROM chip on the NeXTdimension:

(https://farm1.staticflickr.com/380/18970843341_4141c97945_z.jpg)

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...
Title: NeXTdimension ROM image
Post by: M Paquette on June 19, 2015, 11:01:32 pm
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

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
Title: NeXTdimension ROM image
Post by: barcher174 on June 19, 2015, 11:33:57 pm
Someone get this man an FTP!  :lol:
Title: NeXTdimension ROM image
Post by: jroark on June 20, 2015, 10:48:26 am
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?)


$ 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
Title: NeXTdimension ROM image
Post by: M Paquette on June 20, 2015, 02:50:58 pm
Quote from: "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?)


$ 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.
Title: NeXTdimension ROM image
Post by: andreas_g on June 21, 2015, 04:08:51 pm
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.
Title: NeXTdimension ROM image
Post by: M Paquette on June 21, 2015, 06:28:00 pm
Quote from: "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.


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.

#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.
Title: NeXTdimension ROM image
Post by: andreas_g on June 22, 2015, 06:08:04 am
Quote from: "M Paquette"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?

Quote from: "M Paquette"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.

Quote from: "M Paquette"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.
Title: NeXTdimension ROM image
Post by: M Paquette on June 22, 2015, 06:40:35 pm
Quote from: "andreas_g"
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.


//
// 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.

Quote from: "andreas_g"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]
Title: NeXTdimension ROM image
Post by: andreas_g on June 23, 2015, 06:11:04 am
Quote from: "M Paquette"
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).

Quote from: "M Paquette"
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 (http://git.redump.net/mame/plain/src/emu/cpu/i860/i860dec.inc)
Title: NeXTdimension ROM image
Post by: cubist on June 23, 2015, 07:30:24 am
Quote from: "andreas_g"
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 (http://git.redump.net/mame/plain/src/emu/cpu/i860/i860dec.inc)


Stardent.  There's another name from the past...
Title: NeXTdimension ROM image
Post by: pentium on June 23, 2015, 04:08:39 pm
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.
Title: NeXTdimension ROM image
Post by: andreas_g on June 23, 2015, 04:50:46 pm
I don't think that it is neccessary to do anything on the hardware side. It is definitely not worth to risk the health of the board. I'm quite sure there is a way to obtain the data from the software side.

Furthermore it might turn out to be too difficult or time consuming to emulate. It does no look too good at the moment.
Title: NeXTdimension ROM image
Post by: M Paquette on June 23, 2015, 05:08:22 pm
Quote from: "andreas_g"
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.


You should be aware that the only reason the i860 was faster at 32 bit graphics than other solutions at the time was because of certain hardware advantages that will not appear in emulation.  With a full emulation of both the i860 and 68040, complete with emulation of the communications overhead, and the lack of hardware speedups such as async multiprocessing, the dedicated i860 FPU pixel processor (used for all drawing, compositing, and 3D code) and a true deep pipelined dual instruction issue engine, I calculate that the level of performance for graphics will be around 12-20% of the current Previous emulation of the NeXTStation Color.

More on the i860 core here: http://www.realworldtech.com/intel-history-lesson/2/

As I mentioned before, you'll get the biggest improvement for your efforts by implementing mechanisms in the emulator to spot blit loops and having the emulator transfer control to a full native implementation.  Something similar is done in commercial emulation software.  For example, the old SoftPC software would spot calls to the VGA/EGA graphics routines and rather than stepping through the VGA code, would call routines on the native platform to perform the same task, often using GPU acceleration where available.  (Guess who wrote that?)
Title: NeXTdimension ROM image
Post by: andreas_g on June 23, 2015, 05:54:37 pm
I'm aware that emulating the NeXTdimension won't speed up, but slow down Previous. It is not a goal of Previous to provide maximum speed. Emulation speed is intentionally limited to a realistic value, rather than maximum speed. So there is some kind of "reserve". At the moment i see no need to improve efficiency, except for the DSP emulation.

Note: The timings are not accurate at the moment. Therefore the speed of the emulated machine does not match a real machine. Anyway, if the host system is fast enough, the speed of the emulated machine is independant of host performance.

The only reason emulating the NeXTdimension would be having 32-bit color and because we can   :wink:

To have fast enough speed it would be neccessary to run the emulated i860 in a separate thread.

At the moment screen drawing and timings work like this: After a defined number of emulated CPU cycles a routine is called, which draws the contents of the emulated VRAM to the host screen, skipping unchanged pixels. Also this routine checks if a defined value of real time has passed since the last call of the routine. If not, it waits until the time has passed an then continues emulation. This limits speed to a defined value.
Title: NeXTdimension ROM image
Post by: M Paquette on June 23, 2015, 09:46:47 pm
Quote from: "andreas_g"
The only reason emulating the NeXTdimension would be having 32-bit color and because we can   :wink:


That's what I thought.  It might make a nice personal goal for you.

Quote from: "andreas_g"To have fast enough speed it would be neccessary to run the emulated i860 in a separate thread.


Heh.  Just remember, new threads don't necessarily create new CPU cycles.   Once all the processor cores are occupied, that's about it.

Quote from: "andreas_g"
At the moment screen drawing and timings work like this: After a defined number of emulated CPU cycles a routine is called, which draws the contents of the emulated VRAM to the host screen, skipping unchanged pixels. Also this routine checks if a defined value of real time has passed since the last call of the routine. If not, it waits until the time has passed an then continues emulation. This limits speed to a defined value.


Idle thought:  Watch for cache flushes that include VRAM addresses.  NeXTStation Color and the NeXTdimension board run VRAM as cacheable by the local processor to enable burst or pipelined framebuffer reads and writes.  DPS or it's ND board back end will flush the caches at display time.
Title: NeXTdimension ROM image
Post by: andreas_g on June 24, 2015, 06:50:49 am
Quote from: "M Paquette"Idle thought:  Watch for cache flushes that include VRAM addresses.  NeXTStation Color and the NeXTdimension board run VRAM as cacheable by the local processor to enable burst or pipelined framebuffer reads and writes.  DPS or it's ND board back end will flush the caches at display time.

In real hardware screen refreshes are not triggered by the CPU. At the moment screen drawing works like it does on real hardware. The screen is refreshed at a defined interval using the data that is inside the VRAM at that time. I see no need to change this.

It seems I can't get a raw ROM and I did not succeed contacting Jason Eckhardt. So I'll stop here trying to reach my personal goal.

btw.
Of course I know that threads do not create CPU cycles. But processing the i860 in the same thread as the m68k will cause one CPU core to be overwhelmed, while others might be idle. I have this exact problem at the moment while running the DSP.
Title: NeXTdimension ROM image
Post by: barcher174 on June 24, 2015, 07:34:05 am
I think I can get the ROM dumped for you. It probably won't be until the end of July though.

--
Brian
Title: NeXTdimension ROM image
Post by: andreas_g on June 24, 2015, 07:45:33 am
barcher174, thank you for your efforts! But it will only make sense, if we can get a usable i860 processor core. So at the moment it is not worth the trouble. But if things change, i'll report back.
Title: NeXTdimension ROM image
Post by: cbrunschen on June 25, 2015, 08:54:44 pm
Quote from: "andreas_g"barcher174, thank you for your efforts! But it will only make sense, if we can get a usable i860 processor core. So at the moment it is not worth the trouble. But if things change, i'll report back.


There seems to be an i860 core in MAME (https://github.com/mamedev/mame/tree/master/src/emu/cpu/i860), and it seems to be under the BSD 3-clause license - would that be a possible starting point?
Title: NeXTdimension ROM image
Post by: andreas_g on June 26, 2015, 05:56:02 am
Quote from: "cbrunschen"There seems to be an i860 core in MAME (https://github.com/mamedev/mame/tree/master/src/emu/cpu/i860), and it seems to be under the BSD 3-clause license - would that be a possible starting point?

I did notice that. I mentioned it some posts before. The problem with that core is, that it was obviously stripped down for MAME. The full version seems to be lost. I tried contacting the coder of the original code. But I did not get a response yet.
Title: NeXTdimension ROM image
Post by: cbrunschen on June 26, 2015, 11:23:43 pm
Quote from: "andreas_g"
Quote from: "cbrunschen"There seems to be an i860 core in MAME (https://github.com/mamedev/mame/tree/master/src/emu/cpu/i860), and it seems to be under the BSD 3-clause license - would that be a possible starting point?

I did notice that. I mentioned it some posts before.


So you did, I had missed that; my apologies.

QuoteThe problem with that core is, that it was obviously stripped down for MAME. The full version seems to be lost. I tried contacting the coder of the original code. But I did not get a response yet.


Looking at the MAME code it lists:


MAME-specific notes:
- i860XR emulation only (i860XP unnecessary for MAME).
- No emulation of data and instruction caches (unnecessary for MAME version).
- No emulation of DIM mode or CS8 mode (unnecessary for MAME version).
- No BL/IL/locked sequences (unnecessary for MAME).
- Emulate only the i860's LSB-first mode (BE = 0).


If I see correctly from pictures of a NeXTDimension board, it holds an i860XR at 33 MHz (compare this picture (http://www.cpu-collection.de/?l0=co&l1=Intel&l2=i860)); so that should cover the top item.

I am going to guess that the precise cache timing is probably also not vital for emulation of a NeXTDimension board.

Comparing the remaining items with the programmers manual (http://bitsavers.trailing-edge.com/pdf/intel/i860/240329-002_i860_64-Bit_Microprocessor_Programmers_Reference_Feb89.pdf):

CS8 is a mode that allows booting form 8-bit-wide memory before switching to 64-bit-wide memory for subsequent operation; this sounds like it might be used on a NeXTDimension (if the boot (P)ROM is 8 bits wide)

DIM seems to be "Dual Instruction Mode" where the CPU executes one "core" and one floating-point operation at the same time, in lock-step; that sounds like it would likely be very useful in the kind of code running here; but it might be that simply executing the instructions one after the other (interleaved rather than in parallel) would still produce the same results, and only timing would be affected.

BL/IL/locked sequences seem to be about locking a bus that may be shared among multiple CPUs; this may not be necessary for NeXTDimension emulation.

Endianness - while it might make sense to use big-endianness for data when the main CPU in the system (680x0) is big-endian, the i860 is natively little-endian, and it might be easiest just to have left it as0-is.

It seems that a lot of these things could be checked for by looking at the code in the ROM: seeing if it includes an instruction to disable CS8 mode; if any instructions have the 'Dual-instruction' bit set; whether any instruction sets the BE bit in the control register; whether there are any lock/unlock instructions. That could then be used to determine what would be necessary to add to the i860 emulation code, if anything.

// Christian
Title: NeXTdimension ROM image
Post by: M Paquette on June 27, 2015, 12:03:48 am
Quote from: "cbrunschen"
Looking at the MAME code it lists:


MAME-specific notes:
- i860XR emulation only (i860XP unnecessary for MAME).
- No emulation of data and instruction caches (unnecessary for MAME version).
- No emulation of DIM mode or CS8 mode (unnecessary for MAME version).
- No BL/IL/locked sequences (unnecessary for MAME).
- Emulate only the i860's LSB-first mode (BE = 0).


If I see correctly from pictures of a NeXTDimension board, it holds an i860XR at 33 MHz (compare this picture (http://www.cpu-collection.de/?l0=co&l1=Intel&l2=i860)); so that should cover the top item.

I am going to guess that the precise cache timing is probably also not vital for emulation of a NeXTDimension board.

Comparing the remaining items with the programmers manual (http://bitsavers.trailing-edge.com/pdf/intel/i860/240329-002_i860_64-Bit_Microprocessor_Programmers_Reference_Feb89.pdf):

CS8 is a mode that allows booting form 8-bit-wide memory before switching to 64-bit-wide memory for subsequent operation; this sounds like it might be used on a NeXTDimension (if the boot (P)ROM is 8 bits wide)


Correct.  The i860 is in CS8 mode on reset and executing from the one byte wide EEPROM.  (I posted the 'swizzling' code earlier that shows how the 64 bit aligned instruction stream is repacked for use in the ROM, along with how it is repacked for use in a ROM programmer which does it's own thing in programming a byte wide device.)  We don't put data in the boot ROM other than as the IMMEDIATE field of instructions.  Data tables needed are built from instructions in the ROM.

Quote
DIM seems to be "Dual Instruction Mode" where the CPU executes one "core" and one floating-point operation at the same time, in lock-step; that sounds like it would likely be very useful in the kind of code running here; but it might be that simply executing the instructions one after the other (interleaved rather than in parallel) would still produce the same results, and only timing would be affected.

DIM is indeed dual instruction mode, a mode in which two opcodes are issued at a time, one to the integer unit and one to the FPU/GPU unit.  Note however that the issued opcodes are in an explicit pipeline, with exposed sequencing including delay slots.  The delay slots are even used when DIM is off.

Look out for sequences like this:

xor 4,r31,r31 // Flip addr to big-endian for fetch...
br 2f
   ld.l 0(r31),r17


That load to r17 is in the branch delay slot.  It executes when the branch is taken.

DIM also impacts how the VM system runs.  Page fault code, for example, has to check BOTH instructions in a pair.

Pretty much all of the window server compositing code is in hand-pipelined DIM code
Quote
BL/IL/locked sequences seem to be about locking a bus that may be shared among multiple CPUs; this may not be necessary for NeXTDimension emulation.

Endianness - while it might make sense to use big-endianness for data when the main CPU in the system (680x0) is big-endian, the i860 is natively little-endian, and it might be easiest just to have left it as0-is.


If you plan on having the i860 emulation work with the NeXTSTEP/OPENSTEP software, it should be big-endian.  The window server and Mach kernel communications paths all assume a big-endian data machine.  If I recall, NeXT was the only i860 customer to use the big-endian mode.

Quote
It seems that a lot of these things could be checked for by looking at the code in the ROM: seeing if it includes an instruction to disable CS8 mode; if any instructions have the 'Dual-instruction' bit set; whether any instruction sets the BE bit in the control register; whether there are any lock/unlock instructions. That could then be used to determine what would be necessary to add to the i860 emulation code, if anything.


The ROM code drops CS8 as part of the jump to a loaded program in ND main memory.
The ROM code definitely flips on the BE bit in the EPSR.
The i860 LOCK/UNLOCK opcodes are NOT supported by the ND bus or NBIC interface.  Interprocessor locking is done with Lamport's algorithm[1].



1. Leslie Lamport, "A Fast Mutual Exclusion Algorithm", ACM TOCS, Vol. 5-1, February 1987, pp. 1-11
Title: NeXTdimension ROM image
Post by: cuby on June 28, 2015, 11:33:39 pm
Quote from: "M Paquette"The i860 LOCK/UNLOCK opcodes are NOT supported by the ND bus or NBIC interface.  Interprocessor locking is done with Lamport's algorithm[1].

1. Leslie Lamport, "A Fast Mutual Exclusion Algorithm", ACM TOCS, Vol. 5-1, February 1987, pp. 1-11

Whow, this is a great example for a quick transfer of knowledge from academia to industry, considering the NeXTdimension came out in 1990 and development of the software must have started some years earlier.

(Sorry for the off-topic, but since I'm currently teaching computer architecture and parallel systems, this immediately caught my eye...)

-- Michael
Title: NeXTdimension ROM image
Post by: andreas_g on June 29, 2015, 08:00:26 am
I think it would require quite a lot of work to make the i860 code of MAME work for the NeXTdimension. It would requite more time, that I have available.
At the moment it is even uncertain, if the full version of the i860 emulator would be good enough. But that can only be tested, if it can be found.

I decided to concentrate now on adding support for Turbo machines. That is quite a lot easier and brings the advantage of having 128 MB memory. Nevertheless it will require some time to make everything work (Ethernet and DSP are broken, 3.1 and later crashes on boot).
Title: NeXTdimension ROM image
Post by: andreas_g on October 09, 2015, 05:55:37 am
This does not entirely fit the initial topic, but as this thread is mostly about emulation a dimension board i'll post it here:

On the internet there are some warnings not to use the monochrome screen on a system with NeXTdimension and dual monitors:
Quote from: "http://www.ding.net/info/next/next1.html"Subject: L5. Why is my machine so slow when I run the monochrome and NeXTdimension displays?
There is a bug with the window system in which if you select the monochrome display as your primary display the server will be much much slower. The solution for those wishing to use both displays is to select the color (NeXTdimension) display as the primary display. The most optimal configuration at present with the NeXTdimension is to run only the color display.

Quote from: "https://ftp.nice.ch/peanuts/GeneralData/Usenet/news/1991/_CSN-91/comp-sys-next/1991/Jul/_On-2-headed-Cube,-Color-Screen-MUST-have-loginwindow-dock.html"Date: Sun 05-Jul-1991 07:59:37
From: izumi@mindseye.berkeley.edu (Izumi Ohzawa)
Subject: On 2-headed Cube, Color Screen MUST have loginwindow/dock

This subject came up under another title, but it seems
important enough to  post a summary now that NeXT is
shipping NeXTdimension boards in quantity.

If you configure your NeXTdimension cube as a two-headed
system (with both color and monochrome displays), you
MUST use the NeXTdimension (color) screen as the primary
screen (screen with loginwindow and your Dock).

The other configuration, loginwindow on the Monochrome screen,
suffers from a severe performance loss on the order of a
factor of 10 or more!
The system also eats up the swap space like crazy.
Some applications, e.g., /NextDeveloper/Demos/VideoApp,
will also refuse to start up in this configuration.

The doc "Getting Started with NeXTdimension" that comes
with the board says that you can choose the primary
screen (also called "zero screen") to be either NeXTdimension
or Monochrome by dragging a tiny loginwindow icon between
screens in the Preferences application.
Don't select monochrome as the primary screen, unless you want
your system to run at snail's pace.

I don't know why there is this asymmetry of performance
between the two configurations.
Some explanation from NeXT or a NeXT person would be nice.


Izumi Ohzawa


It was suspected, that in this configuration all the processing is done on the 68k and the NeXTdimension is only used as a framebuffer. Does anyone (M Paquette) know if that is true?
Title: NeXTdimension ROM image
Post by: M Paquette on October 09, 2015, 02:37:03 pm
Quote from: "andreas_g"This does not entirely fit the initial topic, but as this thread is mostly about emulation a dimension board i'll post it here:

On the internet there are some warnings not to use the monochrome screen on a system with NeXTdimension and dual monitors:
Quote from: "http://www.ding.net/info/next/next1.html"Subject: L5. Why is my machine so slow when I run the monochrome and NeXTdimension displays?
There is a bug with the window system in which if you select the monochrome display as your primary display the server will be much much slower. The solution for those wishing to use both displays is to select the color (NeXTdimension) display as the primary display. The most optimal configuration at present with the NeXTdimension is to run only the color display.

Quote from: "https://ftp.nice.ch/peanuts/GeneralData/Usenet/news/1991/_CSN-91/comp-sys-next/1991/Jul/_On-2-headed-Cube,-Color-Screen-MUST-have-loginwindow-dock.html"Date: Sun 05-Jul-1991 07:59:37
From: izumi@mindseye.berkeley.edu (Izumi Ohzawa)
Subject: On 2-headed Cube, Color Screen MUST have loginwindow/dock

This subject came up under another title, but it seems
important enough to  post a summary now that NeXT is
shipping NeXTdimension boards in quantity.

If you configure your NeXTdimension cube as a two-headed
system (with both color and monochrome displays), you
MUST use the NeXTdimension (color) screen as the primary
screen (screen with loginwindow and your Dock).

The other configuration, loginwindow on the Monochrome screen,
suffers from a severe performance loss on the order of a
factor of 10 or more!
The system also eats up the swap space like crazy.
Some applications, e.g., /NextDeveloper/Demos/VideoApp,
will also refuse to start up in this configuration.

The doc "Getting Started with NeXTdimension" that comes
with the board says that you can choose the primary
screen (also called "zero screen") to be either NeXTdimension
or Monochrome by dragging a tiny loginwindow icon between
screens in the Preferences application.
Don't select monochrome as the primary screen, unless you want
your system to run at snail's pace.

I don't know why there is this asymmetry of performance
between the two configurations.
Some explanation from NeXT or a NeXT person would be nice.


Izumi Ohzawa


It was suspected, that in this configuration all the processing is done on the 68k and the NeXTdimension is only used as a framebuffer. Does anyone (M Paquette) know if that is true?


The screen with the loginwindow is treated as the 'main' screen, the one where the user intends to do most work.  The NeXT AppKit uses the main screen as the designated place to cache all of it's off-screen artwork, images, and UI elements.

If the 'main' screen, the one with loginwindow, is on the NeXTdimension card then that card holds the cache, and display of UI elements, artwork, and images is quite fast.  If the 2 bit MegaPixel display is the main screen, then all the cache contents are kept with the 2 bit display in main memory and swap, and every drawing operation referencing these elements on the ND board has to copy them over the NeXTbus.  That can be relatively slow.
Title: NeXTdimension ROM image
Post by: andreas_g on October 12, 2015, 06:44:15 am
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
Title: NeXTdimension ROM image
Post by: M Paquette on October 13, 2015, 01:12:00 am
Quote from: "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


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.
Title: NeXTdimension ROM image
Post by: andreas_g on October 13, 2015, 06:58:09 am
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?
Title: NeXTdimension ROM image
Post by: ardi on October 13, 2015, 12:38:37 pm
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...
Title: NeXTdimension ROM image
Post by: schubige on October 13, 2015, 05:47:06 pm
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.
Title: NeXTdimension ROM image
Post by: M Paquette on October 13, 2015, 09:20:11 pm
Quote from: "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?


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:

//
// 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;
}
}
Title: NeXTdimension emulation on it's way
Post by: schubige on January 10, 2016, 03:22:42 pm
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
Title: NeXTdimension ROM image
Post by: mikeboss on January 10, 2016, 10:30:13 pm
wow, just wow! absolutely incredible work  8) looking forward to the first public release...

regards,
michael
Title: NeXTdimension ROM image
Post by: gtnicol on January 11, 2016, 03:05:02 am
Well done!
Title: NeXTdimension ROM image
Post by: itomato on January 11, 2016, 09:11:41 pm
Is the ND functionality in the r559 branch?
Title: Re: NeXTdimension emulation on it's way
Post by: ardi on January 12, 2016, 06:07:11 am
Quote from: "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


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.
Title: Re: NeXTdimension emulation on it's way
Post by: Rob Blessin Black Hole on April 16, 2016, 07:40:07 am
Quote from: "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
Where do I find this file? (http://www.nextcomputers.org/NeXTfiles/Images/Hardware/NeXTdimension/previousdim.jpg)
Title: NeXTdimension ROM image
Post by: schubige on April 17, 2016, 08:27:10 am
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.
Title: NeXTdimension ROM image
Post by: Rob Blessin Black Hole on April 18, 2016, 10:21:51 am
Quote from: "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.


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