Arduino Nut

2011-03-15T14:52:00.000-07:00

I always use this program as the benchmark test. If you've ever owned a ZX81 then you know what it is. It has such a strong resonance with me. The first time it loaded from tape after the tense 6 minutes of FSK madness it almost stopped my heart. And then I played it.

Fast forward 30 years...

Ladies and Gentlemen.

ZXpand.

Allow 28 days for delivery...

...or get one in 10

See previous post for links to further information.

ZXpand Issue 1

2011-03-15T00:41:00.000-07:00

Rex lies in wait.

More details and a draft manual appear on http://www.rwapsoftware.co.uk/zx812.html

Making things

2011-03-14T14:49:00.001-07:00

I love making things. Tonight I made this thing:

It's a twin ROM switcher, or rather 2 twin ROM switchers, one of which is destined for a C64. JiffyDOS enhanced kernal in one side, regular kernal ROM in the other. SPDT switch added to the pads with a common centre and it's cake time! I'll post a minimal entry when it's looking a little more complete.

I've been making PCBs for a few months now and I'm getting to the stage where I need to start investing in some beginner++ equipment. I have a ghetto UV exposure box that some kind soul freecycled a few years back. It just about does the job but it only has one tube and that makes getting an even exposure hard. You can see on this board that one side is either overexposed, overdeveloped, overunderdeveloped or underoverexposed. Or something. I'll never know, I guess. I suppose seeing that the traces have disappeared then either the negative wasn't pressed closely enough to the PCB or it was overexposed. Reviewing what I did this evening I find it hard to see how I could overexpose one edge like that. That is the mystery and marvel of this process - you have to aim for a zen-like approach otherwise it will end in tears.

Still I think it'll work. I designed this mainly so that I could try out the new PCB material that I sourced. It's a lot cheaper than the usual gear that I score . Even with my relatively inexperienced dabbling I know I have to get a feel for how it reacts to the chemicals. See? Zen again. The design has a lot of traces weaving through the space between pads. It scared me a little while I was eagling it. Ha but now who's the daddy eh?!

Anyway now I've rambled and the board appears to have dried of natural causes I'm off to drill it. Super!

Presenting: ZXpand!

2011-03-11T14:37:00.000-08:00

It's only taken me about 3 years.

This is the test fitting of ZXpander prototype 1. You can clearly see that there are some sockets empty. Well, I didn't want to overwhelm the poor old chap.

And yes, it worked! Eventually. After being hacked around so badly that the poor thing's mother didn't even recognise it. It ended up carrying another chip and looking somewhat like Joseph Merrick. But let's not get ahead of ourselves! This was P1, after all. Things are supposed to change. So to P2! Fast forward to only 9 months ago!

My good friend and inspiration Ramoth had been extolling the virtue of programmable logic. He has made the transition to the state of the art while I, comme d'habitude, crept in at the lower, and rather more obsolete level. I decided that I could just about cope with GALs and maybe, just maybe these would provide the answer to my overcrowded board problem! For that is what I had. I couldn't lay out the board to any degree of satisfaction now that 7 TTL chips were required.

So one eBay purchase of the most basic programmer capable of writing GAL fuse maps later, I was dipping my toe into the confusing and contrary world of programmable logic.

The best thing about setting out to work with obsolete technology is the complete lack of any decent documentation and sample code. Oh hang on, that's not the best thing is it. That's the _worst_ thing. Ho hum. Still, after having crawled inch by bloody inch up the steepest learning curve I've ever encountered since girls, I managed to make P2 work.

Here's its good side...

5 TTL chips lighter, this one only required some very delicate hacking...

JESUS! What have you done to it man!

Well it needed some ICSPing. And an extra AND gate. And the 'get it quick' prototype board from PCBTrain doesn't get solder mask, so ... it's not pretty. I realise this. But you know what?

It works.

P3 is immanent. Watch this space!

DMAybe

2010-02-18T15:05:00.001-08:00

This little cutie is the dogs dinner pudding.

I've wired and programmed the controller to assert /BUSRQ, wait for /BUSAK and then have its wicked wicked way with the address, data and /WR lines. Thus effecting some access to memory directly for the uC.

It's not enough unfortunately. I'd forgotten that my internal 32K expansion requires /MREQ to be asserted in order to enable the memory decoder. Which would explain why it doesn't work :)

That and the phantom blips on the /RD line that I'm seeing.

I don't know yet whether this is the ZX81's ULA interfering or some pedigree chum-based effect that would go away if I soldered the thing more carefully..!

I'm glad I've built a prototype - even if it is kind of awful.

I'm off to do some more soldering and a bit of firmware tweaking. Be right back.

Laid out cold

2010-02-14T02:26:00.000-08:00

Here is the manually routed board according to the schematic posted last week.

I've learned a lot in the past few weeks. This layout is the result of having the patience to rip it up and start again. Multiple times. I think this is the 4th iteration so far.

I've broken a few rules along the way, I'm sure, but having looked at the Gerber files in a suitable viewer I think, at least electrically, it might work. When I say work I mean not go on fire. There are no bits overlapping when they shouldn't, no vias encroaching uncomfortably on one another's personal space, and no wires with insufficient clearance.

Having two layers to work on at board-house resolution makes things significantly easier than working at home-brew resolution on single-side designs. Sticking to a few rules which at first seemed punitive and arbitrary has produced a good result. One layer has tracks running horizontally, the other has them vertical. It's hard to describe how this makes things easier but once you start routing it surely does. Some board houses restrict the number of vias you can use, but the one I intend to use has no limit.

I find this activity strangely relaxing. If I knew what a zen-like state was then I think this may approach that. It's rare these days that I get into any kind of zone but taking time out to sit with Eagle for an hour gets me really close.

I finished routing this board despite the fact that I decided to use a different IO expander halfway through due to the fact that:

MAX6956 are nearly £10 each to buy...
...when you can actually source them from somewhere.

The MAX has some nice features, not merely the fact that the IO pins line up reasonably neatly with the address lines on the RAM chip. And the fact I've used it before helps too.

I have aligned myself with the Microchip MCP23x17. It's a 16 port expander with either I2C or SPI interfaces. If the SPI version can live peacefully with the MMC interface then I'll choose that - it can be driven faster than the I2C version. There will be times when I'll be reading from MMC and simultaneously driving address lines via the expander. The MMC transfers have to happen in a stream and unless I can cache an entire sector's worth of data in one go then the actions will have to be interleaved. If that's not possible then I'll be looking out for a bit-banged I2C implementation. The I2C and SPI pins and registers are shared on the PIC.

Of course I'll have to try all this out before I commit to FR4. This is the dogs-dinner prototype.

There's not going to be any MMC on there for the moment - the idea is that I'll be using the board to try some elementary DMA by driving the address and data lines on the ZX81. Once I get that working I'll turn my attention to trying simultaneous expander and card access. That can be done on a breadboard though.

ZX81 MMC Redux

2010-02-08T14:04:00.000-08:00

I like a good faff and I suspect you do too. Don't be ashamed. We all do it. However I've done rather too much of it recently and I'm going a little blind.

I want one of these:

Eagle schematic here (you might need to right-click-save-as)

So I'm going to have to bite the bullet and make one. I've decided that the simplicity of bit-banging is all very well and good but sometimes ambition should be allowed free reign.

With that in mind may I present 'The ZX81MMCRAMANDIO Board'!!

Ahem I'll be sacking the marketing man later.

It's a combined 32K RAM, SD/MMC and IO interface for a ZX81. 32K of static ram from 8K-40K will give true hires capability. A jumper will allow the on-board RAM to be disabled on those machines already internally expanded. It will be able to perform some basic DMA and be able to fill the machine's RAM with code and data from the SD/MMC card. This eliminates the need for loading of firmware from cassette or having external ROM.

The Z80 processor has a rather endearing ability to hold itself off the bus when requested. I'll be using this facility to effect the DMA. Simply assert the BUSRQ line and the Z80 lifts its legs obligingly from the circuit. At this point the uC will use some chip or other (a MAX6965 in this first design but I'll have to change this - too expensive) to drive the address lines of the RAM whilst jeffing program data into its bytey cells. The ZX81 will need to be in FAST mode (ha!) whilst this in progress in order that the ULA be quieted and diverted from its usual NMI generation duties which would spoil things rather.

This is a project I've been promising for way too long now and finally I think it's time to commit a design to PCB for manufacture. Follow me if you will. I think it'll be rather fun :)

I'll publish all my materials along the way if you want to play too. As I'm planning to make some of these to sell I'm afraid I'll have to assert some rights though - these ones look quite nice.

This work is licensed under a Creative Commons Attribution-Noncommercial 2.5 Generic License.

Feel free to remix, rework or improve, doodle dawdle or derive. Comments welcomed.

TTFN!

Pinout heaven

2010-01-20T04:33:00.000-08:00

I was thinking the other day about how difficult it can be to find information about a particular pinout for some obscure system or other. I was vaguely considering collecting these useful nuggets and publishing them myself but, for goodness' sake, I can't even add new items to my blog..!

It was with some relief that I found this site detailing vintage consoles and computers:

http://www.6502.co.uk/colmods.htm

I'd love to know what a propellent actuated device is...

I didn't want to leave.

2009-11-20T13:41:00.000-08:00

I visited an amazing shop a while ago. I wanted an oscilloscope and the local supermarket was right out, apparently, so a quick search on teh interwebs and this goldmine was revealed...

There was more around the corner and behind the outcrop on the right. And even then all stock wasn't accounted for. Despite this the owner knew every item intimately. Well, not in the biblical sense. Ahem.

This is what I went home with:

The top one - a Tektronix 465B. Yes, of course I wanted it *all*, but, you know, space. The prices were stupendous and it was obvious that the owner was a real true equipment geek. There were instruments in the rear recesses of the shop which were straight out of a gothic horror - brass spheres held aloft a glass tube encased in a brass and rosewood cabinet - an actual piece of test equipment used for measuring kilovolts on overhead wires. Huge knife bladed switches and variable resistors where the resistance was set by inserting plugs at intervals along parallel copper bars... And a pile of meters and programmers and signal generators and... what the... I have no idea what some of these things were.

And the smell... Divine.

Anyways. That was a while ago. I offered to advertise the establishment but the proprietor was busy enough without the additional traffic. But I'm sure that if you were within visiting distance of Reading, England and you asked...

http://www.stewart-of-reading.co.uk/

PL8-2, R2D2's Dad.

2009-10-08T12:21:00.000-07:00

My children used to refer to C3PO as R2D2's dad. Funny how those minds work, isn't it.

I used to think that real fun could never be anything other than corporeal.

That just goes to show. This is the most fun that I've had in a while :)

It's the V2 incarnation (can that be right? There's no meat here..!) of the PL8 MMC interface.

Here she is, in full component-side glory.

The TTL is a simple read/write decoder. The port onto which this fits provides rough address decoding. I wish it would shave. I hate the chafing.

But I do so love the wiring.

It's a PIC - one of those manly sorts with the parallel slave port. I know it's terribly incorrect to use the word slave - oops I used it again! sorry! but that's just what it is. So the parallel slave port behaves like a chunk of selection logic and wakes the PIC when a read or write occurs. There are /RD and /WR lines. The microcode on the PIC latches data ready to be presented on a port when the /RD line is asserted. No delay, it behaves just as a latch would. Similarly asserting the /WR line will latch the values present on the data bus to a register. Interrupts ensure that these events are recognisable and the remainder of the uC code is shuffling data to and fro.

The performance of this type of interface is already documented in another post <> milliseconds to load programs <> so I won't go into it here.

Needless to say schematics and code, both micro and 6502, are available if you'd like them.

Atom VRAM mod

2009-10-08T12:04:00.000-07:00

I have really struggled with the question 'should I modify this rare vintage micro or leave it as-is?'

Well. The thing about the Atom was that it invited modification.

So I came.

To the party that is, the one that the Atom invited me to. Honestly. Some people.

This is the truncated version of the ill-conceived all-in-one memory board that I started some while ago. It's simply VRAM. Nice. Witness the burned-off resist at or about pin 15. Ahem. Ah well, it's all for the greater good. 2114s are not exactly super-rare, but they use so much wattage. It's not green, it really isn't.

Retro Computer Museum Open Day 2009

2009-10-06T13:21:00.000-07:00

The organisation most commonly known as The Retro Computer Museum are having another all-day gaming event. For those in the UK willing to travel to Leicester you should visit their site and get the low-down.

I'll be taking a boot load of kit to fiddle with over the course of the day and I might even indulge in a little gaming. I'm mad like that, me.

MMBeeb

2009-10-06T13:10:00.000-07:00

