With PowerPC, Windows CE and the WiiN-Pad Slate, Everyone's a WiiN-Er | Hacker News Reader

With PowerPC, Windows CE and the WiiN-Pad Slate, Everyone's a WiiN-Er

oldvcr.blogspot.com

118 pointsgoldenskye28 comments

It is somehow weird to see MPC821 in this kind of device. The point of (Power)QUICC line is that the Communications Processor is some kind of RISC/VLIW core, that offloads various communications tasks and has firmware support for various serial telco protocols. I would not be too surprised if MPC821 and MPC860 are in fact the same hardware only with different firmware that somehow bitbangs the LCD interface by (ab)using the SCC channels (original m68k QUICC datasheet mentions that there is a way to make one of the channels behave like Centronics parallel port).

In any case PowerQUICC with LCD interface is a device that is quite obviously meant for something like dektop phone with large LCD, not for tablets.

Quite large usage of PowerQUICC were Cisco 17xx/26xx series routers (with 16xx using m68k QUICC) that were used by many telcos in early 2000's as "SHDSL modems". If you squint enough the m68k QUICC is an entire Cisco 2500 on a single chip (with the added benefit that the QUICC SCC can more or less do scatter gather DMA directly into IOS's particle buffer datastructure, which IIRC was not the case with the Z8530-derived USARTs in 2500).

We're still shipping hardware with PowerQUICC stuff in it, its used in a TDM/IP intelligent channel bank.

NXP still sells those? Wow, e500 will never die huh

Where are people still using TDM channel banks? As someone who spent far too much time with TDM networks (mostly replacing them) in the late 80s, genuinely curious.

It's TDM internally, but converts to IP at the edge of the device.

It can still operate over TDM for legacy, but yeah, thats the answer.

As a person who really wanted the Sharp Mobilon TriPad PV-6000, this sort of thing makes me sad for what might have been.

I almost returned my Samsung Galaxy Book 12 to Best Buy back when the stylus was crippled to scrolling by Fall Creator's Update --- even now, I constantly have to toggle its compatibility state in Windows 11 to use it with different programs.

That said, my next tech purchase is a Raspberry Pi 5 and a Wacom One 13 w/ Touch --- hopefully it will work as well as the first gen. unit did w/ an rPi 4 and I can get off this software treadmill and just focus on using the machine as opposed to re-learning whatever UI update MS is inflicting this quarter.

hmmm, Surface works fine with Linux here, so that might be a sleeker alternative.

Yes, for folks who can stand NTrig, that works --- Wacom EMR or bust here.

Why would you prefer one over the other?

Hover distance is the big thing for me, and I mislike jitter when drawing slowly in NTrig, and I need more batteries to charge/manage like I need a hole in my head.

I have:

- Galaxy Note 10+

- Kindle Scribe

- Galaxy Book 3 Pro 360

- Wacom One

plus two spare styluses in my EDC bag, two more spares at the coffee table in the living room, and 3 more in a box on a shelf --- that they don't have batteries/capacitors and "just work" when I need them is an aspect of my life which I rely on.

I really wish my wife wouldn't have given her mom the surface I bought for her. I was really curious how well Linux would work on it while she had it for school.

Wow. Maybe if WinCE had this kind of thorough documentation back then it would have done better. Excellent article and history lesson.

(author) Hey, thanks!

WinCE was an interesting beast. The ones we made were MIPS (picked over an ARM system). Running a wildly patched 2.12. Also your PCMCIA issues? Trust nothing. It could be anything. But my guess is it is the driver, as getting that type of flash card to work consistently and correctly takes a steady hand. Your flash could also be slightly corrupt. We had almost that exact same chipset and found it would randomly stop taking commands after awhile and the flash leveling would cause writes to time out leaving half written pages. You also discovered Visual C++ for wince has a lot of interesting bugs. I think it got so bad we were about to start breaking each method into one cpp file as things could 'smear' between methods before the whole thing went EoL. There are newer versions of the compiler that may help some (maybe you already have it). If you got into the right program (or the right company) you could get the ODM build set. Which would compile the whole OS (based on a very bespoke version of visual studio 6 and a crazy mixture of using mklink and crazy batch files). But it would also let you debug the drivers. As for my 'trust nothing' I mean it. The API calls that should 'just work' may randomly crash or leak. Good luck!

