I can't believe what I started. I would be interested in a card as well.
It was asked a while back (and forgive me, my career is torture at the moment - better than bit having work in this economy) how I got the dos card in the centris and how I managed to use an AV card in a centris. The dos card plopped right in. No problem. Prior to that, I had a 7" NuBus adaptor for that machine in the hopes i could find a video card that would run my 20" multiple scan monitor. That turned out to be a pipe dream. I went digging through my stuff and found an adaptor card that had a similar PDS slot my 7100 has. (A right angle 7100/8100 series PDS slot)(Copyright 1994 apple) it had no card in it. I slapped my AV card from my 7100/80 AV in it and it fit perfect and then I dropped it into the centris. Once in the monitors control panel I was surprised to see my second display options. It works pretty well. I traced the adaptor back to having been used for the very small quantity of 6100 AV machines that were made (most AV machines were 7100's or 8100's) I remember I had acquired this card in hopes to replace the stock board with my 300mhz sonnet G3 upgrade and keep my HPV card since the on board video doesn't have enough memory for decent colors on anything larger than a Macintosh color display. That never panned out... The bolt holes were not even close so the card would flop all over in the machine. Sent from my iPhone On May 15, 2013, at 1:36 PM, Jeff Walther <[email protected]> wrote: > > > On Wednesday, May 15, 2013 7:34:49 AM UTC-5, Derek Morton wrote: >> >> >> On May 14, 2013, at 11:29 AM, Jeff Walther wrote: >> >> > >> > >> > On Tuesday, May 14, 2013 10:06:03 AM UTC-5, Derek Morton wrote: >> > >> > Phoenix Enterprises. I was originally quoted $3.46 each 4 years ago and >> > paid $3.85 around 1-1/2 years ago. Minimum order of $150... It would >> > seem I only purchased 50 where I was remembering 100... So much for my >> > memory. >> > >> > http://www.phoenixent.com/ >> > Search for p/n 8807-140-170LH >> > >> > Their website indicates a stock of 3600 and I have requested a quote for >> > pricing (including minimums and break points). >> > >> > >> > Ouch. The individual pricing is okay, but I'm not committed enough to pay >> > the minimum. >> >> Depending on the current pricing, I may be willing to make a second >> purchase... If I do, it would certainly be easy to add a few more pieces. > > Thank you. If you do, please let me know. I would enjoy having a few of > those on hand. Perhaps as many as ten. > >> > I considered building a frame buffer card for the SE/30 a while back. I >> > would still like to, but realistically, I won't get to it until my son >> > finishes college (5th grade now). >> >> This is my problem... 3 & 5 year old sons. > > They're rewarding, but mine leaves me wondering what I was doing with my time > before he came along. :-) It doesn't help that I'm coaching his LL baseball > team two seasons a year. Being head coach is like having a second job. > >> I still have my Micron card (w/greyscale adapter) in my SE/30 so I am set! >> There certainly is an advantage to having been "into" these systems for a >> great many years. My SE/30 was purchased new as an SE back in '88 I believe >> and after upgrading it I purchased a DayStar SE/30 specific 50 MHz >> accelerator and the Micron bits new... Well new, but when they were older >> and not so expensive. LOL > > Nice! Is that the 6030 socket based SE/30 upgrade? I think I recall you > mentioning it in the past, but with so many years on the list... > >> One of my projects was going to be building a zero wait state SRAM Q-950 to >> see how fast it can run when unimpeded by DRAM. I believe Micron once >> offered a full zero wait state SRAM 486 system that was a screamer in it's >> day (though a tad pricey). > > I think I remember discussing that Q950 idea with you at one time. Have you > followed the work that bbraun has been been doing over on 68kmla.org? He's > made a lot of progress decoding/disassembling the Mac ROM to see what it is > doing at low levels. He's created a couple of hacks that increase the > maximum supported memory on some machines, for example, by changing things in > the ROM. > >> Some other things to consider... Power supply (+5V to whatever your system >> needs)... Level shifting (+5V to whatever your system uses)... Buffers >> (possibly in conjunction with the level shifting). You will want to protect >> the real world outputs too. Then there are the multitude of caps and >> resistors which are always present... Not much, but these things do add up. >> The power supply might add an additional $5 - $10 depending on the >> requirements. > > Yep, forgot about power and level shifters. I shouldn't need buffers, as the > FPGA should be capable of handling that function, but there is the possiblity > that having them combined with the level shifters would offer some advantage > that couldn't be had going from level shifter to FPGA. Those will add at > least a few dollars to the cost. And, of course, the ubiquitous caps and > resistors. > >> I am not sure a 160MHz micro-controller will give you the performance you >> hope to achieve. Since you are talking about removing the memory from the >> system bus, your controller will need to be able to recognize a CPU request >> and respond to it in a single memory cycle if you want to maintain maximum >> performance. > > Removing system memory is only a nice-to-have goal. The real goal is just > getting a frame buffer working. But the FPGA would almost certainly be > faster than the existing Quadra memory, although I don't think it's possible > to guarantee zero wait state access. I guess one could with fast enough > SRAM. On writes, the FPGA can buffer the incoming data and hide the DDR2's > latency. On reads, if the data isn't already buffered, and if there's a row > change there will be several FPGA cycles of latency. However, with a 4:1 > ratio between the FPGA and the Quadra, that won't be bad. > >> If you were doing nothing else you might be able to do it... But your FPGA >> is (at the least) going to be constantly moving data to the DACs. > > But that's the beauty of using an FPGA instead of a microcontroller. The > circuit moving data to the DACs is separate from the circuit interfacing with > the host. There's communication between them, because during a VRAM read for > the DAC, the host cannot be accessing the VRAM, but that's always an issue > unless one has double-buffered memory. > > Anyway, the host interface circuit can handle all the communications with the > host, at the same time as the DAC feeding circuit is doing its job, because > different portions of the FPGA are handling those tasks. The only contention > is if they both need to access the DDR memory at the same time. And with > judicious use of internal buffers, that can be minimized. > > Alternatively, I have 2000 SGRAM chips on hand which are 256K X 32 X 2banks @ > 100MHz. I could just use four of those. :-) > >> Consider a 40 MHz PDS bus (yes I know Apple never made one, but many of us >> have over-clocked their systems to achieve that) and the timing requirements >> of said bus. Yes, your FPGA is running at 4x the PDS bus speed, but you >> must detect the request (let's say a memory read), get the information >> requested and place that information on the bus within the request timing. > > As I understand it, the memory accesses use an acknowledge system, so other > than performance desires, there is not really a minimum timing to meet. Or > are there both synchronous and asynchronous modes? In any event, I think I > can get the FPGA/DDR2 combination to be faster than the 70ns FPM DRAM > interface. How much faster is certainly an important question, and, > arguably, where the fun lies. > >> You may think a write is easy, but multiple writes in a row can occur... Or >> writes and reads can be intermingled. > > The worst case would be multiple sequential reads with memory addresses which > all require changing rows in the target memory. > >> Since the idea of PDS over NuBus is performance you certainly don't want to >> slow things down to the point where you may as well have used NuBus. > > Agreed. I have a design concept. Until I make time to actually design > something, I won't know for certain what kind of performance I can hit. It > will be so many years before I can do somethign with this idea, that by then, > there will probably be an EDA tool to which I can just feed the concept and > it will create the finished product. :-) > >> Years ago I built a PC-104 intelligent I/O controller. <snip>This method >> allowed me to keep the ISA bus working at maximum efficiency. > > Buffers and interrupts are nice. The IIfx uses a set of buffers for writes > to DRAM. If it does a single write to DRAM, it releases the bus in one or > two cycles, because the data is in the buffers, and leaves it to the memory > controller to actually get the data from the buffers into the DRAM. This > requires DRAM with separate Write and Read pins, which is also why the 1 byte > wide SIMMs had 68 (64?) pins instead of 30. > >> I am certainly not trying to throw cold water on your ideas, just offering >> some thoughts of my own. > > Not at all. This is fun. And it's better to have the problems and > challenges pointed out **before** one starts actually building a device. Of > course, since I'm in no danger of building anything in the near future, you > have lots of time to think of those challenges. > > Jeff Walther > > -- > -- > ----- > You received this message because you are a member of the Vintage Macs group. > The list FAQ is at http://lowendmac.com/lists/vintagemacs.shtml and our > netiquette guide is at http://www.lowendmac.com/lists/netiquette.shtml > To post to this group, send email to [email protected] > To leave this group, send email to [email protected] > For more options, visit this group at > http://groups.google.com/group/vintage-macs > > Support for older Macs: http://lowendmac.com/services/ > --- > You received this message because you are subscribed to the Google Groups > "Vintage Macs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > -- -- ----- You received this message because you are a member of the Vintage Macs group. The list FAQ is at http://lowendmac.com/lists/vintagemacs.shtml and our netiquette guide is at http://www.lowendmac.com/lists/netiquette.shtml To post to this group, send email to [email protected] To leave this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/vintage-macs Support for older Macs: http://lowendmac.com/services/ --- You received this message because you are subscribed to the Google Groups "Vintage Macs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