Not a voluptuous expression of joy for a broadcaster, but one of these...

... being an MMBeeb board. I have mentioned them before, but I've improved the design somewhat since then. This is from the last batch. SMT components and a rather cheeky regulator placement make these the tiniest and most comely batch yet. I like to make each one different, unique. Electrically they're identical but each has its own character. I like to talk to them when I'm alone.

An MMBeeb board plugs into the user port of a BBC Micro and coupled with some smart coding by the original creator Martin Mather gives the contemporary BBC Micro user the ability to have at their disposal literally thousands of disk images all instantly selectable and appearing as though a genuine 5.25" disk.

They're fast too, programs load in seconds. G'orn there Chuckie Egg!

Mending

2009-09-14T02:19:00.001-07:00

Finally I've had some movement towards finishing a job. Really, it's been a long time :)

A poorly Atom belonging to a friend required a key switch fix. The keyboard on Atom motherboards of issues 1..4 is a strange all-in-one affair where the switch mechanism is a pair of counter-wound springs which connect when a weedy plastic plunger depresses them. They are puny and prone to breaking.

The only effective fix is to cut out the broken part and insert a new switch, as I believe I have blogged about before. This would be a new challenge as the switches I replaced before were at the end of a row and were changed as a unit. This time I would attempt a single unit as I have run out of replacement parts to do the two adjacent switches...

This is the first time I've used my callipers and I must say they're jolly useful.

Here's the replacement switch ready to be dropped in. The antennae were added so that the tiny whisker-like wires at the base of the switch would register correctly with the holes on the PCB. The replacement part is ever-so-teensily different from the one it's replacing, so registration wasn't guaranteed when sliding the piece into the anxiously awaiting gap. When the sides of the switch were coated with superglue that would have been a problem. The extensions fell away as expected when the solder joints were applied.

Hurrah!

Grzzzzzz!

2009-09-08T06:00:00.000-07:00

With a Pic for a brain and a mouse for motion tracking you should consider your hiding options before the head-mounted laser gets added. You have been warned!

Learning as you go

2009-06-23T08:30:00.000-07:00

FAIL!

The board was a brave attempt, but I should have trusted my instincts which said 'This shouldn't work. There's strange voodoo happening.' Here's the inspiration:

The 8K video RAM replacement chip is wired such that /OE and /CE are both tied low. Aha, it's being controlled by CE2! Nope. That's tied high.

Here is the type of board that I was working from. You see on the left how pins 28 & 26, 22 & 20 are tied?

Hmm. It works because the address lines from the video RAM to the VDC are isolated from the rest of the system by some bus buffers. Unless the video RAM is being accessed by the processor it remains 'firewalled', with data presented to the bus constantly. This isn't a problem as the VDC only reads. Reads from the CPU side are also OK as the firewall is only opened as the CPU wants data on the bus. Accessing the video memory on the Atom produces snow. This will be why, then! The data in the memory location you're accessing is displayed by the VDC instead of the data at the current scan position. I'm still not 100% sure how this all works so I'll pore over the schematic with a nice cup of tea and a sticky coconut macaroon later.

The upshot of this is that any memory expected to live on the CPU side of the tracks cannot share address lines with the video RAM. You will not be able to access the memory as the firewall is only opened for addresses in the VDC range.

I'm strangely unperturbed by this failure. I expect it's because I know that electrically everything checks out. It's just the mechanical arrangement that's wrong.

Onward to plan 2!

Happy Father's Day!

2009-06-21T14:12:00.000-07:00

The Atom needs some non-volatile random access storage. I ran out of suitable patience burning EPROMs when updating the firmware for the new MMC board. The old firmware was developed with the aid of an MMC simulation that I shoehorned into the MESS emulator. The simulator allowed me to code against a just-accurate-enough model of an MMC card in SPI mode. The new interface doesn't have such a luxury yet. So I got thinking, and decided that the 32kx8 FRAMs that I got from Ramtron recently would do as an EPROM replacement. But I'd still need the firmware in EPROM available to bootstrap from... Hmm. I'd also been meaning to build a copy of a neat videoram replacement card that I found in an Atom belonging to a friend. So that was that, really. Or rather, this is that:

At the moment it's only the video ram replacement side of the equation. The flying lead takes A10,11,12 from the main board. The rest of the signals are picked up from the vacated 2114 sockets. The empty socket is going to take the FRAM and some decoding logic will live adjacent, unless I can find suitable signals to pick up from the motherboard.

Not all underbellies are soft; This was quite hard, actually:

I shall return with news of FRAM. Dear, dear FRAM.

AtoMMC 2.0

2009-06-18T11:05:00.001-07:00

What's going on here then?

Let's see ... that's:

Acorn Atom Rev.4 with PL8 fitted +
Microchip PIC 16f77 +
74ls00 +
Custom firmware +
DScaler 4.1.15 +
Saleae Logic 1.0.21

An equation that = Joy.

Here's the trace of SPI activity whilst loading the above program from MMC. Click for a larger view. Go on. I know you want to.

That'll be ~5k of Galaxians loading in ... ooh let me see now...

Oh yes. 0.3 seconds.

The previous board sat cuddled up to the VIA and all of the SPI communication was performed by banging bits against one another. This board takes bytes at a time, like a man. These are then passed on to the inboard SPI hardware and the reply posted back.

Some PICs, like the one used here, have what's called a parallel slave port. You access it like any other bus-based device. It has /EN, /OE and /WR lines which directly control the state of one of its 8-bit data ports. With no valid control signals present the chip sits happily processing with the PS port data lines in a high impedance state. Enabling the chip and clocking /WR will latch the data found on the port at that time. Similarly asserting /OE with the chip enabled will take the port out of high impedance state and present latched data to the bus. There are separate latches for reading and writing. The reception and recovery of data can cause an interrupt. Very handy. Having been an AVR freak for a long time now since migrating away from PICs I'm starting to see their appeal once more. There. Ah sayed it. I Love PICs. Again. I don't know why I fell out of love with them, I suppose it was becasue they felt rough and ready. AVRs were sexier. With better development tools. I digress.

So with appropriate code written, and some neat decoding logic in place to translate the 6502's r/wr signal to separate /RD and /WR signals away we go. Fortunately I'm a reasonable programmer and the AtoMMC firmware that I wrote for the VIA interface was device independent. After as long as it took to recompile and burn a new EPROM, I had a new working driver for the new working hardware.

In all the round-trip time from presenting a byte to the chip to receiving a reply is as long as it takes to process the following 16 cycles:

;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~
;
; spi transfer
;
; on entry
;  A = byte to transmit
;
; on exit
;  A = received byte, Y preserved, X trashed
;
xferbyte:
    sta $b400
    nop
    nop
    nop
    nop
    lda $b400
    rts

Quite a big difference from the original code..

;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~;~~
;
; spi transfer
;
; on entry
;  A = byte to transmit
;
; on exit
;  A = received byte, Y preserved, X trashed
;
xferbyte:
    stx XBTEMP
    sty XBTEMP+1

    ldy #8

xb_xferbit:
    sta XBTEMP+2      ; ZP write .. faster than PHA

    and #MOSI         ; present data, CS is low
    ora #CLK          ; bring clock high
    sta VIA

    ldx VIA           ; read data

    eor #CLK          ; bring clock low
    sta VIA

    txa               ; rx'd data into carry
    ror a

    lda XBTEMP+2
    rol a             ; 7<-next bit, 0<-rx'd data

    dey
    bne xb_xferbit

    ldy XBTEMP+1
    ldx XBTEMP
    rts

All this joy has happened relatively quickly since receiving my logic analyser. I don't know how I coped without it. Having a window onto the private world of your signals is more revealing than the televisual programme 'Katie and Peter'. Speaking of feeling dirty I must admit that I used to feel the idea of attaching a peripheral processor arguably more powerful than the host computer to be anathema. However now I'm over the initial revulsion I have to admit I quite like it. Again I digress. So for a perfect example of how having an analyser helps, let's look at the behaviour of the flip-flop that I programmed to change whenever a SPI transfer completes:

You might be able to see it in the thumbnail here, but click for more pixels. The top two signals are enable and write. Taking the falling edge of the write line, when data is latched from the bus and passed to the SPI hardware, we see that the third line, rdy, is flipped about 12 microseconds later indicating that data is ready for reading. The writes occur at about 16 microsecond intervals. Remember the 16 clock code earlier? Aah yes. That code was generating this trace. I could probably drop a couple of NOPs to push things a little faster but I want a small comfort zone. I could also use a faster SPI clock. I'll perhaps experiment with that another time.

Mmm. Katie and Peter. Dirty boy. Go to your basket.

Rapidly scribbled and then

Brokenated XC-Special

2009-06-08T12:14:00.000-07:00

Let's have a little look, shall we? You might feel a sharp scratch... Aah yes that'll be it, then.

I should really conjure up some more robust button scheme. The key switches give the buttons a better feel than the standard tact-switch. Fixing them however has been a case of applying epoxy until they no longer give way. Unfortunately plastic to metal isn't an optimum bond and this is the third time I've had to get the mending kit out. Here's an exploded view:

Here's where the magic happens:

I shall be playing a quick round of Sea Dragon when this glue has gorn orf.

Thank you Atari for deciding serial was the way. You too, Commodore. We can laugh about it now but at the time it was terrible..!

FTW!

2009-06-07T08:02:00.000-07:00

A little vulgar I know, but it's an adequate expression of how I'm feeling right now.

The SD2IEC is working beautifully. Up to this point it was suffering from some syndrome resulting in erratic behaviour at best to a more normal position of outright refusal to work.

I could make things work sometimes by shimmying wires around, so this seemed to be the obvious first move. I stripped all the long wires away and remade the connections. It's often easier to see where a wire should be routed second time around...

While I was at it the ceramic resonator that I used originally was swapped out for a proper crystal. As I've got JiffyDOS in all my C= machines it is necessary to have an accurate clock source. Fastloaders demand cycle-accurate timing and both the internal RC oscillator and resonators are lacking in the accuracy department, to coin a contemporary phrase.

I reworked the cable too as the original one was made from some CAT5 (yellow, yum!) and had been shortened a couple of times to try and increase reliability. The resulting splices were ugly so had to go.

The result of all this industry? Bing bing bing bing Jackpot! Solid, speedy loading. C128, C64 and VC20 all enjoying the flowing bits.

The cassette case is a scaling back of the original scope. I was going to mount it inside a C2N datasette player, hence the fashioning of the board into a rough cassette tape shape. This was because my first SD floppy emulator was a SIO2SD board for 8-bit Ataris, built into the shell of an XC12 (Ugly, ugly brute) cassette player, which I may well present soon as I have to go back inside it to repair a keyswitch.

Here's the board, naked and from behind - exactly how I like it:

I am constantly in awe at the fine people who produce these fine projects. If I had to doff my hat every time the awe swelled within, I would be doffing almost continually. Lars P, Unseen and countless others, you know who you are, you have my deepest admiration.

The features of this device are too many to mention, who would have thought that an ATMega644p, some discrete components and a few hours soldering oculd have produced a wonderful thing like this?! I'm thinking that the SD/MMC bootloader might have to be employed in the Arduino board when I get a 328 to play with...

Considered,

Thrice nay!

2009-06-05T12:03:00.001-07:00

It's a nonsense title for a post, but I was just thinking of Frankie Howerd.

I have a shameful admission. I lied in my last post, or at least mislead you, dear reader. There were 5 projects - though I suppose the scale of this one didn't really register on the need to win scale.

I made a mega-rom adapter for my Atom. I haven't inserted a large image for a while (Matron!), so here goes:

The mega-rom! In an Atom! It allows me to page in one of 16 4k images into the address space allocated to utility software in the Atom's address map. The switch carried with dignity at the end of the cable allows a user to perform the magic. But you probably worked that out.

Don't you just love the green and yellow striped electrical tape? I was speaking to an electronics fashion pundit at the RCM event and they told me (in the strictest confidence) that this years projects simply must have green and yellow electrical tape! Being the capricious sort that I am I simply have to agree, at least for today.

I have been expanding my horizons, not to mention my old computers - ha ha, with contraptions such as this, fabricated with board spacers and socket strip. These nifty connectors are ideal for making up adapters like the one above.

Pictured: A board spacer is sized up by an interested socket strip

I've tried a number of different makes but these are by far the best - If I were Victor Kyam I'd buy the company. Which is SamTec if you're interested. No, I'm not receiving a back-hander. Though if you're reading, SamTec - well let's just say I'm interested... ;)

