On Thu, May 13, 2004 at 11:31:25AM +0200, Fred N. van Kempen wrote: The RK611, but not a UDA50 or anything else that is "smart". When I go through the work of designing a UniBus board, I would put enough on it to run NetBSD on the controller. The UniBus attachment should be implemented in a FPGA to have maximum flexibility in the hardware. Software on top of this should be a NetBSD kernel driver, perhaps with a userland daemon to support the kernel driver and control it. It would be possible to emulate any UniBus device, including a PDP-11, VAX, PDP-10, ... CPU. Unfortunately I don't have the experience nor the resources to build a board like this. "Hey, I can telnet / slogin to the disk controler of my PDP-11!" That would be expensive, but you can do _anything_ with it. So you can use the board for a wide range of applications, resulting in higher production volume and lower cost. I know that a list member was designing a board like this. I don't know how far he got. But my offer is still valid: Give me hardware and I'll care about the NetBSD port. A re-implementation in discrete logic was my thought too. Depending how it fits it may be possible to build a UniBus / QBus combi-board that could be used in both busses depending on jumper settings. -- tsch??, Jochen Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/

On Thu, 13 May 2004 07:25:20 -0700 (PDT) "Peter C. Wallace" <pcw(a)mesanet.com> wrote: I have experience in porting NetBSD to new hardware platforms. If it is an already supported CPU the work is not that hard. I would prefer some PowerPC based stuff. I don't know about the embedded MIPS chips, but I know how fast a StrongARM or Xscale is and that a (quite old) 300 MHz PPC604e is much faster. PowerPC is very well supported in NetBSD and GCC[1]. It is continuously improved thanks to the macppc users. Maybe it is posible to use an already existing evaluation board and interface it to the UniBus... I would not use non-PCI devices. If all I/O beside the UniBus hangs of PCI, all you need is a machine dependent PCI backend in NetBSD to give you acces to all PCI devices already supported by NetBSD. That way you need only to implement a single driver for the PCI bus, not one for every device on your board. Well, when you say. Discrete analog stuff is not my territory. ;-) [1] GCC likes to generate sub-optimal code for "non mainstream RISC" CPUs and you have to be prepared for compiler bugs on "non mainstream CPUs". -- tsch??, Jochen Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/

"Peter C. Wallace" wrote: ... I'm designing a simple board with a PIC cpu and a CPLD which should be able to emulate virtually any disk controller (given software). I have found about 100 of the unibus drivers on the secondary market. The idea is that the cpld holds a register set which the PIC and unibus can read/write and the PIC can be a bus master to read/write unibus memory. A serial port will allow the firmware in the pic to be updated to allow one to change controllers. An IDE interface for a true ide disk or CF card is on other side. My goal is to start with something simple like an RL02 interface. I may go on to do something like the UDA50. This is mostly because I have an RL02 and UDA50 controller. I'm still on paper, so I may substitue one of the cool philips ARM cpu's which have built in flash and ram, mostly because I could then write the emulation code in C. It depends on the speeds I need. I have not done the unibus hdl code yet, and that will drive the timing of the cpu. Initially I want the device to be able to run in "stupid ide mode" by programming the cpld as a pass through and exposing the ide registers directly on the unibus. This way the device can be useful right away and gradually get more sophisticated as more software is written. If I do it right the cpu should be able to reprogram the cpld so everything can be field programmed. the real problem is that my day gig keeps getting in the way of my fun :-) I hope to have a prototype this summer - I'll certainly publish everything and take orders if anyone wants one :-) -brad

On Thu, 13 May 2004 12:57:52 -0400 Paul Koning <pkoning(a)equallogic.com> wrote: [...] Programm and wire the CPLD so that it generates an interrupt to the PIC when the register file is touched. Issue a vector along with the interrupt that tels the PIC which CSR was touched. -- tsch??, Jochen Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/

On Fri, 14 May 2004 09:06:39 -0400 Brad Parker <brad(a)heeltoe.com> wrote: Sure. But when your CPLD is complex enough (or if it is a FPGA) you can implement the controler lookalike logic in the CPLD hardware. E.g. the already mentioned fixed value read only bits in a read / write CSR. -- tsch??, Jochen Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/

