So, I tried an experiment. It was painful and awful and mostly a failure. But it's not completely over. It could turn out rosy and beautiful.

I created a Blogger blog, published it as blog.nimblemachines.com, and copied to the new blog the existing blog posts from here that were about Forth and weren't rants about Sites.

The result? After choosing, at random, a nice green template, and tweaking the CSS a tiny bit so it wasn't idiotically narrow, I notice that it looks like complete crap. The spacing before and after the headings is all wrong, links are BOLD and GREEN, and other retardations of style.

I am sooo sick of companies with zillions of dollars that can't present the option of a small handful of decent templates, instead of gawdawful crap. Would you like your shit in brown or green? I had exactly the same problem setting up this site.

Aside from all that, blogging on Blogger is probably better than on Sites since I could in theory fix the Blogger template to be halfway decent, AND it has RSS, AND it has decent URLs, AND it isn't alphaware - like Sites! - that keeps threatening to lose my posts.

I could even move the static pages over as blog posts, and simply link to them in the Blogger sidebar.

Thoughts?

I'm trying something slightly crazy, and progress is going slowly.

I want to get Forth and a simple USB bootloader running on Freescale's S08JM parts. But instead of doing that the easy way, and buying P+E Micro's USB Mulitlink programmer, I decided it would be interesting to see if I can bootstrap from nothing.

Well, not quite nothing. But to explain that I have to explain some history. The HC08 is really two sub-families: the original HC08 and the newer HCS08. I refer to these here as "908" and "S08". (The "9" means Flash memory, rather than ROM or OTP EPROM. The 908 and S08 parts both use the same Flash.)

The S08s are nicer in almost every respect than the 908s, but they are harder to bootstrap. In fact, without the use of another microcontroller they are basically impossible to bootstrap. Rather than having a bootloader in ROM, like the 908s, they have a piece of hardware on-chip - the background debug controller (BDC). This bit of logic is really a poor man's JTAG. It allows access to the CPU registers, can start and stop the core, read and write memory, and because it can do all these things, it can run code that writes to Flash.

These are really nice features, but the downside is that the custom protocol required to talk to the BDC needs to be driven, with fairly tight timing, by another microcontroller.

Could I use a 908 to bootstrap an S08?

In 2006 I sampled two flavors of 8k Flash, DIP16 parts: the 908QB8, and the S08QG8. Since the 908 has a built-in bootloader, I thought I would start by talking to it, then put just enough code on the 908 to talk the BDC protocol to program the S08... Then put a nice, simple, UART-based bootloader on that chip that I could use to program the S08JM parts - my eventual goal. A long road, but mostly an interesting one.

I met with some initial success. Using two resistors and an HCT244 I was able to connect an RS232 level converter to the 908's PTA0, which the bootloader bitbangs at 9600 bps.

I wrote a bit of Forth code that allowed me to read and write memory, the registers on the stack, and was able within a couple of days of fiddling around to download code into RAM and run it successfully.

Flushed with success, I breadboarded an S08QG8 next to the 908QB8. Since most of the S08 families run at 3v (1.8 to 3.6), I had a voltage-conversion problem. Since I already had an HCT244 on the breadboard, I thought I would use that in the S08 to 908 direction, since the HCT input levels will be just about right for 3v logic. Driving the S08's BKGD pin to 3v is a bit trickier, and I'm not sure I've come up with a good way to do it.

Freescale describe the BDC protocol as "quasi-open-drain". Since it's a one-wire protocol with multiple senders, it needs to have a pullup to Vdd (which is internal to the S08), and the senders need to be able to drive it high, drive it low, and 3-state it.

My approach involved using three port pins: one directly connected to BKGD to pull it low; and a voltage divider between two others - one driven high and one low - that would put approx 3v on BKGD. This doesn't seem to work, and I'm not sure why.

Of course, there is another issue that I haven't mentioned that consumed quite a bit of time to debug. Since the BDC protocol is based on the target's clock speed - each bit transmitted taking 16 BDC cycles - I need to drive BKGD fast enough to keep up with the target. The "host" - in this case the 908QB8 - has an internal oscillator that at the fastest setting yields a bus clock (instruction clock) of 3.2MHz. The 9S08QG8 runs its BDC clock at 8MHz. The tightest code I could write for sending and receiving bits was too slow, so I spent a bunch of time debugging oscillator settings.