There is a slight wrinkle in the construction of these boards. The socket has to be mounted on the same side as the pads. I've yet to find a supplier of through-hole plated proto-board, but when I do I'll use it for this purpose. In the mean time, I use one of two methods. The first involves a 'cost efficient' socket - the pressed pin variety. Splay its legs akimbo and apply solder. Place it right-side-up on the padded side of the (woeful , now I think of it) protoboard that my local electronics supply chain provides. It rhymes with Craplin if you're wondering. Affix to the board with a swift application of iron. Bingo! The 2532 adapter for the tier jerker was manufactured using this method. Apply your eyes to the previous post for a fine example.

The second method, as used here, involves the socket strip. Place this adjacent to the spacer, at chip's width naturally, and solder the pad to the socket where it meets the board. You need a fine iron and a steady hand for this so no beer or porn beforehand. Ooh which reminds me... What?? Oh hush, I'm not soldering tonight.

Here you see socket strip and spacer conjoined with solder bridges. Which are surprisingly hard to make intentionally!

Lordy I've wittered on long enough. I have an SD2IEC to attend to. Please excuse me :¬)

A third-class ticket to despair and back

2009-06-05T04:31:00.001-07:00

I couldn't make it work. I tried... Alas the Fail was strong in this one.

The spectrum wanted its CF adapter. I wanted to oblige. I tried a number of different cards which all appeared to be lacking in Win. I had checked over the wiring a number of times and, although not entirely convinced it would help, I thus set about rewiring the beast.

Guess what! Still no Win. The board resolutely refused to

play nicely and so I took a step back and considered all the possible failure points. Too much stray capacitance? A dry joint? Lack of understanding? The list goes on. At last I decided to cut my losses and re-work the board as an IDE interface. Several tens of minutes later, having used an entire roll of desoldering wick, the board was bare but for the edge connector.

It's a good job I only regularly watch one TV programme (The Apprentice, with S'ralan), as I could get on with some burning myself.

The result:

Joy! I'd carefully checked each connection as it was made and I was certain they were all good. I'm bouyed by the assurances of my meter, and sure of at last securing a payment of success to offset the miserable week spent futilely poking at the CF board. Apply power, insert device -

...

Misery.

With heavy heart I put this project aside until some future time when I can muster the strength of character to return to the joyless debugging. It didn't get much better than this for weeks. I've started four more projects since, each more resoundingly failful than the last!

So that, dear reader, is why there have been no updates. I'm afraid I don't have the strength of character to tell of my winless ways. I can't even bear to tell you what they are. I do intend to return, though, this time with bigger guns. More on that later.

What I needed was something simple to rejuvinate my mojo. To get me to the power-pill so I can start to chase those ghosts.

My opportunity came at a recent retro-computer themed event where I met up with a number of people thus far only identifiable by a 24x24 pixel avatar and psychologically revealing nickname. Amongst these a contact who keeps me fuelled with rare Acorn Atom goodies. In this case I was knighted with a home-built rom-box, containing a couple of eproms.

Forget the soviet nuclear-warhead launching switches! The mysterious dials and socketry - this is truly a thing of beauty. But like most beautiful things, it's what's inside that counts. And that was going to be ME. The dumping challenge was on! [If you or someone you know built this rom-box, then please get in touch!]

Once retrieved from the secure caress of their sockets the lovely ceramic packaged gold legged EPROMS were quivering in the palm of my hand like frightened baby Meerkats. These chips are ancient and JEDEC incompatible. 2532s. 32Kbit arranged as 4K x 8. Here is the adapter I built to allow me to read the eproms using the glorious tier jerker:

And in situ:

As it turned out they contained images of programmers' toolkits. I must admit I was hoping for a rare find, however the images in question are already well known. But that is by-the-by. The thing is an hour had been spent with a soldering iron, a further hour spent reconfiguring the client application to draw the data PC-ward by the magic of electon in serial cable, and then some moments of joy - as the contraption worked. Worked?? WORKED!

I believe my drought is ended. The rains of win are falling, filling drained butts of enthusiasm. I shall venture forth and tackle the next item - Upgrading my SD2IEC in order to take advantage of the JiffyDos-enabled commodore machines at my disposal...

Why?

2009-03-04T12:19:00.001-08:00

Why do I do this to myself?

I've been meaning to start on the ZX Spectrum Compact Flash project for a while now. This site has some great stuff. Pera Putnik is a bit of a star in my humble opinion.

First things first - the terror inducing removal of the incumbent spectrum ROM with a Dremel cut-off disk. No pictures of this process exist as it's so fraught that taking a snap is all but impossible even with the most advanced image stabilisation techniques. The process is thus: (I'm shaking jut thinking about writing it..)

Cut through legs at top of ROM with Dremel. Remove remainder of legs with iron, wick and sucker. Solder in socket. Insert ROM. Relax.

The wire here is A14, I've used a 32k EPROM with 2 images burned in; the regular ROM and PP's CF OS. There's a splendid video that shows the thing in action. I can swap between the 2 with a simple flick of a switch.

Pictured below is a SparkFun CF Breakout board connected to some protoboard with pin headers. The edge connector there is soldered on one side, and I made connections to the second, floating row of pins using some 90 degree header. Click the pictures for the full ~~resolution~~ horror.

This hangs off the back of the spectrum. Now all I have to do is wire it.

Blisters aside, it's getting harder to do stuff like this as my old eyes are gradually losing their ability to focus at close range. It was fun though. And I've had an idea about a soldering station with built-in magnifier...

Now all I have to do is get it to work!

...

Cult of Done

2009-03-04T02:42:00.000-08:00

Pretending you know what you're doing is almost the same as knowing what you are doing, so just accept that you know what you're doing even if you don't and do it.

Read, Loved and

MMmm.. Beeb!

2009-02-11T08:09:00.001-08:00

I linked to the excellent MMBeeb project in an earlier post. It's been at the top of my project list again as I'm taking a pile of BBC B computers to TechAdventure which I'll be attending at the end of the month. I'm hoping to talk about MMC, old computers and the conjoining of the two. I'll have a table full of retro equipment to show, and some to sell.

As one of the first MMC projects I undertook, the MMBeeb board was a stepping stone that led much further than I expected. Whilst revisiting it in the light of all the knowledge I've acquired since then I've come to the conclusion that there are some subtle bugs with the original hardware. I'm hoping to contact the originator of the project and see what he thinks. I'll post an update here as soon as I've determined if I'm on the right path. In the mean time enjoy the view:

The revised circuit uses the same standard resistor divider as used on every other MMC interface I've ever made and a 3v3 regulator. That's it. It's not the hardware that makes MMBeeb special though - it's the software. It's a stupendously slick DFS conversion that integrates smoothly into a system. It also works with a second processor, which is an indication of the care and attention to detail that Martin has put into his work. And for the few paltry Great British Pounds that it costs for one of these you'd be crazy not to..!

Libraries

2009-02-11T04:22:00.000-08:00

It's all go at the moment. Last weekend I attended my first DorkBot London meeting. I must confess I didn't really know what to expect but spent a very pleasant, if cold, day in the company of feverishly soldering artists and makers. I spoke to many people about uFat and the new DevicePrint library. This is some code that allows formatted textual output to a buffer in memory and thus onto some form of persistent storage...

You can get the new library here SMB_LIBRARIES. It adheres to the principles introduced in uFat:- it is lightweight and device agnostic. It should work with any storage medium as long as there is a function available to write a 512 byte sector.

The the code is initialised with a pointer to a buffer, some basic information about the destination sector area, and a writer function. From that point on you are free to use the familiar .print() functions which are best known in their Serial library incarnation. The Arduino base library provides you with so much more than a blinking LED ;)

As usual (1) - there is copious documentation in the form of comments and an example sketch configured to use MMC storage for you to play with. If you wanted to try it out without any devices available then you could always change the write proxy routine to dump the stored data to serial.

As usual (2) - comments welcome!

Toasted and

Chrome Tips

2009-01-30T07:04:00.000-08:00

Two chrome tips for you:

1. The Type 55 0.5mm tip for my new favourite tool-in-the-box - an Antex XS 25 watt soldering iron! Ahem, while not exactly chrome, it does go shiny when tinned! I've only ever used my old workhorse cheap-and-cheerful 50 watt iron before now, which as far as I was concerned was as good as it got. So I was dubious when I was given this little gem to try. Imagine my surprise when I saw the difference that this iron/tip combination makes. I must say I'm absolutely astounded. It manages to pump much more heat into a joint than my supposedly more powerful iron that joints form instantly and cleanly. I'll never use another iron again ...

2. If you're having trouble downloading updates to the ever-so-likeable Google Chrome browser due to proxy issues or similar, then try this. Locate the event viewer for your Windoes system. This is usually in the Administrative Tools section of your control panel. There may well be an entry from the update manager which looks like this (click for a full resolution image):

You will see the URL to which the update service is attempting a connection. Cut and paste this into your favourite browser's address bar. In my case the download hoops are presented and I can duly jump through them, ending up with a newly polished chrome tool. Matron!

Double entendre added then

Say Hello to uFat2

2009-01-22T06:02:00.000-08:00

There has been a flurry of activity recently and a number of uFat users have been in touch, which is nice! In response to this I think it's about time that I posted my latest updates. The code is thoroughly commented and should answer most questions.

Most notably I have broken the dependency on a particular device library. Now you can use any code capable of reading 512byte sectors from any FAT formatted device.

Since a number of you dear readers asked about traversing FAT directories I've abstracted this requirement into a core feature. By providing a function callback you can now process FAT directory entries to your heart's desire!

It's still a lightweight library but there may be new ideas here for some beginner programmers. I don't think there's anything that should scare anyone though. Concepts such as pointers to functions and PROGMEM data storage are used throughout, but you should be able to use this as it stands without this knowledge. The example sketch should cover the most obvious use cases of printing a listing of files and updating a file on the card.

I developed this under the latest IDE at time of writing which is Arduino-0012. As usual, I'm happy to help with any problems or queries you might have.

Here's the goods: SMB_LIBRARIES and for pudding: The demo sketch

Refer to the header files for usage, tips, and perhaps a LOL or two. If you're lucky ;)

Written, admired and duly

Goodbye yellow brick!

2008-12-01T11:42:00.000-08:00

I've been reading about de-yellowing old equipment. Quite a few of my older babies have significant discolouration issues. Until recently I followed with the received wisdom, that once a plastic item has yellowed there's no going back. Chemical changes within the plastic produce the effect, and no amount of scrubbing will ever return your creamy commodore, beigey beeb or tawny tandy to its former glory. So imagine my surprise when I stumbled upon this wonderful posting over at the vintage computer forums.

Old computer enthusiasm and chemistry wizardry have come up with a recipe for undoing the supposedly permanent effects of UV and fire retardants!

I'm definitely going to try this out, as soon as I can get hold of the requisite chemicals...

For your eyes, ears only. Oh, and everyone else's too.

2008-11-15T13:43:00.001-08:00

Intrigued by something I've done? Want some? Just ask. I can't post every bit of code that I write, every schematic. But if you want some help or encouragement then just contact me. I'm always pleased if I can be of some use.

Switch.

I was working a few extra hours this weekend as my code finger was a bit slow last week. It's not often this happens, unlike in my previous life - scratch that - sentence, in the games industry (I'm not bitter - just astounded at how long it took me to realise how ugly it is). Bizarrely I had a camera with me so I took the liberty and a photo.

You know that you can click the pic for a higher resolution version, yes?

The museum has grown a little.. The master has been swapped out for a regular B. It has got a second processor attached though, and you can see its tiny appendage - an MMBeeb interface. Marvellous stuff by Martin Mathers. It's sitting on top of, yes it has to be said - a cardboard box - and quite the largest piece of retro peripheral that I own. A dual 5.25 inch floppy drive. Look at the size of that thing! It has an unbelievably long cable attached too - 10 metres at least - which by any stretch of the imagination shouldn't work. That's quantum physics for you! Probably.

OH! How I wish that Jupiter Ace was mine, alas it's not. It belongs to Mr Cliff. B'stard. ;) This one has a few yellow marks but it still works. Especially after the keyboard contacts got a firm rubbing with an eraser.. Win! Only about 8000 of these were sold. We loaded up some software a while ago and it was fairly obvious why this was a niche machine. If you come across an emulator then try 'fish and flutterer'. It's pure class.

It only takes a Jiffy

2008-11-06T01:25:00.000-08:00

As I now have the uncanny ability to burn EPROMS using only the power of my mind and, well, err, some equipment, I needed to try it out with something.

