Current events
Frustration!
The prototype PCBs arrived on Thursday, and with the excitement of a little kid, I unpacked them and got to working on them. First, I attached the CPLD and the 3.3v supply components, decoupling capacitors for the CPLD, and the pin header for the JTAG lead. The CPLD programmed no problem. So I then added the flash and RAM, and associated discrete components for the ROMCS circuit.
It all started going downhill from there. First, I got a screen of vertical stripes (which was expected) - the flash at this point contains 0xFF, and this is the RST #38 instruction, so the Spectrum would just execute RST #38 over and over and the stack eventually overwrites the screen, hence the vertical stripes. I then closed the 'disable traps' jumper... and got vertical stripes. I discovered that despite triple checking the board, the jumper was connecting the CPLD pin to ground instead of Vcc. An easily worked around problem - just go into Xilinx ISE and change the CPLD to prevent traps.
This still didn't fix it, instead I got random garbage on the screen. After much fiddling and testing I got no further, and could find no errors on the PCB that would cause this. So I set about building a second one. First, I put the CPLD on the board, and configured it. Then the ROMCS components. So far so good, and the relevant OUT commands from BASIC would crash the machine (which it should at this stage). Then I put the RAM on the board, and POKEd in a short program to test I could write a byte and read it back; this worked. Then I wrote a small test program to test memory paging (I also wrote a bin2tzx utility that can be found here in SVN [1] so I could send freshly assembled programs to the Spectrum via the tape socket). This all worked satisfactorily.
Then this morning, I set about putting a flash chip on the new board. However, the solder for some reason wasn't flowing well... and then the tip of my soldering iron broke off just after I got done soldering one side and was cleaning it up with solder wick. I was sure I had a spare soldering iron bit, but it was not to be.
So I'm left with a board that's non-functional for reasons still unknown, and a second board with a half-soldered flash chip and a broken soldering iron bit, and I suspect due to the poor solder flow I'll have to 'hot air' the flash chip off the board and start again. Hrmpfh. I had hoped to have the first board completed by last night.
I don't really feel like working on the software today, so I think I'll take the rest of the day off. Perhaps I'll improve the bin2tzx utility a bit and submit it to WOS for the utilities section. I'll also order some solder paste and needles from Farnell. While the big square chips (CPLD and W5100) and the RAM isn't too bad to hand solder, owing to the long pads on the PCB, the flash chip is really annoying to hand solder, and I think paste and hot air will be ten times easier.
It's of course not all bad news - I do at least know that the CPLD and RAM are working correctly, as is the reset circuit and ROMCS circuit (for both 48K and +3/+2a) is working correctly. I've also checked the flash chip against the datasheet again and found that the connections are all correct. At the moment I'm suspecting either a "poor short" that the continuity tester on my multimeter won't beep at but which is causing problems, or a bad flash chip. Unfortunately, I'm not going to be able to do anything more to the hardware until the middle of next week when the parts I need arrive from Farnell.
Update: I hot-aired off the flash chip from the nonfunctional board, and it no longer crashed the Spectrum and the static RAM read/wrote OK, so there was the culprit. It's either a duff chip, or it's not TTL-compatible (which it *should* be, but there's no way of telling from the package markings and the datasheet gives DC characteristics for both TTL-compatible and CMOS-only devices). If the second board fails in the same way when the flash is attached, I suspect the chip's not TTL-compatible, and I'll have to order alternative flash chips.
Winston 11:21, 20 April 2008 (BST)
PCBs ready...
I just got notification from the PCB fabricator that the PCBs are done and have been sent...
In the meantime, I've not got all that much done, various other projects (including fixing a backed up drain) and social engagements mean I've spent very little time on the code over the last week. However, I now have a working input routine which will work for the user entering configuration items, like the IP address, netmask etc. I've also written (but not yet tested) some routines for saving configuration information into the flash chip. I need to tie it all together with a simple menu-based user interface. With luck I can get that done this week. However, when the PCBs arrive, I expect to spend time on assembling those, too. Busy times ahead!
Winston 22:45, 14 April 2008 (BST)
Back to Code
Firstly, the PCB layout has gone to the fab to be manufactured...
Not the fab of my choice. Unfortunately, I didn't notice that PCB Train had a design rule about drill holes (the drill hole must be at least 0.5mm from an inner layer copper trace). There are parts of the PCB where I've had to squeeze in a lot of vias and thread tracks between them on layers 2 and 3. Oops. So it'd either be a week of redesigning, or use a different fab. I wanted to use PCB Train because it's in the same timezone and run by people who natively speak the same language as me. Anyway, a fab has been found (pcbcart), and a random search of the web shows that others who have used them have given them glowing reports. They also do different coloured solder masks, so I don't have to use the bog-standard green. I went for blue for the prototypes. (In the past I've used Olimex in Bulgaria, but they only do 2 layer eurocards and they don't go down to the design rules needed for 0.4mm pin pitch. I also looked at a few others in the USA, but that would have added lots of delivery time because all the ones I saw that do 4 layer along with solder mask and silkscreen ship it off to China, so the board would go China -> USA -> here). PCB Pool in Germany are just far too expensive - they charge you extra for using industry standard Gerber files! They seem to only really cater for Eagle users. Pcbcart look like a good bet - they will also do odd shapes and 'gold fingers' on request - so if I use them for the production boards, they can put the through port cut-out so I don't have to do it, and also gold plate the through connector. I've opted for no 'gold fingers' on the through connector because I want to see how much the default finish lasts as an edge connector - the gold plating almost doubles the cost of the PCBs. Sinclair got away with a tin-plated edge connector, wobble notwithstanding!
So, back to the code. This weekend adds the following bits of functionality:
- gethosbyname - actually, a subset - it only returns one address rather than a list and all the other hostent stuff. But that covers 99.99% of all situations for networked programs on unix and Windows, so it should be enough.
- keyboard input - internal functions to be used by the configuration UI
- screen output - the existing 42 column routine and extra routines around it
The gethostbyname implementation just needed to use the DNS lookup routine I wrote a couple of weeks back, as well as new routines to be able to parse an IP address as a string - if you pass an IP address to gethostbyname, it won't do a lookup, rather, it will convert the string to a big endian 4 byte integer that represents the IP address. I also added a function to convert a 4 byte big endian integer to a dotted decimal string IP address. The 8 bit int-to-ascii converter is a bit primitive at the moment, for instance, it will display 1 as 001, but it will do for now.
Keyboard input required me to do a bit of research. Not wishing to re-invent the wheel, it uses the CALLBAS exit in my ROM to call the keyboard handling routines in the Spectrum's BASIC ROM. This is fine on a 48k machine, however, on a 128k machine, on reset (when the Spectranet code is active, but before the ZX ROM has been initialized), the wrong Spectrum ROM is paged in (the BASIC editor), so routines to initialize the 128k paging environment vars, and page in the right ROM were added. The get key routine just calls the ZX's ROM KEY_SCAN, K_KTEST and K_DECODE to turn what the user did into the right ASCII character. The +3 added an extra wrinkle as there's an additional page register to prod (plus its associated system variable) so the routine crashed the first time I tried it on a +3. But it works now.
Since the screen output must work before the ZX ROM has been initialized, I'm using the 42-column routine that I wrote ages ago (it's used in the diagnostics board I made last April, since that board has to assume a non-functioning ROM until it's been tested). In fact, sharp eyed readers might have spotted the DNS test from a couple of weeks back wasn't displaying the output in the normal Spectrum character set. While I could write code to get enough initialized to use the ZX ROM's RST 16 character print routine, I would rather use a 42-column character generator for the Spectranet since it allows a bit more on the screen.
I need to generally learn a bit more about the ZX ROM, there's quite a few routines I could use that will save me having to write code. In any case, there's the vexed issue of getting the parser to work; I'll have to read through the stuff Garry Lancaster sent to me.
Plans for the time until the PCBs arrive:
- Get a basic user interface going to allow for configuration.
- Finish off the DNS 'A' record lookup routine - code in timeouts, and failover to second/third DNS servers.
- Perhaps look at writing the DHCP client.
Winston 20:55, 6 April 2008 (BST)