Sleep Paralysis

GDEMUs required to complete the current batch are almost ready but still need to be cleaned, inspected, programmed and tested. And packed. And shipped. Which is a lot of work that people just never even think of when they say “manufacture it somewhere”. Point here is however the next week will have two national holidays and I will take the rest off to recharge a bit. So not much, if any, work will be done in that time.

But, I could perhaps at least prepare the list for Phoebe so orders will open on Saturday. As to actual shipping… we’ll see. I don’t want to mix both GDEMU and Phoebe since there is a risk I’ll mess it up, and at the same time I want to get both out the door ASAP. Usually the problem is people paying later than 24hrs after I ask for money since I try to ship the next business day. So if I do decide to mix both ODEs I will treat all “late” payments as 2nd class and delay the shipping to combine it with the correct devices. This lowers the likehood of a mistake on my side and gives you some motivation to check your email/PayPal more often. Either way you still get the 7-day payment window as before, that doesn’t change.

All early DocBrowns were shipped long time ago, please stop asking about those. The first normal batch is planned for late May. Menu software, the beta at least, is almost ready too so it’ll be a good time to release it.

Forsaken Well

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:

	Marty		FMTg3
	Read (ms)	Write (ms)	Read (ms)	Write (ms)
BYTE	17170	12315	21600	12155
WORD	8590	6170	10810	6080
DWORD	5565	3140	5410	3050

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:

	Marty	FMTg3
BYTE	15090	23625
WORD	7560	11815
DWORD	7550	5920
FONT	367450	383870

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.

TBC.

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.