Difference between revisions of "Current events"

From Spectrum
Jump to navigation Jump to search
Line 1: Line 1:
== The last 10% that takes 90% of the time ==
As I said in earlier news, I've decided not to do any more features before I get the first release out. So what I've done is:
# Finished off the first basic set of configuration code. (Very tedious code to write, but it had to be done!)
# Made some progress debugging various niggling problems.
# Made TNFS more robust, especially in situations of high packet loss. More work is needed though.
# Finished off the autobooter (part of the BASIC extensions)
A big item, though, will be writing a manual for the standard modules (BASIC extensions, etc).
I'm also changing the build process. At the moment, the Spectranet ROM code is built with sjasmplus. The assembler has served me well, but it has a few drawbacks which makes maintaining the sources a bit painful at times - namely, although the ASM source is split into many files, they are all joined together with a set of "include" directives, because sjasmplus is a traditional (in the sense of 8 bit tradition) 3 pass assembler. This means files must be assembled in a certain order, or else weird and difficult to debug things can happen (for instance, if a vector table gets accidentally shoved out of its proper home). Sjasmplus also has some other drawbacks, I had to modify the source to make it work properly on my Mac, and it's not necessarily compatible across versions.
So I'm switching to the GNU binutils, since they now support the Z80. Also, Chris Smith (author of the most excellent [http://www.zxdesign.info/book/ ULA book]) recommends this assembler, and I've found out why. Unlike pasmo or sjasmplus or HiSoft GENS or the BBC Micro assembler (traditional 3 pass assemblers that work on effectively one huge asm file) it works by building object files and linking them, just like what you expect with a C compiler. The assembler and linker have many powerful directives that are very useful, and consistent too: after all, GNU as and ld are used as the back end to the GNU Compiler Collection, probably one of the most widely used C compilers today. The linker allows me to define sections that live in certain places in memory, so it doesn't matter for example when "vectors.asm" is assembled or in what order the object files are linked, I can tell the linker I always want this section at, say, 0x2000. I can have a common linker script file so that all modules are linked the same way, instead of having to specify it each time in each makefile. It also means that things like circular dependencies are no longer an issue, and I can build libraries for commonly-used code. It also means I can use standard Makefiles rather than the shell script I currently use to control the build process. It'll be a bit of work to convert everything, and put section labels in where they are needed, but it'll be worth it as it'll make ongoing development smoother. I've already converted the snapshot manager to use the GNU assembler and linker, and the benefits are already obvious!
Finally, two events coming up right now: firstly, R3PLAY is this weekend and you can see three networked Spectrums there (and write tweets if you like!) followed immediately by Retromañía in Zaragoza, where you'll also be able to see networked Spectrums (and I'm doing a talk on how the system works)
[[User:Winston|Winston]] 19:34, 2 November 2010 (GMT)
== Concentrate! ==
== Concentrate! ==



Revision as of 19:34, 2 November 2010

The last 10% that takes 90% of the time

As I said in earlier news, I've decided not to do any more features before I get the first release out. So what I've done is:

  1. Finished off the first basic set of configuration code. (Very tedious code to write, but it had to be done!)
  2. Made some progress debugging various niggling problems.
  3. Made TNFS more robust, especially in situations of high packet loss. More work is needed though.
  4. Finished off the autobooter (part of the BASIC extensions)

A big item, though, will be writing a manual for the standard modules (BASIC extensions, etc).

I'm also changing the build process. At the moment, the Spectranet ROM code is built with sjasmplus. The assembler has served me well, but it has a few drawbacks which makes maintaining the sources a bit painful at times - namely, although the ASM source is split into many files, they are all joined together with a set of "include" directives, because sjasmplus is a traditional (in the sense of 8 bit tradition) 3 pass assembler. This means files must be assembled in a certain order, or else weird and difficult to debug things can happen (for instance, if a vector table gets accidentally shoved out of its proper home). Sjasmplus also has some other drawbacks, I had to modify the source to make it work properly on my Mac, and it's not necessarily compatible across versions.

