Learning as you go

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!

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

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

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!

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!

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

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...