Jump to content


  • Content Count

  • Joined

  • Last visited


About Gorgonops

Profile Information

  • Gender
    Not Telling

Profile Fields

    Board-Certified Kvetcher

Recent Profile Visitors

2750 profile views
  1. Sure, but given practically every modern CPU has had floating point built-in since the mid-1990s and much of the really backbreaking stuff we expect from modern CPUs leverages the floating point hardware (granted often in the form of SIMD instructions) you certainly can't just ignore that if you're trying to map out just how much performance (both absolute and per-clock) has evolved over the years. But, yes, this is a little off topic for the 68000. (Although hypothetically you can *use* a 68881 with one it doesn't integrate the same way as it does on the 68020+. The 68010-based SUN-2 sys
  2. Since you have access to such a wide range of systems, how would you feel about running the old "flops.c" floating point benchmark on them? I'm grimly curious how that scales to really old systems. (I used to have a collection of results for that going back to the Pentium era, but now the oldest I can find is some scores from G4 systems.) flops.c results can be very compiler optimization-sensitive, which I suppose is a downside. I'd probably just suggest going with "-O3" across the board on the first crack.
  3. Just to satisfy my curiosity I made a "junior" version of the benchmark that finds the primes under 32768. (IE, the limit of a signed 16 bit integer.) I compiled two versions of it on the Tandy, one retaining the 32 bit "LONG" ints and the other using the standard 16 bit ints. The results: (Ignore the incorrect printout from the "PRIME16" binary in this shot, I neglected to change the printf format string on this run and didn't catch it until I already processed the screenshot. Fixing the format string produces the correct output.) The "Long" and short of it is the one with
  4. I suspect that anything that's not a 32 bit CPU is automatically going to take a huge hit. "Longs" don't come naturally to the 8088. (That may put the 68000 in a slightly interesting spot because hardware-wise you can kind of argue it's really a 16 bit CPU emulating a 32 bit one, IE, it has a 16 bit ALU, etc.) In general usage a 68030 is certainly going to be a lot faster than a V20 but 35x per clock is probably overstating it a *bit*. (The spread observed here is actually of very similar magnitude to the difference in BogoMips scores between the two CPUs, coincidentally enough. And as t
  5. I don't think you'll specifically need a C++ compiler, that code is really elementary C and should be pretty easy to get running on just about any C dialect.
  6. Ahahaaahaaahaaa! So the grand total is about four hours and 24 minutes, or 15,845 seconds. For comparison here's what it takes on a 2.6ghz i7 2019 Macbook Pro: $ gcc -O2 dosprime.c -o dosprime $ time ./dosprime 78498, 999983 real 0m0.222s user 0m0.214s sys 0m0.004s Or about 75,000 times faster, give or take. And, of course, it’s only using one of the six cores so the truth is far, far worse. Of course I'm sure this is about the worst conceivable case scenario for an 8086 compatible CPU, performing a shedload of modulus operation on 32 bit numbers, but I'm st
  7. It's a shame nobody's replied to this. For laughs just compiled your benchmark set to look for 78,498 primes using Turbo C++ 1.0 on my Tandy 1000HX, I'll update when it's finished running. I'm grimly curious how its 7.16mhz NEC V20 stacks up against the 68000.
  8. Okay, so, this is not the first time this kind of stuff has been posted here with absolutely no explanation, so I've deleted the files. This is not some kind of malware mirror site, and if it's not malware the OP owes a clear explanation as to how this is relevant to the focus of this forum and why they believe the audience here might be interested in it. Thread locked.
  9. The Greaseweazle might be a better bet, it supposedly works with "standard" SCP flux images which gives you several options for decoding 800k data. The "Blue Pill" ARM board it uses is very cheap and widely available. (You can buy a few plus a programmer off Amazon for $15-ish.)
  10. FWIW, I just went ahead and pitched this into the PPC powerbook/ibook forum.
  11. One thing to be a little wary of is that those green phosphor tubes are a little more susceptible to burn-in than the white ones. An Apple II is less likely to have something permanently on the screen like, say, the Mac menu bar, so... just throwing that out there. But, yes, if the yokes physically fit you should be able to swap them. It can be a pain to get the yoke correctly oriented, though.
  12. Mod Hat: It's possible there could be something of use to *somebody* on the MLA since some of these tools could be useful for generic bare-metal 68000 development, but it does seem like it's a bit of a stretch. It would probably be preferable if the OP would stash these somewhere else, maybe stuff them on Github or whatever, and link to it with a coherently titled thread about "68000 cross-assemblers for Windows RT" or whatever.
  13. In case anyone is confused, apparently rmac and rln are cross-assembly tools for developing 68000 and other binaries, mostly targeted at Atari machines: http://rmac.is-slick.com/about/about/
  14. Mod note: I went ahead and moved this to "Compact Mac"; the auto-redirect link in the Mac II forum will expire in 30 days.
  15. If we want to be super-pedantic according to the spec CompactFlash cards should also support several alternate addressing modes, one of which is access via an 8-bit subset of the data pins. This is to make the format easier to use in some embedded applications. (And it's also used by some homebrew retrocomputing storage devices, like the XT-CF card for 8-bit bus PC compatibles.) But CF cards running in IDE adapters or plugged into a full PCMCIA slot will be running in normal 16 bit IDE mode. (They usually even support DMA modes.)
  • Create New...