Jump to content

dlv

6502
  • Content Count

    32
  • Joined

  • Last visited

Everything posted by dlv

  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
  15. Hi - It’s a busy weekend so I haven’t had a chance to read or do much more research but on Friday evening, I think I found a cheap ($20) Chinese FPGA board on eBay that is comparable to the miniSpartan6+. It doesn’t have an HDMI port, so that will need to provided by the carrier board. That shouldn’t be any harder than the circuitry necessary to interface with PDS. In fact, I seem to recall from the VA2000 schematic, that the pins of the FPGA are just wired directly to the HDMI pins. I’m totally happy to pay $20 to experiment with this FPGA board. I think a great first step would
  16. I'll take a look at PDS but part of the motivation for me is doing this for a Quadra 950, which is the only 68k Mac I really care to collect. I imagine targeting the 68040 PDS is technically not any more difficult than targeting the 68030 PDS but there are likely to be other challenges, e.g., the '040 PDS connector, which is why I had been exploring Nubus. That's all; I don't doubt designing for PDS is a better route. I was speaking to the usability (i.e., UX/UI) of classic MacOS at resolutions beyond 1080p which, at pixel densities we're seeing on modern panels, might suffer.
  17. Thank you all for the discussion so far. You mean, interfacing with the VRAM built into the motherboard (or whatever)? I doubt Nubus/PDS has enough bandwidth to pull the contents of VRAM at any usable frame rate. A FPGA board providing its own frame buffer to the system and outputting the video signal independently is definitely the way to go. Unfortunately, it looks like the miniSpartan6+ FPGA board used in the VA2000 project is no longer sold which is too bad because, from what I've gathered, it was particularly well suited for this type of application (and relativ
  18. Yeah... I'm not that nostalgic for old CRTs (been there, done that). My focus is on the machine, so I think getting a crisp 1080p signal from a Q950 would be a fascinating way to interact with it
  19. I came across the open source MNT VA2000 project last night (https://github.com/mntmn/amiga2000-gfxcard/tree/master) which brings HDMI output to the Amiga 2000. Is anyone aware of a similar project or efforts for Apple Nubus? It appears to me (naively) that the VA2000 could be leveraged for such a project. One of the main challenges is, of course, porting from the Amiga's Zorrow II/III bus to Apple Nubus. I've begun reading through "Designing Cards and Drivers for the Macintosh Family" as a starting point, just to get myself familiarized with the basics. However, I do
×
×
  • Create New...