[HECnet] PDP-11/70 on FPGA

[Paul Koning]

On Aug 11, 2010, at 3:14 AM, G  ran   hling wrote:

All of the interfaces "supported" are "oldish", i.e. they were implemented in TTL without any local "interface processor". Later interfaces were more or less all based on some embedded CPU to do the shuffling.

So, in taking this great work further, some suitable "soft processor hardware" needs to be implemented.

I realize there are several "commercial" alternatives, some supplied by chip vendors etc, some requiring costs, licensing etc... None of that is worthy to be a part of an open design, in my opinion...

Would it be more feasible to us in this community to use some design we already can master, and that we already have the tooling for? Should a PDP-11 be used for peripheral needs? If so, which model of the 11 should this "I/O-slave" be designed around?

Or is there already any "better" alternative (architecture so superior that it's worth learning/getting tools for) that I should put my eyes upon for this task?

opencores.org would be a good place to start.   The "wishbone" open internal bus would be a logical part of this, as a way to tie the embedded interface processor to other things it would need (like an Ethernet core for a UNA emulation, or an IDE interface for a UDA).   Then it becomes a matter of preferences along with the availability of supported programming tools.

Personally I like Forth, and not too long ago I started looking for a Forth processor.   It turns out there were several.   I think I dropped the idea before finishing the evaluation.   At least one or two look like they are serious and should work; one is 16 bit and another 24 (!) bit.   There is also one that was written in fake VHDL that doesn't actually work at all and never will...

Forth has the advantage of being a medium-high level language (not quite C but much higher than assembler), very compact and quite efficient.   Its origin is real time control (astronomical telescopes) so the fit is good.   I've used it in years past for pretty large projects; the "unsupported" interactive kernel dump analyzer "SDA" that's part of RSTS 10.1 is done that way.

	paul