All Rheas have been shipped so it’s time for that small GDEMU run. I will open orders, as usual, on Saturday. As promised I will try to better match the time to USA west coast. If my calculations are correct you should be able get up at 8 and still have time for shower and breakfast. I’m not making it USA exclusive but I do reserve the right to reject other orders.
Also, people, the “Name” field in the ordering form? It’s for your name. Preferably it should match the Paypal one, it makes my life easier. I’m not selling your personal info on the side to Facebook or Google (or anyone else for that matter), I’m not that evil. Besides Paypal probably already did that long ago 🙂
Now, I wanted to explain a few things regarding FM Towns Marty because it gets a lot of flak from uninformed people. Some even actually own the console and still repeat that BS anyway…
First thing is the Marty CPU. The 386 “haha, slow piece of shit” SX. Well, I now have a working generation 3 Towns tower and have run some actual tests to compare. Here are the RAM read and write results, done for 8, 16 and 32-bits access patterns:
|Read (ms)||Write (ms)||Read (ms)||Write (ms)|
Noticed something? Write is faster than read – that’s curious but not that uncommon, depends on any extra cycles that have to be added to meet setup and hold times to make things reliable. Plus the tests aren’t identical. But the real shocker is how Marty is actually way faster at 8- and 16-bit reads, and pretty much matches 32-bit ones even with it’s reduced 16-bit bus. How is that possible if the tower has a 386DX CPU running at the same clock speed?
The answer is actually simple – wait states. Now this is a bit of my speculation but back in ’88 or so, when Towns was close to release, DRAM was still slow and expensive. And much like today the faster you went, the more it cost. So first generation Towns had a slow RAM that required 3 wait states to work, and my guess is that setting was left for gen 2 and gen 3 to keep things at the same speed and not break any compatibility. The CPU was the same anyway.
Marty was released after gen 3, along with generation 4 and the new U-models that had the monitor integrated in the case. These too were 386SX based. By that time though DRAM was considerably faster and so it’s running with zero wait states, basically removing that SX half-width data bus penalty. “Wait,” you might say, “wouldn’t optimized software deal mostly with 32-bits anyway?” – and that is faster on the DX, if not by much. Plus what about VRAM? Well, I’ve run some more tests:
These are VRAM writes, and the last test is font rendering (again measured in ms). As you can see Marty is way faster except for 32-bits – which is now exactly the same speed as 16-bits due to CPU having to split each access into two and no clever optimizations for that taking place. So only very optimized 32-bit block copy routines will be faster on the 386DX. But hey, that’s probably what games mostly use, right? Perhaps, but 386 doesn’t have any cache memory (not counting TLB) and you still need to actually run the program, and x86 code is messy. Which means every instruction is RAM read, often more than one if the fetch is not power-of-two bytes long, or longer than 4 bytes, or unaligned. At which point Marty will pull ahead and indeed the font test was faster on the SX-based system.
So, TL;DR is Marty has it’s issues but slow CPU is not one of them.
By the way, there is a program that can change the wait states on gen 1-3 Towns, though keep in mind the actual slow RAM is still there, you can’t reduce it by much and expect the system to still work. As a rule of thumb you can go one less wait state with each generation, so my unit can actually go to zero and still seems to be stable. I’ve tested that setting too and, except 32-bits, RAM reads are still slower than Marty. But with writes getting a bit faster and 32-bits too, the font test is now clearly won by the tower. Starting with generation 4 there is also a FAST mode, basically zero wait state mode guaranteed stable by manufacturer. Though to be frank if the 386 isn’t cutting it for a game you want to play, neither FAST mode nor a 486SX will help. You need a DX2 or Pentium based machine.
UPDATE: GDEMU orders were open what, 3 minutes, and everything went. In fact it’s possible some of you will have to wait a bit more since I might have oversold a bit – this was a small batch after all.