Since my SD2IEC (currently broken) supports the JiffyDos turboloader, I decided to upgrade my C= machines with new kernels (Or is it kernals? The two spellings seem interchangable in the world of Commodore, but I'll stick with the former). This upgrady action might give me the impetus required to fix it.

The '128 was easy enough, the ROM chips used were pin-for-pin compatible with modern 27c types. The VIC needed a small adapter board and some leg-bendy, jump-wiry action. The real fun started when I cracked open the '64c. This later model of '64 has serious cost reduction issues - like a lack of sockets for ROM chips. At least the chips they used were, like in the '128 model that followed, pin compatible with modern EPROMs.

Undaunted I considered desoldering the chip and adding the socket, but that wouldn't have been hacky enough, would it? :D

So I got out my side-cutters and removed the power leg. Covered the wound with a small sticking plaster (band-aid for our international readers) and patched a wire from the PCB stub to the power leg of my EPROM.

Next I bent the EPROM's pins slightly under itself, giving it a bow-legged aspect that I found rather pleasing. This newly lamed chip was then spring-loaded piggy-back fashion over the top of the incumbent ROM.

Like so! Isn't that sweet :) It's giving the other one a special cuddle!

I powered the old girl up and ... nothing. Black screen. Panic sets in. Turn it off and on again. Despair. Slump back onto my ample rear and hello! What's this?! I hadn't been waiting long enough for the machine to boot - I forgot that they take a second or two. It worked! Of course I knew it would..;)

I briefly considered holding the new chip in place with some gaffer tape, but that didn't give me a warm feeling. It would also have meant that the gaffer could have escaped. And we didn't want that either. So I decided a semi-permanent arrangement of solder to two diagonally opposite legs would do the job.

Yes I know it's a blob, but it was early in the morning!

Tier Jerker

2008-10-21T12:22:00.001-07:00

The Finished Shield:

40 lines of IO plus a number of the Arduino's lines brought out to header sockets. A couple of status LEDs and we're done. I've taken the PORTC lines, AKA the analog inputs A0-A5 and D2-D7 to the back of the board. As it is, the shield's pass-through connectors are offset by 50 mil, making piggy-back boards impossible to make cleanly out of proto-board. The power lines and D8-D13 have their pass-throughs in place, as they are essential for my MMC sail.

The Linguine Layout:

I love kynar wire! Did I ever mention that?? :D The enamel coated copper wire is great too.

The EEProm Topper:

This is a a scavenged megabit chip. My first application for this board will be to program this. As it slots into the IO card so it will fit into a small adapter board that I have in mind to enable it to emulate a 64k ROM to transfer code to my burner.

The Assembled Wedding Cake:

Silly! But that's what I like about it. An antidote to the misery happening in the world today ;)

Shields ... On?

2008-10-09T13:56:00.000-07:00

Up you blaggard! Up!

No, on second thoughts 'on' is definitely more appropriate in this case. As I mentioned in a previous post I'm crystalising the max expander board. It's about time I ruined my eyes and lungs with some close work.

I'll be putting two of the blighters on this board. Seeing as I'm down there anyway I reasoned that 40 lines is better than 20, what.

I didn't see any sense in making this a fixed purpose board, hence I'm opening up the lines with SIL sockets so further adapters can be inserted. The 1st will be a programmer for some of the megabit EEPROMs that I've salvaged from a couple of P2 motherboards.

New Logic Analyser Brainstorm

2008-09-20T14:39:00.000-07:00

Twin 4040s. 128k static RAM. A line buffer, probably in the region of the number 244. Something related to Arduino in a vague fashion.

8 data lines connected to the buffer, and from there onto the RAM chip. The 4040s provide the address generation.

Press a button or otherwise glean a clue about an appropriate time to start sampling from some logic or other. Reset the addressing logic. While ram not full:- increment address, latch data into the buffer and then write it to the RAM. When RAM full, await instructions to download via serial.

Could work, non?

Alternatively there seems to be a little logic analyser war happening right now - I'd back this regime. If you earn in dollars, then it's offering quite good value for money. If you earn in English pounds then you're laughing.

Programmer Redux

2008-09-19T12:15:00.000-07:00

The drop-in centre for stray capacitance was closed by the health and safety after it was shorted by a stream of wee created by a Superintended Nindo. At least I think that's what I heard. I could be wrong. Whatever happened, all the residents must have all come to join with the raving mass I already had, the result of which is that the board resolutely refused to work again after my last witless ramblings.

Pictured: Stray capacitance gathering
ready to frustrate my EEPROMming.

So - I started again!

The code was as much of a lash-up as the board, so I gutted it in favour of a Max6956 IO expander cum LED display driver. 20 gorgeous lines of GPIO, all driven by the Wire library and 2 lines off the Arduino. 12 Address lines, 8 data lines - Pimms o'clock! It's so much cleaner now without having to clock data around scratchy shift registers. I might actually show it to you.

The board came together in about 40 minutes and the code didn't take long at all because I already had a working sketch that drove the beastie. And to my immense relief it worked first time, and reliably every time since. I think I may well solidify this design onto one of the Arduino shield PCBs that I bought from Lady Ada aeons ago 'in case I ever needed one'.

You can see here the new MMC sail, #4 in a series of many. My favorite one so far, this has more than the requisite 6 resistors. I got a smart colleague to recommend a way to get an LED to flash in response to the clock line clocking. He told me that a monostable would do the trick and here it is. Why not just pop an LED on the line? Well, I'd done that already and sometimes that clock line might be left high.

Lash-up!

2008-09-16T11:55:00.000-07:00

What a mess! But it works - sometimes :) All that stray capacitance - well someone's got to give it a home.

This is what I'm forced to do because the Stag PP39 EPROM programmer that I was so generously given by a fellow FreeCycler works well, but for its serial connection. Ho hum. Wanting to burn an EPROM to hold the driver code for the Atom MMC interface was the necessity that was the mother of this frightful invention. In a fit of pique I had the idea that I should create a 3-step process: Burn my code into an EEPROM, transfer this to the programmer's buffer, and thence into an EPROM! Why not just use the EEPROM for my project? An astute question, esteemed reader. Well the type of EPROM expected by the Atom is an olde-fashioned marque with a subtly different pin-out to the more contemporary (read: standard) 27x series. Luckily the PP39 can burn the 2532 that was required. Even luckier I suppose is the fact that I had one of these! An adapter board can be made to facilitate the harmonious interfacing of the disparate breeds, but this would involve less lashing-up, you see? And we all need a jolly good lashing from time to time.

I digress. What you see before you (or more correctly above) is an ls299 accompanied by a brace of ls164 shift registers. These in turn are connected to an 8k Atmel EEPROM. In the driving seat you see the Arduino and - naturally - a poor but functional MMC interface. The 164s are in charge of address generation, and the 299 has bi-directional data line duties. It's a simple and effective design which I have referenced before.

I've developed the Atom MMC driver in assembler, naturally. This time I opted for cross assembly. If you saw the code attached to my previous post (my - is that the time?) you may well understand why - the inline assembler is hard work with its terse labelling syntax. I develop and assemble on a PC, using a custom Visual Studio workspace and a freeware 6502 assembler. The resulting binary is debugged as far as possible using Wouter Ras' brilliant though tricksy DOS Atom emulator. When I'm happy with the code it gets put on the MMC card and burned to the EEPROM using a subtle combination of swearing, crossed fingers and sacrificial chickens. The burning process needs to be attempted a fair number of times (the stray capacitance, bless) until the verify step passes and I can be sure the lash-up has worked. Once transferred to the programmer, the code fizzles its way onto a freshly UV-cooked EPROM and then into its warm and welcoming bed - Socket IC24. And so to work:

Presenting - the MMC adapter I built to fit on the venerable machine's expansion port, as visible here.

And in situ:

Goodness - that is the time! Two and a half months this post has taken me! Either that or my post-Sachertorte coma was deeper than usual... Whatever, forgive me. I am off to play Atom Invaders - which now loads in under 3 seconds, a far cry from the original 5 minutes of the tape version!

He's at it again!

2008-07-01T08:59:00.000-07:00

I'm getting back into the Atom swing! After a fruitless hour measuring incorrect logic levels at the Atom's expansion port I was on the verge of giving up. I had been prodding the VIA, according to available documentation, and getting nowhere. All I wanted was a toggly bit. Was that too much to ask for? That's when I decided to do some chip swapping.

It takes me longer than most people to get to this point as I'm a software person at heart and so blame that first ;)

I just happened to have a vintage 6522 VIA lying on my desk so I swapped the chips over. Joy! I was flipping bits like a demon. Naturally my thoughts turned to MMC...

10@=0
20!#208=!#208+3
30V=#B800
40W=#FFF4
50T=#80
60DIM LL(13),C(6)
70F.N=0TO13;LL(N)=#FFFF;N.N
80F.N=1TO2; DIM P(-1)
90P."PASS "N',$21
100[
110\ main
120:LL0 LDA @#0
130STA C+1; STA C+2; STA C+3; STA C+4
140LDA @#95; STA C+0
150JSR LL3
160LDA @#40+#0; JSR LL7
170LDA @CH"1"; SBC @0; JMP W
180\ select card
190:LL1 LDA @0; STA V; RTS
200\ deselect card
210:LL2 LDA @#20; STA V; RTS
220\ init hw and go spi
230:LL3 LDA @0; STA V+#C
240LDA @#FE; STA V+2
250LDA @#20; STA V
260LDY @10
270:LL4 LDA @#FF; JSR LL5; DEY; BNE LL4
280RTS
290\ xferbyte
300:LL5 STX T+0; STY T+1; LDY @8
310:LL6 PHA; AND @#80; STA V
320ORA @#40; STA V
330LDX V; AND @#BF; STA V
340TXA; ROR A
350PLA; ROL A
360DEY; BNE LL6
370PHA; JSR #F7FA; PLA
380LDY T+1; LDX T+0;
390RTS
400\ command
410:LL7 STA C+5; LDY @5
420:LL8 LDA C,Y; JSR LL5; DEY; BPL LL8
430:LL9 LDA @#FF; JSR LL5; AND @#FF; CLC; BPL LL10
440DEY; BNE LL9;
450SEC
460:LL10 RTS
470]
480P.$6
490NE.N
500END

If you're an ex-atommer or you've been around BBC micros you might recognise this. If you don't then I can tell you it's some Atom basic with inline assembler. The Atom's Basic dialect was hard on the eyes but lightning fast. By the standards of the day, naturally ;)

The built-in assembler gave the user of this machine an instant boost when learning to program. No fussing with 3rd party apps, loading the assembler or machine code, or the attendant problems with cassettes. Turn on. Assemble. Bam! (Which is as it happens almost quite literally what happened to my 1st Atom over 20 years ago...) Now if only it was that easy for the kids of today - it was much better in the old days - I remember when all this was fields etc. etc.

The above listing is code to bit-bang SPI to an MMC card attached via the simplest of hardware harnesses to the rear expansion connector of the Atom. I'm looking at making a ROM based solution that hooks into the OS's filing system vectors. It's all quite primitive at the moment but I'm hoping it'll solidify. Get in touch if you have any experience of developing this kind of Atom program. I'd love to talk to you.

It's gone all doubley-spaced!

2008-06-28T03:04:00.000-07:00

(edit)
The listings are back!

~~Apologies about the listings, esteemed reader, they appear to have lost their formatting and become double-spaced. I'm looking into it but in the mean time, please bear with me!~~

Atom Power!

2008-06-26T13:15:00.001-07:00

She's arrived! After many years of fussing and prevaricating I've finally taken the plunge and bought myself an Atom. The prices were rocketing in the bay of E, and I reckoned on the time being nigh. This one was advertised as having a broken key and otherwise with little hope of receiving a working box I decided on taking a punt and fixing it up if necessary. I've always loved this machine. I owned one as a boy although it was only a half-populated board without a case. It still did the business though!

I must admit to being a little saddened when I opened the wrapping. It was grubby and half of the keys appeared to be smashed in, sitting a good 6-7mm lower than their neighbours. The 1st thing was to open it up and check the power supply status. The Atom was infamous for overheating and many owners bypassed the internal regulators in favour of feeding it a regulated 5v diet. As was indeed the case with this one. It had received some tweaks in its time, but I was really happy to see the work was all of a high standard. These were all what I call 'magazine hacks' - the electronic equivalent of a one-liner joke. Single wire patches for enabling an eighth bit on the printer port, joining some lines to an external socket for wiring a joystick, nothing major. I was chuffed to see that it was fully expanded memory and support-chip wise. 12K RAM & 12K ROM plus a utility kit that I'm still having trouble finding any info about. I'll have to resort to a disassembler I think. No colour board but then I wouldn't ever have even contemplated that. Too rare.

