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.

> 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.

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

> The components one would need are:
> 
> TH8200 or TH8135 DAC (converts digital data into video signals for monitor) < 
> $10
> Xilinx Spartan 3A XC3S700AN - FG484   ~$40
> 200-pin DDR2 SO-DIMM Socket              ~$3
> 200-pin DDR2 SO-DIMM (any size)          ~$16
> Connector to Logic Board                           $4 - $10
> VGA and/or DB15 connector                      $5 - $15
> Non-volatile memory (Flash)                        $3
> Printed Circuit Board                                  ~$15
> 
> Total:                                                             $96 - $112
> 
> Xilinx has IP included in their development tools for the DDR2 controller.   
> The toughest part would be learning and understanding the Macintosh interface 
> and the declaration ROM.    The Spartan FPGA can run at 166MHz, so at least 
> four times faster than the Macintosh bus.  It would handle translating read 
> and write requests from the Mac bus to the DDR2 memory and pulling words out 
> of the DDR2 in order to send to the DAC.  It probably needs to be between the 
> Flash/declaration ROM and the Mac interface as well since the Flash will also 
> load the FPGAs configuration.
> 
> DDR2 may seem like an odd choice for the VRAM, but I've looked at the various 
> options, and it really seems to be the best choice economically and 
> performance-wise.   Some fast SRAM would be easier to work with, but that 
> stuff is relatively very expensive and also difficult to find in speeds which 
> will challenge the DDR2, even with the latency.

I have a reasonable amount (perhaps 32MB) of NOS SRAM purchased years ago for 
Quadra projects (it was more difficult finding the connector than the memory.  
I think it is 10nS or so which is fast enough.  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).

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.

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.  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.  
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.  You may think a write 
is easy, but multiple writes in a row can occur...  Or writes and reads can be 
intermingled.  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.

Years ago I built a PC-104 intelligent I/O controller.  It had a 20MHz or so 
PIC processor running a custom pseudo RTOS.  Even though the PC-104 ISA bus can 
only achieve around 1-2 MBps, I used a 16 bit bi-directional hardware buffer to 
ensure maximum performance.  This allowed the main processor to complete a 
(single) bus transfer at full speed without needing to wait for the PIC to 
respond to the I/O event.  As soon as there was data in the buffer it triggered 
an interrupt in the PIC which was handled sufficiently fast enough to clear the 
buffer prior to the main processor being able to make another transfer.  On the 
reverse side the PIC was able to place data in it's buffer which would trigger 
an interrupt on the ISA bus indicating an I/O event to the main CPU.  When the 
buffer was read it would automatically clear and alert the PIC to the event via 
another interrupt.  This method allowed me to keep the ISA bus working at 
maximum efficiency.  Without this hardware buffer the 20MHz PIC would not have 
been able to respond quickly enough to the ISA I/O request and wait states 
would have been inserted as a result.  This is especially true since the PIC 
was handling other tasks concurrently (it was an intelligent I/O controller 
after all).

> Besides, with a DDR2 DIMM on board, the video card could double as a big RAM 
> disk, and/or a RAM expansion card.   The video is only going to need 
> something like 8 MB of VRAM.  The rest of the 512MB+ is available for other 
> things.

Keep in mind that each "slot" is allocated 256MB in 32bit mode.  You can 
certainly assume control of additional memory space (with a PDS card), but the 
total space allocated to the NuBus slots is 2GB...  Which should be more than 
enough I would think.

I am certainly not trying to throw cold water on your ideas, just offering some 
thoughts of my own.

Derek

-- 
-- 
-----
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.


Reply via email to