> Mostly the lack of any ability to disassociate stuff. I think I get where you are coming from. I've never approached FPGA work in this manner. What I mean

> Mostly the lack of any ability to disassociate stuff. I think I get where you are coming from. I've never approached FPGA work in this manner. What I mean by that is that every single FPGA board I've worked on I designed from scratch for the specific narrow application we were trying to address. I haven't had the need for full or partial dynamic reconfiguration at all. Maybe I misunderstood. Modern tool sets from Xilinx (and probably Altera, but I am not that familiar with their offerings) have the ability to do incremental compilation. That, combined with allocating an area to your framebuffer code should net you reasonably quick design iterations. Unless you are trying to do more than the basics a frame buffer isn't all that complex. A standard DRAM controller core to talk to memory, a set of FIFO's and a state machine to decide who does what when. If this is strictly for painting text and some basic graphics on the screen it's a relatively simple matter to double or triple buffer the interface you can render text/graphics in the background and flip between the live and background buffers during the vertical blanking period. S-100. Ah. The good old days when you could actually wire-wrap your own peripheral boards. Here's a data point to date me: I ran AutoCAD on an S-100 system with a separate S-100 math co-processor card and a 640K ram-drive card. Worked like a charm. Oh, yes, interaction was through a VT-100 terminal (the real deal) and a tablet with a wired puck. How many people on HN do you figure actually touched an IMSAI (outside a museum)?