The mother and key boards were in a real state. I think it had been stored on top of kitchen cupboards at some point in its life and it had received a good layering of yellow grease and fibres. Some keys were sticking and this was the main reason. I've since scrubbed it with a toothbrush and plenty of warm soapy water and now you'd never know! I was shy of putting it in the dishwasher as some people recommend, this may be ok for generic PC keyboards but rare vintage '80s hardware...

At some point in its history the three keys in the lower left had been replaced. They were replaced with high quality keyswitches, which - well I never - made the keycaps sit higher. What had happened was that the previous owner had raised the original keycaps with superglue to match the height of the replacements. The original mechanism is a cheap spring-based creation which I've only ever seen in Atoms ... and a keypad that I was given recently! That was handy, wasn't it! So I hacked the keypad and replaced the switches with something contemporary and far more suitable. And the same height! The caps all came off and were cleaned and repaired where necessary.

The machine is now clean and tidy, ready for work.

One tough trick was finding a plug to fit the odd power socket dimensions. It's some olde fashioned imperial jack size. Eventually located with the assistance of an Atom owning colleague I was able to juice the old girl. To my immense surprise it eventually reset and presented me with the very comforting words:

ACORN ATOM
>

Joy!

A computer's no good without software, right? Like all good '80s machines this one needs some square-wave goodness. I couldn't locate any software to generate the required signals that worked on a modern PC, so being handy with a compiler I got to work. I'm pleased I did all the work on ACE - the techniques transferred instantly and I had a program to translate raw program dumps into WAVS. And text files into raw dumps. And vice versa.

I'll be happy to pass these on to anyone that wants them. The source can be found here. It's vanilla C++. I'll be happy to help with porting, compiling or whatever.

There looks to be a new site emerging that could eventually be a must-see for any Atom fans. I'm speaking in the future tense as it's not there yet but I've spoken with the masters and they're promising big things. Watch this space.

If you're an Atom fan, get in touch.

IO, IO it's off to work we go!

2008-05-15T05:06:00.000-07:00

This is my 1st attempt at getting a PCB made. It was rushed so please excuse any glaring stupidity :)

A colleague was having some PCBs manufactured and had a little space left on the plate so I knocked this together during a lunch hour. I'm pretty pleased so far - the boards have come back and, despite being less than optimally packed, they're quite neat.

This is a ZX81 IO board. As I'm sure you've already worked out, esteemed reader! The 8255 is a general purpose IO controller and it's mapped to the Z80 IO space at ports 0x07 and 0x17. I'll be attaching the MMC card to it later :)

I've included links to the schematic and board files in case you want to fire up Eagle and have a play. This is a package with a very steep learning curve. I've been playing with it for about a year and I can only now say that I'm beginning to become confident. Version 5 has just been released which adds some polish to the mix. It wouldn't be uncharitable to say that the package weas a little rough around the edges before..! I haven't pushed V5 much - and it's likely I never will :) - but you can just tell that there's been some love and attention lavished. Hurrah for CadSoft!

Click the schematic for a very high res version. Or get the binaries from HERE.

I'll let you know how it works out when the SMT 74s arrive!

Average bits 10.2

2008-05-02T11:25:00.001-07:00

May I present some of my non-human babies. Continued thanks go to my employers - you know who you are - for allowing the museum to exist on my desk.

The C128 rear-left has a proto-board built SD2IEC card installed inside the tape drive. I shaped the PCB like a cassette. Press eject and you can insert an SD card into the presented slot. Cheesy but fun :)

The Apple //e front left is my latest baby. I'm awaiting a prototype board from the states so I can build an IDE card. They're ridiculously simple to build, it seems.

The centre column contains a QL, an STe, a Spectrum 128 and a BBC Master 128 with MMBeeb interface. They're nice, but not my favourites. Especially as the Sinclair machines require attention due to defective membranes. A pathology known around these parts as the curse of Clive.

No, the favourite machine honour belongs to the Atari 800. This is another machine with a SD card interface secreted away in a hacked tape drive. I dreamed.. no.. seriously fantasised about this machine when I was pecking away at my ZX81. (Not pictured - it's on the bench at the moment having an SD card and keyboard upgrade, natch)

One thing tends to be common amongst these machines and that's the addition of SD card interfaces.. My hat goes off to the engineers linked in this post. MMBeeb was my first exposure to the practice, which gave me enough of a kick-start to design my own interface for the zx81. Monster maze loads in 6 seconds. Bliss!

I guess it remains to be said - I AM 8-BIT

And proud :)

Like a record baby!

2008-04-27T12:01:00.000-07:00

I've been inspired by someone or other's homebuilt spinner. I probably saw it on Make or Hack-a-day, I forget. If you aren't familiar with the aforementioned input device it's like, well you know, like an arcade game control that could be found on such classics as Tempest, Arkanoid, Cameltry and many many more. You spin it. Hence the name.

I had to have a go. I have a project stack 100 deep at the moment and no time to do anything, so I needed a quick fix, a micro-project if you will. And this seemed like the perfect candidate.

So the obligatory VCR head was pulled from a dead Matsui. This particular model had a wonderful head motor mechanism that came apart very easily and cleanly, leaving no random sprue like some I've been near. It also furnished me with convenient screw holes. The motor shaft has a metal disk at the end which was just the right size for some idle tweaking. There's something very relaxing and .. zen I suppose .. about VCR head motor mechanisms. I suggest everyone try hefting one and idly spinning away a few minutes :)

An old USB mouse was inspected and found to be of the correct vintage - ball era. The optical encoder disks were removed and the pcb ritually prepared. The left/right encoder was severed and the traces replaced with kynar wire. Did I already say that this stuff has changed my life? I did have to modify my wire strippers to nip away that micro-fine insulation and I must admit the very act made me feel quite hardcore!

So with the emitter/receiver pair free to do their thing I started to try and mount the encoder disk on the base of the motor. What a nightmare. I tried different adhesives and when the little black brolly wasn't teetering drunkenly on the shaft or resolutely embracing my fingers it was wholly and utterly eccentric. In the end I liberated one of the tiny rare earth magnets from a sneakily swiped Magnetix stick. To this I super-glued the encoder on its truncated shaft. This could then be pinged onto the end of the shaft and repositioned easily whilst still holding position. When it was rotating as centrally as I thought it could, out came the hot glue. One quick spin draged a glistening thread of glue from the gun like silk from a spider's arse. And there was the disk in place, semi-permanently fixed. Result!

To mount the spinner I chose a CD 'cake box'. I'll leave the details of mounting the motor to your imagination as I am wont to do. All I will say is knife and screws were involved, but not my friend the rocket scientist.

So with the motor mounted all that needed to be achieved was the solid mounting of the transceiver pair. Tip #2: Don't use stiff wire. I thought that this would be simple, quick and give me plenty lattitide to position the payload precisely in space with little play. Wrong. It bounced around like Katie Price on a trampoline. So I did what I always do at moments like this - reach for the Lego. A small 1x2 hinge, a 1x8 plate and some more hot glue later I had the PCB shard mounted in the right position. More hot glue saw it fixed and locked. Game on!

[Click for a much, much bigger view! Erk!]

Cuts on your fingertips are painful. Rough-edged spinning steel disks attached to a momentum powerhouse cause cuts. Thinks needed :) The rubber 'tyre' that encased the middle mouse wheel was promptly repurposed. An almost perfect fit! I was understandably quite chuffed. While in the heightened state of chuff I figured some buttons might be useful too, in order to save splitting control between the keyboard and spinner when necessary. So off to the bits box and one feisty rummage later we have control! And the old BBC Master computer has 2 less keys.

One leisurely wiring of these buttons to the mouse PCB switch pads and there we have it. One spinner. It may not be pretty, but it was a project! And it works great with Tempest :D

[Click for a much, much bigger view! Zoinks!]

u-Fat filesystem

2008-04-13T01:00:00.000-07:00

Not a truncated attempt at a verbal slight, but a solution to PC compatible file access for micro-controllers!

Many FAT file system implementations are, by necessity, too large to take a place in micro-controller applications. Long file names, fragmented files, the FAT tables - no wonder a 'proper' solution weighs in at many K of code and buffers. One solution is to carry out raw access to the card, but this then involves compromises when getting the data off the card onto the desktop.

My solution is to reduce weight of code by applying stringent use restrictions:

Only 16 files (potentially), named in 8.3 format, pre-allocated and contiguous.

This enables us to locate the start sector of the file and read/write to it as we wish. The files can be freely swapped between PC and micro controller application using standard operating system commands. To reach this state of nirvana all that needs to be done is format the card before copying the pre-allocated files to it.

The only external requirement for servicing the code is a function that reads sectors, using logical block addressing, from your chosen FAT device. If you look in the ACE post previously the code zip there includes a complete MMC solution.

I found a schematic on the arduino site that is almost identical to my own and comes very highly recommended. If you haven't got a card reader that you can cannibalise then edge connector works well too. It's a common way of doing it and there are many good examples around - you can find one here.

Here's the header which shows just how micro micro can be!

 /*
 /  Microfat.
 /
 /  Developed by Charlie Robson in 2008.
 /
 /  This is the bare minimum* functionality required to read and write data
 /  to a FAT formatted device. In this case, an MMC card.
 /
 /  Rather than build a fully-featured FAT implimentation this will allow
 /  the user to locate sectors associated with a file on the device, and
 /  read and write to them in a brute force manner. No error checking, no
 /  long filenames, not even any support for fragmented files :) This is
 /  raw access, we only deal with existing files.
 /
 /  What you do get is a very lightweight module for extremely limited
 /  environments. Arduino has 2k of SRAM. Holding the sector of FAT data
 /  needed to traverse a fragged file would instantly gobble up 1/4
 /  of that. Enough said. Another benefit to not using the FAT is that
 /  there's no need to worry about whether a device is FAT12 or 16.
 /
 /  To use:
 /    Format a card.
 /    Make a file big enough to hold all the data you expect to write.
 /    Copy to the card.
 /
 /  With the MMC module started up, call initialise. This will cache some
 /  relevant information about the card such as the sector location of the
 /  root directory and data area.
 /
 /  Call locateFileStart, passing the name of the file which is providing
 /  the backing store for your transfers, and assuming the file is found
 /  in the directory you'll receive its start sector and file size.
 /
 /  Now feel free to read and write data to and from the sectors allocated
 /  to the file. Code carefully though - stray writes can twat your card!
 /
 /  Enjoy :) 
 /
 /  *Massive understatement!
 */

#ifndef __MICROFAT_H__
#define __MICROFAT_H__

// some data structures we'll be encountering on our travels.

typedef struct
{
  byte bootable;
  byte chsAddrOfFirstSector[3];
  byte partitionType;
  byte chsAddrOfLastSector[3];
  uint32_t lbaAddrOfFirstSector;
  uint32_t partitionLengthSectors;
}
partition_record;

typedef struct
{
  byte jump[3];
  char oemName[8];
  uint16_t bytesPerSector;
  byte sectorsPerCluster;
  uint16_t reservedSectors;
  byte fatCopies;
  uint16_t rootDirectoryEntries;
  uint16_t totalFilesystemSectors;
  byte mediaDescriptor;
  uint16_t sectorsPerFAT;
  uint16_t sectorsPerTrack;
  uint16_t headCount;

  uint32_t hiddenSectors;
  uint32_t totalFilesystemSectors2;
  byte logicalDriveNum;
  byte reserved;
  byte extendedSignature;
  uint32_t partitionSerialNum;
  char volumeLabel[11];
  char fsType[8];
  byte bootstrapCode[447];
  byte signature[2];
}
boot_sector;

typedef struct
{
  char filespec[11];
  byte attributes;
  byte reserved[10];
  uint16_t time;
  uint16_t date;
  uint16_t startCluster;
  uint32_t fileSize;
}
directory_entry;


namespace microfat
{
  // Cache some relevant info about the card.
  //
  bool initialise(byte* buffer);

  // Get start sector, file size for given filename. Returns false if the file
  // is not found in the directory.
  //
  bool locateFileStart(const char* filename, unsigned long& sector, unsigned long& size);
};


#endif // __MICROFAT_H__

Now for the meat:

#include <wprogram.h>
#include "microfat.h"
#include "mmc.h"

// Data which remains constant over one session. Re-initialise if
// the card is changed.
//
static struct
{
  uint16_t sectorsPerCluster;

  uint32_t rootDirSect, cluster2;

  byte* buffer;
}
vars;


