Jump to content

Gorgonops

Moderators
  • Content Count

    4851
  • Joined

  • Last visited

Everything posted by Gorgonops

  1. Just to be clear, you're running the system without a PRAM battery? There are a lot of unpleasant side effects to no PRAM battery in that vintage of machine, you might want to install one.
  2. I think it's that, because I interpreted your second post as a claim that you *didn't* need a "driver" (in the context of executable code on the card) right after I'd convinced myself that in most cases at least you probably did. (The edge case of a strictly single-mode fixed function framebuffer like that in the SE/30, which does have a declaration ROM and otherwise masquerades as a Nubus video card, is one possible exception.) Apparently you thought I meant drivers on a disk. The reason I was turning this over in my head is I was pondering the possibility of, for an initial stab at developing an FPGA-based card, if one could start with something just as dumb as the SE/30, IE, say an 800x480 1-bit monochrome fixed framebuffer. This would require less than 64k of RAM, I'm pretty sure some relatively cheap FPGAs could handle this without external memory. A card like this would likewise need only a *very* minimal declaration ROM, my question was 'how minimal'?
  3. Read the section you quoted carefully. It's pretty clear that there is, on a typical card, a "driver" stored in the declaration ROM, along with initialization code. There's not much to this driver, but it's there to translate the "generic" mode setting API calls made by the system control panels, et al, to the actual register tickling that has to happen to program the video hardware to display the requested mode. As I noted in my previous "oh yeah" post this makes sense: different video hardware might use radically different methods. To do without some kind of driver code (ie, make initialization/modesetting at boot completely a high-level message passing affair) you'd basically have to put an embedded CPU on every card. Roughly speaking this is the equivalent of the BIOS code there is on PC video cards from EGA onward that handles initialization and mode settings, it's not a "driver" in the "Windows driver" sense. (Or the "extension loaded from disk that enables enhanced functionality in the control panels or acceleration or whatever" sense.) On a typical card I doubt it took more than a few K in ROM. Quickdraw defines what the actual video modes need to look like and how they're manipulated so none of that is in the "driver" in the declaration ROM. All the driver does is program the raw registers to set up the field.
  4. Yeah... and after reading that I realized that, wait, any video card beyond an extremely simple fixed-function framebuffer would probably require at least a bare minimum of driver code to initialize the video chipset; the registers for programming CRTC functions are not standardized by any stretch of the imagination, so unless the card was hardwired to come up in a usable video mode *and* there was no reason to ever switch modes then, yes, you'll need a driver to handle that.(*) (* I'm curious if the "stub" declaration ROM that's inside of an SE/30 has any driver code in it, because its video hardware actually basically fits this description.)
  5. Yes, several people have been burned by that. In addition to not being able to physically power the CRT I also believe that Apple's DVI to ADC adapter *also* only carries the digital display lines used by LCDs through it. The CRT is an analog device.
  6. My "off the top of the head" answers. Your mileage my vary: For a dumb framebuffer card that's about the size of it. Definitely not with Nubus, it'd just be too slow and high-latency. It might be a *possibility* on 68030 or 68040 PDS, at least for a very low-res card, but it would be nontrivial. (This is the sort of thing you really want built directly into the system chipset's RAM controller.) I'm too busy at the moment to Google for them, but I know there are several good articles out there that go into *reasonably* comprehensive depth about how Apple's 8*24GC accelerator worked, and it's basically the model for the breed. I don't know if there's strictly enough there to just sit down and start writing an extension for whatever hardware you stick on the card, but it's definitely a start. (The 8*24GC used an AMD 29000 CPU on it, which was a general purpose RISC CPU that wasn't especially optimized as a graphics accelerator; its most common application for its relatively short market life was as a laser printer CPU. The 29000 family is stone dead so *replicating* the 8*24GC and using the same drivers probably isn't in the cards, but its architecture suggests some common modern CPU like ARM would be able to do the job just fine.) DeclROM sets the board up at startup and contained the drivers for the card at the same time so you could see the happy/sad Mac machine state and then watch the system extension icons load/fail to load as they're read from disk.  According to my reading of the docs strictly speaking a "dumb" video card doesn't have to have a "driver" per se in the declaration ROM, it only needs a bunch of resources that inform the built-in "Generic framebuffer support" in Quickdraw about the specific modes supported by the card and how to switch between them. It's not clear to me that any of this needs to be executable code. This is for basic support, of course. I think even some "dumb" cards still required extensions to control some more advanced features? (Mode switching, refresh rate selection, etc?)
  7. For all its many faults ISA at least made good use of dynamic bus sizing. (A feature Intel retained in the 486, unlike Motorola with the 68040...) An 8-bit-only ISA card is automatically byte, not 16-bit word, aligned.(+++) As I noted it is technically possibly to make *pretty stupid* 8-bit cards for Nubus too, if you're willing to write your driver to deal with the consequences of having your I/O ports word-aligned. It is simply not an option for video cards or other "memory-like" things.(*) (*) I may be misremembering some details, but I vaguely recall a horror story written by a Linux developer who claimed he discovered when writing the driver for a Mac NuBus ethernet card which utilized a brain-dead 8 bit 3com(?) chip commonly used on XT cards that the card *did* use only 8 bits to access the 2k packet receive buffer. The result was that to empty it when you got the interrupt you couldn't just copy it in one swoop, you had to in the driver read the contents from every fourth address and reassemble it in system RAM the same way the slot manager reassembles 8-bit declaration ROM. (Writes to the transmit buffer worked similarly.) When I read that years ago I didn't really get why you'd build the card that way, but having read all this junk now I get it. (+++) Edit: another note: VESA local bus, the closest to PC world had to 68040 local bus slots, also supported dynamic bus sizing. The extremely popular Tseng Labs ET4000 VGA chipset only had a 16 bit bus width for most versions but it could still perform pretty well when stuck on a 33mhz bus.
  8. Gorgonops

    How interesting is the Lisa?

    A Lisa running Lisa Office System is "interesting" in that, sure, it's a window to the initial all-encompassing computer-as-an-appliance vision that Apple was pursuing with their first GUI work. (The first Macintosh is a significantly watered down version of said vision despite, ironically enough, actually having the hardware itself nailed tighter shut.) But I'm pretty sure I'd be done playing with one after a few hours and never really be inclined to touch it again. So unless I were actually interested in curating a computer museum then, no, I don't think I'd want one. Even for free, really. (Assuming I'm not allowed to flip it.) I don't know off the top of my head what the percentages are but my perception at least is that the majority of surviving Lisas were are effectively used as MacXLs (regardless of whether they've had the screen modification that makes it official or not). In one sense those might actually be more fun to "play with" because, well, there's a heck of a lot more software. But objectively speaking they're also kind of terrible Macs, slower than even an original Fat Mac (except for the hard disk) and lacking compatibility in some areas such as sound. So, again, they're mostly interesting as museum pieces. Or as part of a freak show. Apple IIs are completely another kettle of fish. If you want to debate places in history the Apple II's is about as secure as the Lisa's in terms of significance. (IE, strictly speaking neither was the first of its kind, but the Apple II was *close* to the first mass-market color personal computer and the Lisa was the *among* the first fully GUI-centric computers specifically aimed at the personal computer market, albeit the very high end of it.) And unlike the Lisa the Apple II was actually commercially successful and is with a varying degree of fondness strongly engraved in the memories of those who lived through the initial decade of the personal computer revolution. (Class of 1977-1986.) The population that actually has contemporary nostalgia for the Lisa is far smaller. People love the Apple II at a gut level and its limitations and warts are an integral part of its experience, the Lisa is pretty much solely interesting because it's a "technical milestone".
  9. No. Here's where I think you're also a little confused: it feels like you think there's something "magical" about a "16 bit" card (like an LC PDS card) that can output 24 bit color, and that somehow matters to the CPU side interface bus. It matters *not in the slightest*. Only the output circuitry cares about 24 bit color, and the only aspect it cares about is that the backing store of RAM is fast enough to feed the output circuitry's (be that a DAC, a TDMS encoder, whatever) insatiable hunger for uninterrupted pixel data on a very strict timing schedule. The CPU interface bus could be a single-bit SPI bit-bang if that's all you have to work with, Honeybadger just don't care. The thing that kind of matters with Macs is the built-in video rendering system, Quickdraw, has specific ideas about what the framebuffer should look like logically to it, and it's actually a really simple requirement, IE, that the frame buffer appear to it as a continuous array of RAM with linear pixel arrangements, not some "weird" arrangement with bytes or words of VRAM scattered in non-linear chunks or weirdly interlaced, et al. (Which was actually really common back in the 80's.) So, in a Mac, video RAM is "RAM", so a the constraint you face on the Mac side is the same as if you were making a RAM card. A "RAM Card" for 68030 can be 16 bit or, heck, even 8 bits wide, and it's completely a trivial affair because the 68030 has specific support for accessing narrower blocks of RAM exactly as if they were fully 32 bits wide; all you need to do is pull up a sizing line when the read or write is made and the CPU will happily and completely transparently-to-software do two or four bus cycles instead of one to read/write a 32 bit word into/out of a 16 or 8 bit wide block or RAM respectively. It's completely transparent, Honeybadger, IE, Quickdraw, just don't care, nor does it have to. The point about Nubus is that sizing mechanism is not in play, a RAM-like card has to at least fake being 32 bit. Ironically this whole discussion is sort of pointless when you consider that Nubus actually just doesn't have that many lines, and depending on how we're intending to arrange our video card a Nubus version might require fewer FPGA I/O lines than PDS does. Nubus being multiplexed totally helps us here if we're planning to have the same FPGA handle the computer bus and the video RAM; The entirety of the 32 multiplexed data/address lines and all the control signals on a Nubus slot is only 51 pins, not counting grounds and power leads. For a 16 bit PDS video card with 4MB you're looking at at least 38-ish for just data and address, not counting any control lines *and* making the assumption that you can actually get away with partial address decode on PDS. (I'm not 100% sure on that? I though the PDS Macs all offered a slot enable signal that's lit up when the address range is inside some predefined slot area and thus you'll only need enough address lines for your VRAM range, but if I'm wrong about that then figure a full 48 bits for data/address.) So, again, unless there's something I'm totally misunderstanding about this from page 95 of the 3rd edition "Designing Cards and Drivers blaw blaw": You are stuck. A Nubus video card needs to be 32 bit. Which may not be that huge of a deal when designing one from scratch, but is important if you're trying to adopt a 16 bit card for another bus.
  10. There are still two different things floating around in your head that are sort of irreconcilable. Yes, Nubus supports byte and halfword transfers. (And unaligned transfers, which on the Motorola 68k are a fact of life because even though the 68000 architecture was designed as a "32 bit" ISA the original implementations were effectively 16 bit CPUs (one variant of which actually had an 8-bit bus) and instructions can therefore be aligned "off" from 32 bit words. x86 has the same issue. So any bus for these systems needs to be able to handle the situation.) Here's the thing about Nubus, though: *by definition* it always uses 32 bit multiplexed data/address words. You can't run a "24 bit subset" of it even if your plan is to only land a 16 or 8 bit peripheral that only needs some subset of the address lines. "Unaligned data support" simply means that if a read/write is split on an awkward non-word border it's smart enough to do two bus cycles and use the correct byte lanes to complete the transaction, instead of just losing half the transaction. Let's go crazy here and pretend that you're intending to stick something like a Motorola 6821 PIA on a Nubus card. This is an 8-bit chip that has two 8 bit parallel ports and two sets of control registers. This effectively means that on an 8-bit computer you need 2 "address lines" to select between the I/O ports and the control registers. (Obviously this does not include the address lines you need to decode the memory address at which the chip actually resides in the address space, but let's pretend we're doing this in something like an Apple II that has pre-decoded slots that give you a "this line is active if this card is supposed to be" line; I believe Nubus in the Mac also has this, which makes "simple" Nubus cards a little more straightforward to build than, say, ISA cards, which do have to have full address decode on them.) What that document is saying about "narrow cards" (which technically is a different issue from 'non-aligned transfers') is that, sure, with our incredibly brain-dead 8 bit card we can take some shortcuts and effectively not care about the upper 24 bits of data we get from *either* the address or data cycles of the multiplexed Nubus lines if we place the PIO's data lines on the correct side of a full 32 bit word and specify that when we're communicating with this chip we specifically address the parallel ports and registers on word boundaries. (IE, instead of the PIA occupying "32 bits worth" of memory address space it's going to occupy 128 bits.) This mechanism is explained on page 18 of that document you linked to, under the header "data byte placement". THESE SHORTCUTS SPECIFICALLY DON'T APPEAR TO APPLY TO RAM-LIKE CARDS, WHICH A VIDEO CARD IS. Let's say you're sticking a video card with an 16 bit memory bus in a Nubus slot. You do not have the option of 32 bit word aligning a 16 bit RAM by declaring you're only using two of the four byte lanes, because that would effectively mean that every-other-halfword of the video buffer would be missing. Macintoshes expect packed linear framebuffers, and when they're doing a block copy, move, memory fill, whatever, they expect to treat the RAM on the video card just like it's main memory, IE, I can just copy this from here and splat it over there. I'm pretty sure this is where the comments about PDS having the advantage of working directly with the 68030's dynamic bus sizing mechanism come from in the Apple card development manuals; a Nubus card can declare in its declaration ROM that it's only 16 bits wide, which the Slot Manager will honor at initialization (IE, it'll know to do word-level hopscotch when reading the rest of the ROM and piece it together in RAM rather than trying to execute any code on it in place), but it doesn't actually flip any hardware bits that will automatically map full word writes to only use the two byte lanes you stuck your VRAM on, it'd be on you to write a unique video driver (and probably rewrite Quickdraw) to deal with your weird non-linear vide buffer. So unless there's something that says otherwise in the video card section it looks to me like that just flat out won't work, and if you want to have an 8 or 16 bit wide VRAM on a Nubus Mac you're going to have to do it by sticking a 32 bit buffer on the Nubus end and blocking the subwords into your narrow memory with additional cycles. This might not be a big deal if your VRAM can cycle massively faster than the Mac can (See Trag's comment about how fast the 16 bit DDR interface on some of these FPGAs can go), but this *does* pose a barrier to literally taking an LC-slot video card and adapting it to Nubus. Best case the card will run about half as if it were 32 bit, all else being equal. I've gone through the Apple development documentation looking for more information about byte lanes and, again, I could be wrong but I don't any indication that declaring the card as "narrow" in the byte lanes specifier does *anything* other than affect how it handles the ROM (apparently even 32 bit cards like the Toby video card that's used as the video card example, and make no mistake, its VRAM is 32 bits wide, being composed of 8 or 16x 64kx4 RAM chips, might have an 8-bit declaration ROM). Every indication to me is that a RAM-like card (verses some sort of register/data port device) needs to be able to deal with 32 bit read/writes.
  11. Maybe you need to draw me a picture to explain what the heck you're talking about. If you're trying to share the same lines between the Nubus interface and VRAM refresh you'll need to have separate buffers isolating those lines from the bus most of the time, and video refresh is going to *stop* when you're handing the memory bus over to Nubus. Or are you trying to say something else? Also, unless I misinterpreted what it was saying Apple's development docs actually seemed pretty explicit about saying that if you're interfacing a peripheral that's less than 32 bits wide you have to handle bus resizing on the card, the bus as implemented on the Nubus Macs is one size fits all. (I recall some specific verbage about the 68030's built-in bus sizing magic not applying to Nubus cards *and* that not being implemented natively on the bus itself.) Yes, the SRAM suggestion was mostly a suggestion for keeping as simple as possible if you decided to split the bus interface circuitry from the video refresh circuitry. (IE, using some PLDs or whatever for the Nubus/PDS glue "south" of the memory bank and an FPGA for the video generation.) Arbitration for that scheme would be pretty simple. But if you're going to let the FPGA do it all using the built in DRAM interface might totally work, expecially if you can set up some sort of FIFO buffering to handle the latency.
  12. No. If data and address are multiplexed on Nubus then you'll need 32 lines for that function on Nubus, and *completely separately* you'll need data and address lines for your VRAM bank. (Assuming you've decided to do the bus interface and the 'video card itself' on the same FPGA.) It kind of seems to me you keep conflating the *computer's* address and data lines with the separate needs of the video hardware's address generation and refresh circuitry. Remember, technically speaking how you arrange your VRAM is completely arbitrary as long as whatever you come up with is in aggregate fast enough. If your target is a 4MB framebuffer (which covers 2^22 addresses), you could spend 32+22=54 lines between data and addresses for a 32 bit wide channel to a simple non-multiplexed bank of SRAM, or, if it's fast enough for your needs, in theory you could get away with, I dunno, 19 lines, for an 8-bit wide bank of RAS/CAS-addressed DRAM? (11 lines for RAS/CAS and 8 data lines. Obviously you'll need a few more in either arrangement for control signals.) The latter is a perfectly feasible arrangement as long you find DRAM that can cycle fast enough to answer the refresh needs of the display with enough left over bandwidth to allow the CPU read/writes to happen without excessive latency.
  13. Just to note, I did do a quick look for parallel high-speed SRAMs, and maybe "that much" is a matter of degree. For chips that can be hand soldered (vs. BGA) you're probably looking at around $7-10 a megabyte. That's peanuts compared to what it cost once upon a time, but I know how people in this particular corner of the hobby freak out at the thought of spending money for new build stuff...
  14. Actually, I realized I kind of lied when I said you needed 20 address lines for 1mb... *if* you were using 32 bit wide memory. In that case you'd need 18 address lines. (Since your 1mb would be organized as 256 kilowords.) Not that it makes much difference. Anyway... since 720p 16x9 is just under a megapixel for 24 bit you'll obviously need about 3mb of RAM, so... still talking 20 lines. My vague thoughts on this problem of affordable FPGA boards not having enough I/O to decode both the PDS/Nubus slot *and* a control bus for a RAM bank actually sort of boil down to, well, okay, so don't do it all in the fpga. Just spitballing here: use the FPGA to handle the output circuitry and timing generation, implement the bus decoding with some simple PLDs, and do address generation with a couple binary counters. (Which are choreographed by the FPGA, along with the bus contention signals.) Offload the bus decoding and effectively multiplex a few control signals into your 20-something line RAM address bus with the counters and I see you getting away with, I dunno, maybe as few as around 50 I/Os on the FPGA proper? Not to handwave excessively, but this is essentially how a real mid-90's level of integration card would work. I'd also suggest using plain old SRAM instead of DRAM for simplicity. 4MB of it, which should be ample, isn't going to cost that much.
  15. Yes, you're wrong. The VRAM is addressed as a chunk of memory so you need at minimum the same number of address lines as accessing that much RAM would take. So for a 1MB VRAM card you'll need to decode at least 20. (On the memory buffer side you'll only need half that many if you're using DRAM with row/column multiplexing, but the PDS bus doesn't do that.)
  16. Completely, utterly off topic: I was looking at the 1992 (verses 1990) version of the "Designing Cards and Drivers..." book and I ran across this paragraph on page 275, Chapter 12: Uhm, whut? Has anyone ever actually tried this?
  17. One of the slightly interesting tidbits the "DCaDftMF" book where it contrasts the simplcity of PDS with the painful drudgery of Nubus is how it notes that when you use the 68030 PDS it lets you take advantage of the dynamic bus sizing abilities of the 68030, which makes it relatively simple (compared to Nubus, apparently) of implementing a card for said bus that's only eight or 16 bits wide. (For instance it suggests that this functionality would make it relatively trivial for a designer to make SE and SE/30 versions of the same expansion card containing an 8-bit widget on it.) Obviously if you're looking for MAX POWER you're going to want to have a 32 bit wide card but... on the flip side, if you're interested in literally porting that Amiga Zorro II-targeted card design over it should be completely possible to build a 16-bit wide video card for 68030 PDS. (Which would add up to very minimal changes.) (For the record I'm pretty sure the VRAM built into an SE/30 is only 8 bits wide; for all practical purposes it's implemented as if it were a *really* brain-dead PDS video card, including a stub Declaration ROM.) 68040 PDS might be another kettle of fish. Doesn't the 68040 require external arbitrators to handle different-width peripherals? (I kind of thought that was one of the reasons why Apple was so much in the business of using 68040->68030 bus bridge chips in so many cheap-o desktop and Powerbook models...) There may well be. I certainly haven't read the manual that's being bandied about here well enough to say one way or the other. All I will say is it seems to have a lot of contradictory statements about 24 vs. 32 bit mode. (In the SE/30 PDS section, for instance, there's a specific blurb about how since the SE/30 only included 24 bit Quickdraw a video card designer should factor in having to bundle a RAM-resident 32 bit Quickdraw implementation...)
  18. It's a different aspect ratio than 1080p so if you want something that scales naturally to 1080p it's a bad choice. It's also not a particularly common resolution for stand-alone monitors; 1280x800 and 1366x768 are both (probably) more common, although, again, they're far more likely to be found as panel sizes in cheap laptops than in monitors. Of this motley crew of also-ran resolutions 1280x800 is probably about the best to target because at least its 16:10 ratio *is* pretty common (it's a widespread small laptop/table panel size, and it also scales by 1.5 and 2.0 for 1920x1200 and 2560x1600, which are also "not rare", albeit less common than 16:9 monitors) *and* it likewise comes in at *barely* under one megapixel. (1366x768 is barely more.) So, I believe the tl;dr there is from a software standpoint a PDS video card shouldn't look much different from a Nubus one. I'm looking at the same reference you are right now, and while, yes, it doesn't specifically include an example of a PDS video card *if* you build such a card that maps to the appropriate "Pseudo-slot" addresses and includes a declaration ROM (whose contents will essentially be identical to a real Nubus declaration ROM) the same mechanisms that allow such cards to be ID'ed and used at boot time will apply. Just an offhand comment about "Designing Cards and Drivers for the Macintosh Family"... it is kind of hilarious how the book essentially slags Nubus over and over again for being needlessly complicated...
  19. As noted in this thread about emulating Target Disk mode using a Linux computer: I discovered my test mule Aluminum G4 PB had a borked internal hard drive. (And a borked memory slot, but I'm ignoring that for now.) While browsing everyone's favorite e-Commerce big brother for the right FireWire cable to do some additional testing on another machine I stumbled across a listing for a laptop-size PATA to M.2 SATA adapter for $13. (The particular seller for the one I bought is sold out now. Here's the same one listed for $20, but someone else may well have it cheaper. So, just for laughs I bought it and The second-cheapest 128GB M.2 SATA stick that didn't have terrible reviews to see if it would work as an HD replacement. The bits got here today: And so after the expected hassle I got it installed in the Powerbook. (Side note: Jeebus Xrist, I'd apparently blocked out just how terrible it is to replace the HD in an Al PowerBook G4 despite doing it fairly regularly once upon a time. That stupid little yellow cable is basically folded sharply in two when the HD is fitted and that makes it almost impossible to get the little bugger plugged back into the motherboard... aaaargh!) TL;DR, it seems to work fine. I booted the laptop over Firewire from my Linux computer as described in the linked thread, installed OS X 10.4.6, and let Software update do the combo update. It boots in about 20 seconds from the initial gray Apple logo to the Desktop, and TenFourFox is actually close to usable on the system, which is particularly amazing considering at the moment I'm stuck with only 512MB of RAM. It's quite remarkable how much it helps the computer, well, suck a lot less. I stumbled across this thread of people posting Xbench results for various SSD-in-a-PowerPC solutions; this particular combination of parts nets a disk score of 218.94. This seems to be near the ceiling that people can get with this laptop if the results of that thread are accurate. Total BOM was about $40, so for the price this seems pretty darn good. (I don't want to slag on OWC's turnkey solution, but there's a lot of difference between $40 and $130.) It looks like mSATA-IDE adapters with a similar laptop form factor are even cheaper so maybe I should have gone with that, although the drives are slightly more expensive so I guess in the end I would have broken about even. In part I bought a 128GB drive instead of a larger one because I was kind of curious if the drive would be compatible with my B&W (assuming it still works) when fitted with a 40-to-44 pin desktop adapter, but after what a pain it was to get it into the PowerBook I don't think I feel like pulling it back out. Anyone tried something like this in an older machine? Also wondering how durable this is likely to be, but I'm guessing I probably won't use the machine enough to stress it too hard.
  20. Uhm, I think your Calcucorn may be busted, because mine says that 1920x1080 equals 2,073,600. Note that the reason that Apple (and a lot of workstation vendors) liked that 1152x870(ish) resolution was that it's basically the highest 4:3 aspect ratio video mode that fits neatly in 1MB of RAM (It leaves less than 46k) at 8-bit color depth. (By comparison, 1024x768 wastes 256k, and 1280x960 needs almost 180k more.) Conveniently enough 1MB is also the same size as a 24 bit standard Nubus slot space, which means that there's no issue with using the card at its full (indexed) resolution regardless of whether the Mac is in 24bit or 32bit addressing mode. I'm certainly aware that they made Nubus cards with more VRAM than 1MB and capable of resolutions up to the 1600x1200 ballpark, but I frankly do not know what complications that introduces to the drivers and hardware of said cards. (I'd assume some of those really capable last-gen ones only worked in 32 bit addressing mode?) TL;DR, going over one megapixel may significantly increase the complexity of what you're trying to do here. If you want to make a first crack at this I'd probably suggest drawing the line at 720p.
  21. Alas it's been a long time since I've seen a monitor that had the "just center it in the middle" option for lower resolutions. It is sort of ironic that some of the oldest LCD monitors usually had more flexible scaler engines than ones just a few years newer, but I suppose it also makes sense given that there was a greater chance that they might be connected to machines that didn't honor VESA DDC mode suggestions. I used to have an ancient AOC 17" flat panel from 2002 that would work with anything I tried on it, including oddball Sun workstation modes. Downside is, of course, that the LCDs from that era really looked like... LCDs from that era.
  22. I don't really see how the OSSC is relevant to making a new video card from scratch. I also don't see how it's of much use if your goal is trying to get the output from an old Mac video card that outputs some Mac-specific mode onto a newer monitor, because having read the documentation it looks like the one thing it does *not* do is deal with frame rate issues. (IE, if you have a Mac video card that only does 640x480@67hz instead of the "standard" 60hz the OSSC will output an HDMI signal at a very nonstandard 67hz, which on most monitors isn't going to get you anywhere.) It's pretty clear from the wiki that it doesn't manage to work with some consoles and arcade boards that are only a few points of a percentage off from the standard frame rates. Here is an interesting project for interfacing a Raspberry Pi to a simple eight or sixteen bit bus so it can act as a video card. Unfortunately the repository seems to be incomplete; there's some source code for the FIFO board (which is the really interesting part and it's on my to-do list to see if I can wrap my head around it) and a debug listener but no trace of the actual render code that I can see. Alas the whole thing appears to have been abandoned; I was really curious to see if he'd implemented a linear framebuffer in the graphics core (which is what you'd need for a Mac video card) or if it was implemented entirely as a display list processor. (IE, essentially something more along the lines of a TI 9918/A.) Still, even if it's of no real use as a graphics engine the idea of tacking a FIFO buffer on to let you snoop bus transactions without having to worry about exact timing could be super useful for other applications.... Anyway. Strictly speaking a video card for a Nubus Mac should be a pretty low hanging fruit as long as you're happy with unaccelerated video (as it looks like that VA2000 card is). Macs require a linear framebuffer with "chunky" pixels (not planar like VGA modes higher than 320x200 originally were) for 8 bit-and-less color depths mapped into the Nubus slot space and, if I'm recalling the documentation in the book I downloaded off Archive.org at one point correctly, a *pretty* simple initialization ROM that just tells the Mac what modes the card supports and what bits to poke to select them. (There are some additional wrinkles, of course, such as how the bitmap will need to be able to map into both the 24 bit slot space and the 32 bit Superslot spaces, modes that require more than 1MB of RAM need special handling, etc, but I believe it *is* all documented.) Examples of FPGA video generator code are a dime a dozen so it's really all down to the Nubus interface code. Casual googling has yet to turn up for me an example of open FPGA/CPLD code for implementing Nubus but it may well be out there. (Don't forget you'll be needing some level converters too, given the lower I/O voltage of most modern FPGAs.) A PDS card would indeed be somewhat simpler mainly because the 680x0 bus is more copiously documented. Late at the end of the "PDS era" there were a few video cards made for LC PDS that used standard off-the-shelf VESA-bus VGA chips so, again, the requirements for actual video hardware itself are pretty loose. If it can do Chunky video with a linear frame buffer it'll probably work.
  23. It exercises a bunch of Quickdraw calls, all of which are 2D. One thing to be clear on: hardware-accelerated 3D simply wasn't a thing during the 68k Mac era. The very first consumer-oriented video cards incorporating 3D polygon-based graphics engines didn't come out until 1995, at which point a few 68k Macs were still technically for sale but... yeah. No game written in 68k code is going to support such a card. Depending on how the game engine is structured a 2D accelerator *may* help. For instance, if you have something like a flight simulator game that renders its graphics as lines and solid non-textured 2D polygons (like MS flight simulator of that era) and the author of the game uses the Quickdraw 2D line/shape drawing API to display said polygons (instead of simply asking for the frame buffer location and drawing everything itself) then a card that accelerates those functions may add some value. But in the general case, probably not a whole lot.
  24. Gorgonops

    Mystery Ebay iBook...

    I would hazard a guess the hardware is fine. That looks about like the bellyaching I'd expect from a NetBSD machine that can't join a network.
  25. Gorgonops

    Mystery Ebay iBook...

    mDNSresponder runs on most POSIX compliant systems, including Linux and the various BSDs. Though I believe there's at least one other alternative it's pretty standard to find it on machines that have been configured to do ZeroConf network discovery for... whatever reason. (IE, set up to act as media servers, XBMC/MythTV clients or backends, etc.)
×