After finding a 25Mhz crystal, I'm now running the 908 with a 6.25MHz bus clock, which is fast enough to keep up - but it still doesn't work.

Which is why I thought I'd take a break and document my progress, instead of driving myself crazy.

I'm working on porting Forth to Freescale's 908 and 9S08 parts. I got my first samples in 2006, got discouraged, and stopped working on the project. For mostly unknown reasons I've been recently inspired, and have picked the work back up.

Now that it's the end of 2008, I wish I had worked on it in 2007 and early 2008 so that on 2008-08-08 I could have released my code to the world!

Oh well. Better late than never?

If I had any sense, I would be using Atmel AVR parts. Why do I say this?

• there are a bunch of folks in dorkbotpdx using Atmel AVR, including building nifty boards, so there is local expertise and groovy local hardware available;
• the AVR is fast, and it's a good match with Forth - at least from the perspective of register allocation
• there are decent USB parts available, as well as low pin count DIP packages for easy experimentation.

Why, then, am I concentrating on Freescale's HCS08 instead?

I've mentioned elsewhere that I like the 6800 heritage. It's nostalgic for me. But that's a ridiculous reason, right? So what are some compelling reasons to use these parts?

Attractions of the S08

Cost

They are quite cheap - cheaper than comparable PIC or AVR parts - and you get a lot of bang for your buck. For instance, the S08QG parts in DIPs have a UART, SPI, and I2C, all standard, a good selection of timers, 8 channel 10 bit ADC, and some nice add-on features, such as clever compare logic in the ADC that causes an interrupt only when a value crosses a threshold. The USB parts have 12 bit ADC, 2 UARTS, and 2 SPI ports.

Also, it's quite easy to get free samples, directly from Freescale, and also to buy directly from them, for very competitive prices, even down to quantity one.

Flash

Unlike Atmel's Flash, which is only good to 10k cycles (if you're lucky) and has a short retention lifetime (10 years?), Freescale's Flash, like much of Microchip's, is good to 100k cycles and has a retention of more like 100 years. This might not sound like a big deal, esp for hobbyists, but philosophically I find it unappealing to use something so obsolescent as Atmel's chips.

Von Neumann architecture

A feature that is here in the "pro" column but also has a dark underside. Since RAM and Flash exist in the same memory map, it's possible to execute code out of RAM - and in fact it is necessary to do so when executing code to program the Flash. Code in RAM make several things possible:

• self-modifying code
• "specialised code", generated on the fly on the target
• nice interactive development - ie, the ability to define and execute new bits of code while "online" with the target

Built-in debug architecture

This is an attractive feature, esp if you're going to use Freescale's development software, which can take full advantage of it.

Basically, every S08 part - even the lowliest 8 pin part - has not only a background debug mode (BDM) single-pin interface (which can be used to Flash empty parts, to reprogram parts, and to debug running code!) but also a tiny built-in in-circuit emulater (ICE). There are two code breakpoints and one data watchpoint available in hardware, with sophisticated chaining available between two of them. There is also an 8 entry trace buffer, allowing the capture of address and data bus values.

Considering how "low-end" some of these parts are, this is quite a stunning feature.

Quality peripherals

It's more "gut feeling" than real empirics, but the quality and flexibility of the on-chip peripherals seems very high, compared to AVR and PIC. Maybe when I re-develop all my code for AVR I'll have harder data on this one. ;-)

Upward migration path

Freescale have introduced several new S08 families with the so-called Flexis architecture. The new USB parts - the S08JM family - are Flexis parts.

Flexis families have both S08 members, and 32-bit ColdFire members, which are pin-compatible and only a bit more expensive than their 8-bit cousins, making it easy (assuming your code is not in assembler!) to upgrade to a fast 32-bit core. The peripherals are exactly the same 8-bit peripherals in the S08 parts, so all that code - again, assuming it's in a high-level language - will port over trivially.