Brad> Paul Koning wrote: Brad> well, yes, cpld need to notice when a register is written from Brad> the unibus and potentially interrupt the cpu. Brad> there are certainly some interlocking issues to keep the two Brad> cpu's in sync. Brad> no reason why the cpld can't do this on bit by bit basis... It's worse than that in some cases. For example, if you have mixed read/write and read-only bits, if you write the CSR and then read it, you want to read the correct read-only status values. If you try to fake this by having a microprocessor restore those bits after being interrupted by the CPLD, the read may get there first. Similarly, the values you see in one register may change depending on what's in another register. An example is the drive status, which reflects the currently selected drive (in a number of disk controllers). Again, a software emulation may not get there in time. You might try to cheat by holding off SSYN on the Unibus read until any pending CSR fixups are done, but then the microcontroller has a rather tight time limit (20 microseconds or so). paul

Jochen> On Wed, 12 May 2004 23:30:49 +0100 Frank Arnold Jochen> <fm.arnold(a)gmx.net> wrote: Jochen> Sure. But who will fab the big, odd-shaped UniBus boards? Do Jochen> you have enough UniBus transceiver chips in stock? Transceiver chips might be an issue. The board doesn't have to be all that big -- quad size is enough. Jochen> Hmmm. Replicating the RK611 in an FPGA is an interresting Jochen> idea. - If you can get complete shematics and there are no Jochen> funky things like an AMD bit slice CPU in it. All the disk controllers before the MSCP family are hardwired logic (except maybe the RL01, I'm not sure about that one -- and ignoring screwball stuff like the Pro disk controllers). So none of them should be all that hard. If you want to emulate an old disk controller, the RH11 family might be better, since those are larger disks, so you can put larger flash cards to good use. Jochen> There isn't one if I use the original RK611 controler. That Jochen> is an other issue: If you emulate the entire controler, you Jochen> have to make the emulation good enough for all operating Jochen> systems. It may work for a RK611, but what about a UDA50 with Jochen> its AMD bit slice CPU or a controler that has a T11 with some Jochen> non-trivial firmware on it. You can't stick this in a (cheap, Jochen> small) FPGA. The UDA doesn't have a T11 in it. What it has is about 200 words of microcode that implement a small instruction set that looks a lot like a stripped-down simplified PDP11 instruction set. But it isn't a PDP11 instruction set and it isn't done with a PDP11. The 2901/2910 is a pretty simple beast; it would be easy enough to put that in an FPGA, I'd think. The real issue is that you'd have a hard time finding the UDA firmware. Then again, if you wanted to emulate an MSCP controller, you don't need to emulate the structure of the controller, you only need to emulate the command interface. That is certainly doable. (It's been done before -- consider the various PDP11 emulators.) paul

On Thu, 13 May 2004, Jochen Kunz wrote: You could do a very short (2 inches?) card to save PCB costs Well, a Spartan3 XC3S200 is about $16, has about 27K bytes of block RAM that can be used as RAM or ROM, and you could fit at least a couple of 100 MHz 16 bit CPUs inside plus whatever other hardware was required. It would require level shifters for the bus however. Peter Wallace Mesa Electronics

Xilinx has embedded PowerPCs inside Virtex-II FPGAs. SDRAM interface is certailnly possible to arrange on that kind of FPGA, if you need. PCI is certainly possible to achieve at a cost (money or blood, sweat & tears). For more info go see the site below. http://www.xilinx.com/ipcenter/processor_central/ultracontroller/index.htm Probably not for this one. Anything commercial and good enough to handle these big FPGAs will cost you dearly. Without any detailed knowledge I would guess you will end up at about 10 to 20 kUSD (or more) for a profes- sional design kit (e.g. Synplify HDL synthesis, Xilinx ISE place & route, ALDEC AHDL simulator, all these Win blech :) The more *IX you want the more bucks you have to pour into it. I know about gEDA and Icarus verilog, but have so far had no luck... We are all admitted to have an opinion, no matter how unpractical... ;) Good luck. /Ulf A.

On Thu, 13 May 2004 19:57:02 +0200 "Ulf Andersson" <ulf.andersson(a)sodra-moinge.se> wrote: Well. If there is no other practical way I would use a WinPeeCee, but only in the way of a tool / appliance. Switch on, do work, switch off. I don't need it for anything else. -- tsch??, Jochen Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/