Jump to content


  • Content Count

  • Joined

  • Last visited


About Gorgonops

Profile Information

  • Gender
    Not Telling

Profile Fields

    Board-Certified Kvetcher

Recent Profile Visitors

1451 profile views
  1. 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.
  2. 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.
  3. 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?
  4. 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.
  5. 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!
  6. 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.
  7. 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".
  8. 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.
  9. 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.
  10. 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.)
  11. 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?
  12. 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.)
  13. 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.)
  14. 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.)
  15. 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.