Or so the story goes. It's a nice idea, and if you're not interested in ever using the 8-bit version, it's a way to get quite cheap 32-bit parts.

And since ColdFire is essentially 68k, it's a good target for Forth and C (and everything else) and also nice for nostalgia buffs.

Distractions of the S08

Ok, so how about downsides to the HCS08? There are several, and a few are big ones.

• lack of community
• lack of open source support
• lack of cheap, universal, and easy-to-use development hardware
• lack of off-the-shelf "target" hardware (eg, like Arduinos and clones)
• lack of registers! making Forth a bit tricky
• von Neumann architecture slows execution considerably
  
• most S08 parts are 3v only (1.8v to 3.6v), though there are a few 5v families (intended mostly for automotive customers)
  

I think the hardest for me right now is the lack of development hardware. I have some chips, but I have to do some work to be able to try them out. I'm currently busy writing code, but soon I'll want to try it on some real hardware!

My samples of the S08JM16 and S08JM32 parts are on their way. Sadly I don't have a way, when they arrive, of doing anything with them. I lack the breakout boards to make them useful - they are in LQFP32 and LQFP44 packages - and I lack a way to talk to and program them. S08 parts use a Background Debug Mode (BDM) - a single-wire, half-duplex interface that is used both to program the Flash and also to debug live code.

One annoyance with Freescale is that there isn't a single super-cheap board to talk to BDM via USB. Each subfamily (such as JM) has its own DEMO board (costing $30 to 90), which has a USB to BDM connection, but usually somehow castrated to work only with that subfamily. The one "universal" BDM board is about $99. I may have to get one. It's the AVR Dragon of the S08 world - but more expensive!

I just realised that a fun way to play with this stuff might be the JMBADGE. These are quite cheap ($30 I think), and have loads of possibility. The JM family is one of the "Flexis" families, which consist of S08 (8 bit) parts on the low end (8k to 60k Flash), and ColdFire V1 parts on the high end (50MHz CPU, 64k to  256k Flash). I could misuse this to program other parts via BDM. And it looks like a fun gizmo.

Once I finally understood what a Benito board was, I started thinking "well, that's pretty neat, but it lacks any ADC on-chip; otherwise it would make a nice replacement for the Arduino, at a fraction of the price".

Well, clearly Don (a fellow dorkbotpdxer) has similar ideas.

But it doesn't end there. I'm currently exploring the idea of using Freescale's S08JM family of USB microcontrollers - in part because they are retro & nostalgic (for me - I wrote my first program for the 6800), and in part because they are true von Neumann machines (one memory space for both code and data), rather than Harvard machines like their AVR and PIC competitors. A true Harvard architecture makes interactive Forths difficult to write, since RAM is always in data space, and Flash is in code space. For interaction I want to be able to execute code out of RAM - but I can't.

There are some serious downsides to using these Freescale parts. First, Freescale's toolchain - the bloated Codewarrior - while free is not open source, and is Windows-only. Second, there isn't a single piece of cheap hardware - like the AVR Dragon or PICkit2 - that can program all of Freescale's HC08 parts. Each family has its own DEMOxxx board, and each one costs $50. There is a nifty thing called the USBSPYDER08, but it only works with lowest-end parts - not with the JM family.

Wondering about this once again, I did the following Google search: "open source hc08 tools" and landed on a Freescale forum devoted to the OSBDM08 - an "open source programming cable". Sadly, it seems to be supported only under Codewarrior. But, rather interestingly, the latest thread is by "Brad R" who "writes Forth compilers" and is interested in Linux support for the OSBDM08!

This is, of course, none other than Brad Rodriguez, long-time Forth author and explainer, who created the CamelForth series of 8-bit Forths.

Pretty cool.

But it seems I'm spending time, instead, farting around with this silly site, and silly Sites.

I discovered that I can subvert, to some degree, the lack of an editable stylesheet, by embedding some style info in my elements. A good example is the markup for Forth words in MuforthReadme. I generated this page using the code that used to run my wiki site. It's a Perl script that mostly rewrites the wiki markup into HTML, and wraps the body in some boilerplate. It was pretty easy to confuse it – by setting a few environment vars – into thinking it was running as a CGI, and to "render" pages by spewing them out stdout. I'd simply select the text, copy it, and paste it into the Sites page editor. It's clumsy, but I'm not planning to do this very much.

