Jump to content

Gorgonops

Moderators
  • Content Count

    5269
  • Joined

  • Last visited

2 Followers

About Gorgonops

Profile Information

  • Gender
    Not Telling

Profile Fields

  • OCCUPATION
    Board-Certified Kvetcher

Recent Profile Visitors

1406 profile views
  1. I vaguely recall the Wikipedia page for the 53C9x series claims that MESH is indeed a lightly cooked version of that chip, so, sure, in a roundabout way Apple may well be being both truthful and elusive with the claim that the SCSI built into Heathrow is "MESH Based" even though it's actually a lower-spec core from the same licensed family.
  2. According to the dev note both internal and external SCSI are hanging off the Heathrow, there is no separate SCSI chip. (And if you look at the specs for Heathrow in the PDF you'll see that the built-in SCSI is based on MESH; MESH *is* 10MB/s capable in the stand-alone ASIC used in various "thousand-series" machines but it doesn't appear to be so in Heathrow.) External SCSI on the machines that had both was buried in the "Curio" ASIC. Considering what Heathrow has it in it I can't help but wonder if it's actually more of a "Curio" descendant than MESH. (Or maybe the SCSI in Curio is just a brain-dead version of MESH too?) And yes, the "Paddington" ASIC that was used in the tray-loading iMacs and B&W G3 does apparently have the MESH cell from Heathrow still buried in it but not connected to anything. I've heard vague rumors that the Paddington ASIC actually ended up in some Beige G3s, either in prototypes or possibly even shipped, but I don't know what to make of that. I suspect it's confusion based on some Beige G3 models shipping with 10/100 ethernet *cards* installed. (Main difference between Heathrow and Paddington is the latter has 10/100 ethernet integrated instead of just 10m.)
  3. I'm fairly certain the Beige only has the *slow* bus. Unlike some of the bigger Beige PPC iron the internal and external connector are on the same chain (like a Quadra or older class machine), and that means the MESH integrated to the Heathrow ASIC is limited to 5MB/s. Honestly I don't think there's really much future in SCSI-to-"a real device" adaptation. If you really need a high-speed solution and are a little patient you can get one of those ACARD adapters for optimistically what a truly high-speed remake would cost, and coming in right around the prices of those devices are things like the SCSI2SDv6 that are getting into the same speed ballpark as "pretty decent" contemporary-to-the-machine drives. I understand that, yes, there *are* people (literally dozens of them, maybe?) still doing things like video capture and whatnot on that original hardware, but for almost anyone else who just wants to use a machine of that vintage for "retro fun" SCSI2SD-style solutions are performant enough. Is the real audience for "blazing fast, way faster than the original!" drive performance for 1993 vintage machines really big enough to need a new-build device to fill it?
  4. Let the record show that 4MB/second is the equivalent of a 26.6666x-speed CD-ROM drive. Why do you need something super-fast if your goal is to drive laptop PATA CD-ROM drives, again? (Sure, that is only about 3x if you're using DVD as your benchmark but, still, it's fast enough.)
  5. There's this project from 2008 on OpenCores that was active for a week and a half before they suspended it. That's not too promising. https://opencores.org/projects/scsi_chip That said, there are plenty of software bit-banging solutions out there for doing SCSI with just some buffers. (There's SCSI2SD, that project for doing it with the GPIO ports on a Raspberry Pi, etc.) An FPGA god probably wouldn't have a *lot* of trouble converting the code that drives those buffers into hardware state machines. It's just a lot of picky, excruciating work for someone to do out of the goodness of their heart. And the end result would probably have to sell for a *lot* more than a SCSI2SD sells for if you want something *fast* and "production quality". (Based on several projects I'm vaguely interested in having it looks to me like the minimum ballpark price for a complex FPGA "hobby" project is in the $100-$200 range. That's a lot to hook up an old IDE CD-ROM drive.)
  6. I'm sure whoever owns ACARD's intellectual property at this point isn't particularly interested in sharing. Their old marketing spiel says their converter ASICs had a built in "High Speed ACARD RISC Microprocessor" on it, what the actual specs of what that is are and whether it used an ISA that has FPGA implementations openly available are utter unknowns to me. (Although perhaps you might be able to figure it out by analyzing a firmware file. For cheap thrills I downloaded one and ran "strings" on it; it looks like it has the SCSI ID text fields in plain text so it might not be encrypted in any way, so if you could make an educated guess what the instruction set is and could run a disassembler program on it in principle you could learn a lot about its internal architecture. Those are really big ifs, though. It's not unusual for ASIC-embedded CPUs to use highly customized ISAs; it might be derived from, say, MIPS, but contains weirdness in it that renders it cryptic without the customized support toolchain.)
  7. Re: the performance discussion, it bears pointing out that the adapter in the OP is almost certainly *far* slower than an Acard-style adapter, and very likely significantly slower than the better variants of the SCSI2SD. It's based on an 8-bit MCU designed in 1980 as a competitor for devices like the Z-8. It's clocked pretty high for an 8 bit CPU (... of the era, not now) but it doesn't look like there's any external RAM, which would almost certainly rule out DMA operation. An 8-bit MCU with a very small amount of RAM task-switching between doing PIO with that SCSI chip and driving the IDE bus is anything *but* a recipe for high-speed operation. Color me surprised if this thing could keep up with even the fairly mediocre performance of the ZIP 250 drive it was connected to.
  8. That chip with the "SLS/7.43" sticker has 28 pins, which does indeed make it a good candidate for being the ROM. I haven't read the label on every chip but every one I have looked at seems to be a generic 74xx series part, so there may well be no programmable logic on this thing besides the CPU. I'm going to demur on whether this is actually a useful thing to try to clone; it has a pretty high part count and the availability of the SCSI chip is probably a significant issue. (I see one guy selling a box of 11 of them on eBay. One guy. That's not a good sign.)
  9. In essence those things worked in a manner vaguely similar to how those adapters they sell for connecting your MP3 player up to a cassette-based car stereo work, IE, they press a little magnetic transceiver up against the read/write head in your floppy drive. As noted, they do *not* emulate the geometry of an actual disk and are useless without the software that knows what's going on there. They would also almost certainly *never* work in anything but a standard high-density floppy drive that uses DOS-style low-level formatting because according to the scanty documentation for the protocol they speak they present their UI as if it were the first two sectors of a standard 18 sector track; controllers that use GCR or only run at lower data rates wouldn't even be able to talk to the UI. (The same source that documents that also says the read/write transceiver only works if the head is positioned over track 0, so even if you could somehow replace the firmware with one that tried harder to pretend to be a floppy disk it wouldn't work because stepping through the tracks will cause it to lose communication.) In short they do basically count as useless for most "retrocomputing" purposes; by design they can't act as a general purpose drive replacement like a Gotek or Floppy Emu. That said I'd kind of like to see what one looks like taken apart. I'm curious how the dingus the head sits on is actually set up, and if there's some sort of sensor connected to a phony hub ring that uses the motor spinning as a signal to wake up.
  10. Gorgonops

    601 processor replacement experiments

    No, the Apollo core does not run on the ARM core built into Cyclone V FPGAs. This is evident by the fact that the core can be implemented on Cyclone III family devices that do not have the ARM core. (And to be clear, not all Cyclone Vs have it either, only the "SoC" variants. Which Apollo accelerators do not use.) Re: the link to UAE4Arm, that's just a repository for an ARM-tweaked version of the UAE version of the Amiga Emulator, it's not a magic gateway to an already implemented "I stick an ARM CPU into an alien CPU socket and run 68k code MOAR FASTER while looking just like the original CPU" widget. That said: I suppose if someone *were* to use something like an Cyclone 5 SoC to essentially adapt an ARM core to interface to a 680x0 socket you certainly could use the UAE CPU core as the basis for your 68k emulator. But honestly that's by far the most trivial aspect of this build; the hard/interesting part is going to be making the bus logic to make the Macintosh "body" accessible to the ARM brain. In principle at least one should be able to pull it off; you'll need to build the appropriate state machines in the FPGA so the accelerator "looks" like a 680x0 from outside and behaves correctly in response to the interrupts/bus sizing signals/wait states/whatever. Then from the ARM's standpoint I suppose the most straightforward thing to do would be to chop and shuffle the Mac's memory map a little so you can address the whole thing as a memory mapped peripheral, route the interrupts appropriately, and then set the whole thing up so when powered on it executes a compact and highly optimized 680x0 emulator out of the onboard RAM/Flash in the FPGA. This is going to be harder than a simple software emulator, of course, because you *will* need to be able to respond to hardware interrupts/etc, in real time, unlike in a complete emulation where you can handwave/delay things to your heart's content, but it's probably... totally possible, assuming your ARM is fast enough. Essentially what you'd be building here is the equivalent of a 680x0 ICE pod. The real question, of course, is exactly how *much* faster you'll be able to run than the original. The Vampire accelerators for the Amiga replace a lot more than the CPU; they include their own RAM, and *also* replicate most of the custom chipset features internally. Broadly speaking they basically wear the host Amiga like a mask and themselves run internally essentially the same way as a full FPGA Amiga like the MiST/Minimig does. Access to any hardware outside the Vampire is *muuuuch* slower than operations inside of it. So based on that I suspect that if you *just* replaced the CPU in an old Mac with an FPGA-interfaced ARM CPU (or even a full "real" CPU core like the Apollo "68080") and didn't include RAM, etc, on the accelerator then the total gain you could expect would be... very likely disappointing.
  11. Looking at that Usenet post I think the critical part is it's mentioned in the context of an accelerator/expansion board that included its own RAM onboard. (I'm going to hazard a guess the board they're describing is either the MacRescue or the same thing wearing another beard and mustache.) Boards like that would need the 128k ROMs to drive the SCSI controller they add (among other things) so it would be a prerequisite to have them, but you wouldn't actually be using the machine in a "128ke" configuration. (It's notable that the ROMs in that picture of a MacRescue I pointed at appear to be EPROM pirates. No doubt that sort of thing was pretty rampant among... less than reputable... repair/upgrade shops.)
  12. My vague recollection is that a "128ke" actually has a few hundred bytes less free RAM, and it's enough to prevent it from running... one of these two, MacPaint or MacWrite. But I've never tried it so I can't say. I'm *extremely* skeptical that Apple ever in any way signed of on this as an official upgrade and would be happy with an official service center doing it, but there was a thriving "gray market" for Mac upgrade parts despite Apple's attempts to rigidly control the supply, so I'm not at all surprised it existed in the wild despite that. Although, honestly, I don't see the point; if you're going through the trouble of having your Mac cracked for the ROM/disk upgrade you might as well have a third-party 512k RAM upgrade soldered in there while you're at it. I thought that Apple probably charged a different price for upgrading a 128k vs. a 512k, but not sure enough to say. So, yes, the full from-zero upgrade of a 128k up to a Plus was just shy of $1,100, which while kind of painful was still well short of the price of a new Mac. (The Plus cost $2,600 at introduction.) A thing worth considering, though, is there's a less-than-zero chance that someone upgrading their 128k to a Plus may have *already* ponied up for a 512k upgrade. Apple initially charged $999 for that, so worst case it's possible that someone could have ended up paying a total of $2,499 + $999 + $299 + $599 + $129 (keyboard upgrade) = $4,525 for their Macintosh Plus if they stepped through every iteration. It has round serial ports, so it's a Plus board. You can't swap boards without swapping case backs unless you're planning to do some plastic surgery.
  13. I think technically the way they priced the upgrade is a "prerequisite" for the Plus upgrade was having the 800k floppy drive upgrade which also included the 128k ROMs, so technically for a full Plus upgrade you were buying two SKUs at once. The drive upgrade was surprisingly affordable as Apple products go at "only" $299, but I don't remember what the Plus board part of it cost. (And google-fu is failing me.) There's one reference out there that the trade-in cost for a 512ke (which already has the drive) was $799, so maybe it was $1100?
  14. If you have enough RAM the greater amount of native code in OS 8 will basically counterbalance it being "heavier" than System 7; the advice that "earlier is better" breaks down pretty badly on PPCs. (There probably is some truth to it on 68k Macs, although you still need to think about how much of your time it's worth to track down all the control panels and extensions you need to essentially turn System 7.1 into 7.5.5 minus some phantom bloat that I'm frankly skeptical exists once the two are actually configured the same.) Again, the *only* justification I can see for going with the lesser OS is if you're seriously RAM constrained; if you have at least 20-something MB I'd not bother with 7.5.x at all unless there's some very specific thing you want to run.
  15. 7.5 cannot read HFS Extended, period, so this shared partition would have to be HFS. And HFS becomes *horribly* inefficient when used on large volumes. The TL;DR is that it has the same allocation limits as FAT16, IE, only 65,536 blocks. That means on a 128GB partition the minimum file size would be, what, something like 2MB? Unless you really think you're going to be spending a lot of time under 7.5 (I'm not sure why you'd bother, 8.x is a real improvement over any 7.x version on Power Macs because of the greater use of native code) I'd personally recommend you allocate just a small amount of disk space to be readable to the older OS and format the rest HFS+.
×