Jump to content

trag

68030
  • Content Count

    3259
  • Joined

  • Last visited

About trag

Profile Information

  • Location
    Austin, TX
  • Interests
    Model & Amateur Rocketry

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I'm not aware of a RAM bandwidth tester. That doesn't mean I've never seen one. It just means I can't remember seeing one. Today. If I was looking, I might take a look in Tech Tools Pro. It seems like that's the kind of thing that might be in there, but I don't remember ever seeing one.
  2. That's bad news, but don't throw the boards away. Even if you decide to get rid of them, they may still be useful to someone for parts. I think I've seen new/unused PPC601 chips on Ebay for under $30. Heck of a soldering job though.
  3. Is that the one that is tetrachloroethylene (causes cancer, but only in California)? I ask because I have a couple of cans of brake cleaner left over, and while I was at the auto parts store I noticed that the can of Contact Cleaner from the same brand, was exactly the same size, and had exactly the same ingredient list (just the tClC2H4) as the brake cleaner but cost about $3 more.
  4. Actually, it's kind of an interesting idea. I don't like it, because I too abhor the fad of wanting to glue a Raspberry Pi on everything. Also, I just think programming things in hardware language is more elegant. But then, I'd rather program in assembly than C, and I do everything in my power to avoid going higher level than C. When one programs in assembly, one controls the result; programming in anything higher level than assembly is just making suggestions. Building hardware logic on an FPGA is even better.... But, my emotional shortcomings aside, the Pi already has all that logic and stuff for driving a display on board and its cheap. Finding a way to feed it a Frame Buffer from the Mac and make it come out of its already built video port is a very tempting morsel if the main desire is to build a working video card on least effort. Re: latency. I don't know what speed the Pis typically run at, but with the host machines running at 16 - 40 MHz, and more relevantly, the NuBus running at 10 MHz, one can fit an awful lot of Pi cycles into every host cycle. On the other hand, didn't dlv write earlier that one of his goals for this project is to learn to use a hardware description language?
  5. Perhaps this is already obvious to all those involved, and if so, I apologize for being the nerd jumping in unneeded... Re Quickdraw Acceleration: Many (most?) ROM/Toolbox routines are called as unimplemented instructions. The 68K architecture has a feature where there's a whole slew of unused op codes. If your software makes a call to one of those opcodes, it triggers a routine in the CPU much like an interrupt handler, where the program counter jumps to a location set in a vector file. So a bunch (all?) of the (Color) Quickdraw routines are called using these unimplemented instruction codes. The CPU handles those and goes to grab a program counter vector off of the address/vector table, and the program counter vector/address has been set up to point to the corresponding Quickdraw Routine in the ROM. In order to implement Quickdraw acceleration, or acceleration of any other routing contained in the ROM and called with this method, one simply loads a driver/extension at boot time that modifies the address/vector table. Specifically, go to that table and substitute the address for your replacement routine for the address in ROM of the stock routine. In the case of Quickdraw acceleration, this would probably take the form of a routine that sends a code/instruction and any necessary data to the video card, and the video card has logic that, for example, handles rotating the entire image 90 degrees in the memory of the video card, rather than having to read it all out the CPU memory, operate on it and write it all back to the video card. So you shouldn't really need special guidance, although it would be nice. It should be enough to identify the (Color) Quickdraw routines that are available. Decide which lend themselves to hardware acceleration. Learn enough about how they are normally called (any associated data structures/arguments, etc.) and then write your own subsitute routine that sends the requisite data to the video card hardware and add logic on the video card to do the processing. I'm pretty sure the Quickdraw routines are documented well enough to provide the necessary information. An example to copy or reverse engineer, would contain what? Maybe a clear list of which routines are worth accelerating?
  6. trag

    Ethernet Hub Repair

    AC adapter failure is probably the most common cause of small hub failure. The hub is fine. Its brick is sick. There are also probably caps on the hub's circuit board that eventually need replacing. I opened up an unreliable D-link 10/100 switch and there were a bunch of diseased electrolytics on the thing.
  7. I don't think that number is meant to be raw RAM bandwidth. I think it is RAMometer's report of the speed it managed in testing. A substantial portion of the test process is all the compare and branch statements. Which would explain why the PPC is so much faster. A typical test sequence involves writing the test pattern to memory. Then reading a portion to RAM, or just reading one word to a register. Then compare what was read to the test pattern, branch to the next test on pass, or fall through to error on a fail. Add in increments to at least the read address counter. So, at the least you have an address increment, a memory write, another address increment, a memory read, and a compare per every single word of memory tested. That's a far cry from how long does it take to read one word; how long does it take to write one word. BTW, I got similar results back when I was testing IIfx RAM with RAMometer: In theory
  8. trag

    Macintosh SE video problem

    https://www.digikey.com/product-detail/en/texas-instruments/SN74LS38N/296-1664-5-ND/277310
  9. trag

    Mac Plus Display Problems

    IIRC, Pina warns about discharging without a resistor and that it will cause that specific problem, somewhere in the text of one of his books. Perhaps in both The Dead Mac Scrolls and in Upgrade and Repair Secrets. I recommend against discharging the CRTs because of problems such as this. Also, I used to do a lot of work on compact Macs, and the **ONLY** time I got shocked by a CRT was in the process of discharging it. If I had just left the CRT alone, I would have been fine. Also, the shock was startling, but hardly life threatening. Perhaps if one has a pace maker... Anyway, that component is available from Digikey: https://www.digikey.com/product-detail/en/texas-instruments/SN74LS38N/296-1664-5-ND/277310
  10. trag

    SCSI to IDE adapters (bridges)

    They're great and fairly transparent performance-wise. I.e., the thing holding your disk system back will be the speed of your bus or the speed of your hard drive, not the capabilities of the adapter. The problem, as you alluded, is that the time to purchase these affordably has come and gone. About ten or twelve years ago, there were hundreds of the adapters available for about $30 each. Now they are somewhat difficult to find and typically command $150 - $200. Ouch. Acard made/makes a large line of such adapters. The AEC-7720U was a good model to use in the typical Mac, but again, hard to find and expensive today.
  11. Newertech's RAMometer which is later subsumed in their Gauges set has a continuous memory test. Run it as long/as many iterations as you like. I think it must alter the data patterns from one run to the next, because back when I was buying new DIMMs, I'd run it on new memory and usually faulty stuff would fail within 10 - 15 iterations, but there was some stuff that only failed around the 1200 - 1500 iteration mark. And it failed consistently in the same place. Cell leakage in capacitive memory cells based on data patterns in surrounding cells is a whole other topic... I keep a copy here: https://www.prismnet.com/~trag/Ramometer.sea.hqx and https://www.prismnet.com/~trag/NewerTech/ or maybe: https://www.prismnet.com/~trag/gaugepro1.1.sea.hqx https://www.prismnet.com/~trag/gaugepro.hqx
  12. Those early PPC601s can overheat within tens of seconds, so don't try to operate it without the cooler. Clean off the crusty old heat sink compound and reapply and replace the heat sink.
  13. If you're seeing the full RAM you should be fine. The currents involved are tiny. They could cause signal integrity/ringing problems if not balanced properly, but they won't blow the board. I suppose in a ridiculously sensitive machine, it might be possible to destroy the output buffers on the memory controller. The bits of logic that output the actual signals to the DRAM modules are rated to output a certain level of current. If you connect a whole bunch of extra RAM chips to them, then for example, the address output buffers might see too low of a resistance (too much current drawn) and this could in effect be the equivalent of being exposed to a short to GND or 5V. But that's really far fetched. The main thing I was concerned with, when I read your first message, is memory that seems to work, but isn't actually reliable. This would only be a concern if your two bank memory was seen as 1/2 capacity. If the board was truly one bank only, then it would be activating all the /RAS signals to a DIMM socket for every transaction. On a dual bank board, half the RAM is connected to two of the /RAS lines and the other half of the RAM is connected to the other two /RAS lines. The computer selects between them by selectively activating the /RAS lines. Otherwise all the signals between the two banks are common. So, when a machine accesses a double-banked DIMM/SIMM as if it were single banked, it is actually performing all the reads and writes to both banks simultaneously. This overloads the data bus on reads (a little) but has the bigger issue that tiny variations in process (manufacturing process) might cause the RAM chips to try to drive the data bus at different levels, the contention can cause all kinds of signal noise. In practice, I think this rarely happens.
  14. Ultimately, for VGA output, I was looking at something in this family for a, geeze, I'm having vocabulary failure today, the thing a majigger that acts as the D to A converter and changes a stream of pixel data into video out data. ths8135.pdf ths8200.pdf THS8133.pdf ths8134b.pdf The THS8135 is less than $10 at Digikey. But to start with, using the VGA output provided on the/a development system simplifies matters tremendously. Leave all the CLUT stuff for later, unless the Macintosh requires it and won't work without it.
  15. Here is a summary of my thinking, back when I was looking at this type of project. The FPGA development board I was looking at (something in the Spartan family) had a DDR2 chip on board and a rudimentary VGA out port on board. The VGA port was actually something like a ridiculously crude (resistor ladder?) D to A converter, but servicable. Code for displaying images through the VGA output for the development system was available. Code for using the DDR2 chip was available. My thought was that the starting point should be, as others (Gorgonops) have noted above, choose a segment of the DDR2 to use a frame buffer. Point the VGA display code for the development board at that region of memory. Then the two tricky parts remaining, are: 1) Provide a (mumble, what'sit'called?) ROM that will tell the host system this is a video card. 2) Provide an interface so that reads and writes on the NuBus (or PDS) interface come from and go to the segment of DDR2 being used as a frame buffer. You can work up to these things in small steps. I would start with: 1) Get the VGA display code working. Display a solid color or other test images. 2) Learn to write to and read from the DDR2 using potted code. 3) Learn how to point the source for the VGA display at the DDR2 chip. 4) Change the DDR2 contents and watch to see the VGA display change. 5) Interface the FPGA development system with the Macintosh electrically. 6) Get the FPGA interface to the Macintosh bus working. Try some simple write to/read from experiments from Macintosh to FPGA. Perhaps something as simple as a program on the Macintosh that pokes an address in the FPGA/expansion card address space and lights up an LED on development board. 7) Get the declaration ROM recognized/working. 8 ) Set up the declaration ROM to point at the segment of DDR2 chosen to be the frame buffer.
×