Jump to content


  • Content Count

  • Joined

  • Last visited

About dlv

  • Birthday 09/19/1986

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    San Francisco Bay Area

Recent Profile Visitors

252 profile views
  1. Thanks. That read more like marketing for the 8*24 GC but was still interesting. What I was looking for is Imaging With QuickDraw (PDF), which I highly recommend since it has answered a lot of questions already. A quick search revealed Apple donated the source code of the 68000 QuickDraw implementation to the Computer History Museum. It's a fine software-only reference implementation (although may not implement Color QuickDraw) - and might even be able to be used largely as-is if we had a 68k processor or FPGA core available to us - but that's only part of the challenge. What's missing w.r.t. accelerated graphics cards is the interface between an accelerated QuickDraw implementation and the hardware, and how an accelerated QuickDraw is enabled and used. Also, how QuickDraw operations are queued for execution. That's likely to be highly implementation-specific, so I don't expect to find documentation. Reverse-engineering the 8*24 GC may be necessary (but would require in-depth knowledge of several things, including the Am29000 processor).
  2. Yes. And a shift register is a much better/cleaner idea.
  3. Yeah. Well, a big part of what I want to get out of this, is to learn about FPGAs and FPGA logic design. Any plans with ARM would be way down the line. Perhaps soft cores might be worth looking into for QuickDraw acceleration later? Where might one read more about that? Yes. It might be worth exploring if SDRAM becomes intractable. It is, thanks. That's roughly what I expected for a CLUT. I don't think B&W support would be hard either? I imagine (naively) you'd probably want to read a byte (for example) every eight pixel clock cycles, and on every pixel clock cycle perform some bit masking to determine the state of the current 1-bit pixel, then output the appropriate 24-bit pixel. That is more or less the same progression I see, except HDMI and SDRAM instead of VGA and DDR2, respectively. I used "streaming" kind of loosely, sorry. There is no primitive (some sort of DMA?) for grabbing bytes from memory and pumping them to the TMDS encoder that I am aware of. I agree CLUT is not a big deal, at least in theory. I was simply lacking imagination at 4am last night for how it might be done in an FPGA but BMoW's pseudocode totally makes sense. Yeah, I briefly looked at the equivalent ADV7123 DAC, since that's what's used on the optional daughter board (which I did not purchase) of the QMTECH FPGA dev board I have. QMTECH ships an example design to drive that IC. The link I shared earlier about hacking 1080p @ 60Hz output from a Spartan 6 appeared to imply an HDMI TX IC would be able to workaround the serialization bandwidth limitations of that FPGA, so I also looked at the TFP410 and ADV7513. --- BTW thanks again for all the input and discussion. I'm definitely going to need all the help I can get to have any hope of realizing this project.
  4. I wanted to elaborate my thinking: I think true color is actually a natural choice to target at the beginning because it's what the HDMI TMDS encoder takes as input. Supporting B&W would require extra FPGA logic to stream 1-bit pixels and convert them into a 24-bit pixels to feed into the encoder. That is probably not hard but I wouldn't know where to begin with a design. Similarly, supporting a CLUT would need extra FPGA logic to perform the lookup and stream 24-bit pixels. I'm certain these are solved problems, but let's follow the path of least resistance. The unknown for me is how MacOS interfaces with CLUTs but that mystery can wait.
  5. Yeah, I find myself going back to a NuBus design: Easier than I expected to understand (so far). E.g., after a few hours tonight, I understand, at least at a high level, how single transaction reads and writes work. Maybe avoid having to re-read the Motorola MC68030 manual for now. It's not clear to me whether a read of the NuBus/NuBus90 specification is necessary yet. Electrically slightly less challenging (10MHz, fewer I/O pins, fewer things to solder when the time comes) Will work in my Quadra 950 No need to source a Mac with a 68030 PDS (although I think I want an IIfx some day) I've also been musing about the possibilities a FPGA with ARM SoC opens, just for fun. It might be possible to do some really neat stuff like running WebKit on the ARM cores and rendering to a framebuffer that's overlayed onto space within the window of a custom browser interface. A hardware web accelerator. Some thoughts on current discussion: I wouldn't rule out the use of a fast microcontroller either but I believe a FPGA really is the right tool here. I'm not worried about color depth or CLUTs appreciably affecting complexity? I'm oversimplifying but I suspect that B&W output will be just as challenging as true color, but once we figure out any sort of output, other modes will follow.
  6. A little bit... After a quick Google search, it appears the Spartan 6 doesn't quite support 1080p at 60Hz. And in fact, I see now the VA2000 lists 1080p @ 30Hz support as experimental. This is not a show stopper, of course. There is still plenty to learn. It appears Lukas is developing a successor to the VA2000 called the ZZ9000, which so far appears to be a carrier board for the MYiR Xilinx Zynq-7020 FPGA development board, with a lot of interesting features including full 1080p support, but release of schematics and sources is pending. This is one of the dev boards I was originally considering but my desire to stay close to the VA2000 project, plus its significantly higher price ($120) led me away from it.
  7. My guess is since the FPGA is going to spend the majority of its time reading from the framebuffer and pushing pixels, that needs to be really fast or at least take priority. One way to make it fast is to use techniques like burst reads from RAM, which we may not be able to take advantage of if we're constantly skipping across memory. Or at least not without a lot of added complexity. There are likely other timing considerations e.g., DRAM bank refreshes. Right. I think with the introduction of FIFO buffers, the matrix transform might even be effectively transparent. Can you elaborate this? Where are you getting that number from (240MB/sec)?
  8. dlv

    Dual 600MHz Cube

    Wow, very cool!!
  9. Oh hmm... I dismissed the need to support CLUTs (my own interest is in true color at 1080p) but that totally makes sense for a general purpose video card. I recall someone suggested this earlier in the thread. I agree it could be worthwhile for hints and testing assumptions in software. Perhaps even a software implementation. I suspect that would not be technically difficult to implement once everything else has been figured out but I wonder what is required in the software/driver/ROM side to make that option available. I know Apple developed portrait displays, so it must be possible. Another exciting possibility is dual screen support, provided the FPGA has the bandwidth to push that many pixels. In any case, we're kind of getting ahead of ourselves... Baby steps. It's clear I need to do a more thorough reading of the NuBus documentation. Regarding the challenge of communication... This is one of my favorite diagrams. We need to be patient with each other
  10. That's exactly the same conclusion I have come to regarding a PDS design vs NuBus design. I read through a good chunk of the Motorola 68030 manual two years ago to try to understand what would be involved with creating a quad-processor homebrew 68030 computer (entirely too ambitious), but it has been long enough that I would need to revisit it. I don't expect PDS will be "easier" but in a way, it's "better understood" (modulo Apple-specific stuff) because at that level, you can discuss general computer architecture design and techniques. I think this project is actually feasible, given that the VA2000 and similar open-source projects have led the way and done the bulk of the work. As you identified, the main challenge is the PDS/NuBus interface and hooking everything up. I expect large portions to be borrowed wholesale from the VA2000 project. That said, I have a professional career and life, so progress will be sporadic
  11. Well, if only because these machines are well documented in documentation accessible to me. I suspect the number of available I/O pins on my FPGA board is likely to dictate the decision between NuBus and PDS. State machines appear to be natural to implement in a FPGA so the prospect of implementing NuBus isn't as daunting as it once was, although by no means do I expect it to be trivial. I know you had some concerns about the speed of NuBus, which I share, but that seems like a later concern compared to getting it to display anything. Thanks for the offer. Alas, a 68040 PDS card is extremely unlikely, not only because the connector is challenging to source but because the additional I/O lines would put it beyond the number of I/O pins available on all FPGA development boards I've seen. It would still be possible to press forward but would require designing the entire card from scratch (perhaps copying portions of the design from an FPGA development board which is what the VA2000 project did from the miniSpartan6+), and then soldering the FPGA's BGA package and other components onto it. But that's well beyond what can be done (reliably) at home, so it would be necessary to reach out to a fab to not only manufacture the PCB but assemble and place components too... That only makes sense at scale, which requires capital. In that case, it would likely have been realized as a NuBus design in the first place, since it would then work in the greatest number of machines. But it's fun to dream
  12. Hi all - I'm sorry I've been remiss posting updates. At this point, I have the FPGA, its JTAG programmer, and development environment (on my Windows 10 machine) all working. I'm able to upload and write bitstreams, get LEDs to turn on with the push of the a button, etc. All the basics I had originally set out to do. I've been reading FPGA tutorials and looking through the VA2000 code, especially to understand how the author implemented the state machine for the Zorrow II/III bus. Documentation-wise I've read through (mostly IIfx-relevant parts of the) 68030 PDS discussion in DCaDftMF3e. It was enlightening but it appears I need to go back and understand parts of the NuBus documentation because the PDS documentation largely focused on the physical and electrical design guidelines. I also continue to pour over technical specifications for various components on the FPGA dev board, the FPGA itself, HDMI/TMDS, etc. I've also started a draft of the schematic for the FPGA carrier board. Gorgonops is correct that interfacing the FPGA with HDMI and SDRAM/DDR memory is a solved problem (indeed, many decisions I've already made have been in the hope of recycling as much of the VA2000 project as possible). Getting it electrically hooked up to a NuBus/PDS bus is a matter of a handful of some level converters. The FPGA can drive HDMI signals directly. And so the carrier board will essentially be an adapter. This also means the meat of this project is going to be in the FPGA code, specifically interfacing between NuBus/PDS (DeclROM, pseudoslot addressing, etc) and the FPGA modules driving HDMI and SDRAM. Where I left off was pin I/O management: The FPGA dev board makes available 108 I/O pins (the FPGA itself has a lot more, some of which are used to connect to the onboard SDRAM and SPI, etc). The (IIfx) 68030 PDS slot has a 120 pin connector of which it appears 24 pins do not need to be connected (because they're tied to power, ground, reserved, etc) to the FPGA, which leaves 96 pins. HDMI appears to require (from the VA2000 schematic) two pins each (a differential pair) for DATA0, DATA1, DATA2, and CLK and another two pins for SCL and SCA (for EDID). So it's tight - we're just under, at 106 I/O pins - but we also need pins to drive the direction of the level shifters, which is where things get tricky: What signals are unidirectional? Bidirectional? When? Which can be grouped together? I believe I need to revisit the MC68030 documentation for answers. If we need more than 108 I/O pins, are there PDS pins whose signals we do not need? Perhaps it would be good to go back to a NuBus design? My goal now is developing this carrier board because that appears to be the requisite before anything interesting can happen. Since I don't have the time, resources, and experiences to make PCBs at home, I plan to submit the design to a fab. But that means less room for experimenting / need to get things right the first time. Once I have a carrier board in hand, some good first experiments would be outputting something to HDMI, or as Gorgonops suggested, writing to a register and blinking LEDs on the FPGA dev board. Once those kinds of experiments are working, I think further development will be rapid since it's a matter of hooking together the existing FPGA modules. I found from the "Macintosh Quadra 900 Developer Notes" document that the 68040 PDS connector on the motherboard is a KEL 8817-140-170SH. The PDS card connector is a KEL 8807-140-170LH. From what I've seen, these connectors are difficult to source except at wholesale quantities. I've resigned to the fact that a PDS video card for my Quadra 950 is unlikely, at least for a first iteration. Note: I've been targeting the IIfx because that's the only 68030 Mac I would be interested in collecting, but an IIsi might be cheaper for this project (and less of a big deal if I break it in the process)... If anyone has either of these available, please speak with me.
  13. Not a whole lot from me. Work has been demanding a lot of my time as deadlines approach. The FPGA and USB programmer arrived last week but I need to source a 5V power supply to begin playing with it. In the meantime, I've been learning about TMDS encoding (used in DVI/HDMI/DisplayPort) and following through its implementation in the VA2000 project. I also began drafting a schematic of the daughter board but need to better understand 68030 PDS in order to understand how best to wire it to the FPGA. Towards that end I've been making (slow) progress reading through DCaDftMF3e and Spartan 6 documentation.
  14. I've begun working on a schematic of the HDMI daughter board for the QMTECH FPGA, but I'm realizing that if I'm going to have PCBs made, it would make a lot of sense to wire in PDS (or NuBus), and save money and time... Guess I'll need to catch up and read the documentation you've all referenced. Stanford University (where I work) appears to have several of the "Inside Macintosh" volumes available, including one on QuickDraw, which I'm also curious about.
  15. That's great news, inkage? QMTECH's XC6SLX16 board available for sale from many vendors on eBay such as: https://www.ebay.com/itm/XC6SLX16-Spartan-6-Xilinx-FPGA-Development-Board-w-Micro-SDRAM-Memory-32Mb/264229717341 You can find the schematics, documentation for the board and its components, and example code FPGA code, under their GitHub project for the board here: https://github.com/ChinaQMTECH/QM_XC6SLX16_SDRAM I chose this board because it is the closest to the miniSpartan6+ used in the VA2000 project: Xilinix Spartan 6 LX16 (the miniSpartan6+ came in either LX9 and LX25; specs say the LX16 is closer to the LX25) 32MB of SDRAM 108 user I/O pins SPI NVM for FPGA bitstream and ROM For the proposes of this project, its only major shortcoming compared to the miniSpartan6+ is the lack of a built-in HDMI port but that could easily be provided by a carrier/daughter board. Of course, that means less than 108 I/O pins will be available for PDS/NuBus but there should still be enough? There is a DDR2 version of this board but I want to reuse as much of the MNT VA2000 project as possible (including SDRAM controller code for the miniSpartan6+). Anyway, I've been reading documentation of the three chips on the QMTECH board, understanding how it is all wired together, and comparing with the miniSpartan6+. The QMTECH board and Xilinx programmer are on their way. Baby steps... setup the development environment then see if I can program the board and blink some lights