bool microfat::initialise(byte* buffer)
{
  vars.buffer = buffer;

  if (RES_OK != mmc::readSectors(vars.buffer, 0, 1))
  {
    return false;
  }

  partition_record* p = (partition_record*)&vars.buffer[0x1be];
  long bootSector = p->lbaAddrOfFirstSector;

  if (RES_OK != mmc::readSectors(vars.buffer, bootSector, 1))
  {
    return false;
  }

  boot_sector* b = (boot_sector*)vars.buffer;

  if (BYTESPERSECTOR != b->bytesPerSector)
  {
    return false;
  }

  vars.sectorsPerCluster = b->sectorsPerCluster;
  vars.rootDirSect = bootSector + b->reservedSectors + (b->fatCopies * b->sectorsPerFAT);

  long dirBytes = b->rootDirectoryEntries * 32;
  long dirSects = dirBytes / BYTESPERSECTOR;

  if (dirBytes % BYTESPERSECTOR != 0)
  {
    ++dirSects;
  }

  vars.cluster2 = vars.rootDirSect + dirSects;

  return true;
}



// Get start sector for given filename.
//
// Returns false if the specified file wasn't found in the directory.
// Short filenames only. Be aware that the directory fills up with 'deleted'
// filenames. Rather than deleting too many files try a quick reformat.
//
bool microfat::locateFileStart(const char* filename, uint32_t& sector, uint32_t& size)
{
  if (RES_OK == mmc::readSectors(vars.buffer, vars.rootDirSect, 1))
  {
    // The filenames are stored in [8][3] format. No dot, all upper case. 
    // Names shorter than 8 chars are padded with spaces.
    //
    // Cook the supplied name. fred.txt -> FRED----TXT
    //
    char cookedName[11];
    for(int i = 0; i < 12; ++i)
    {
      cookedName[i] = 0x20;
    }

    for (int i = 0, j = 0; i < 12 && filename[i]; ++i)
    {
      if (filename[i] != '.')
      {
        // Force char to uppercase. Cheesy I know :)
        //
        cookedName[j] = filename[i] >= 96 ? filename[i] - 32 : filename[i];
        ++j;
      }
      else
      {
        // Continue cooking chars at the extension position
        //
        j = 8;
      }
    }

    for (int i = 0; i < BYTESPERSECTOR; i += 32)
    {
      directory_entry* de = (directory_entry*)&vars.buffer[i];

      // Don't match with deleted or system/volname/subdir/hidden files
      //
      if (de->filespec[0] != 0xe5 && (de->attributes & 0x1e) == 0 && memcmp(cookedName, de->filespec, 11) == 0)
      {
        sector = vars.cluster2 + ((de->startCluster-2) * vars.sectorsPerCluster);
        size = de->fileSize;
        return true;
      }
    }
  }

  return false;
}

Which as you can see is smaller than the header - due in no small measure to the size of the FAT structure definitions.

As it stands this code could be improved by using non-static file info structures - only one is supported right now but the change would be trivial. Also allowing the filename search to traverse the entire root directory space would allow access to more files. However I don't really see the utility in ths -wherever I've used this code I've never needed more than one file :)

As usual any Qs are welcome.

More ACEness

2008-04-06T03:00:00.000-07:00

Here's a more portable command-line driven utility to generate wav files ready for ACE's ears. There's a tiny enhancement that ramps up the volume during the lead-in which should prevent the kind of pants-wetting shock that I keep delivering to myself :)

/*
* Support code for ACE - the arduino cassette engine
*
* Example code to write a wav file which can be played to
* a microcontroller running the ACE software.
*
* Should be fairly portable unlike the original example.
*
* Enjoy.
*
*/

#include <iostream>
#include <fstream>

typedef unsigned char uint8_t;

// adjust these to control endiannesses.
//
static const int ENDIAN0 = 0;
static const int ENDIAN1 = 1;
static const int ENDIAN2 = 2;
static const int ENDIAN3 = 3;

static const int ENDIAN0_S = 0;
static const int ENDIAN1_S = 1;

// desired wave structure - AHEM THESE ARE READ-ONLY
// - THEY CAN'T BE CHANGED WITHOUT FUTZING THE CODE. SORRY.
//
static const int CHANNELS = 2;
static const int SAMPLERATE = 44100;
static const int BITSPERSAMPLE = 16;

// this is as loud as we can get. not quite 11,
// but approaching it.
//
static const double maxLevel = (double)SHRT_MAX * 1.0;
static const short maxLevelS = (short)maxLevel;
static const double minLevel = (double)SHRT_MIN * 1.0;
static const short minLevelS = (short)minLevel;


// number of samples per cycle. 60 samples = 1 low or 2 high cycles.
//
static const int f1 = 60;
static const int f1cyc = 1;
static const int f2 = f1 / 2;
static const int f2cyc = f1cyc * 2;

// useful values, maybe
//
static const int usPerCycle = (int)(((double)f1 / 44100) * 1000000.0);
static const int usPerHalfCycle = (int)(((double)f1 / 44100) * 500000.0);
static const int usPerQuarterCycle = (int)(((double)f1 / 44100) * 250000.0);
static const int usPerEighthCycle = (int)(((double)f1 / 44100) * 125000.0);

static const int baudrate = (1000000 / usPerCycle);

// 8 + stop + start;
//
static const int bitsPerFrame = 10;

static const int samplesPerBit = f1 * f1cyc;
static const int samplesPerFrame = bitsPerFrame * samplesPerBit;


static const int LOW_BIT = 0;
static const int HIGH_BIT = !LOW_BIT;

static const int LEADIN_BIT = LOW_BIT;
static const int START_BIT = !LEADIN_BIT;
static const int STOP_BIT = !START_BIT;


// NASTY HACK FOR WRITING WAVS. PLEASE LOOK AWAY NOW.

void CreateWaveFile(std::ostream& output)
{
    char chars[4];

    output << "RIFF";
    *(int*)chars = 16;
    output << chars[ENDIAN0] << chars[ENDIAN1] << chars[ENDIAN2] << chars[ENDIAN3];

    output << "WAVE";
    output << "fmt ";

    *(int*)chars = 16;
    output << chars[ENDIAN0] << chars[ENDIAN1] << chars[ENDIAN2] << chars[ENDIAN3];

    *(short*)chars = 1;
    output << chars[ENDIAN0_S] << chars[ENDIAN1_S];

    *(short*)chars = CHANNELS;
    output << chars[ENDIAN0_S] << chars[ENDIAN1_S];

    *(int*)chars = SAMPLERATE;
    output << chars[ENDIAN0] << chars[ENDIAN1] << chars[ENDIAN2] << chars[ENDIAN3];

    *(int*)chars = (int)(SAMPLERATE*(BITSPERSAMPLE/8*CHANNELS));
    output << chars[ENDIAN0] << chars[ENDIAN1] << chars[ENDIAN2] << chars[ENDIAN3];

    *(short*)chars = (short)(BITSPERSAMPLE/8*CHANNELS);
    output << chars[ENDIAN0_S] << chars[ENDIAN1_S];

    *(short*)chars = (short)BITSPERSAMPLE;
    output << chars[ENDIAN0_S] << chars[ENDIAN1_S];

    output << "data";
    *(int*)chars = 0;
    output << chars[ENDIAN0] << chars[ENDIAN1] << chars[ENDIAN2] << chars[ENDIAN3];
}


void FinaliseWaveFile(std::ostream& output, size_t bytesWrit)
{
    char chars[4];

    output.seekp(40);

    *(int*)chars = (int)bytesWrit;
    output << chars[ENDIAN0] << chars[ENDIAN1] << chars[ENDIAN2] << chars[ENDIAN3];

    output.seekp(4);

    *(int*)chars = (int)(bytesWrit + 36);
    output << chars[ENDIAN0] << chars[ENDIAN1] << chars[ENDIAN2] << chars[ENDIAN3];
}

// OK IT'S SAFE TO LOOK AGAIN



// here we represent:
//
//   0 bit as 1 cycle of low frequency,
//   1 bit as 2 cycles of high frequency
//
// where the high frequency is double that of the low.
//
void OutputBit(std::ostream& output, int bit, size_t& written,
    short maxval = maxLevelS, short minval = minLevelS)
{
    // default to low
    //
    int cycles = f1cyc;
    int samplesPerCycle = f1;

    if (bit != 0)
    {
        cycles = f2cyc;
        samplesPerCycle = f2;
    }

    // generate square pulse, start with rising edge
    //
    for (int i = 0; i < cycles; ++i)
    {
        for (int j = 0; j < samplesPerCycle / 2; ++j)
        {
            // high [1] period
            //
            output << uint8_t(maxval & 0xff);
            output << uint8_t(maxval >> 8);
            output << uint8_t(maxval & 0xff);
            output << uint8_t(maxval >> 8);
            written += 4;
        }
        for (int j = 0; j < samplesPerCycle / 2; ++j)
        {
            // low [0] period
            //
            output << uint8_t(minval & 0xff);
            output << uint8_t(minval >> 8);
            output << uint8_t(minval & 0xff);
            output << uint8_t(minval >> 8);
            written += 4;
        }
    }
}


// outputs a start bit, 8 data bits and a stop bit
//
void OutputByte(std::ostream& output, uint8_t value, size_t& written)
{
    OutputBit(output, START_BIT, written);

    for (int i = 0; i < 8; ++i)
    {
        OutputBit(output, (value & 0x80) ? HIGH_BIT : LOW_BIT, written);
        value <<= 1;
    }

    OutputBit(output, STOP_BIT, written);
}


// outputs a lead train of bits, terminated with a start bit.
//
void OutputLeader(std::ostream& output, int milliseconds, size_t& written)
{
    int microseconds = (milliseconds * 1000) - usPerCycle;;

    // this is a bit of a decoration - 
    // ramp up the volume during the 1st half of the leader. this might
    // prevent some unexpected eardrum-rupture events.. and yes, i know
    // that volume should be ramped non-linearly :) this will do for
    // the time being.
    //
    double vol = 0, ramp = 1.0 / (microseconds/(usPerCycle*2));

    while (microseconds >= 0)
    {
        OutputBit(output, LEADIN_BIT, written, (short)(vol * maxLevel), (short)(vol * minLevel));
        vol += ramp;
        vol = __min(vol, 1.0);
        
        microseconds -= usPerCycle;
    }

    OutputBit(output, START_BIT, written);
}


void main (int argc, char **argv)
{
    if (argc < 3)
    {
        std::cout << "Usage: makewav [input file] [output file]" << std::endl;
        exit(1);
    }

    std::ifstream inner(argv[1], std::ios_base::binary);
    if (!inner.is_open())
    {
        std::cout << "Could not open input file." << std::endl;
        exit(1);
    }

    std::ofstream outer(argv[2], std::ios_base::binary);
    if (!outer.is_open())
    {
        std::cout << "Could not open output file." << std::endl;
        exit(1);
    }

    // write wav header
    //
    CreateWaveFile(outer);

    // determine input file size
    //
    inner.seekg(0, std::ios_base::end);
    size_t size = (size_t)inner.tellg();
    inner.seekg(0);

    size_t pc = 0;
    size_t written = 0;

    // file is structured:
    //   some seconds of leader
    //   size msb
    //   size lsb
    //   {
    //    data[512]
    //    some milliseconds of leader
    //   }

    OutputLeader(outer, 2000, written);

    OutputByte(outer, uint8_t(size >> 8), written);
    OutputByte(outer, uint8_t(size & 0xff), written);

    while (pc != size)
    {
        // dummy data - replace this with either read from buffer indexed by [pc]
        // or a byte get from the file to be encoded
        // 
        OutputByte(outer, inner.get(), written);

        ++pc;
        if (pc % 512 == 0 && pc != size)
        {
            OutputLeader(outer, 50, written);
        }
    }

    FinaliseWaveFile(outer, written);

    outer.close();
}

No, really!

2008-04-03T12:13:00.000-07:00

Mrs. Edna Welthorpe of Hatheringon under Nicely wrote in to let me know that she'd seen through 'my little April fool joke'.

Well, Mrs. Wellthorpe, the joke is indeed on you. The ACE posting is 100% genuine :)

Enjoy!

Awesome mix #6

2008-04-01T12:11:00.000-07:00

I've been laid up with a succession of minor bugs of the viral kind and subsequently there's been no movement on the hardware front. I think it's time to post something though and with that in mind please be upstanding for the one - the only - ACE!

That's the Arduino Cassette Engine to me and you.

Hankering after some old-skool interfacing? Got the urge for PCM? Here's some Arduino code to read a data stream encoded in a frequency shift keyed manner. As usual I'm presenting this in its completely raw form. There are plenty of comments in the code and enough information to allow any intermediate level programmer to get started. If you think it's useful but don't have a clue where to begin adapting it then, as always, I'll be happy to help. The code is my testbed which reads blocks of data and writes them to an MMC card. The MMC code is a minimal set adapted from the SD2IEC source. (Thanks guys!)

