Jump to content

Gorgonops

Moderators
  • Content Count

    5166
  • Joined

  • Last visited

2 Followers

About Gorgonops

Profile Information

  • Gender
    Not Telling

Profile Fields

  • OCCUPATION
    Board-Certified Kvetcher

Recent Profile Visitors

1284 profile views
  1. Gorgonops

    Lower Geekbench score after installing a 7800GS

    Does Geekbench break down the tests in such a way that you can see any disproportionate hits on individual tests?
  2. Depending on what monitor you have it hooked to changing resolutions might not be an option. Many of Apple's low-end monitors at the time were fixed frequency and only did the one resolution. (The ones paired with an LCIII were most commonly either 512x384 or 640x480 only.)
  3. Gorgonops

    68K (no Mac) Designs OK?

    The VCFed Vintage Computer Forum might be worth a look. There are a lot of very knowledgeable people there, and coincidentally I recall seeing a thread discussing 68000-based development systems just the other day.
  4. Gorgonops

    Original Hackintoshy Thing

    Be aware that there's a remote but non-zero chance that you'll damage a VGA monitor by using that cable to directly connect to an output like this. This port has digital TTL-level outputs, which means the high level is somewhere between 2.4v and 5v, while VGA analog is spec-ed as a swing between 0v and 0.7v. The input circuitry on a decently built monitor will *probably* tolerate the over-voltage but your mileage could definitely vary. For the record, the info slip included with the PowerR adapter is referring to *digital* RGB monitors, like early NEC Multisyncs.
  5. Gorgonops

    Found some Lisa diskettes

    Based on the stamped labels on the diagnostic floppies I wonder if those were included with a machine sold through Sun Remarketing.
  6. This only refers to the hypothetical machine you've built in your head that somehow accomplishes what real delay lines don't do. It's a thought experiment to imagine exactly how you're supposed to change the pitch of a signal without either storing it and playing it back at a different rate (ie, requiring a memory of some kind) or doing some kind of brutal lossy periodic resampling. (Which is what, for example, toy electronic voice changers do, but those techniques are not applicable to raster video, at least not if it's running at a different frame rate.)
  7. NO. For now the third time, delay lines *delay*, they do not *slow*. Perhaps that's a un-intuitive distinction, but it's actually pretty simple: If I pick up the phone and call you from a mile away and that conversation goes through a direct trunk line there will be essentially zero *delay* in the call; you will hear my voice with probably less than a millisecond of delay between the encoding on the microphone end and the reproduction in the speaker. Now let's pretend I call you on a telephone that relays my voice via a laser pointed at one of the reflectors the Apollo astronauts left on the moon. That's almost a four second round trip for light, so there will be a *significant* delay in you hearing the sound of my voice. (If you were looking at me through binoculars you'd see my mouth moving like you were watching a *very* badly dubbed movie.) But, and this is the important part, the pitch of my voice will not change. It is delayed, but not slowed. You clearly have. Think about what you're saying here and ask yourself how the delay line which *delays* every pixel by, say, the 20% you're bandying about here, from arriving at the monitor also manages to *stretch* that pixel by the same 20% so the waveform is the same, but slower, and then think about what happens to each subsequent pixel as they pile up at the start of your waveform-stretching-with-no-memory-to-buffer creation.
  8. Well, technically yes, a resistor isn't the *optimal* way to reduce voltage because technically it restricts current, not voltage, and thus the voltage drop over a resistor is dependent on the current draw. (And it's also terribly inefficient at high currents, converting most of the input power to heat.) In real life you'd want to use a more sophisticated power regulator. "Resistor" was simply shorthand for "a flow limiter" or "kink in the hose" because in the (yes, flawed in certain respects, especially in how it ignores magnetic fields) "Water Analogy" for electricity PRESSURE EQUALS VOLTAGE. In any case this is completely irrelevant to the underlying point I was making, which is that frequency is NOT equal to pressure.
  9. I mentioned analog delay lines in my previous reply, and I will repeat: those are not the droids you're looking for. These devices introduce delay in signals, they do not change their frequency. Frequency is what you're trying to change if you're attempting to take pixels output at dot-clock X and massage it to run at dot-clock Y. The closest digital analog to a bucket-brigade device is a dynamic shift register; both are essentially a type of memory that can only retain a value by cycling the bits through it, and the bits can only be read off at the same frequency as they were written in.(*) (* Okay, that's not *entirely* true, I think in theory you *might* be able to fill a bucket brigade device and then clock it down or up and play it out at an alternate rate, I don't know enough about the devices to know for sure, but the sample length actually stored in them is very short, and that's at audio frequencies. These antique devices simply will not work for video applications; there's a reason why they've been almost entirely replaced with digital sampling and RAM.) Also, just for the record, what "didn't sound right"? You explained it yourself that a "Gate Valve" controls water pressure, and the electrical analogy to water pressure is voltage. Again, pixels are *transitions* in voltage. A plumbing analogy to that might be vibration from water hammer or rapidly slamming the valve open and shut again? Sorry, but I don't know what plumbing apparatus exists to take *vibration* from a pipe full of water and magically change it so it's vibrating at the same amplitude but at a different frequency. (IE, preserving the information embedded in the vibration but "de-clocking" it from the source.)
  10. The OSSC won't help at all with that. Its output rate can only be even multiples of the input.
  11. So far as I'm aware (most?) regular LCD monitors/TVs refresh their LCDs at the same rate as the input so the only circumstances under which tearing or judder would appear would be with a buffering converter. You certainly wouldn't see it with the OSSC since its whole selling point is there's no buffering, it's designed with minimizing any and all lag as the primary success criteria. Here's an example of an FPGA-driven converter targeting oldschool system that does frame-rate conversion: https://www.serdashop.com/MCE2VGA It uses the oft-forgotten 400 lines@70hz timings that the original VGA cards used for text and EGA high-res modes. The modes it's using this to display were originally at 50 or 60hz. It apparently produces very pretty output, but even it gets trashed by that certain subset of gamers that obsesses about *any* delays or video artifacts, even ones that the human eye really can't readily pick out or only become apparent in certain edge cases. (Diagonal scrolling of playfields, etc.) I think the main sticking point here is that what's desired is some magic glue that will work with *any* old Mac video card, including obscure high-end ones that came out of the box pre-configured to work with *very* specific monitors. It's not an *impossible* ask, but it may be a product with a target market measured in the single digits. (Frankly if your interest is running ancient productivity software that benefits from massive pixel counts you'd be far better off running that on a newer computer than the original 68k platform. Unlike games most of that stuff is decently tolerant of running either on a newer Power Mac with more-modern video hardware or fully in emulation.)
  12. There isn't any way to do what you're describing because, think about it: a gate valve controls *pressure*, which is roughly analogous to voltage. The electronic analog is a simple resistor. The problem here is *frequency*, IE, we need to reduce the number of phase transitions per second for an output relative to its input without losing any data except for discrete packets we choose to throw out. There's no way to do that I can think of without a "memory", and further I'm having trouble thinking of any analog memory systems (like, I dunno, mercury delay lines) that allow the output to be " clocked" at a different rate than the input.
  13. Gorgonops

    Original Hackintoshy Thing

    Interesting. Googling the model number of that drive indicates that it is a factory-built Fujitsu clone of an Apple drive. Didn't know such an animal existed.
  14. For the most part I basically agree that this is a solution looking for a problem. While it's true there are individual edge cases where you might be stuck looking at a video output that's genuinely difficult to find a modern monitor work with (IE, mono portrait or two-pages display cards, really old Mac cards that only support composite sync, etc) *most* Macs will work at least begrudgingly with decent "pro-grade" LCD monitors that aren't that hard to find. Even with many of the hard cases (TTL or ECL two-page-er's) it's possible to fudge it with solutions like resistor-ladder DACs that fall well short of full timeshifting scalers; the only requirement is, again, you will probably be stuck using an older "Pro-grade" monitor instead of a cheap TV with a VGA port. The one thing the world probably could use is a hobbyist-priced sync-on-green separator for old Mac video cards that don't have separate TTL sync. (The 67hz bit really shouldn't be that big of a deal as long as you're willing turn over a few rocks for a monitor.) Here's a ridiculously expensive one. It should be possible to make one for considerably less than that because there exist dedicated sync-separator chips, it's just a little bit more complicated than slamming one chip on the line because those chips don't *strip* the sync off the green... But, well, quite a few LCDs that support non-VESA framerates also support Sync-on-Green, so maybe that's not even that big of a deal.
  15. You can't just "analog-ishly" pitch frames onto the floor to resolve frame-rate mismatches. Remember, what's being transferred in the video signal at any given moment in time is the color/intensity of a single pixel *somewhere* in the 2D grid that makes up the screen, and that feed is completely continuous. That moving dot of light *always* needs to move a continuous fixed speed, IE, the pixel clock, and that clock is different for the same video mode running at different frequencies. Outside of some very specific special cases (like simple "line doublers" to turn 240p into 480p) there's no getting around needing to buffer entire frames of video. Note about what I said about needing enough RAM to buffer 2 full frames; that's not necessarily true if you have dual-ported VRAM; in that case you can simply have the input scan repaint the pixels in the same buffer that's being referenced by the output scan. The downside to this approach is you *can* get tearing and other anomalous artifacts because your output will essentially always be a combination of two input frames. To understand this, imagine the output circuitry running at a 60hz frame rate starts sending an all-white frame, call it "Frame A" to the monitor. Shortly after it starts doing that input from the computer starts painting an *all black* frame, "Frame B" into the buffer. Because the input frame rate is 75hz the input scan passes the output scan halfway through the frame, and the moment it does the converter will no longer be outputting the white pixels from frame A, it'll be throwing out the black pixels from frame B, resulting in the monitor receiving a half white, half black frame that was never actually output from the computer. For most purposes (especially involving a simple GUI desktop) this isn't going to matter a whole lot, but it is technically a visual anomaly that might be perceptible under certain circumstances.
×