So I'm switching to the GNU binutils, since they now support the Z80. Also, Chris Smith (author of the most excellent ULA book) recommends this assembler, and I've found out why. Unlike pasmo or sjasmplus or HiSoft GENS or the BBC Micro assembler (traditional 3 pass assemblers that work on effectively one huge asm file) it works by building object files and linking them, just like what you expect with a C compiler. The assembler and linker have many powerful directives that are very useful, and consistent too: after all, GNU as and ld are used as the back end to the GNU Compiler Collection, probably one of the most widely used C compilers today. The linker allows me to define sections that live in certain places in memory, so it doesn't matter for example when "vectors.asm" is assembled or in what order the object files are linked, I can tell the linker I always want this section at, say, 0x2000. I can have a common linker script file so that all modules are linked the same way, instead of having to specify it each time in each makefile. It also means that things like circular dependencies are no longer an issue, and I can build libraries for commonly-used code. It also means I can use standard Makefiles rather than the shell script I currently use to control the build process. It'll be a bit of work to convert everything, and put section labels in where they are needed, but it'll be worth it as it'll make ongoing development smoother. I've already converted the snapshot manager to use the GNU assembler and linker, and the benefits are already obvious!

Finally, two events coming up right now: firstly, R3PLAY is this weekend and you can see three networked Spectrums there (and write tweets if you like!) followed immediately by Retromañía in Zaragoza, where you'll also be able to see networked Spectrums (and I'm doing a talk on how the system works)

Winston 19:34, 2 November 2010 (GMT)

Concentrate!

I've had an awful lot of distractions recently that's kept me away from the Spectranet, some retrocomputing related, others not, and then there's been the stuff on the calendar, too. But to summarize:

RetroEuskal was great fun again, although we were really short of people this year. I had a Spectranet stand with three networked machines, and of course the Twitter client. There's been a news clip from ETB already (Euskal Telebista), and hopefully they'll have their longer programme about Euskal Encounter and Retro Euskal later in the year. I also did a talk about the Spectranet which went well. Last year was more of a demo of what it did, this year since I speak much more Spanish, I went into a lot more detail about how it actually works and how you can get an old 8 bit machine online. I had quite a few people wanting to know more at the stand, too. I also got to meet Nolan Bushnell (founder of Atari), the two Pacos (authors of the first Spanish commercial game) and Alfonso Azpiri who drew the artwork on two hundred Spanish titles (mostly for the Spectrum, CPC and MSX).

On the Spectranet, I've decided to not do any more new features for now, so the FTP filesystem will wait. What I want to devote my time to doing is tying up the mountain of loose ends and bugs. In the main, this is fixing user interface annoyances, making an installer for Windows users who want to install the TNFS server (although I may have help with that), making a proper configuration system so modules can store some stuff in flash etc. I also got one of Guesser's flash boards for the +2A/B and +3 machines. He had used a PLCC Am29F010 flash IC, and I was surprised to see that its footprint was hardly larger than the TSOP that I'm currently using. And about 1000 times easier to solder to the board, having relatively widely spaced J leads. So although it'll cost me a little since the PCB phototools have to change at the PCB fab, I'm going to re-layout the memory side of the board to take the Am29F010 in a PLCC instead of TSOP. It's the only component that really gives me grief on account of its very short leads (I'm guessing changing the layout will take less time than soldering and testing just two of the TSOP devices, so it'll pay off fast). The PLCC version is also cheaper, which surprised me.

Next week I'm going to clear some time so I can at least do a few hours of Spectranet work and get the project pushed forwards a bit. R3PLAY in Blackpool and Retromañía in Zaragoza are coming up in November and I want a practically "production ready" board to be on show. It's been too long already!

Winston 21:39, 16 September 2010 (BST)

Argh

It took all day to get here, but the new Issue 1 board works and has been tested

Well, the solder paste stencilling decidedly failed to work as planned. Basically, a day of disasters.

While the flash chip went on fine, and had no open circuits (but plenty of shorts, there still seems to be too much solder paste going in) the W5100 was another story. There was a short 3.3v to GND that could not be fixed until I took the chip off again and cleaned up the pads. On replacing the W5100, a new short showed up shorting the 1.8v supply to GND, and this couldn't be fixed. But three reworks was too much and a pad lifted on the PCB - given the W5100 pins are so small that PCB is scrap, even though the CPLD and memory work fine.

