New Logic Analyser Brainstorm

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

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!

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!