Jump to content

Gorgonops

Moderators
  • Content Count

    5208
  • Joined

  • Last visited

Everything posted by Gorgonops

  1. Gorgonops

    Proper Mac Plus ROM split HI/LO

    I haven't taken even the slightest look at the Mac Plus schematic to base this idea on, but I wonder if your some-odd-seconds of screen corruption before it clears and proceeds with booting could be that there's something up with the processor reset circuity. Typically computers of this vintage have some sort of timing delay circuit that waits a discrete period of time after power-up before pulling the RESET signal to officially start the CPU running. (Until this point the circuitry typically holds the line as if a "reset button" was being held down, halting the CPU.) If for some reason that circuit is having trouble stabilizing it could be holding the CPU in a halted state for some random period of time. Throwing this out there because I saw something like this on a Commodore PET I was restoring years ago. (Fixed by replacing a bad *ceramic disk* capacitor.) PET used a simple 555 timer to hold reset for about a second after power on.
  2. Gorgonops

    Proper Mac Plus ROM split HI/LO

    Perhaps the software you're using has an Endian disagreement with the Motorola 68000. (IE, perhaps the software assumes little-endian hi/low, in which low would be the first physical byte, but the Mac ROMs assume "high" is the first of each 16 bit word.) As long as you're correctly getting even/odd byte distribution you should be fine burning your ROMs with it split either way, it's just the terminology that's confused. Just plug them in after flashing and if they don't work first time swap them.
  3. Gorgonops

    FUN CHALLENGE: 2006 iMac in 2019

    It is kind of remarkable just how wide the range of performance there is to be found in consumer-level machines these days. It kind of reminds me of how it was around 1993 when you could still pick up a "Computer Shopper" and buy from the same white-box sellers anything from a 386sx up to a Pentium off the same menu.
  4. Gorgonops

    Fitting a SCSI2SD in a 68k Mac

    I always just used a hacked version of HC SC Setup; there's a simple ResEdit hack that disables the firmware signature checking. Supposedly the version on the A/UX setup disks also doesn't do signature checks and works fine for regular MacOS.
  5. Gorgonops

    Fitting a SCSI2SD in a 68k Mac

    The Seagate ST225N you're setting the product ID to *is* a 21mb hard drive. (It's the drive Apple stuck in the original 20MB external box for the Mac Plus.) I've seen that recommendation to set the Product ID to that in order to get the SCSI2SD to work with Apple's unmodified formatter software for System 6 (Apple used to tie their formatter to only work with drives they sold), but if you're planning to run System 7 or higher it may not be a brilliant choice. It sure seems like what's going on here is when the Apple formatter sees that Product ID it's not bothering to query the drive for its full size and is instead just hard-coded-ly generating a 21MB format.
  6. Gorgonops

    68K (no Mac) Designs OK?

    I'm kind of surprised in retrospect that it doesn't seem like Sega explicitly pointed that out in their advertising for the Genesis, as it's also a dual 68000/Z-80 architecture. (Of course, it's also interesting that Sega marketed the Genesis as a "16-bit" system while most of the computer makers using the 68000 heavily emphasized the 32-bit attributes of its ISA.)
  7. Gorgonops

    ROMBUS - 64 MB flash interface for Mac Plus

    Okay. Well, I mean if it looks like it's going to work I'm in no position to criticize. I do have to admit something does make me just a *little* leery, though; I googled up an application note for these quad-SPI flash chips, and this is what I got: https://www.st.com/content/ccc/resource/technical/document/application_note/group0/b0/7e/46/a8/5e/c1/48/01/DM00227538/files/DM00227538.pdf/jcr:content/translations/en.DM00227538.pdf The application note talks about running these chips in parallel; it doesn't have an example of four in parallel, but it does have one for two. This diagram has me scratching my head: Maybe I'm missing something, but the implication I get from this is that the way the memory cycle works with these things is that when you "go wide" with multiple packages it still expects each chip to send and receive a full "byte". IE, the data cycle is going to send two sets of four bits across the I/O lines as a unit. I don't find anywhere in this manual where it talks about the chip acting like it's only composed of four bit "nibbles" which are individually accessible. So if you have four of them in parallel (IE, "16 bits" worth of quad-SPI lines) won't you actually be pushing 32 bits per data cycle? Not that it would be something you couldn't handle, since you're planning on driving this with software on the 68000 instead of depending on this to just "transparently" look like ROM or a disk. Anyway I think mostly what I had in mind when I suggested the SD thing was, given the aforementioned limits on the signals you have access to on the socket, was implementing the port in the form of a "mailbox" buffer between the Mac and a self-clocked MCU that actually handled the communication with the SD card. (Or, actually, in this scenario an MCU that can act as a USB host might be better? Something like a PIC 24FJ64GB00x?) That'd let it run asynchronously from whatever the Mac is doing, all you'd need is a register to communicate a "busy/ready" flag. Ultimately I think something like that would be stuck with performance somewhere in the same ballpark as the Mac Plus' built in SCSI controller. (Which also communicates entirely by polling in that machine.) So maybe there's no point. (Might be a fun upgrade for a 512k?) I'm not sure off the top of my head what would really benefit from "lightning fast" bulk storage throughput in a Plus but it's certainly an unfilled niche. So by all means go for it.
  8. Gorgonops

    Minimum Compact Mac Value?

    This one is moderately debunkable, although it could also be true that Apple was the victim of catastrophically bad timing in terms of bringing the Mac to market. There was a DRAM price squeeze in late '82 into the beginning of '83 that did provide a lot of motivation for the Macintosh team to try to cram the system into 128k, pressure that was all the greater because the initial target price for the Mac was to be $1,500, not the $2,495 that Apple decided to jack it up to practically on the eve of its release. But by late 1983 the price of the 128k of RAM had gone down to less than $80 retail. Apple could have *easily* sold the Mac with 512k at its new price in January... except the 256kbit RAM chips necessary to fit it into the only 16 sockets they had on the motherboard weren't really available in mass quantities until a few months later. Apple might have been better off sticking with the original price (or closer to it) with the 128k Mac, or waiting a couple months and debuting it at 512k. Seems like they kind of did the worst possible thing instead.
  9. Gorgonops

    ROMBUS - 64 MB flash interface for Mac Plus

    So, to be clear I don't intend this as a criticism, but I am curious: if the storage on the 64MB flash you're adding is accessed like a "disk", what is the advantage of your design compared to hanging, say, an interface to an SD card controller off the ROM sockets? From an API standpoint SD cards present a "SCSI-like" storage interface and you get whatever rudimentary wear-leveling the manufacturer sticks on the card for free. (Flip side is it would probably be painfully slow if you had the Mac running the card via SPI itself through minimal glue, although, honestly, if it at least presented itself as a buffered 8-bit port and didn't require the CPU to bit-bang everything it may well be as fast as the Plus' built-in SCSI controller.)
  10. Gorgonops

    Found some Lisa diskettes

    Because the Sony drives actually worked. Twiggy was a disastrously ill-conceived and badly engineered failure, a monument to the worst of Apple's worst "Not Invented Here" tendencies.
  11. Gorgonops

    Found some Lisa diskettes

    Disks for the Lisa 1 fit that description, but essentially all Lisa 1s were upgraded to Lisa 2s, which used the same 400k floppy as the Macintosh. (And then later most Lisas that didn't end up in a landfill were converted to clumsy Macintosh compatibles; software for that purpose is what was on the OP's disks.) Anyway, the proper name for those failed Lisa 1 disks is "Fileware", but they're more commonly called " Twiggy disks". And yes, those would definitely be collector's items.
  12. Gorgonops

    68K (no Mac) Designs OK?

    Are you planning to share RAM between the CPU and the framebuffer? Because if not I suspect the 55ns RAM will be plenty fast for a 68000. (I assume you're using AS6C4008s for now?) Not that larger 10ns SRAMs are prohibitively expensive or anything. the AS6C4008 just happens to be really popular for homebrew because it's still available in a standard DIP package.
  13. 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?
  14. 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.)
  15. 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.
  16. 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.
  17. 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.
  18. 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.)
  19. 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.
  20. 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.
  21. 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.)
  22. The OSSC won't help at all with that. Its output rate can only be even multiples of the input.
  23. 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.)
  24. 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.
×