Jump to content


  • Content Count

  • Joined

  • Last visited


About Gorgonops

Profile Information

  • Gender
    Not Telling

Profile Fields

    Board-Certified Kvetcher

Recent Profile Visitors

1046 profile views
  1. Gorgonops

    How interesting is the Lisa?

    Just to clarify, I certainly wouldn't say that the Lisa hardware/software package isn't "interesting" in its own right and that there aren't any rewards to be had in hacking and exploring it if such things float your boat. I'd just argue that unless your goal *is* to dig into it like that it's not a particularly, well, accessible, computer. (Given the difficulty and cost of getting a working one to play with you can take that literally as well.) Sadly, I think the main reason I really enjoy hacking around with my Commodore PET is because it's a simple enough machine I *occasionally* have sufficient spare cycles available to wrap my head completely around a problem and make actual progress. *sigh* (Although, for the record, it also has a disk controller powered not by one, but *two* 6502 derivatives. If you want a weird MMU, though, you'll need to look at the rare CBM2/SuperPet models.)
  2. As Cory notes, it's a good idea to remove the PRAM battery before you store the system for a "long time". This would apply to any brand. Under normal circumstances a battery that has enough charge to do its job isn't going to leak. "Battery Explosions" are generally the result of letting a battery sit after being completely drained for weeks/months/years. If you're using the Quadra and the battery is holding PRAM contents it's *very* unlikely you'll just wake up some morning and find it's gone nuclear.
  3. 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.
  4. 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'?
  5. 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.
  6. 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.)
  7. 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.
  8. 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?)
  9. 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.
  10. 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".
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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...