Loading Einstein programs from SD card

Finally it's working!

http://www.youtube.com/watch?v=VA3agKxpm8k

There are still a few issues around some of the timing for handshaking, but I'll apply the logic analyser once I've found a reproducible test case.

What did _you_ do in your lunch-hour?

As per the previous post - they were out of raspberry and white chocolate muffins, so...

It's amazing what a coat of paint does for a prototype board! This is the result of a careful spraying of Plastikote 'Creme de la creme' - AKA 'Retrocomputer white'. Ignore the bloom in the picture - that's just an artifact of whatever additional compression has been applied to the JPEG. In the flesh, as it were, the board is a gleaming off-white.

And here's the solder side. I can't wait to get stuffing.

If you click to embiggen then you may see the teeny tiny capacitors - 0402s. They'll be the teeniest thing I've ever used.

I treated myself to a fresh etching solution today as I was short of time. This board went from printer to camera in just under an hour. It would have been about half that if there wasn't a 60 way IDC connector and 44 pin CPLD socket on there :D

At least I didn't drill any body parts today.

If you haven't been following (shame on you!) then you have been looking at the second prototype of einSDein - an SD card interface for Tatung Einstein computers.

Today I wrote data from my Einstein to the PIC controller.

The PIC controller is announcing the title, and a small test program on the Einy is writing the ubiquitous string, where it is received and displayed by the PIC.

.module fnMessageToHostW

fnMessageToHostW:

   ld    hl,message-1

   jr    _endtest

_send:

   call  waitByteTaken

   jp    c,reportTimeout

   out   (WRITE),a

   ld    e,a

   push  hl

   DOSCALL(CPM_FUNC_CONSOLE_OUT)

   pop   hl

_endtest:

   inc   hl

   ld    a,(hl)

   and   a

   jr    nz,_send

   ret

.endmodule

The hardware has changed a little since my first stab after finding out to my horror that unless I upgraded the processor to a totally over-the-top type then I wasn't going to be able to use hardware SPI and the parallel master port at the same time. Disaster. Of course I could have used software SPI - like I did in the Acorn Atom version of this board - but that would have been too easy. Instead I chose to stand on the shoulders of a giant and implement the parallel port in the CPLD. My friend Phill had done this for the Dragon and so I've lifted a good portion of his design. Thanks Phill! 

Phill's design has several advantages over the built-in hardware of the PIC. 

1. It's processor agnostic so this design could be used with AVR, ARM, or whatever other chip you have handy.

B. Unlike the PIC the host computer can query the state of the buffers making for a slight increase in speed when polling long operations.

It hasn't been easy, I've spent a couple of days crying into my milk because it wasn't working and I just didn't know why. I added LEDs to make myself feel better. I stripped the implementation back to literally nothing and started again a couple of times. I stared at the code for Einy, PIC and CPLD until I realised my stupid mistake. One part of the design used active low logic, and the other was active high. With that sorted we appear to have lift-off!

Here's some glamour shots. Firstly - the thing in action!

To the left is the Xilinx programmer, to the right is Pickit3. Centre stage is the serial lead, an FTDITTL232. Bet you're really pleased I told you that.

And here she lies, disconnected. Do you like the wiring mess? :D This should sort it out:

Miraculously I've managed to fit this on a single layer which should make things a touch easier.

Next step will be to add the SD card handling to the PIC code. Or making the new board. Or a raspberry and white chocolate muffin. Decisions, decisions.