A second attempt by using the solder paste syringe went badly also. Firstly, while placing the CPLD, I dropped it and solder paste got smeared everywhere, so I abandoned that PCB and started on a new one. However, after soldering the memory side I found an incurable short on the CPLD. Reworking it fixed it, but I think the CPLD got fried in the process because there is now a short between non-adjacent pins (or solder got underneath it). So I gave up on that one too, although I suspect the PCB can be saved.

I tried again with the stencil but far too much paste went in, and it would have been a lost cause so I tried again and the same thing happened; result - clean it all off with IPA and go back to the syringe.

Finally I made a working board, it went just like the old ones - hours chasing shorts and opens particularly with the flash memory. At least I've proved that the new board layout doesn't have any problems and actually works, but it took all day to make just one working board. (I also have an extra one for RetroEuskal). Making them this way is just not a viable proposition. I know PCB Train do an assembly service, so I have asked if they do partial assembly (so get them to do all the difficult bits using a machine and reflow oven). If they do it'll only be about £3 or 4 per board to do it, then I'll put on all the passives.

Winston 20:40, 18 July 2010 (BST)

Significant redesign

BASIC streams fail on the 128K toastrack

This weekend, I was hoping to move on with the FTP filesystem, the new filesystem module I'm writing so that an FTP site can be accessed just as if it were a disc or a TNFS filesystem. The beauty of implementing things as a filesystem is that there's no need to write a whole new lot of user interface code. Make a filesystem, and all the BASIC commands will just work with it. Programs that know how to load and save files will work with it. There may be some limitations (to start with, the FTP filesystem will only allow one open file at a time) compared to something designed from the get go as a filesystem, but as a whole it's more integrated, and existing software can use it with no modifications. That's the whole point of having the modular Spectranet filesystems, after all. (I'd also like to do an IDE filesystem, it will be the proper way to support the DivIDE. And access to +3 discs etc).

However, these plans were dashed.

When my bench looks like this it generally means there's big trouble
Closer look at the heap of wiring and bus breakout board

In the photo (top right) you can see the half-loaded menu with the rather strange "8 End of file" message with a flashing K cursor stuck to the end of it. This first came to light at the Vintage Computing Festival when Chris Smith gave me a transistor to fix one of my two dead toastrack 128K Spectrums, and the games menu wouldn't load. (So on that machine, I loaded the Twitter client and left it, as we went to lunch. I was very surprised when I came back and found people playing games - what had happened is the menu intermittently worked, and got more reliable as the machine warmed up, but I didn't know that then). At the VCF, I didn't have any time to actually analyze it and we were going to get some lunch, anyway, and I was speculating there may be an incompatibility in the 128K's ROM. Andrew Owen thought not, he didn't think there would be anything that would break channels and streams - he suggested "put the ROM in your +3 and see if it works", so I did. And it worked fine.

There were a few red herrings, too. I repaired the other broken 128K machine I have, thanks to some new RAM that Jose Manuel sent me (he runs El Trastero del Spectrum - the Spectrum Junkroom) and that 128K functioned fine. I had put a new Z80 in it because the M1 line had been zapped - it now had a Mostek NMOS Z80. So I thought - it's not a Spectranet problem, obviously there's a faulty RAM chip on the other machine that's corrupting the streams stub code. Or is it... RAM failures don't usually happen with just one or two bits, usually what happens is a very large piece of RAM stops working, and it causes the whole machine to die. So I tried a different Z80, given this one had a socket - and the random failure of the games menu came back again. With an NMOS Zilog chip from 1984, the failure is infrequent but random, perhaps once every 100 or so INPUT# commands. With a CMOS Z80 from Zilog made in March 2010, the failure was rather more frequent, once every 5 or 6 INPUT# commands on average. I also tried putting a new CMOS Z80 in a rubber key Spectrum, and it caused the problem to start happening on that machine, too. This is all very well tested on rubber key Spectrums (and Pluses) with their original Z80 without a problem. The brand new CMOS Z80 in my +3 gave no problems whatsoever, it functioned perfectly.

