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.


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.

Reign of Ivy

I’m almost done with current GDEMU batch so I will open orders for Rhea on Saturday.

After that is done I’ll try a short GDEMU batch targeted towards US west coast, since that place is the most disadvantaged when it comes to time zones. Depending on how many people will try to get one I might have to put a temporary geo-restriction. I dislike that idea and it’s more work for me but it would be silly to target west coast and end up selling everything to EU and Asia.

And, after all that is done, comes Phoebe. Probably the last week of March or early April, depending how well shipping goes. I might not make any additional posts, rather update this one, so please visit the blog before every weekend to make sure you don’t miss any ordering windows.

In the meantime I’ll try assembling the first few Marty ODEs and will ask some you that wanted one if you still do. As with every new device there might be some initial issues or limitations, and there is no menu software yet (working on it). So keep that in mind.

EDIT: I guess I didn’t make myself clear – when I said there will be a short GDEMU batch after Rhea is done I meant after I’m done shipping everything. Not this weekend.
EDIT2: Rhea orders are now open. Sold out.

EDIT3: In case you didn’t get your confirmation email the TL;DR version is “Wait up to 3 weeks, check your Paypal every few days and don’t bother me unless it’s important”.

Also, pray to whatever gods you fancy for the MLCC shortages to end quickly or it’s going to get ugly soon…

Where We’re Going

I feel better now but the same can’t be said about my coworkers so Saturn ODEs will be delayed further. I hope to have better news to share come 2nd week of March or so. But we did manage to get something done – I will have some GDEMUs for sale next week. I will open orders this Saturday.

Now, I need to explain a few things, let’s start with PCE: My device is meant to replace the CD-ROM drive, and only that. If you are looking for something more then there is another solution on the market that basically replaces the whole IF unit and AFAIK even lets you play cart-based games. It’s an interesting (if somewhat expensive) approach but personally I’ve always preferred to leave as much of the original console intact as possible. Because once you start improving and replacing things, where do you stop? But you have a choice now – and I wanted this to be clear as some people expect me to pretty much make the same thing, but cheaper.

With that out of the way let’s talk about FM Towns. Here’s a mockup of how the new ODE fits inside the Marty:

The final product will have black/gold PCB. I would’ve liked to keep the SD card socket at the edge of the PCB but it’s not really possible here – there are some pros and cons of this approach. You need to learn how to remove the card with your fingernail (it’s easy once you figure it out) but at the same time there is less risk of it falling into the console. Plus the PCB doesn’t move around as it’s being held by the original metal pegs. No soldering of any kind, obviously.

With the latest changes to the PCB I got it working pretty well, so well in fact I will offer that overclock option I mentioned to speed up loading times. And now it’s even better than 10% 🙂 I’ve tested a few dozen games with it on and everything loaded just fine. It’s completly optional though. Now I plan to order just a few PCBs to assemble by hand for the final check, and try to sell them. If there are no problems I will make a bigger batch. I still expect this batch to be small, while the PCB is bigger and considerably more expensive for me. Shipping will be somewhat more expensive too. Expect a bit higher price than usual, for now I think 150 Euro will cover everything.

Speaking of prices, I did take a look at non-Marty FM Towns machines. Well, I didn’t much like what I saw. For now I’m going to try getting a broken unit and attempting a repair – though I’m not very optimistic about that. But at the very least I will have some spare parts and something to study closer, since I have to figure out the connectors, where and how to put the ODE, etc. But a good, working FMT box is about 800 Euros (and full sets go for way more), and worse yet there are at least 3 distinct kinds: The original one with vertical CD drive, the U* versions that had the monitor built-in and a more typical tray drive, and the later 486 horizontal desktops. Which apparently also got an upgraded x2 speed drive at some point. I’m not even going to bother with the late Pentium and above models.
So chances are all these have different drives with different protocols, and I’m not buying one of each to verify that. Not at these prices plus I really have no space for any of it. So, those of you that want FMT ODE, any ideas on what to do about it? Please leave comments.

EDIT: GDEMU orders are now open closed. As usual please allow a few days for processing.

We Don’t Need Roads

