oh certainly not! it is totallyu against the VAXway of doing things to 
have it all in one processor anyway. MSCP shoudl be handled by a separate 
processor, which only communicates MSCP packets over something, which 
itself only communicates over somethign that ultimately only gets known 
by the processor via a nexus- paged virtual scatter/gather DMA. 
i'd sick a small mips or even ppc chip, maybe a strongarm at it. 
Also, what about floating point implementation? We live in a world full 
of very fast VAX floating point implementations: 21064 chips that have 
been tossed into the bin along with their 21064 boxen. Theyre plenty fast 
for a 50 vups box (i'd aim for that as a first goal) and theyre already 
there. personally i also wouldnt mind making the actual VAX be a small 
pile of other processors, essentially microcoded to do a VAX 
implementation. no, it cannot have anything intel in it.. though the
relatively fast, cheap, small mips or strongarms sound quite nice. I would
separate out some of the functions into different units, stil lon the same
board but not necessarily the same chip, each of them has a small rom with
its 'microcode' which does its part of the VAX system. This woudl be 
worth doing a future implementation with, i can see it being more 
feasible than trying to break a performance barrier with gate arrays. 
meanwhile, a '750 on a chip would still have to have a bunch of supporting
cast. The 750 had a bunch of caches here and there, stuff that would be
murder to fit onto a single gate array. We might be better with
several gate arrays, and put the caches, etc, in between them to go where
the vax's stuff went. Perhaps a board-for-board copy: it woudl use more 
(and smaller) gate arrays, to copy the 3 or 4 boards one each, and that would
allow us to isolate out more of the memory banks, and such, as well.

We still need to fingure out an interface to the outside world. My two
candidates would be TURBOchannel (still) and VME. Another thought is this:
are there any gurus here who could undertake to make the UNIBUS adapter 
in a 750 into a Qbus adaptor? then, this vax could be stuck onto a Qbus
board and we'd have access to all the peripherals were familiar with, and it
would connect to the tiny SBI on the board. Perhaps we could stick two 
of them onto the board, to have a dual-Qbus machine? 

this is all taking it away from a single chip rather cheap solution and
into being a real computer... 8-)

isildur 

On Tue, 26 Jun 2001, Chuck McManis wrote:

> At 10:04 PM 6/26/01 +0100, Matt London wrote:
> >Hrm, maybe if we actually start making progress we should check with them
> >- after all, how much could they bother about the design of a processor
> >that's 20 years old, the family of which is no longer in production.
> 
> The VAX prints are copyrighted, and thus using them as the basis for your 
> design is a violation of the copyright law. However, as a lot of people 
> point out, Compaq isn't particularly worried about or care about hobbiests 
> re-creating the VAX, they would no doubt not allow any of our work to be 
> used commercially without paying them but hey this isn't a money making 
> venture :-)
> 
> Finally, I would *LOVE* to see the press generated by Compaq trying to sue 
> a group of people who love the VAX trying to keep it alive and Compaq 
> trying to keep it dead :-) Frankly it would be worth it to do this for just 
> that possibility!
> 
> On a more practical note, the FPGAs in question have lots of gates but not 
> enough RAM to hold the WCS so that would have to be external. Second the 
> MSCP protocol is pretty much a PITA if you have to implement it as well and 
> I don't think you could fit the VAX and a MSCP processor and a Qbus or 
> whatever into one chip (you might but it would be really tight). I suggest 
> that the first step be a VAX that can access memory and has an accessible 
> front panel to put simple programs into and run them. Concurrent with that 
> a serial port at the correct locations so that you can boot the VAX 
> monitor.  *THEN* you can think about real peripherals. You might find it 
> easier to emulate the SGEC for Ethernet and perhaps the SII for a DSSI bus. 
> Then again, the SII is a lot more complicated than it seems at first glance ...
> 
> --Chuck
> 
> 
> 
>