Thurlby-Thandar LA4800 logic analyzer showing ZX bus activity

Swapping the Z80 obviously showed it was an electronics problem, and nothing at all to do with ROMs. The first hypothesis is that it was a problem with the ROMCS circuit - the Spectranet holds ROMCS high while its ROM is paged in (to page out the ZX ROM), and releases it either because an OUT instruction has told it to, or it's executed an instruction at 0x007C (the normal exit point in the Spectranet ROM). I hypothesised that ROMCS might be being released insufficiently quickly, causing the wrong instruction to get executed occasionally. However, it didn't take much time with the oscilloscope to show that ROMCS was releasing very fast (and the ULA could then pull ROMCS to the ZX ROM down in under 100ns, which is kind of slow for an M1 cycle, but given that there's about 9 more T-states before the next instruction fetch, the Spectranet's ROMCS line was without a doubt totally beyond suspicion.

I have an old Thurlby-Thandar LA4800 logic analyzer. Normally, it sits for months and months, forgotten and a bit unloved. Someone told me a while ago "why do you want a logic analyzer? They are complex, expensive and you use them so infrequently that you forget how to use it, and 99 times out of 100 a digital storage scope is all you need". I didn't listen anyway, and picked the LA4800 up off an ebayer about three years ago with a collection of various pods for a couple of hundred quid. Just like whoeveritwas who said "all you need is a scope, you'll hardly use it" - this has turned out to be true. I hardly use it. But when I need it, there is nothing else that will do and it's worth its weight in gold. The LA4800 can simultaneously capture 48 channels of data, and you can make it trigger on various conditions, from simple "if you see this, trigger the capture" to a more complex sequence of events. It makes it easy to see exactly what is happening on the data and address bus and all the Z80 control lines. A logic analyzer is the only way you can find exactly where the expected code execution is going wrong on the real hardware, and what wrongness is happening. In short, it's awesome. And the LA4800 is very easy to use, a simple menu driven interface with on-screen help. I made sure I gave it a friendly pat once it had revealed to me what was going wrong.

Initially I was hampered by one of my 128K machines - what I didn't know is that another RAM chip was starting to go flaky on it (it has now failed completely, I have a spare but I've run out of desolder wick). The other 128K hampered me by blowing its TR4 again (and thus, you lose the display, since the TEA2000 no longer has a 12V supply). The other problem is the 128K's bus is rather marginal - it really doesn't take much extra loading on the bus to make a toastrack 128K stop functioning properly - and the logic analyzer has nice long ribbon cables, and that plus the bus breakout board plus the Spectranet was at times just too much, so the debugging lasted a lot longer than it should.

After doing a set of general captures to see that the Spectrum was behaving normally after the Spectranet ROM page out (it was), I set the trigger to trace the program that writes the channel stub to RAM (an earlier trace showed the Spectranet not even getting paged in on INPUT#). This showed the channel code getting written correctly (and showed me to what address, which depends on what the ZX ROM allocates for us). PEEKing that memory showed that the stub was loaded correctly. So now I could tell the logic analyzer to trigger on the address within the stub code where the CALL MODULECALL instruction lived. And there it was - the problem. The LA showed that when the call was made, the Spectranet wasn't paging in. There's some logic in the CPLD that decodes CALL instructions to 0x3FF8 to 0x3FFF, and it wasn't working.

The problem is this. The +3 which functions perfectly is electronically much better than the earlier Sinclair machines. It doesn't have a set of resistors as a bus multiplexer, it's done properly in the +3's ASIC. The +3 has a shorter bus with fewer chips on it, and less loading. The rise and fall times on the +3 is faster. However, the 128K machine has quite a long bus, with many chips on it, plus resistors between lower RAM and the CPU (so the ULA can read lower RAM at the same time as the Z80 writes/reads from upper RAM). There are many reasons for this, the +3 is a lot newer for a start so the cost for doing it the "nice way" had come down a lot. But the upshot is the timings are incredibly tight for the call trap to work on a machine other than a +3 or +2A/+2B, especially if the CALL instruction is in lower RAM.

The bad news is - it's essentially impossible to fix. The minimum time granularity I have in capturing the CALL instruction off the bus is half a T-state. If I read it half a T-state before MREQ+RD go high, this works fine on a +3, but it's unreliable on a 128K toastrack. If I read it when MREQ+RD go high, it doesn't work at all. (Edit: thinking more about it, it could also be that the voltage levels aren't properly reaching either V(IL) or less likely, V(IH) for the CPLD) So with much regret - the CALL trap mechanism that has worked well with all my testing for the last couple of years will have to go. It's a shame because it meant programs didn't have to know what I/O port to use to cause the Spectranet to page in. Now I could instead trap execution at this range of addresses, but the reason I didn't is that some ROMs have code here (but none made a CALL to that address). Alternately, I could just list the ROMs that run code at these addresses as "incompatible" - I'll have to see what the various different ROMs put in this piece of RAM before I can really decide on it. (Edit: and indeed, this is what I've decided - I've changed it to an execution trap at 0x3FF8-0x3FFF, the devices I most care about don't use these addresses. No common ROM that will be paged while the Spectranet is plugged in uses these addresses, and so I won't have to change any software).

