Jump to content


  • Content Count

  • Joined

  • Last visited

About Trash80toHP_Mini

  • Rank

Profile Information

  • Gender
  • Location
    Bermuda Triangle, NC, USA

Recent Profile Visitors

2065 profile views
  1. Trash80toHP_Mini

    Oh. Great. Another IIsi...

  2. Trash80toHP_Mini

    Dual / Multi LC PDS slot

  3. That sounds like a great Idea for a first run at this thing, baby steps. Since we don't need to use Apple's physical design guidelines we could get by with a generic adapter to PDS and smaller form factor carrier dev boards. The mockup above was meant to have a PDS connector on the solder side for an outrigger development board plugged in thru the opening in the SE/30 chassis. Substitute a PCI connector for EuroDIN120 and all carrier revisions remain within the 10x10 SEEED square and are easily swapped out. Header/socket thruholes below the PCI connector would allow breadboarding a first rev "PCI" carrier board for the much shorter edge card connector. Keep the breadboard connector thruholes configured for EuroDIN120 and late model, much larger standalone carrier boards using those more expensive connectors would be handily installed/removed as well. A short run of adapter boards could be used through the entire development process. edit: moving development boards onto 'PCI" was planned for major reduction in cost of development.
  4. That's what I thought I'd said: The DRIVERS for a video card as in "Cards and Drivers" reside in DeclROM to bring the card online, allowing ?Mac machine state indication before disk access for loading the OS begins. Was that a comms error between us or am I missing something here? Whatever "drivers" shipped on disk with the card set it up for special features via extensions a/o a provide a customized Control Panel replacement for the Monitors Control Panel. I found a tidbit about VidCard Driver/INIT loaded at boot's ability to usurp function of the DRIVER in DeclROM to be interesting and possibly a handy development tool. Once a basic setup for implementing that is coded, up and working it might make tweaking DRIVER development possible w/o the need for removing and burning a new ROM for the card with each iteration. Might not be necessary if provision for updating an EEPROM on the development board via USB or the like would be better, Dunno about that stuff, but I thought I'd mention it. The latter would be better in terms of adding/tweaking display mode options in DeclROM, assuming that might not be possible to do from the host Mac?
  5. Trash80toHP_Mini

    MDD G4: $70 a good price?

    I wouldn't say ANYTHING collectible of any sort is of investment quality these days. When cell phones are implanted on the mastoid bone in your skull there'll be little reason to use your head. Bog only know what will happen at that point, we'll be talking "FAKE REALITY!!!!!"
  6. Reading what? MooshBrain mode had me neglecting to say that the "extended documentation" on the Macintosh II Video Card (TOBY?) was in DCaDftMF3e. The screencaps I posted wer from DCaDftMIIaMSE with a reference to dri9ver development in Chapter 9 of same. Took a quick gander at both and it looks to me that all video mode settings are stored in DeclROM along with drivers for anything necessary. The Mac side consists of only the Monitors Control Panel remembering which video mode was last chosen and booting the system into that mode in single bit for Happy/Sad machine state indication before System/Drivers ever begin to load from disk. Presumably with a default setting of 640x480 for any worthwhile card at whatever silly frequency and 60Hz in the case of the proposed new development card. The driver setup for any mode would reside in DeclROM per above with the Monitors Control Panel handling any mode switching. It looks like the only real purpose of coding an INIT for a card is to override whatever resides in DeclROM that may have become obsolescent. This jibes with all my long experience with VidCards, NuBus and PDS. I've never NEEDED to load a driver to get basic function, most of the time at all resolutions/bit depth settings listed as available for any given VidCard. I'm sure a few exceptions have slipped through the cracks in my slowly crumbling mind, but the observation stands as a good rule of thumb. Looking forward to having Volumes IV and V of Inside Macintosh arrive next week to confuse the crap outta me with info on driver coding. < beats head on KBD in frustratiohn > sad;lagjn;lrkg;oaerht;kjearhtk;jwe4ht;iowhaerfo[u3q4['otij34qlktn;qk34th;q3i4io;hg2q34jr'q23jh4rthq
  7. Trash80toHP_Mini

    MDD G4: $70 a good price?

    For once I can agree with you on that front. I got the OS9 MDD release mainly to round out my collection of PortlyMacs. I've since given up on the B&W version as a Blueberry distraction from the Graphite to Mirror set. I find your findings on that front to be suspect. Pismo/500 was far slower running Illustrator under OS9 than the QS'02/1000 with one CPU tied behind its back. Yep, shop shipping charges for 'em on eBay for price comparisons or do an estimate IRL at the Post Office. OS9 on X-Ware will only get better and better with the passage of time. I'm idly watching for one of G5s as well. You got a wastebasket? Those'll be the next Cube at some point. Gotta get 'em while the gettin's good, Millennials may get tired of staring at an iPhone HUD in a few years.
  8. Trash80toHP_Mini

    Damaged ROM SIMM Socket on SE/30

  9. Trash80toHP_Mini

    MDD G4: $70 a good price?

    Heh, that's less than the price of shipping one safely. It's not OS9 correct, but if that's not of concern to you I'd say go for it. Faster bits to stuff in there shouldn't be a problem.
  10. Trash80toHP_Mini

    Damaged ROM SIMM Socket on SE/30

    OOPSIE! Misread the topic, as I just said in another thread, my brain state it "moosh" ATM. Is there enough head room in the SE/30 to install sockets for the soldered on header hack? I've got socket/header combos in that pitch, they've got a considerably lower profile than SIMM headers would. You'd want to use GG-Lab knockoffs of dougg3's original socketed ROM card for a programmable solution.
  11. Quick answer to that would probably be found in the extended documentation of the TOBY frame buffer card for the Macintosh II. That appears to have been added in the third edition of DCaD after the discontinued TOBY frame buffer card was discontinued and no longer available to developers from Apple. I'd think providing drivers for the Macintosh II in System ROM. Brain is moosh ATM, so: Online PDF of DCaDftMIIaMSE is scan format, so I screen capped the DeclROM section, leaving off the "Card connectors" page. edit: Resized second page to better match the first in picture flip mode.
  12. Trash80toHP_Mini

    Damaged ROM SIMM Socket on SE/30

    @Bolle came up with a great solution for a set of 16MB SIMMs, but I don't have a link handy. I've got a busted socket to fix at some point too. It seems Apple didn't have the market all to itself when it came to Spindly plastics. edit: coming up with a new, dual install method 16MB SIMM design with thruhole for RA header strip setup comes to mind. Edgecard connector "teeth" and traces to those thruholes could be deleted and an alternate router path for making the PCBs smaller would net more boards within the 10x10 SEEED Square. Card thickness hassles involved no more and a larger PCB compatible with headspace availability in the SE/30 become interesting possibilities.
  13. Yes and none that I can think of offhand. Dunno if it's possible, but you're right about *not* doing the unthinkable from the perspective of bandwidth. IIsi setup is called Vampire Video because it sucks the blood out of system memory along with the performance levels of much greater throughput of dedicated (double ported?) VRAM. QuickDraw acceleration is beyond my ken, but I'd think a concurrently running development project for a second version of the VidCard would be dynamite DeclROM set a board up at startup and contained the drivers for a VidCard at the same time so you could see happy/sad Mac machine state indication and then watch the system extension icons load/fail to load as they're read from disk. Making any and all questions public seems like the true path to enlightenment to me. Heck, my silly/misguided questions about saving I/O lines on a NuBus implementation helped G understand something wondered about back in the day. In that light,"reading "all this junk" and playing ping-pong with the tidbits that stick out would seem to be the point. edit: the first Meg of IIsi memory is dedicated/buffered from main memory so its contents can't be stepped on while it's acting as the internal video's frame buffer. Now I'm wondering if hardware buffering would have been required if the Mac OS had had a protected memory setup?
  14. Thanks, I was hoping !V and V were readily available online for anyone interested to peruse. I'm guessing I/II/III and x-Ref were released on developer CD and so are now available for download? Just ordered IV and V in paperback for less than $22 and they'll arrive this time next week. Something to thumb thru in downtime at work or to lull me to sleep. Not magical, just a sweet spot for development. If we might keep 68030 PDS development backward compatible with that 68020 PDS subset used in all LC slot Macs that would be the thing to do. Moving it to a NuBus slot doesn't seem all that daunting a prospect from what I've been reading all these years. However, as you pointed out this approach would pretty much cut performance in half as opposed to a full 32-bit NuBus implementation and that would be a big no-no. We might not want to hamstring a card for the IIsi/SE/30 PDS by adhering to the LC slot model either, especially if it will make it easier to move onto NuBus and the 68040 PDS. A 24bit 720p VidCard design compatible with the 16bit video card connectors in 190/5300 and 1400 as well as the Blackbird PDS now . . . THAT would be magical! I got stuck in a late Eighties, 8-bit ISA interface to a ROM emulator frame of mind. You could break it down and lash it up in the easiest possible manner in hardware and then smoosh it all around in the software to fix everything back up at the far end of the cable. Which would, of course, be pretty much what NuBus was intended to render obsolete. Once again, thanks for the education, Eudi. @trag did you take a look at those part numbers and the logo in the 040 PDS connector pic? I don't recognize that triangle maker's mark?
  15. I'm thinking along the lines that though the card itself may "need to" field 32 bits of addressing for memory, the for that card can ignore that "requirement" in the hopes of finding more wriggle room for the decoding setup?