I haven't had a chance to make the schematic or perfboard layout for the interface but it'll soon come.

Also included in the archive is the c# app that creates demo data to be read. It was adapted from another application I wrote to get data from binary images into my zx81 which explains the cockamamy structure. And the icon! If you have problems downloading let me know.

Beware of the output from SquareWave - it's as loud as it can possibly be. Make sure that volumes are turned right down before running it. You have been warned!

Enough blabber - here's the skinny ripped right from the code:

 /*
 /  'Arduino Cassette Engine'.
 /
 /  Developed by Charlie Robson in 2008.
 /
 /  This is half of a solution for getting data into an arduino. The other
 /  half being code to generate frequency shift keyed (FSK) data in the form
 /  of WAV files which should be widely playable. These can be recorded or
 /  otherwise electronically distributed. Why do it this way? 1. Because it's
 /  funny. 2. Having given an updatable arduino-powered 'toy' to someone, I
 /  can't expect them to re-program the device by traditional means in order
 /  to update it. Everyone has a means of playing a sound!
 /
 /  On with the show.
 /
 /  The data is encoded like so:
 /
 /    Lead-in
 /    High byte of data length
 /    Low byte of data length
 /    {
 /     Data[0 < size <= 512]
 /     (Lead-in)
 /    }
 /
 /  Lead-in is a train of bits terminated with a start bit. This means the lead-in
 /  bit needs to be the logical complement of the start bit.
 /
 /  Every byte is represented by 10 bits - a start bit, 8 data bits, and a stop
 /  bit. The start and stop bits are complementary.
 /
 /  Data arrives in 512 byte blocks. Each block except the last is followed by a
 /  short period, about 25 milliseconds, of lead-in. This is to allow processing time
 /  on each block as it arrives.
 /
 /  Decoding a data bit is done something like so:
 /
 /    Await a rising edge then take 2 samples at a period which will allow us
 /    to distinguish a 0 or 1 bit. Sampling 2 identical values yields a 0 bit.
 /    Delay so the next bit read will occur when the signal is in a low period.
 /
 /  Following is a picture of a '0' bit, or low frequency cycle, followed by
 /  a '1' bit or high frequency cycle, with some important times noted.
 /
 /    The X shows a rough expected time at which we start the bit reading.
 /    The 0 shows relative time zero, when we detect the rising edge.
 /    The + signs show the times at which we sample.
 /    The * shows the earliest time at which we can await a new bit. IOW, X.
 /
 /        __`_____`__             __
 /       |  `     `  |           |
 /       |  `     `  |           |
 /       |  `     `  |     `     |
 /     ` |  `     `  |     `     |
 /   __`_|  `     `  | ____`_____|
 /     ` `  `     `        ` 
 /     X 0  +     +        *
 /     ` `__`__   `   _____`
 /     ` |  `  |  `  |     |
 /     ` |  `  |  `  |     |
 /       |     |     |     |
 /       |     |     |     |     |
 /   ____|     |_____|     |_____|
 /       `
 /       `
 /       |-----------------------| = usPerCycle        = 1360uS
 /       |-----------|             = usPerHalfCycle    = 680uS
 /       |-----|                   = usPerQuarterCycle = 340uS
 /       |--|                      = usPerEighthCycle  = 170uS
 /
 /
 /  It's assumed that the audio signal is connected to PORTB-0 which is
 /  digital pin 8. If you'd like to change that, then replace occurrences
 /  of...
 /
 /      PINB & 1
 /
 /  ... with the direct bit-access for your implementation. I do it this
 /  way because it's slightly faster than digitalRead()ing. If you do change
 /  the port you'll also need to change the logic in readBit as this relies
 /  on the fact that we work with bit 0. 
 /
 */

Enjoy!

Itnrtaenrslfeearvse!d

2008-03-26T06:41:00.000-07:00

Some back-of-the-envelope calculations later I'm looking at about an 8-10khz playback rate. At 10khz I'll be needing to feed the DAC a new sample about every 100uS. Each byte transfer over the SPI bus takes up to 40uS. By breaking up the transfer process into interleavable chunks we should be able to achieve the required rate - but waaiiiit a minute. The DAC requires a 16bit transfer. So I guess I'm looking at 8khz. I know I could get better by using serial EEPROM, FRAM, SRAM, BLUEJAM or whatever. But that isn't the point! I always like to just have a go and make what I've got work.

If you're familiar with transferring data from MMC you'll know that there are command blocks involved in the process. These are 48bit monsters. It might be that with the latency involved in sending the commands and the MMCs reply delay we are looking at even less than the 8khz as a replay rate. We'd need to be pushing a sample out as fast as we can read them which means the time taken for sending command blocks would cause glitches.

I'll have to do some more sums and see how long we can sustain continuous playback with some buffering. With the Arduino's 2k of SRAM we could possibly hold 1024 pre-loaded samples whilst reading a new sector from the card... My head is saying about 3.5 seconds - roughly 50 sectors of 512 bytes.

SPI vs SPI

2008-03-25T07:06:00.000-07:00

I've taken the software spi master code as published by Atmel and converted it into c++ to allow it to be modified. I spent a frustrating couple of days, a few moments at a time, trying to work out why MMC card access was broken when using the software master. It turned out to be that I was sampling the input on the falling edge of the clock. This was most likely due to some subtle detail lost when reading the original AVR ASM code, or dense stupidity :) I found it using, my now favourite tool in the box, the parallel port logic analyzer.

I've upgraded the software so that the grabber runs under 2K, XP and (probably) up. This is way more convenient than having to have a machine booted into DOS as I'm sure you can imagine. I've also worked on the viewer app so that you can zoom in to waveforms and see information like sample position and time - both absolute and relative to a marker.

Features, creepy in their nature, keep suggesting themselves and I'm having a hard time keeping off the code, which is presented in source and precompiled form, here.

Usual caveats apply, use at own risk, no responsibility taken for damage to potted plants ahem ahem.

Here's a couple of shots showing both the soft and hardware waveforms as snaffled up by the analyser. The ordering of channels is different as the pin assignments are different in the two modes. The cursor in both cases is poised at the moment that we expect our first byte of data back from the card. As you can see if sampling is done on the falling clock edge then a mis-read will occur. The incoming bits will be read as 0xfe,0x03 instead of 0xff,0x01. Bugger!

Soft:

'Ard:

As always, these posts are just a little flavour of the cake that is the tortured analogy for my development hobby. If you want the full recipe, then an email or comment will do the job.

And while you're considering that, there's this...

Sampling

2008-03-17T06:22:00.000-07:00

I've had a weekend away from thinking about maladjusted fuses, and now I'm feeling much, much, better. I had occasion to add some flashing pulsing coloured lighting to the cardboard rocket that I built with my boys on Saturday morning so naturally the Arduino came out. It's amazing how something as inconsequential as some modicum of lighting can transform the lifeless cardboard tube into a dynamic play area.

While I was at it I thought that it would be easy to add some silver-foil capacitive switches which would trigger sound effects. With my collection of freebie chips in front of me now I can see that I have a brace of MCP4922 DACs that I ordered from MicroChip a while ago that remained unused. These are SPI compatible 12bit DACs which should be trivial to connect up and drive.

I'm imagining a circuit with both a DAC and some form of persistent storage on an SPI bus. I'll probably go for SD/MMC as I'm familiar with driving these and I have some solid code to work with. Most likely I'll be using a software SPI master as the DACs are unbuffered. This way I can read from the MMC and write to the DACs in an interleaved fashion which will give me greater flexibility in coding and control over playback rate.

MicroChip have a relaxed attitude to people requesting samples that I wish other companies would follow. They must go by the assumption that the more people experience using their parts the better. Word of mouth is a powerful advertising medium after all. If you've never thought of doing this I recommend giving it a try. What's to lose? :)

Another company that's sample-friendly is Dallas/Maxim - makers of the ever-so useful Max232/3 serial level converters amongst other devices.

The trick with sampling is to have the time to sit and browse the entire product range. After all you might be inspired when you see that digital potentiometer...

More poking...no more joy.

2008-03-14T07:06:00.000-07:00

Hmm. The waveforms look about right.

There wasn't any software that would drive the parallel port breakout cable that I built. (Yes, I know it's ironic given my previous statement about how I wasn't prepared to solder up another DB25!!)

So I ended up crashing together an app in OpenWatcom for DOS to do the grabbing, and a C# program to display the data. Talk about a technology clash! I think at this point unless anyone can point out the problem with the attached code I'm going to concede defeat! For now ;)

ChaN's programmer is looking a lot more like the next project. I have a couple of old TTL-stuffed boards that I've been meaning to get the hot-air gun aimed towards. The need for a '299 for the programmer means I might just do that this weekend.

All this to recover a £3.25 microcontroller? No! Just for the sheer amusement!!

Here's the final draft of the code. I've been over it so many times now I've gone codeblind so if you see any howlers please keep your derision to good-humoured banter :)

// XA1 XA0   Action when XTAL1 is Pulsed
// --- ---   ---------------------------
//  0   0    Load Flash or EEPROM Address (High or low address byte determined by BS1)
//  0   1    Load Data (High or Low data byte for Flash determined by BS1)
//  1   0    Load Command
//  1   1    No Action, Idle
//
const byte XA_LOAD_ADDR = B00;
const byte XA_LOAD_DATA = B01;
const byte XA_LOAD_CMND = B10;
const byte XA_NOP       = B11;

const byte CMD_ERASE      = B10000000;
const byte CMD_WRITE_FUSE = B01000000;
const byte CMD_READ_SIG   = B00001000;
const byte CMD_READ_FUSE  = B00000100;

#define DLY delayMicroseconds(100)

inline void SETB(byte x)
{
  PORTB |= _BV(x);
  DLY;
}
inline void SETD(byte x)
{
  PORTD |= _BV(x);
  DLY;
}

inline void CLRB(byte x)
{
  PORTB &= ~_BV(x);
  DLY;
}
inline void CLRD(byte x)
{
  PORTD &= ~_BV(x);
  DLY;
}


// PORTB

#define PIN_BS1 0
#define PIN_XA0 1
#define PIN_XA1 2
#define PIN_BS2 3
#define PIN_PAGEL 4
#define PIN_POWERTOCHIP 5

#define SET_BS1 SETB(PIN_BS1)
#define CLR_BS1 CLRB(PIN_BS1)

void SET_XA(byte xtal_action)
{
  PORTB &= ~(_BV(PIN_XA1)|_BV(PIN_XA0));
  PORTB |= xtal_action << PIN_XA0;
  DLY;
}

void CLR_XA()
{
  PORTB &= ~(_BV(PIN_XA1)|_BV(PIN_XA0));
  DLY;
}

#define SET_BS2 SETB(PIN_BS2)
#define CLR_BS2 CLRB(PIN_BS2)

#define SET_PAGEL SETB(PIN_PAGEL)
#define CLR_PAGEL CLRB(PIN_PAGEL)

#define SET_POWERTOCHIP SETB(PIN_POWERTOCHIP)
#define CLR_POWERTOCHIP CLRB(PIN_POWERTOCHIP)


// PORTD

#define PIN_XTAL1 2
#define PIN_RDYNOTBSY 3
#define PIN_OE 4
#define PIN_WR 5

//  <- PORTD3 rdy/bsy
//
void AWAIT_READY()
{
  while ((PIND & _BV(PIN_RDYNOTBSY)) == 1);
  long time = millis();
  while ((PIND & _BV(PIN_RDYNOTBSY)) == 0);
  Serial.println(millis()-time,DEC);
}

#define SET_OE SETD(PIN_OE)
#define CLR_OE CLRD(PIN_OE)

#define SET_WR SETD(PIN_WR)
#define CLR_WR CLRD(PIN_WR)

void PULSE_WR(bool wait = true);
void PULSE_WR(bool wait)
{
  PORTD &= ~_BV(PIN_WR);
  delayMicroseconds(100);
  PORTD |= _BV(PIN_WR);
  if (wait)
  {
    AWAIT_READY();
  }
}

#define SET_XTAL1 SETD(PIN_XTAL1)
#define CLR_XTAL1 CLRD(PIN_XTAL1)

void PULSE_XTAL(bool wait = true);
void PULSE_XTAL(bool wait)
{
  PORTD |= _BV(PIN_XTAL1);
  delayMicroseconds(100);
  PORTD &= ~_BV(PIN_XTAL1);
  if (wait)
  {
    AWAIT_READY();
  }
}

