Jump to content

dlv

6502
  • Content Count

    32
  • Joined

  • Last visited

About dlv

  • Birthday 09/19/1986

Contact Methods

  • Website URL
    http://whywolf.com

Profile Information

  • Gender
    Male
  • Location
    San Francisco Bay Area

Recent Profile Visitors

379 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
  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 cyc
  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 m
  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
  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
  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.
  8. 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
  9. 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 actu
  10. 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
  11. 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 discussi
  12. 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 Spar
  13. 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.
  14. 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
×
×
  • Create New...