I think this is how it's done, and since I've now embarrassed myself by pulling my InterPro emulation into public view, I thought I'd give a quick update.

More of the boot ROM diagnostic routines are working. Some very basic DMA handling is working, to the point where the system can now read a partition table from a floppy disk.



I've now refactored the ioga, sga and mcga as separate devices, and done some preliminary work on the cammu (although actual address translation isn't done yet).

The CPU now sends all its memory access to the CAMMU, which decides which of the 3 real address spaces to hit (main, i/o or boot), and fowards them on. This killed performance, so I've hacked a primitive instruction cache into the CAMMU for now, which helps a bit. Probably I just need a faster PC.

Lots to do, and still quite some way away from being able to boot CLIX I think.

It's been a while, with life and work getting in the way, but have recently made a bit more progress.



Nothing too earth-shattering:

• nmi is working properly now
• dma is better, now working read and write for the floppy at least
• configurable ram sizes (not working completely)
• most devices are now at least stubbed out and mapped
• basic mmu address translation is working
• added the diagnostic 7-segment led, which is nice to watch during diagnostics

The system still spews diagnostic errors at boot, but it's passing some of those it was failing previously.

I also now have my hands on a real physical keyboard, so I have no excuses for figuring that out in the future.

Most importantly, I've made contact with someone who has a working 2000 and parts(?) for a 2400, and the means to dump some of the key ROMs from them and especially their graphics boards.

All iogadiag tests are now passing (although due to a hack forcing bus errors during dma operations).

More importantly, SCSI is alive!



Hopefully now I have enough of the basics working to begin to tackle OS boot.

First step on the road to OS booting - serial DMA is working!



The new "Fic" variation of the Forth diagnostic monitor has new commands to play with as well.

So now to figure out what it doesn't like about my disk, and whether I can get to the next step.

Dear diary, it's been a while since my last entry, so...

The big news is I now have the keyboard and a very primitive amount of graphics working, so I can start using them interactively instead of the MAME terminal emulation. Floppy is working well enough to load the diagnostics from disk, which includes the graphics diagnostics I need to implement at least some of the rest of the graphics hardware (bitblit, line drawing, clipping, antialiasing, stereo, etc.). It seems the lack of some of these functions is what's preventing me from doing anything useful after loading the boot floppy from the "rebuild" set (which should show a blue menu screen with functions to format the hard disk and create partitions, etc.).

WIP screenshots

Thanks to contributions from others, I also have boot ROMs for the 2000, 2400 and 2700 systems, and these are working to about the same extent as the 2800. The 2000 is the most different, as it uses the C300 CPU and has different floppy, Ethernet and SCSI devices to the other three, and has no flash/eeprom on board. The 2000 system was known as a Turquoise model, while the other three (and the otherwise yet not sourced 2500) are Sapphire models.

Intel 82586/82596 Ethernet is implemented, and working as far as passing almost all the diagnostics; starting the Sapphire systems (2400/2700/2800) without any disks will cause them to start trying to RARP an address and network boot with TFTP.

Probably a bunch of other things I've forgotten to mention, but it's a significant milestone just the same. I'm now working on reverse engineering the graphics, and hopefully that'll result in something a bit more pretty to look at in due course.

Still here, working my way through the GT graphics hardware. The screenshot shows a few things:

• Identified the hblank/vblank screen parameters needed to get the Bt459 cursors to align with pixel graphics
• Haven't implemented Bt459 dual-cursor OR/XOR behaviour yet
• Clipping status register computes Cohen-Sutherland clipping outcodes for each of two input points
• Aliased (the opposite to anti-aliased, I learned) clipped hardware line drawing is working, although may not be 100% pixel-perfect matching with real hardware

Next up is a different method of hardware line drawing (using the "RI" function of the custom graphics ASIC), and then onto bitblit operations.

This is the most awesome thread on this board lately.

Could you make them generic? I could use that in hp_ipc.cpp (which has a monochrome frrame buffer driven by a custom HP GPU).

Thanks for the comment Vas - hope I can keep entertaining.

Shattered, I'll do what I can, but I might be somewhat limited in how generic I can make it depending on how closely I need to emulate the NS DP8510 bitblit unit in the system. No promises at this stage

Bitblt operations (now commonly called ROPs because that's what Microsoft named them in Windows and Nvidia and AMD followed suit) are just "src (math operator) dest", so I'm fuzzy on shattered's thinking that they're scary.