Jump to content

Trash80toHP_Mini

68040
  • Content Count

    13727
  • Joined

  • Last visited

Everything posted by Trash80toHP_Mini

  1. I mentioned Three Two Pulldown conversion of 24FPS Movie frames to the 30FPS NTSC Television format in passing a while back, but nothing came of it. So to reboot that WAG, here's the graphic from the linked Wikipedia article: The classic approach creates two "dirty frames' of five and the modern version creates a single "dirty frame" of five causing "judder" which can be minimized. Roughly, as I understand it anyway: Pre-VGA Mac resolutions for Built-in Video and early Mac Video Cards run at higher than 60Hz frequencies producing 67FPS (66.6?) and 75FPS output at several standard VGA and Mac Specific resolutions. My theory here is that in an active VGA converter with CPLD might produce/reduce common denominator interframes per the Three Two Pulldown model. If CPLD conversion is fast enough for the task, no classic 3-2PD "dirty frames" need be produced by simple combinatorial algorithms if tweening can be implemented in the process? By indexing freqs with the Gamba CPU, VRAM, and Monitor Matrix, tables, a large, but limited set of Mac/VidCard resolutions/frequencies to be converted can be generated. From there we'd reduce the parameters to a workable set for common VidCard output that's beyond the capabilities of onboard video as well as the answer simple things like the eternal question: How do I convert IIci video to VGA, it's not working with my adapter? I know, kinda complicated as usual for my notions, but an interesting twist came up in between that offhand mention and this proposal: Rather than worrying about producing HDMI output from the video buffer in a new VidCard design over a limited set of I/O lines, CPU/VidCard Video input requires next to nothing in terms of I/O lines, no. Knocking things down even farther in the food chain, might such a setup be prototyped (at reduced frame rates if needs be?) on GPIO lines in the PiVerse? Obviously, all of this is well beyond my pay grade, but stringing crap like this together via outlandish WAG is what I do. Whatchathink? Lest we forget featuritis: Add support for infernal, proprietary DE-9 TTL Output to Dedicated Monitor VGA conversion to the wish list? edit: forgot the bit about automagically scaling Mac resolutions to 1080p Displays over HDMI at convenient letterbox framed sizes.
  2. Already acknowledged that. Enough already, that doesn't keep it from being interesting or possibly leading to more useful applications of the concept. That didn't sound right after some thought, so I researched "Analog Delay Circuit" and came up with some interesting tidbits: https://en.wikipedia.org/wiki/Analog_delay_line https://en.wikipedia.org/wiki/Bucket-brigade_device the concept of which led to development of the CCD. Here I'm curious about modifying the single BNC output of in my SE to something more stable for the several multisync LCDs and CRTs I've recently tested with mixed results. Also wondering about application to early Full Page Display cards if they're analog interfaces and any other proprietary analog interface for a dedicated display. A digital version of same might bring the multitude of proprietary DE-9 TTL interfaced cards into phase with true VGA adaptation or a Mac sync rate that can be handled by available LCDs? The frequency mismatch between the Radius Full Page Display card generations might be another application. I know of at least one member lucky enough to have Display and a mismatched card. Putting any FPD card's output onto an LCD would be a very cool in general.
  3. Agreed, somewhat disappointed at that, but I'll agree. That feels like too much of an oversimplification of what I was trying to say. The video signal is a stream of those values as you describe, each right on the dot clock. Gate valving the higher frequency stream of the first four frames to match the display's expected input over four consecutive frames keeps that stream steady. The fifth frame gets dropped when it's time to draw the first of the next four frames and so on. IOW, you're analog-ishly retarding each and every pixel signal to match phases over four full scanline sequences and then jumping to the sixth scanline sequence of the input to start the first frame of the next four on the display end as there is no time remaining for that fifth frame to be drawn/converter/whatever? That's muddy as all get out as well, maybe it's backwards? edit: a gate valve is used to lower fire hydrant water pressure levels to garden hose water pressure levels. 75FPS being the hydrant and 60FPS being the garden hose.
  4. You don't need to go on and on about it. Ugly business grade multisync panels are not yet in short supply, got it, enough already. We covered that way up at the top. One day, when those high hour LCDs fade away, we may well need such an active converter as all the CRTs will have perished as well. But need will come up no time soon, that's clear enough. This is an offhand technical discussion and very interesting in the details so far, more of a feasibility study, most certainly not a market study. I like my three big CRTs, they go with the collection. The UltraSharp's are convenient, but do not fit in with my collection outside of the G4/OS9 Graphics setup. Nor do the KDS/Radius Panels I've collected from the Nineties for that matter, but they do look a lot better than the Dells when I'm playing with one next to the IIfx and big Radius TPD. Active conversion to HDMI displays would be aimed at working Classic Macs into a primary workstation in the future where styling won't matter so much. Two or three Macs on a shelf, rotating in and out of the collection and sharing main display, keyboard and mouse would be handy for Classic Mac playtime. ATM a Dell Multisync (1600x1200 20") is the menu screen for my primary display and I can play with the IIsi that lives under the desk or any of several other Macs in rotation on it.
  5. Reread and tried to fix the multiplier/divider numbers for clarity, but edit window closed, so: 75Hz/75FPS x .8 = 60Hz/60FPS or 4 full frames plus 1 extra full frame to be pitched onto the floor. First of the 4 remaining full frames at baseline 60Hz sync position with incremental delays applied to the 3 remaining full frames to evenly hit the 60Hz/60FPS rate ticks. Analog operations ought to be fast enough to iteratively loop the required delays to those 3 remaining full frames in sequence using a single circuit? Maybe three circuits would be required? More may be less, more simple in implementation and requiring less speed than iterative processing? A timer might be used to trash that pesky, extraneous fifth, full frame without any intelligence required of the adapter? Might keeping everything on the adapter within the analog realm do the trick? Dunno . . . still clear as mud. edit: MUD
  6. That really is weird. It's right out of the strange, but true field. Curious to know how that may work from a technical standpoint. Dropping frames sounds like the path to a doable, if non-trivial solution. Dropping 67Hz from the spec sounds to me like the other half of a possible solution? All the higher resolutions in question (including Portrait from the RBV afflicted twins) run at 75Hz, which is a delightfully dividable number, that extra 15Hz being a 25% multiple of 60FPS frame rates. The inverse being an 80% multiple of 75FPS to achieve that appropriate 60FPS rate for my cheap VGA-HDMI converter's input. 832 x 624 @75 Hz 1024 x 768 @ 75 Hz 1152 x 870 @ 75 Hz 640 x 870 @ 75 Hz You'd be dropping every fifth full frame, but requiring implementation of a delay mechanism to sync the remaining four full frames to achieve an even 60FPS VGA signal stream for that inexpensive, off the shelf VGA-HDMI converter. Might this approach sidestep the standard two-page frame buffer setup with its unworkable memory requirements? From the little I recall, analog delays aren't all that difficult to implement? Evenly or randomly distributing the dropped frames might decrease "judder" to a level that would be unnoticeable? Gaming would be a worst case scenario, but higher than 640x480 resolutions we're talking about aren't particularly suited to that anyway. Dunno, caffeine is kicking in so I'll have to apply logical analysis to this WAG later today.
  7. edtt: two posts late to the party, cell phone died mid-post. I'll agree wholeheartedly with you there about keeping a couple of extra Mac Res capable LCDs for backup. Do you know if the UltraSync series is still in production or when it was discontinued if not? I'll step out on a limb and assume those "above-60Hz refresh rates, up to ~144" are being developed for Gaming, 3D 4K movies, VR and such? I'd not pin a lot of hope on such new standards being backward compatible with much of anything pre-dating 60Hz 1080p. Is such display tech really MultiSync in the traditional sense or more a support for fixed resolutions developing within those new realms? That makes two of us! What you've described as two-page framebuffe setup sounds close enough. If so, I'll put a hard ceiling of 16" and Portrait resolutions at 8-bit or maybe even 16-bit on the spec to limit the amount of RAM required for taking built-in video output digital. 8-bit 21" Grayscale Res should also fit somewhere in between, but 4-bit would be fine for that if needs be on a 1080p Panel. That ceiling spec would pretty much cover everything from Mac II Cards thru LCIII Macs and all but the highest end VidCards from that era. Second gen Quadras, maxed VRAM Q700/900 and the LC475/Q605 venture into 24-bit territory at 16" and lower resolutions, but RAM requirements for 24-bit anything would be insane? I hope I'm not asking for the world here. Sure a new build VidCard would be awesome, but we'd be talking about developing three new VidCards to cover NuBus, LC PDS and 030 PDS machines that could all be supported along with a crap-ton of lower end VidCards for same by developing an Active, Digital VGA output converter for those inputs. New, outlandish WAG __________________________________________________________________ The two-page framebuffer setup you describe sounds painfully linear to me. Might pipelining parallel processes cut down on the speed hit and memory requirements using something on the order of JPEG type compression to limit buffering to processing DELTA rather than full frame? Expecting a rapid slapdown for this marginally sane WAG. At only 4 or 8 bits for GS or even 16-bit for RGB, there might be a lot of opportunity for compression on the fly?
  8. I think you've missed the point: at this time what you say may be true to a very limited extent for that one pitiful resolution. But the supply of MultiSync CRTs is rapidly dwindling. Capable MultiSync LCD panels are showing their age and being phased out of currently available product from what I've seen. I expect availability of new MultiSync Displays compatible with classic mac freqs/resolutions to drop off entirely in the not so distant future if that hasn't happened already? Unfortunately we're currently mired in the age of inexpensive 60Hz limited 1080p Displays. While a terrible desktop resolution to my way of thinking, is an incredibly inexpensive vehicle to fold a wide variety of Classic Macs into our primary workstations. With single of multiple HDMI inputs and BMOW's magic ADB box, current USB, multiple HDMI inputs of cheap switchboxes will suffice and modern KVM switch tech can be brought into play. BTW, I'm the one who pointed out that new build Adapter from Oz. With the active adapter as proposed, just as oddball 75Hz higher resolutions on the list come into play from more advanced, VRAM enabled built-in video output and VidCards over several generations. 832 x 624 @75 Hz 1024 x 768 @ 75 Hz 1152 x 870 @ 75 Hz 640 x 870 @ 75 Hz Active Adaptation of those resolutions to 60Hz 1080p over HDMI could be the cat's meow? It would without doubt bring the most out of the sad;y limited capabilities of the IIci and IIsi. Portrait rocks, even in 16 grays it puts 640x480 to shame, color or not. Again, that's the way I see it. Pixel doubled 640x480 in color from the RBV twins on a HDMI panel would kill.
  9. Trash80toHP_Mini

    Micron Xceed w/ Grayscale Adapter Questions

    Cool, waiting patiently for that answer. Is the "enabler" a driver/INIT per se, a Control Panel, or both? I'm willing to bet a shiny nickel the Xceed card will boot right up into a grayscale screen with the SE/30 Video ROM pulled long before the Happy Mac Screen appears. Could very well be wrong about that theory, but I doubt it. The Xceed Declaration ROM almost has to contain code that sends built-in video buffering/registers into a comatose state in the hardware initialization sequence long before the CPU has the first thought about video output. That's a much wilder guess, but that's my theory until convinced otherwise. I've never taken any interest in this particular Unicorn/Money Pit from Micron, or the SE/30 at all for that matter until a DOA Mobo example (Recap Disaster) showed up on my doorstep in trade when someone requested a redundant LC475 I had on hand that was unloved and in need of a bit of TLC. I was easily resurrected and a the SE/30 finally got a heart transplant and some goodies in trade when another member requested bits from the two foot plus 1400 stack. It's amazing how disinterest or idle interests in the hobby can morph into obsessions with the unexpected appearance of new toys. As the RCPII/IIsi work undertaken for the "SE/30's bane" Rocket Powered SuperIIsi project migrated to its nemesis, I was finally bitten well and good by the SE/30 bug. ProtoCache1 adapter and NuBus in SE/30 projects quickly ensued, pushing the SuperIIsi aside after required feasibility studies were completed successfully. Let's swing this post right straight back to the first paragraph and your Micron Xceed testing and then back out onto another tangent. My current obsession (most of the time) is finding a workable path to developing a dedicated, internal only GS Card for the SE/30. Figuring out the workings of the Xceed in terms of its poleaxing of internal video operations is right up there on the to do list. If we can fathom that mystery, the most serious roadblock to development of a new GS Card will have been cleared . . . maybe. Such would also answer the most basic of questions about initial testing for adapting the Fartallon LC PDS NIC to the SE/30. These various projects are tangled together like a half full packing box of assorted Mac, PC and Sun cables that hasn't seen the light of day through a series of four moves and in and out of threedifferent storage rooms at various times but for ransacking of its contents, making random substitutions with a generous application of topsy-turvy rearrangement of various boxen thrown into the mix at every location.
  10. Trash80toHP_Mini

    Micron Xceed w/ Grayscale Adapter Questions

    Concur, I outlined why no Declaration ROM/Slot Manager card can act as a startup screen without the required baseline drivers being available long before a Mac hits a startup disk and loading drivers in another thread. That subject might make for an interesting thread topic on its own. The driver (a Control Panel in all cases of which I am aware offhand) offers added flexibility for using drivers in DeclROM required for any supported resolution/bit depth combination. The Control Panel might possibly be required for PRAM setup to get grayscale output from the Xceed up and running for the and Happy Mac screens, but I doubt it. With no sense lines detected on its external monitor connector, I'd think the Micron Xceed would kick into grayscale mode during initialization as the default as there would be no other reason for the card to have been installed in the SE/30 given that machine state but grayscale output. Should the Xceed card fail to initialize during the startup sequence, the SE/30 would certainly default to its internal B&W Video ROM setup, giving the appearance that the Xceed card had come up in single-bit mode? All guesswork of course, but not entirely wild or uneducated I should hope.
  11. http://lowendmac.com/1994/macintosh-display-card-24ac/ 640 x 480 @ 67 Hz 640 x 480 @ 60 Hz 800 x 600 @ 60 Hz 832 x 624 @75 Hz 1024 x 768 @ 60 Hz or 75 Hz 1152 x 870 @ 75 Hz 640 x 870 @ 75 Hz Maximum Bit Depth: 24-bit/16.7 million colors (all resolutions) 640 x 870 Portrait Res in 16 grays is the most you can squeeze out of that infernal Vampire Video/RBV setup of IIci and IIsi. Scaled up or even unscaled it would be nice to send over HDMI to a cheap-as 1080p Panel. Pixel Doubled 640x480 at 1280x960 would be pretty sweet from those machines, with or without interpolation. 8-bit Portrait output and the additional 8-bit 832x640 16" resolution that Radius Color Pivot Cards offer to LC and 030 PDS Macs would be doubly sweet, again scaled or unscaled. Coffee's kicking in so that's it for today's WAGs, I hope this makes sense to someone and might prove workable. Finding a MultiSync Panel for Paleolithic Mac resolutions/freqs ain't gettin' one bit easier.
  12. Trash80toHP_Mini

    Daystar Turbo 601 IIsi adapter...SE/30?

    OOPSIE, it's the Carrera040 that was the problem/major project at hand, not T601: Time to make coffee again.
  13. Trash80toHP_Mini

    Daystar Turbo 601 IIsi adapter...SE/30?

    Didn't find the topics @joethezombie has been trying to revive and extend (not even sure they were T601 threads) in a quick search, but I found something FAR more interesting: https://68kmla.org/forums/index.php?/gallery/image/487-img-1490/ https://68kmla.org/forums/index.php?/gallery/image/486-img-1489/ That is NOT the IIsi adapter that's been tested and failed AFAIK. As I understand it joe and co. have been trying to get the Turbo 601 up and running with a standard PowerCache adapter and have failed at every turn. ISTR something about a Cache daughtercard for the back of the T601? Note the much lower position of the "IIci Cache Slot" connector than on the IIsi PowerCache Adapter. Might that relocation create cubic necessary for the cache card? @toples50 Do you still have this adapter in your collection? That GAL/PAL might be the Holy Grail of T601dom? n.b. not enough caffeine in my system ATM and it's never been something I've paid much attention to, so this morning's WAG might be farther off base than usual. edit: how the heck to you link to a pic in the gallery?
  14. Trash80toHP_Mini

    Daystar Turbo 601 IIsi adapter...SE/30?

    https://web.archive.org/web/20000417011457/http://www.daystar.com/pages/hardware/upgrades/030.040/Trb040.html That looks like a comp for a magazine for a vaporware lineup that wound up on DayStar's web site.
  15. Trash80toHP_Mini

    Original Hackintoshy Thing

    IIRC, @Gorgonops or @trag knows how TTL output can be converted to VGA. That would be the kicker. The Cat Mac articles in Computer Shopper were fascinating, that was the code name for such shenanigans before Hacintosh became the word of the day. Very cool machine, that's a real piece of Hacker history. More pics of the wire harness please!
  16. Trash80toHP_Mini

    Original Hackintoshy Thing

    Are you saying you have that adapter in your possession or are only posting pictures of it? If the former, developing a schematic from it would be a wonderful recovery of lost information for posting online. For that book and others: https://vintageapple.org/macbooks/
  17. Sorry, I thought you were looking for an ultimate processor upgrade since you're swapping things around. I'd suggest searching for a set of Final Cut Pro Key Caps. Even if you don't intend to use them might not be an ultimate accessory in that case, but it's s striking personalization of the baseline system. I've got the FCP dedicated Ikey board, but the styling isn't perfect for QS, whereas a set of caps for the Pro KBD would be a striking personalized upgrade.
  18. The searches for ULTIMATE G4 setups are to be found at http://www.macos9lives.com/smforum/
  19. Trash80toHP_Mini

    Help Identifying Mystery LC PDS Video Card

    Sounds like a plan. Doubtful you'll need drivers as they should be in the Declaration ROM. I can only recall a single instance where drivers were required for basic function of a video card and don't recall for sure if that one was Slot Manager/DeclROM architecture. Drivers in DeclROM are required for any VidCard to be the primary display on boot after POST, else you'd never see the icon indicating successful hardware check. Happy Mac screen indicating boot drive located would only be seen at some point after extensions/drivers were loaded, the process of which would be on a blank screen. I've never seen that to be the case and I have or have had and played with a very large number of VidCards. Frantic driver hunts to get a card that doesn't appear to work at all would in response to output/sync rate/display mismatch as I see it, not a lack of driver support. Drivers add features, not the basic functions necessary for any VidCard to support a Primary or Single Display. That's how I see it of course, others may disagree.
  20. Trash80toHP_Mini

    Help Identifying Mystery LC PDS Video Card

    TattleTech tells all.
  21. Trash80toHP_Mini

    Farallon ETHERMAC LC NSC w/NuBus drivers in the SE/30 PDS?

    Has anyone got a handle on how "Address Set E" is generated from the jumpers on the Asante NIC? Haven't buzzed the lines yet, but I have a sneaking suspicion this setup leads to GAL/PAL intervention? The Spectrum/8 appears to be hardwired to "Address Set 9." ISTR other cards being set up for only two "Address" Sets using the same two jumper setup. Very curious, time to break out the continuity tester is seems, but any ideas/theories would be much appreciated.
  22. Dunno where this one will lead, but gotta give it a shot. So many folks have been asking about the prospects of doing something like this for so many years that it has to be tried. maceffects has placed two of his Farallon NICs into my grubby little paws, so it's time for a bit of olde schoole wire wrapping fun. The 68030 LCIII PDS version of this diagram has been kicking around here and there in different projects for years. This time it's been dumbed down to the bare essentials of its 68020 LC PDS origins: RosettaCache-01-002.PDF The signal known as /SLOTIRQ in the LC docs is better described as /SLOTIRQ.E in the expanded 32-bit 68030 PDS LCIII update of theLC PDS. We've been talking on and off about prospects for using it on an available interrupt on the 68030 PDS of the SE/30 and IIsi. That NMRQ line bit in the signal description makes me wonder if there's another pin on the 030 PDS? /NuBus might work where the /IRQ lines may not? Is the 12V line on the LC PDS to power a FDD on a IIe Card's octopus cable or might the NIC need that voltage as well? Any help with proofing the signal map would be much appreciated. I found one boo-boo, but proofreading your own work is just oxymoronic.
  23. Trash80toHP_Mini

    Asante Video Card in SE/30..... Apple IIGS Monitor??

    Ditto. I don't have a 10bT/Thicknet only version of the Asante NIC, but that's exactly how it would look with the ThickNet Passthru section of the NIC removed and a video port installed in its place on the slot cover per the instruction manual. IIRC the feature was documented as for use with Radius cards (and the like) in the IIsi.
  24. Trash80toHP_Mini

    Farallon ETHERMAC LC NSC w/NuBus drivers in the SE/30 PDS?

    I'm actually expecting conflict to be the case, which is why I said I don't expect full function for the LC NIC even if it by some chance does show up in that slot space. I'll be happy if I can get its DeclROM to show up anywhere at all in that report. Thanks for the warning, didn't realize such conflicts could cause damage to the circuitry? Wasn't planning on loading drivers for testing the MacCon card in that configuration, now I definitely won't.
×