The markup that script generates, for a Forth word, is

   <code class="forth">word</code>

Since the Sites editor strips out class attributes, I added a style attribute and tried to style the text the way my CSS sheet would:

   <code style="font: monospace 100% bold; margin: 0 0.2em; color: #800000">word</code>

That sort of worked, but the font bits were stripped out. Their stylesheet renders <code> elements as monospace already, so all I needed was to make it bold. Easy: wrap the whole in a <b> element.

So I edited my script, re-generated the page, uploaded, and voilà.

But, hey, the site is up, and it might be a useful resource for people, for now.

I have three major beefs with Sites:

• their HTML is awful, and posting my pre-generated HTML and then editing it was really awkward
• their wysiwyg editor keeps inserting <br> tags in random places - evil!
• after a really hairy edit, in HTML mode, I updated and it barfed and lost all my changes - also evil!
• there isn't meaningful CSS editability, so the site is ugly. I made it narrow for readability, but it's ugly still.

I'll look seriously at wikidot after this. And maybe I'll get it together to abuse Blogger and bend it to my wishes.

I'm doing all this - enduring the pain of understanding how Sites work and trying to make the best of it - so that I can start working on muFORTH again, but also have a place to share my thoughts about it and my progress.

What I plan to work on in the very near future:

• update muFORTH's license, changing from MIT X to two-clause BSD
• update the boilerplate that's supposed to refer to a place on the web where info about muFORTH lives, and which now points into etherspace
• add support for Freescale's HCS08 architecture so I can start to fiddle around with the MC9S08GQ8 chips I have, and also with some MC9S08JM16 USB chips that I plan to sample

With luck I won't derail myself before I make any progress. Wish me godspeed.

I needed a place to put an introduction to muFORTH so I could modify the git sources to point there instead of ... nowhere, which is currently where they point.

I'm not a big fan of Google's approach to publishing - at least their "canned" solutions like Google Sites (what yer lookin at) and Google Pages (which they are deprecating and will eventually no longer support, in favor of Sites). But, being a beggar - looking for free places to post content - I can't be a chooser. (And I don't want to wait any longer for me to figure out how to bend Blogger to my wishes.)

Why so curmudgeonly? Well, they (Google) care about different things than I do. I care about (among other things)

• valid XHTML
• semantic, rather than presentational, XHTML
• using CSS to support said semantic markup
• using nice human-friendly (wiki-style) markup to author content, rather than wysiwyg editors that generate non-extensible markup
  

At least in their publishing apps, Google mostly don't care about these things. Or they do, but they don't give me the choices that I'd like to have, instead choosing perhaps to present an interface that will satisfy many users, and those left out will suffer or go elsewhere.

For this application I'm stuck with what Sites does and doesn't. But that's ok, since you're here to read about muFORTH and not to listen to me rant about web publishing.

I hope that you're enjoying my choice of the silliest, mostly childish "theme" I could find. It's a sort of ironic raised middle finger pointed at Google.

If, in spite of all its faults, you want to use Sites, you might be interested in the following quirk I discovered. I'm using the version of Sites that exists in Google Apps (which hosts most of nimblemachines.com). The version of Sites that you get with your regular Google account might be different.

Sites tags both site activity and anouncement posts (like this one) with a Real Name that is derived from the username of the person who made the changes. In the Apps version of Sites, this association is made in the "user list" part of the domain dashboard. What's strange is that on an old site that I had set up, the name it used was simply the unadorned username. Today I noticed it used my Real Name, and that there was no way, in Sites, to change this behaviour.

What is even odder is that Real Names associated with anouncement posts (like this) are generated dynamically from the current name in the user list for the domain, but the Recent activity log - both on the sidebar and available from the footer link - is statically generated and contains the Real Name associated with that user at the time the activity occurred.

For unexplained reasons it annoyed me that my Real Name would be splattered willy-nilly over this site. So I deleted the old site and re-created it to start with a clean slate.

I also changed my Real Name to something that is hopefully amusing.