Winston 17:19, 4 July 2010 (BST)

ZXI

(Edit: Corrected port numbers)

There's a very sensible proposal going around that all new peripherals use a certain port range to avoid clashing with older stuff (and with stuff that doesn't fully decode I/O addresses). The I/O address range is 0xhh3B, the lower eight bits are nominally for the ZX Printer (probably seldom, if ever going to be used with a newer peripheral, and an easily-made fixit board will serve if someone really does want to use a ZX Printer with a ZXI-compliant device). The upper half of the address bus is the actual port range, and we've got the full 256 ports. Two are already used by the ULA+, and now four are used by the Spectranet. The trouble is the Spectranet had a (fairly harmless, but potentially annoying in the future if a network+chip tune project were to be done) clash with the AY so I was going to have to change the port range anyway (it was 0x80E9, 0x80EB, 0x80ED etc). The new range is 0x003B to 0x033B inclusive. The relative order of the port assignment stays the same (and in any case the actual port is all abstracted away by the various Spectranet ROM library functions). The full list is now:

  • 0x003B - Page A memory selector
  • 0x013B - Page B memory selector
  • 0x023B - Programmable trap register
  • 0x033B - Control register

The Spectranet CPLD performs a full 16 bit decode.

Winston 20:23, 27 June 2010 (BST)

The VCF, and gone off solder paste

Spectranet solder paste stencil

Going from newest to oldest, first I thought I'd try and assemble one of the newly arrived PCBs with an also newly arrived solder paste stencil (see photo, that's a Kapton solder paste stencil for the Spectranet PCB). But I think my solder paste is now past its sell by date, it's gone rather hard and doesn't spread easily. Also the stencil lifted a bit and far too much paste went on... result, well, the workshop now stinks of isopropyl alcohol as I had to clean everything off again. So I'll get some more (probably a small pot of the stuff, rather than a syringe), plus a portable fridge to store it (the better solder paste needs to be kept cool, the stuff in the syringe I was using was fine if kept at room temperature, but this isn't true of all solder paste. Lots of people incidentally have complained that the Edsyn CR44 that I was using doesn't keep its shape as it's heated, it's probably a tradeoff you have to bear to get a solder paste that's happy being stored at room temperature).

Last weekend was the VCF, and this went really well - people loved the Twitter client, and I also fixed one of my toast rack machines to boot, which means I can now get on and fix the bugs that have surfaced on that machine (although I need to reassemble the workshop first, I've not had the chance yet). Indeed, the Spectranet took pride of place on the BBC News article about the VCF, and on the Register, too - BBC report here: http://news.bbc.co.uk/1/hi/technology/10364135.stm and the report at the Register is here: http://www.theregister.co.uk/2010/06/21/vintage_computer_fair/ . I also wrote about the VCF on World of Spectrum here: http://www.worldofspectrum.org/forums/showthread.php?t=30079

Older News