// <-> PORTD6...7 will be used as DATA6...7
// <-> PORTC0...5 will be used as DATA0...5
//
void SET_DATA_IN(void)
{
  DDRC &= B11000000;
  DDRD &= B00111111;
}

byte GET_DATA()
{
  return (PORTC & B00111111) | (PORTD & B11000000);
}

void SET_DATA(byte data)
{
  DDRC |= B00111111;
  PORTC = (PORTC & B11000000) | (data & B00111111);

  DDRD |= B11000000;
  PORTD = (PORTD & B00111111) | (data & B11000000);

  DLY;
}

//
//
//


void LOAD_COMMAND(byte command)
{
  SET_XA(XA_LOAD_CMND);
  SET_DATA(command);
  PULSE_XTAL(); 
  CLR_XA();
}

void LOAD_ADDRESS(byte address)
{
  SET_XA(XA_LOAD_ADDR);
  SET_DATA(address);
  PULSE_XTAL(); 
  CLR_XA();
}

void LOAD_DATA(byte data, bool low)
{
  SET_XA(XA_LOAD_DATA);
  if (!low)
  {
    SET_BS1;
  }
  SET_DATA(data);
  PULSE_XTAL(); 
  CLR_XA();
  CLR_BS1;
}

byte GET_SIG(byte offset)
{
  LOAD_COMMAND(CMD_READ_SIG);
  LOAD_ADDRESS(offset);
  SET_DATA_IN();
  CLR_OE;
  byte x = GET_DATA();
  SET_OE;
}

inline void PROG_ENABLE(void)
{
  SET_POWERTOCHIP;
  delayMicroseconds(100);
}

inline void PROG_DISABLE(void)
{
  CLR_POWERTOCHIP;
}

inline void PROG_ENABLE_PROPER(void)
{
  SET_XTAL1;
  CLR_XTAL1;
  SET_XTAL1;
  CLR_XTAL1;
  SET_XTAL1;
  CLR_XTAL1;

  SET_POWERTOCHIP;
}

//
//
//

void setup(void)
{
  Serial.begin(115200);

  // PORTB 5...0 all outputs. Zero the ports before setting them as outputs
  // to prevent spikes.
  //
  PORTB = 0;
  DDRB |= B00111111;

  // Not interested in DATA pins, they'll get set later as required
  //
  // PORTD0/1 are rx/tx: leave alone
  // PORTD3 is input
  // D6/7 are set on demand
  // the rest are output
  //
  PORTD = 0;
  DDRD = (DDRD & B11110111) | B00110100;

  // bring the active low pins to their inactive state.
  //
  SET_OE;
  SET_WR;
}


void loop(void)
{
  Serial.println("Fuser 1.0 Ready.");
  while(!Serial.available());
  if (Serial.read() == 'p')
  {
    Serial.println("Sig: ");

    PROG_ENABLE_PROPER();
    Serial.println(GET_SIG(0),HEX);
    Serial.println(GET_SIG(1),HEX);
    Serial.println(GET_SIG(2),HEX);
  }
  else
  {
    Serial.println("Burn: ");

    PROG_ENABLE();

    delay(2);

    Serial.println("Erase: ");

    LOAD_COMMAND(CMD_ERASE);
    PULSE_WR();

    Serial.println("Lo fuse: ");

    LOAD_COMMAND(CMD_WRITE_FUSE);
    LOAD_DATA(0xE1, true);
    PULSE_WR();

    Serial.println("Hi fuse: ");

    LOAD_COMMAND(CMD_WRITE_FUSE);
    LOAD_DATA(0x99, false);
    PULSE_WR();
  }

  PROG_DISABLE();
}

Heroic failure!

2008-03-13T15:05:00.001-07:00

I've slapped it all into shape and electrically things look solid - but no joy.

Result: Heroic failure!

I'll probably poke around a bit more before consigning this to the 'nearly works' pile as I get the same nonsense results with a known good chip. So you never know.

This might be the time to get my cheap-as-chips parallel-port logic analyzer built... It's easy to see how my project stack grows :)

Spaghetti

2008-03-13T00:41:00.000-07:00

Here's the basic harness wired into the Arduino board. The three-pin header is the power connector, ready to accept +12, gnd and +5v connections from the transistor switch contraption that I'll put together on a breadboard later.

I used very fine enamelled wire cohabiting the protoboard holes with the socket pins. A good application of heat and solder later - bingo!

To connect the wire to the header pins I put a tiny blob of solder on the iron tip and insert the cut end of the wire. Within a second or so the enamel melts and you can see the solder flow around the wire. It's then ready to fix it to its destination.

And what better to listen to whilst soldering than some very fine oldskool belgian skizzo??

Arduino to planet fuser

2008-03-12T06:45:00.000-07:00

Here's how I plan to wire the fuser board to my Diecimila:

[Apologies to some viewers: I've just looked here using IE7 and the diagram is flummoxed. Adjust the font size downwards and things will look a little better]


     Target - atmega32
                         ____ ____
            |    pb0   =|    U    |=   pa0   |  bs2
            |      1   =|         |=
          / |      2   =|         |=
      DATA  |      3   =|         |=
          \ |      4   =|         |=
            |      5   =|         |=
            |      6   =|         |=
            |      7   =|         |=
               reset   =|         |=   aref
                 vcc   =|         |=   gnd
                 gnd   =|         |=   avcc
                       =|         |=
     xtal1  |  xtal1   =|         |=
                 pd0   =|         |=
  rdy/~bsy  |      1   =|         |=
       ~oe  |      2   =|         |=
       ~wr  |      3   =|         |=
       bs1  |      4   =|         |=
       xa0  |      5   =|         |=
       xa1  |      6   =|_________|=   pd7   |  pagel




  Diecimila - pin assignment

  ANA-IN5  |o|  DATA5
        4  |o|      4
        3  |o|      3
        2  |o|      2
        1  |o|      1
        0  |o|      0

  D0 [rx]  |o|  -
   1 [tx]  |o|  -
   2       |o|  xtal1
   3       |o|  rdy/~bsy
   4       |o|  ~oe
   5       |o|  ~wr
   6       |o|  DATA6
   7       |o|  DATA7

  D8       |o|  bs1
   9       |o|  xa0
  10       |o|  xa1
  11       |o|  bs2
  12       |o|  pagel
  13       |o|  juice
  gnd      |o|  -
  aref     |o|  -

The power switching is going to be implemented identically to how ChaN implements his. I'm lazy that way! Which is to say, The Good Way. Why reinvent?!

The plan to blow all the fuses

2008-03-11T10:24:00.000-07:00

The aims of this mini project are quite humble: Build an out-of-circuit parallel mode programmer lite which can whip a borked avr back into something like its factory condition ready for in-circuit programming. At the moment I'm going to concentrate on one chip only and if it all works, and there's sufficient interest, I'll think about expanding the scope.

I'm not going to go into depth - this is just really a sketch of what's happening in my bonce right now. I'll be abstracting quite heavily and using my own terms because it doesn't make sense to just repeat all the detail in the datasheets. Code and schematics will be posted as and when available.

All the information I needed for V0.1 is in the atmega32 data sheet. It looks like it'll be quite easy to reset the fuses.

I've come across a design for a parallel port programmer which looks like it would be simple to build but I don't relish the thought of soldering up yet another DB25 connector. So I've decided to drive this project with an Arduino. I'm imagining nothing more than a socket on some stripboard connected to some header pins that will mate with my Diecimila, some power regulation and switching. I would have built a shield but for whatever reason the designers of the board decided to use a non-standard spacing between 2 sets of sockets which makes building shields on protoboard difficult. Grrrr.

The procedure will simply be:- Erase chip, reset fuses. Job done. The chip erase step has the effect of resetting any lock bits. As one of the locks controls our ability to write fuses this is essential. The state of the EEPROM will be indeterminate after this step, however, as there is a fuse controlling whether the erase cycle also clears EEPROM. And we don't know how this is set.

There are two ways to enter high voltage programming mode. The first involves gently tickling a port but it relies upon the clock settings for the chip being set to external. I think this might have been how I borked my chip, but as I couldn't ressurect it with an attached clock signal this could well not not be the case. So I'm going to go for the second method. Brute force!

Powering up the target with 12v @ 250uA on its reset line, logic low on four specific pins and a wait of 100uS should be enough for it to become willing to accept programming commands. Which are loaded thus:

Set the 'mode select' pins to 'load command'.
Present the desired command to the DATA pins.
Pulse the clock pin to latch the command. All pulses need to last at least 250nS.

Commands are executed by giving a pulse to ~wr. Progress can be tracked by monitoring the rdy/~bsy pin, which will go low until the action has finished.

Addresses are loaded in the same manner, we just substitute 'load address' as the mode.

All the dirty details of the required pulsing is clearly outlined in the timing waveform diagrams in the data sheet.

In order to check how the hardware and code is functioning I'll read the signature bytes of the chip as my first step.

Load the 'read signature' command.
Load the address of the desired signature byte, 0-2, to be accessed.
Set ~oe low.
The target presents the requested byte on the DATA bits.
Set ~oe high.

When this is returning what I expect then we'll start on the fuses. First though - some erasing.

Load 'erase chip' command.
Pulse ~wr.
Wait for the command to complete. This will take between 7-9mS.

Once this is done happily then we're ready to blow the fuses! We'll do low, then high.

Load the 'write fuse' command.
Load DATA with the low fuse byte.
Give ~wr a pulse and wait for rdy/~bsy to indicate the process has completed.

For general write operations this will take between 3-5mS.

Load the 'write fuse' command.
Load DATA with the high fuse value.
Give ~wr a pulse and wait for rdy/~bsy.

And that should be that!

I'll let you know how I get on :)

Here's an untested arduino sketch that I've hacked up, which should give a better idea of the specifics. It should be read in concert with the data sheet chapter 'Memory programming'.


/* CUT DUE TO ITS TEMPORARY NATURE - PLEASE SEE LATER POST */

Retro Heaven

2008-03-07T05:43:00.001-08:00

I've just hacked together an MMC2IEC interface on my breadboard. Thanks Lars!

It's a serial device that pretends to be a commodore 1541 disk drive. It uses SD card storage and disk images to deliver retrogaming goodness to my '128. This is #4 of 4 in my old computers that I've added flash storage to series. Seriously - if you have old computers and a few spare hours it's worth the solder burns.

Having got that device working in its original Lars form I noticed that the open source design has been picked up by a couple of other bods who have taken it to another level. Details are scant, unless you speak German, but I've managed to scrape enough information together to upgrade Lars' original hardware design with some improved firmware called SD2IEC. This supports many more features such as high capacity cards, disk switching, some fastloaders and JiffyDos which should speed things up considerably. Which if you've ever used a C64 disk system you'll know is a must. Some details in English are here.

During the process of upgrading I managed to half-brick an AVR chip. Unlike PICs they are easy to render unprogrammable by changing their configuration fuses in an an unfavourable way. My mistake was not reading the output of this avr fuse calculator carefully enough. Instead of making the AVR desire an external resonator, I made it lust for Clock. Which is different. I've done this a couple of times before with some 168s. In the aftermath of that embarrassing mistake I did some research and found that usually these chips can be resurrected.

If you program a chip to expect a clock, then it should be possible to reprogram it as long as the relevant signal is present. I usually program chips in a little home-made ISP cradle which doesn't have a clock available. For the 168s it proved possible to get them going again by dropping them in my Deicimilia board before attempting to reset the fuses.

The mega32 hasn't responded to this trick though. I used an Arduino to provide what I thought was a good clock to no avail. It's going to need something a little more ... high voltage. AVRs can be programmed using SPI in-circuit, or by more conventional parallel means out-of-circuit. Programming serially you need a well configured support circuit for the chip. Using a parallel programmer you can reset fuses that would prevent SPI from working. So here's my next project - an avr fuse reset device. A cut-down high voltage parallel programmer that only has one job - to reset the fuses to a factory fresh state. Insert AVR, press button, bingo! At least in theory :)

I'm off to grab some of Atmel's brilliant application notes. Then it'll be time for a nice sit down and some strawberry cheesecake.

Hello, world!

2008-03-01T08:05:00.000-08:00

I want somewhere to doodle about the mucking around I'm doing with Arduin o. This, as you might well have guessed by now, is it.

If you don't dig digital, if you aren't amorous with analog... Oh forget it. It's going to be spoddy!

I'm off to town for a vanilla slice, but when I get back I'll play with this blog thing a little more and start posting about the microcontroller hackery I've been getting up to in the last few months or so.

If you like POV toys, LED tokens of love, zx81s, shoehorning data on and off MMC cards and FSK cassette interfaces then I'm sure you'll be riveted!

If not - well, there will be cake :)