Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Gorgonops

  1. Gorgonops

    Regressing to an earlier OS?

    I will second that the B&W is, well, kind of a piece of junk. I would rank it slightly higher than the Beige but in my opinion all of the MPC106 machines Apple made simply don't rank among their finest efforts. (This also encompasses the Wallstreet and Lombard Powerbooks and the tray-loading iMac.) The "Rev 1" machines did have faulty hard disk controllers, although the problem usually didn't show up with only a single drive installed. They also have known issues with the Firewire module flaking out. My personal B&W with the Rev. 2 motherboard works okay, mostly, but it is *incredibly* picky about what DIMMs, hard disks, and PCI cards it works with. Architecturally the B&W is kind of a mongrel, which I don't think helps in the stability department; it uses most of the same motherboard chips as the Beige, but with (essentially) an overclocked frontside bus and PCI video slot, a *weird* PCI bus bridge arrangement for the non-video slots, and USB, Firewire, and the UDMA/33 hard disk controllers essentially just tacked on as if they were built-in PCI cards. Overall I'd say the Uni-North machines just "feel" generally more stable and less cobbled together. But most of them do bottom out at OS 9 if 8.6 really is a priority. (I can't really think of a good reason why it should be, but it is what it is.) Only the oldest Sawtooth machines will do 8.6.
  2. I was using an AppleDesign keyboard with my IIgs last I played with it and I didn't notice any issues that affect functionality, although I do vaguely recall another minor issue with later keyboards and the IIgs (ROM1 at least) is some issue with the caps/num lock indicator lights? Technically if you dig into the most arcane parts of the IIgs technical reference and the Mac II-generation hardware documentation (IE, later editions of Inside Macintosh) there are a few *very minor* places where the ADB spec was changed (or, perhaps more accurately, more fully defined) between the first editions of the IIgs and how it was implemented on the Mac. (Some of the signal time intervals which were open to interpretation on the IIgs were more fully specified.) It's *possible*, I suppose, that your particular IIgs' keyboard/ADB controller is "sloppy", or at least sloppier than average. There are known issues with the ADB controllers on some IIgs motherboards, some of which might not necessarily manifest in a complete failure.
  3. I recently bought a super-cheap LCD/Scaler combo that uses a Realtek-based scaler chip that's ridiculously widespread in the cheap boards. I've done digging on the "RovaTool" software mentioned a lot in this guy's posts and I have been wondering if it's worth trying to tweak it, since its out of the box configuration is less than optimal. I don't have the link handy, but there's actually a tool out there that can program the board without a separate programmer if the board has a VGA port wired according to the reference design. (It can pass SPI through the DDC channel.) That said, these tools are *extremely* user unfriendly, and are mostly for getting the board to work with specific panels. I haven't found anything on how to tweak the input parameters, which is also a thing I'd like to do. It may not be possible with this chip; it seems to be a very TV-centric device.
  4. A word of warning: Those NECs mentioned above are a decade and a half old now. I have one of the 20" 1600x1200 ones in the garage that I trashpicked because, yeah, at first glance it looked awesome featurewise, but it didn't take me long to realize that there has been a *lot* of water under the LCD monitor bridge since those were made. Not only is the "best case" color reproduction and contrast of the LCD not that great, there's a good chance that a used one has a *lot* of miles on the old CFL backlight. I would strongly recommend seeing a monitor of this age in person before ponying up any money for it. There's a fair chance the display will leave a lot to be desired.
  5. Gorgonops

    PS/2 in MacOS

    Technically there is no such thing as "standard" support for anything other than keyboards and mice on PS/2 ports. I have no experience with this particular device you're interested in, but it looks like how it may have worked is essentially "proxying" the keyboard and mapping normally unusued scancodes to its own buttons. If that's the case it's almost absolutely a sure thing that the MacOS driver for the joystick isn't going to have any idea how to deal with it. (The ADB protocol *does* allow for "arbitrary" devices that are addressed directly, I would assume that's how the Mac version worked. My *guess* is the PS/2 ports on those Starmax clones probably show up at a software level as if they were attached ADB devices and, again, unless for some reason the ADB version of that stick also proxies keyboard input the same way as the PC version, which would be pointless, then the code path will be different and it won't look for those extra scancodes on the keyboard device.) Also, of course, you'd still need to somehow adapt the 15 pin analog joystick port into something the Mac can understand (the PS/2 part only carries codes for all the extra buttons), did they even make such a thing?
  6. Gorgonops

    FPGA Mac

    If I'm reading the specs correctly it looks like even the G1 has an FPGA larger than the original MiniMig or the MiST platforms, so if someone were to get a bug in their bonnet to post an Amiga or ST core to them you could *potentially* come up with some kind of business plan based around buying in bulk and turning them into little retro game consoles. But the lack of open I/O really is the bummer; you're basically stuck with USB unless you want to start cutting traces on the board.
  7. Gorgonops

    FPGA Mac

    I remember seeing a comment in that thread of doom in the OP where the claim was thrown out that Pano hadn't implemented their interface to the DDR2 chips in the "standard way" and that was somehow making it hard, but I have *no idea* what the qualifications behind that claim were. (Frankly the actual implementation details for something like this are way above my head, I'm *just now* building up to thinking about buying a GAL programmer.) I'm sure they'd appreciate it if you could point out that they're boneheads and it's JUST THAT EASY!
  8. Gorgonops

    FPGA Mac

    Yep. It's a "legacy" product but the company's website promises they're going to keep making it until at least 2027. The toolchain issues the guy was moaning about were basically entirely self-inflicted. (I mean, yes, I get it, it's pretty absurd that you can have a "free thing" that only runs on a non-free OS despite the deeply ironic fact that it's actually in a VM wrapper containing a free OS, with mickey-mouse copy protection/DRM locking it up for seemingly stupid reasons... but that's how hardware vendors roll, sorry.) Given that the Spartan six is a bigbigfat BGA package if it *does* have unusued I/O it's a fair guess that they're lost to you on the Pano board unless it brings them out to hidden solder points. It doesn't appear looking at a picture of the board that it has any kind of GPIO header on it so, yeah, implementing legacy connectors probably isn't going to happen. Here's a Github specifically dedicated to documenting the reverse engineering of the board: https://github.com/tomverbeure/panologic-g2 It looks at least like they've got the basics laid out, but there are holes in what they know about driving some of the chips. They also don't appear to have the source code for any of what Pano did with it, so they're stuck with reverse engineering their own FPGA code for things like the DDR and USB controllers (it has a chip that has the USB PHYs in it, but the controller itself was implemented in the FPGA). In *theory* they can modify stuff off the shelf to do it, but since it's not a well documented reference platform it's understandable that it's taking them some time to sort it out. I guess the question is if there really are enough of these things in circulation to make it worth coming up with the needful to turn them into little Amigas or whatever.
  9. Gorgonops

    FPGA Mac

    Actually this is about the easiest problem. The Mac ROM does a really amazing job (for the most part) abstracting the underlying hardware, to the point that most mainstream classic MacOS emulators *don't* strictly emulate any particular real Mac, they hack the loaded ROM image to reference simplified synthetic representations of things like disk devices, frame buffers, etc. (BasiliskII and Sheepshaver are the poster children of this approach.) Taking this approach would be the most *efficient* way to utilize an FPGA to emulate some kind of generic enhanced 68k Macintosh with the best possible speed. Downside of it is the resulting machine isn't going to be strictly compatible with any *particular* real Macintosh, and will definitely fail to run software for Macs that *does* directly drive the hardware. (Alternate OSes like A/UX is a biggie.) Anyway, sure, that Pano Logic G2 board seems to be a really cheap way to lay hands on a great big Spartan6 FPGA that already has some RAM and UI ports soldered onto it. Digging through the articles the downside seems to be that no one has actually yet fully figured out how to use those pieces. Once they're figured out and the boards become a well-understood target for development... they're probably going to become less of a bargain, ironically enough. But indeed, sure, why not, I'm sure you could probably make a fairly freakily-fast "psuedo-mac" out of one of these things, particularly if you weren't too concerned about absolute best compatibility. The CPU core used by the "Vampire" series of accelerators for Amigas substantially outruns any real 68k CPU (through the 68060, anyway) and fits in substantially smaller FPGAs. If you do the "rom-hacking" approach you don't need a whole lot more than a block of RAM, a dumb framebuffer, some kind of storage, and UI interfaces to turn a working CPU core into a "Mac".
  10. Out of curiosity I looked up what that "Wavetable" mode does on the ASC, and perhaps I'm missing something but it does seem like it might be a little optimistic to describe it as a full-featured synthesizer in the sense of, say, the Ensoniq 5503 they used in the IIgs. It's my vague recollection that before the Quadras Macs only supported 8-bit samples (and I also think the sampling rate topped out at 22.5khz?), while the PAS 16 supported full 44.1khz@16bit "CD-Quality" sound. The PAS16 also has a Yamaha OPL3 hardware synth chip on it, and a hardware MIDI port. How well contemporary Macs could utilize any of that I have no idea.
  11. 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.
  12. 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.)
  13. 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?
  14. 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.)
  15. 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.)
  16. 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.)
  17. 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.
  18. 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.)
  19. 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.
  20. 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.
  21. 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.)
  22. 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.
  23. 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?
  24. 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.
  25. 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+.