Let me start with some bad news first: I have a cold, or flu, or whatever that is that’s been bugging me for a week now. And not just me I’m afraid – so long story short the Saturn ODEs will have to wait until 2nd or 3rd week of February. Hopefully by then I will have enough of either Rheas or Phoebes to take orders.

Since I’m having some trouble with PCE I decided to do something else, for the fun of it. I got some help too so a lot of time consuming tasks (like checking what signals go to what chips) were done for me. Again long story short I’ve recently made this:

It’s FM Towns Marty ODE I’m calling DocBrown – and the good news is I just got it to boot games this past weekend. Now, obviously it’s a prototype but seems to work pretty well actually, even if right now it needs that FPGA next to it to fix timings on one of the signals that I can’t get right with the MCU alone. I should be able to overcome this with some external logic/PLD though, I already have an idea and if parts arrive soon I can test it next weekend.

So far I’ve tested: Flashback, Loom, Indiana Jones and the Fate of Atlantis and Ultima Underworld – everything works. UU loading time is still terrible but that’s how the game was coded, it does a lot of short reads (tons of small files) and Marty requires drive seek times not to be zero. Still way faster than original drive, plus I found out I might be able to offer a small data transfer speedup via signal overclocking. It’s going to be optional and not enabled by default, and it’s just 10% or so – nothing fancy. Oh and the hardware was designed with CD+G support in mind but I haven’t tested or even coded that yet, first I need to get that core functionality right.

Anyway, if Marty ODE is something you’re interested in buying please leave a short comment – when/if I get it working without FPGA I could order revised PCBs for initial batch. Do note Marty drive is not the same as in regular FM Towns! If it’s the other one you want please leave a comment too, I might just buy that system next 🙂


I’m old enough to remember that a 386 not respecting R/W page bits in ring 0 was a big deal that had to be worked around in SW, incurring performance penalty. Fast forward a couple of decades and it seems paging is still a difficult subject. Make no mistake, this is no bug (Intel admits as much) but a design decision that produced perhaps faster but ultimately unsecure CPUs. Welp, not my problem, I have a buggy Ryzen 🙂

Anyway, I have some GDEMUs for sale so I will be taking orders this Saturday. Not all that many so it’ll probably be a short sale. More devices are in production and I should have some more Saturn ODEs soon as well. As in maybe this month but I’m not sure about that yet.

Very sorry about lack of PCE status updates, my December was more busy than I predicted, but there will be something worth showing in the coming weeks. Turns out working on so many projects at once can slow things down quite a lot. Who knew?

EDIT: GDEMU orders are open closed. Before you complain about this being sneaky, trust me, it’s the better solution. A lot of you claim you’d be willing to get on the list even if it meant months of waiting, so long you were sure you are getting one. Let’s just say I tried that and know from experience it’s BS so I won’t be doing it this way anymore.

The Stroke of Midnight

Consider it a late Xmas present: There is a new FW for Rhea/Phobe that should fix those few games that use CDDA for voiceovers. It’s probably not a complete list but the affected titles are:

  • Taito Chase HQ
  • Side Pocket 2
  • Space Jam
  • Nobunaga no Yabou Shouseiroku
  • Monster Slider

I did test it but not very extensively and the code change is significant so new bugs might manifest too 🙂 Speaking of bugs, keep in mind that Bug! works but only when booted cleanly without RMENU. And obviously the fixed games I mentioned do require the images to contain all the subchannel data to work – so make sure your dump is correct. I will ignore any problem/bug reports from people who can’t tell, but I realize not everyone knows (or want’s to know) such technical details. So as a rule of thumb a CUE/BIN format doesn’t have subs (yet another reason why it’s shit) but CCD does. If it was properly dumped from original disc anyway. Same for CDI but this format defaults to no subs so again you need to know how to rip the CD properly or you will end up with an image that doesn’t quite work. MDS/MDF is like CDI, it can carry subs but it’s not the default setting.

This whole format issue comes back every now and then, and each time I hear the argument that CUE is not so bad – 90% of games work without issues. Well, I don’t aim for 90%, I aim for 100%.