We had the ODM. Had to rewrite critical pieces of it to make it work at all. The timer service had races - we fixed it and offered the fixes back, but arrogant Microsoft wouldn't take them, they were smarter than us and didn't need our help. So we had to repatch every release as they shipped the same broken code again and again.

Had to rewrite the DHCP code, theirs was one run-on procedure written by some intern. Didn't handle half the cases, took forever to conclude if it ever did at all. We needed to roam across subnets on the order of 100's of ms. Theirs took seconds to maybe complete. Junk. They of course rejected that too.

Best if WinCE were buried and forgotten?

I think MS didnt really 'own' the code. There was another company (b squared?) that owned large portions of it. We had the same DHCP issue. Also fixed many bugs in the ATL code taking up precious flash space for our bespoke version as we were 2 vendors removed from getting to talk directly to MS.

> Best if WinCE were buried and forgotten?

I am going to say yes. If someone ever finds one of the ones I worked on, my advice is to set it on fire then once it is done smoldering bin the thing and just get something better.

From my experience (though it was with CE 7) I got the impression that core kernel code is decent, but the rest of stack is haphazard collection of barely working hacks. APIs look like their NT equivalents, but not really, often missing crucial functionality. Documentation is often wrong or outdated, especially in BSP area, where it frequently mixes up how OAL interacts with the kernel with details of the optional PQOAL library. Same thing with driver documentation, where it confuses driver interface with describing MDD libraries. Finer semantics of the interfaces are mostly guesswork. Multiple barely documented touch device stacked on top of each other, with various ways of loading the driver and sending events to GWES. And the build system... that thing is just hideous.

If I remember right, Bill set several teams to writing an os for devices. The one that finished first, shipped. The 'winners' weren't even OS programmers. Thus, the naïve implementations of so many critical OS functions (drivers, timers, interrupt handling, flash)

I hate that attitude. I found a bug, fixed it, offered back to the company and they said "Don't worry, we'll find it ourselves eventually." Er, OK?

Wow, I had no idea it was that iffy under the hood. I might do more messing with the flash if it gets goofier. Yes, the issues with VC++ got annoying in a hurry.

Had one bug where we had a stray tab between methods. Would cause it to crash out the compiler. Putting us squarely in the no tabs camp.

The shape of that battery looks like it's got a pair of 18650s in them.

> This machine came from the Atlanta, Georgia area (snip), and certain identifiers left on it trace it back to Patient Care Technologies, a home-care, hospice and telehealth software provider. It's not clear if this machine was actually in the field or only used internally for testing. PtCT was bought by Meditech in 2007.

I'm sort of not surprised, the ancient winCE UI is about as ancient as meditech's UI.

Data General really gave it away. I was really thinking this thing was gonna be heavily a MEDITECH tie-in. DG was basically the platform MT was running on back in the day (before OSAL happened).

Wow, the author's gone above and beyond. Pages and pages of useful information, and this statement is just in the middle of a sentence:

"turn this into a phony ELF binary"

That would alone take me days to tackle (convert a PowerPC PE into a PowerPC ELF). He mentions it like it's similar to copying a line on a text editor.

Totally amazed at the level of detail and amount of work went into this article. Thanks!

(author) Thank you! But this was actually not very difficult. The PE format is well-documented, so I just extracted the code segment addresses, then generated an ELF by emitting code like this with a hacky Perl script:

  .globl main
  main:
     trap
     .byte 0xfc
     .byte 0xff
     ...

etc. Assemble, run that in gdb, it traps immediately, and just disassemble from PC.

The entire article was like 100X what anyone deserves. It was an awesome amount of detail. I absolutely love when random lost pieces of hardware/software history end up right where they belong with exactly the right person to know what to do with them.

32-bit PowerPC implementations do support little endian mode, but not from power-on reset. You can have a little stub handler that basically does the switch to LE by setting MSR.{LE,ILE} via srr1 and then performing a RFI after loading the return address into srr0.

It is notoriously difficult to write bi-endian code though. I really wish there were assembly directives to change the word swapping per instruction instead of doing it manually, for my own sanity.

I think the 970 supports this too, but it’s a bit weirder with the MSR.HV settings.

Note that little endian mode on PPC affects all memory accesses, including real mode when MSR.ILE is set.

Given that PowerPC supports indexed load/store instructions with reversed endianness it's doesn't cost extra cycles or code size to access little-endian peripherals. The real problem is how fragile drivers are these days.

Reply on news.ycombinator.com