Difference between revisions of "Current events"

From Spectrum
Jump to navigation Jump to search
 
(101 intermediate revisions by the same user not shown)
Line 1: Line 1:
== It's alive! ==
== New Spectranet firmware ==


[[Image:Itlives.jpg|thumb|300px|right|The complete prototype PCB powered up and communicating for the first time]]
Spectranet firmware has been updated - the current version is labeled R544.
[[Image:Completeproto.jpg|thumb|300px|right|A closer view of the now populated prototype PCB]]


The board was completed last night, but it didn't work straight off - but it wasn't hard to find the cause: a bad solder joint from the 25 MHz crystal to the W5100, and a bad joint on the 74HCT245; just a simple case of inexperience when using solder paste and hot air for assembly. The bad joints were easily fixed - since there was already solder on the pads, it just required pressing the tip of the soldering iron on the pad and offending pin to remelt the solder and properly make the joint. I decided to leave it until today to do the work though since it had gone midnight - and last time I tried to fix stuff gone midnight I ended up irretrievably breaking it by ripping up a pad.
Changes:
* '''Streams module:''' Incorrect flags being set when creating a file (thanks Guesser)
* '''Streams module:''' Now ensures a sane file mode is set when creating a file
* '''Snapshot manager:''' No longer makes snapshots world writable when creating them (oops) on fileservers with POSIX permissions


A couple of observations:
How to update your firmware:


The paste is great for doing chips with hot air. It's so much better than using the soldering iron to solder fine pitch surface mount.
%mount 0, "vexed4.alioth.net"
The paste is terrible for mounting the small passives with a soldering iron (and hot air would blow 0603 components away).
%load ""


So without using a reflow oven, the best assembly method is do the chips with paste and hot air, then do the discretes with the soldering iron.
Choose "A..Firmware check/Update".  


Getting back to the board - after fixing the two bad solder joints, I powered up the Spectrum and the experimental ROM code showed a good read back of the configuration data sent to the chip, and the LINK light came on as the ethernet connection was detected. A quick test showed everything working nominally - I sent a .SCR image of the Elite loading screen over the network, and it appeared on the Spectrum's display.
[[User:Winston|Winston]] 18:10, 19 January 2013 (UTC)


So what next?
== ZX Breakout ==


First, give the prototype board a good workout (and disassemble the breadboard prototype, to reclaim my breadboard and some desk space). Then, get a basically functional ROM in place that exposes the socket library, plus a C interface. By basically functional, I mean:
There's a new mini-project: the ZX Breakout. This little board allows you to prototype your CPLD designs easily with either a Xilinx XC9572XL or an XC95144XL. It has header pins for all the ZX bus signals, as well as 39 GPIO pins from the CPLD routed to headers. Read about it on this page: [[ZX Breakout]]


* DNS lookups.
A batch of boards is currently being made, and should be back with me this week or early next week.
* TCP (SOCK_STREAM) and UDP (SOCK_DGRAM) socket interface for asm and C, with a reasonable amount of testing.
* DHCP client.
* Configuration interface.


While waiting for various bits to arrive to complete the first PCB, I also mulled over the current CPLD design, which is my first use of programmable logic. I think there are quite a few improvements that need to be made here, so things like the paging mechanism may still change yet (which will cause a code change).
This board was originally just going to be a level translator board so the user could prototype FPGA circuits (or other designs with 3.3v chips that were not 5v tolerant). However, to get the most from a new board I decided to use a 3.3 volt CPLD with 5v tolerant IO pins. This means it can be used as a level translator but also has a lot of added usefulness since it can be used to prototype the logic for other things, too. To give an idea of the logic resources available, the XC95144XL was used by Chris Smith to make an implementation of the Spectrum ULA, and the ULA uses all the resources of this chip - that's to say, the '144 gives you about the same resources that were available to designers using a Ferranti 6000 series ULA.


I *just* missed the 26th birthday of the Spectrum for getting the first prototype PCB up and working - so I've overrun by a couple of days than my intended schedule. I hope I can have a few prototypes made in about 6 weeks time which are suitable to get into the hands of developers. Overall, the PCB itself has gone pretty smoothly - only one error on the prototype PCB, and it was only a minor one that was easily worked around. Well, so long as nothing turns up when testing the through port!
[[User:Winston|Winston]] 22:16, 16 October 2012 (BST)


[[User:Winston|Winston]] 20:46, 25 April 2008 (BST)
== Failure rates, regenerating clocks ==


== Grey goo ==
I'm going through my box of incomplete/to be reworked Spectranets. Enough people are after them that I want to make some available before the next batch is done. Out of interest, out of the failed ICs so far since I started doing this (from about 50 boards or so):


[[Image:PartialAsm.jpg|right|300px|thumb|Partially assembled PCB, connected to a 48k machine]]
5 duff flash ROMs (one died on a board I had been using for demos for some time)
2 duff static RAMs
1 duff W5100
1 duff CPLD


I received the bits I need to continue soldering from Farnell today, namely soldering iron bits, and some solder paste (Edsyn CR44, in a syringe). This time, things went rather better. I decided to start with a fresh PCB for now and go back to the others later.
I thought originally there were 9 duff flash ROMs, but one board turned out to be in my rework box by mistake (there was absolutely nothing wrong with it), one turned out to be a very small solder bridge on the CPLD shorting the chip select pin that was going to the flash and the other two actually turned out to be the RAM that was duff. Fortunately, this means I don't have to change the PCB footprint for the flash chip - I did think this was causing poor solderability but apparently not. I don't like making changes to a proven design if I don't have to.


I've never used solder paste before. You can get it in bulk (in tubs) or in syringes - and it's fantastically expensive. A small syringe of the stuff is 10 pounds! However, you only need to use minute amounts. In fact, even though I put what I thought was a minute amount on the pads (I gave up trying to put individual blobs on each pad, and instead drew a line of the stuff down each row of PCB pads and hoped surface tension would do the rest) it was too much. However, it's neater than hand soldering fine pitch SMD components, and there's far fewer solder bridges, so less mess left from wicking up excess solder. This also saved me from having to test each pin on each chip, since I could easily see how much neater the solder joints were, and see any problems with a magnifying glass.
The duff CPLD was actually my fault, it was one of the early boards (and it still sits in my rework box today...) - I accidentally connected Vcc and GND the wrong way around on my JTAG lead when preparing to program it. Not only did the CPLD die, smoke came pouring out of the +3's power supply. The duff W5100 was easy to spot - the chip started getting really hot the first time the board was plugged in. My intention is to keep the boards that are not in new condition for demos, and the rest which are in new condition to go over to Rich Mellor to fill in while the next batch is made. I should have 10 of them in new condition.


The solder is a kind of grey goo - a viscous paste which is a thick suspension of solder and flux in some kind of solvent. After laying down a line of this on each row of pads, I placed the chip (first the flash), and then got my trusty B&Q heat gun - which on its lowest setting only happens to be nominally the correct temperature for reflowing solder! The air stream isn't too violent either, so the chip doesn't get blown away. It's still too much for tiny 0603 size discrete components, though, so I hand soldered those.
Looking at some new project work, I've successfully made a digital PLL in Verilog which will regenerate the Spectrum's 3.5MHz clock, that's to say it generates a clock that is in sync with the /CLK signal at the edge connector, and keeps running during periods of contention. This is important if you want to accurately be able to count the number of T-states the ULA sees. This has been tested with a real Spartan-6 FPGA too, and it works! There's a discussion about it here: [http://www.worldofspectrum.org/forums/showthread.php?t=40885 World of Spectrum forums]


I should have used paste for the RAM, but seeing as it's in a SOJ package, I thought it would be just as easy to hand solder...but it ended up taking far longer than the CPLD or flash chip in the end.
[[User:Winston|Winston]] 18:12, 29 September 2012 (BST)


The good news is that the problems I was having earlier must have been just a bad chip. This time, the Spectrum came up just fine. I've run some test code and even programmed the flash, and it all appears to work nominally. The only thing left to do on this particular board is mount the W5100 itself and its associated buffer IC.
== Spectrum30 ==


[[User:Winston|Winston]] 00:03, 24 April 2008 (BST)
Just over a week ago, we had the Spectrum30 event organized by Thomas of Sintech (all the way from Germany!) It was an excellent event, with a numner of luminaries giving talks (including Rick Dickinson, Kevin Toms and Chris Smith).


== Frustration! ==
It also marked general availability of the Spectranet! Unfortunately, the latest boards have almost all sold out already. Fortunately, I will be getting more made :-) The Spectranet is available at the [http://www.sellmyretro.com/ Sell My Retro] site run by Rich Mellor of RWAP Software (he'll be handling all the sales side, as already mentioned).


[[Image:Protopcb.jpg|right|300px|thumb|The prototype PCBs have arrived]]
Secondly, I'm thinking of a new hardware project. Having got the Speccy online, we need to make sure it can continue to display on monitors and TVs for some time to come. I'm currently investigating the feasability of making a DVI-D interface for the Spectrum, which will work both for DVI monitors and televisions with HDMI inputs. Initially, I'll be looking to put out a 480p (640x480 resolution) signal to the display since it's standard and should be supported by everything - but I'll probably look into resolutions that won't cut off as much of top and bottom border when line-doubled. I've already got a Xilinx Spartan-6 development board to prototype this. It'll be much work, but probably less work than the Spectranet (much, MUCH less software required). The challenge will come with the high speed digital design aspects - the frequency of the TMDS outputs even at 480p resolution is pretty high. The development blog will appear here too.


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.
[[User:Winston|Winston]] 22:39, 19 September 2012 (BST)


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.
== On sale at last? ==
With a bit of luck, yes, you'll be able to buy a Spectranet at Spectrum30 ( http://spectrum30.org.uk ) in Cambridge this weekend! Rich Mellor of RWAP Software will be in charge of handling the sales.


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 [http://spectrum.alioth.net/svn/filedetails.php?repname=Spectranet&path=%2Ftrunk%2Futils%2Fbin2tzx.c] so I could send freshly assembled programs to the Spectrum via the tape socket). This all worked satisfactorily.
Also, you'll be able to play Spectank (see http://www.youtube.com/watch?v=6fEvuENABZY )


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.
In other news, there's been some last minute changes to the CPLD. One circuit that's not changed since the very first prototype CPLD is the memory paging circuits. These have been optimized and made much less complex - their initial complexity was really just an artifact of my inexperience with the CPLD and Xilinx ISE. Also, some improvements have been made to the programmable trap circuit. This circuit reads two bytes (to form the low and high halves of the address that must be trapped) using a single IO port. To control which register gets written to, there's basically a flip flop configured as a toggle. This gets reset on power-up or when the reset button is pushed, but very occasionally, the programmable trap would fail to work. I suspect there were some transient signals during the very slow rising reset signal that comes from the Spectrum, and occasionally this toggle could get flipped. Additionally, the timing was somewhat tight on when it toggled (basically the register that got filled relied on the propogation delay being sufficient within the CPLD), so the timing has been changed to be more robust - the toggle now switches on the 'leading edge' of the IO cycle instead of the trailing edge, so it will have been set several hundred nanoseconds before the Z80's write signal rises at the end of the cycle. And to add a belt and braces approach, software can also reset the toggle to guarantee its state will be known before writing to the register. The reset is performed simply by reading the IO port that is used to set the programmable trap (this read also returns the CPLD version, which is now updated to 0001 binary. The three versions are: floating bus = prototype, 0000 = first production batch which the early adopters got, and 0001 is the ones that have existed since last Saturday. The prototype is floating bus because it simply never had the version read circuit, and there are ten of them in the wild I can't have reprogrammed easily.


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.
[[User:Winston|Winston]] 00:04, 4 September 2012 (BST)


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.
== The Raspberry Pi and the Spectranet ==


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.
[[Image:Spectranet-and-pi.jpg|thumb|right|300px|Raspberry Pi nestles amongst Spectranets at Imperica Horizons]]


'''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.
The Raspberry Pi promises to be a great companion to the venerable Spectrum when equipped with a Spectranet :-)


[[User:Winston|Winston]] 11:21, 20 April 2008 (BST)
I have just received mine from Farnell. I've gone and downloaded the SD card image for the Debian Squeeze distro, and put it on an SD card and gone and booted the little machine (just how The Creators Intended, using the composite out on the Pi to a CRT television...). The Pi comes with all the development stuff you need to build server applications. I've done some testing already with the TNFS (file server) program, and the Pi is now serving files perfectly to a Spectrum.


== PCBs ready... ==
I've also done a brief test of the Capture-the-Flag server (there's some bits of code which aren't necessarily terribly portable in the CTF game server), and so far indications are good that it's just a straightforward build to make it all work. I need to get another Speccy on the network to test it properly, though. All this should be on show at RetroEuskal in Bilbao later this month, and of course at the Cambridge Speccy 30th anniversary event in September, and later on at Replay Expo in Manchester.


I just got notification from the PCB fabricator that the PCBs are done and have been sent...
I intent to make some pre-built Debian packages (and a little Debian apt repository) for the Raspberry Pi programs. At the same time I'll do the same for x86 and amd64 based Debian systems.


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!
Incidentally, on the subject of shows, I should have written about it then - but the Imperica Horizons Speccy at 30 event in London was excellent, some very interesting people gave talks including Saul Metzinger, the director of "Micro Men" (who hung out with us later at the bar at the BFI). Videos and pictures are here: http://www.imperica.com/horizons (and of course there was a talk on the Spectranet!). Eben Upton was there too to present the Raspberry Pi, since we're talking about the Pi. I have a nice pic of one of the early models nestling amongst two Spectranets (as you can see!)


[[User:Winston|Winston]] 22:45, 14 April 2008 (BST)
[[User:Winston|Winston]] 22:42, 3 July 2012 (BST)


== Back to Code ==
== Emulating the Spectranet ==


Firstly, the PCB layout has gone to the fab to be manufactured...
The Fuse (Free Unix Spectrum Emulator) SVN trunk now includes Spectranet emulation - so if you don't have a Spectranet you can at least try it out emulated. You will have to build it from source, though, at the moment - so you'll need some kind of Unix-like development environment. It runs well on Mac OSX and Linux, and some brave souls have built it on Windows so far; if you ask in IRC on #spin you might find something out about that.


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!
To get the Fuse source, visit Sourceforge - [http://fuse-emulator.sourceforge.net/]


So, back to the code. This weekend adds the following bits of functionality:
Once you have Fuse running, you'll need to install the firmware and save an SZX snapshot with the firmware loaded - see this guide here: [http://fuse-emulator.svn.sourceforge.net/viewvc/fuse-emulator/trunk/fuse/hacking/spectranet.txt]


* 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.
[[User:Winston|Winston]] 10:42, 25 February 2012 (UTC)
* 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.
== Delinquency ==


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.
OK - so I have been *incredibly* delinquent in writing any updates (a year!) But 2011 was fairly eventful, and other things in life kept me away from my projects. But the current update on the situation:


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.
* Production was sorted out! A fair number of Spectranets have been factory assembled. A number are in the hands of "early adopters" to shake out any bugs.
* A manual is being written.
* Many bugs have been fixed, thanks to early adopters.


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.
I hope to soon have details on how you can get your hands on one.


Plans for the time until the PCBs arrive:
[[User:Winston|Winston]] 21:39, 14 January 2012 (UTC)
* 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.


[[User:Winston|Winston]] 20:55, 6 April 2008 (BST)
== Perhaps production is sorted out.. ==


Thanks to the Zonadepruebas Jupiter Ace project, I think I've found somewhere which will do the assembly of the Spectranet for a reasonable cost. At the moment the target date is the end of Feburary.
Watch this space...
[[User:Winston|Winston]] 16:27, 16 January 2011 (GMT)
== Argh! A hardware problem! ==
So I'm almost done and I've discovered a hardware problem: there's a bug within the W5100 chip which means if the reset pulse arrives at the wrong time, it won't connect to a 100Mbps network (in other words the kind of network most people have). Of course I have about 30 of the chips with the bug already, it wasn't fixed by Wiznet until the end of 2009 or so, so it's only recently chips without the bug have been around.
There is a solution but it requires changes to the PCB. It requires the W5100's reset line be controlled directly via the CPLD instead of using the Spectrum's reset signal, and it also requires that the LINK LED output from the W5100 be taken to the CPLD so that software can detect the interface state (unfortunately, the W5100 doesn't provide a register that shows the state of the PHY).
As for the software, it's almost done. TNFS now has some simple back-off rules which means it works much better on a network with packet loss or where the server can't respond in a timely way (I modified a copy of the TNFS server to deliberately respond slowly and/or drop packets). Also all of the sources have been transistioned to use GNU binutils - most of the work I did while at Retromañía during the hours of keeping an eye on the Juegodromo.
I now just need to find somewhere that'll do partial assembly of the PCBs. I think it can be quite cost effective to get the time-consuming-to-solder ICs put on the board, then I assemble the rest myself. If that doesn't work out, I'll change the flash chip to a PLCC for the next revision of the PCB which will save about 70% of the time if I construct the boards myself.
[[User:Winston|Winston]] 22:01, 6 December 2010 (GMT)
== 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! ==
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!
[[User:Winston|Winston]] 21:39, 16 September 2010 (BST)
== Argh ==
[[Image:Redspectranet.jpg|thumb|right|300px|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.
[[User:Winston|Winston]] 20:40, 18 July 2010 (BST)
== Significant redesign ==
[[Image:128debug1.jpg|thumb|right|300px|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.
[[Image:128debug2.jpg|thumb|right|300px|When my bench looks like this it generally means there's big trouble]]
[[Image:128debug3.jpg|thumb|right|300px|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.
[[Image:128debug4.jpg|thumb|right|300px|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).
[[User:Winston|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.
[[User:Winston|Winston]] 20:23, 27 June 2010 (BST)
== The VCF, and gone off solder paste ==
[[Image:Stencil.jpg|thumb|right|300px|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 ==
== Older News ==


* [[Old news (Jan 10 - June 10)]]
* [[Old news (July 09 - Dec 09)]]
* [[Old news (Jan 09 - Jun 09)]]
* [[Old News (July 08 - Dec 08)]]
* [[Old News (June 08 - July 08)]]
* [[Old News (Apr 08 - May 08)]]
* [[Old News (Feb 08 - Mar 08)]]
* [[Old News (Feb 08 - Mar 08)]]
* [[Old News (Dec 07 - Jan 08)]]
* [[Old News (Dec 07 - Jan 08)]]

Latest revision as of 18:10, 19 January 2013

New Spectranet firmware

Spectranet firmware has been updated - the current version is labeled R544.

Changes:

  • Streams module: Incorrect flags being set when creating a file (thanks Guesser)
  • Streams module: Now ensures a sane file mode is set when creating a file
  • Snapshot manager: No longer makes snapshots world writable when creating them (oops) on fileservers with POSIX permissions

How to update your firmware:

%mount 0, "vexed4.alioth.net"
%load ""

Choose "A..Firmware check/Update".

Winston 18:10, 19 January 2013 (UTC)

ZX Breakout

There's a new mini-project: the ZX Breakout. This little board allows you to prototype your CPLD designs easily with either a Xilinx XC9572XL or an XC95144XL. It has header pins for all the ZX bus signals, as well as 39 GPIO pins from the CPLD routed to headers. Read about it on this page: ZX Breakout

A batch of boards is currently being made, and should be back with me this week or early next week.

This board was originally just going to be a level translator board so the user could prototype FPGA circuits (or other designs with 3.3v chips that were not 5v tolerant). However, to get the most from a new board I decided to use a 3.3 volt CPLD with 5v tolerant IO pins. This means it can be used as a level translator but also has a lot of added usefulness since it can be used to prototype the logic for other things, too. To give an idea of the logic resources available, the XC95144XL was used by Chris Smith to make an implementation of the Spectrum ULA, and the ULA uses all the resources of this chip - that's to say, the '144 gives you about the same resources that were available to designers using a Ferranti 6000 series ULA.

Winston 22:16, 16 October 2012 (BST)

Failure rates, regenerating clocks

I'm going through my box of incomplete/to be reworked Spectranets. Enough people are after them that I want to make some available before the next batch is done. Out of interest, out of the failed ICs so far since I started doing this (from about 50 boards or so):

5 duff flash ROMs (one died on a board I had been using for demos for some time) 2 duff static RAMs 1 duff W5100 1 duff CPLD

I thought originally there were 9 duff flash ROMs, but one board turned out to be in my rework box by mistake (there was absolutely nothing wrong with it), one turned out to be a very small solder bridge on the CPLD shorting the chip select pin that was going to the flash and the other two actually turned out to be the RAM that was duff. Fortunately, this means I don't have to change the PCB footprint for the flash chip - I did think this was causing poor solderability but apparently not. I don't like making changes to a proven design if I don't have to.

The duff CPLD was actually my fault, it was one of the early boards (and it still sits in my rework box today...) - I accidentally connected Vcc and GND the wrong way around on my JTAG lead when preparing to program it. Not only did the CPLD die, smoke came pouring out of the +3's power supply. The duff W5100 was easy to spot - the chip started getting really hot the first time the board was plugged in. My intention is to keep the boards that are not in new condition for demos, and the rest which are in new condition to go over to Rich Mellor to fill in while the next batch is made. I should have 10 of them in new condition.

Looking at some new project work, I've successfully made a digital PLL in Verilog which will regenerate the Spectrum's 3.5MHz clock, that's to say it generates a clock that is in sync with the /CLK signal at the edge connector, and keeps running during periods of contention. This is important if you want to accurately be able to count the number of T-states the ULA sees. This has been tested with a real Spartan-6 FPGA too, and it works! There's a discussion about it here: World of Spectrum forums

Winston 18:12, 29 September 2012 (BST)

Spectrum30

Just over a week ago, we had the Spectrum30 event organized by Thomas of Sintech (all the way from Germany!) It was an excellent event, with a numner of luminaries giving talks (including Rick Dickinson, Kevin Toms and Chris Smith).

It also marked general availability of the Spectranet! Unfortunately, the latest boards have almost all sold out already. Fortunately, I will be getting more made :-) The Spectranet is available at the Sell My Retro site run by Rich Mellor of RWAP Software (he'll be handling all the sales side, as already mentioned).

Secondly, I'm thinking of a new hardware project. Having got the Speccy online, we need to make sure it can continue to display on monitors and TVs for some time to come. I'm currently investigating the feasability of making a DVI-D interface for the Spectrum, which will work both for DVI monitors and televisions with HDMI inputs. Initially, I'll be looking to put out a 480p (640x480 resolution) signal to the display since it's standard and should be supported by everything - but I'll probably look into resolutions that won't cut off as much of top and bottom border when line-doubled. I've already got a Xilinx Spartan-6 development board to prototype this. It'll be much work, but probably less work than the Spectranet (much, MUCH less software required). The challenge will come with the high speed digital design aspects - the frequency of the TMDS outputs even at 480p resolution is pretty high. The development blog will appear here too.

Winston 22:39, 19 September 2012 (BST)

On sale at last?

With a bit of luck, yes, you'll be able to buy a Spectranet at Spectrum30 ( http://spectrum30.org.uk ) in Cambridge this weekend! Rich Mellor of RWAP Software will be in charge of handling the sales.

Also, you'll be able to play Spectank (see http://www.youtube.com/watch?v=6fEvuENABZY )

In other news, there's been some last minute changes to the CPLD. One circuit that's not changed since the very first prototype CPLD is the memory paging circuits. These have been optimized and made much less complex - their initial complexity was really just an artifact of my inexperience with the CPLD and Xilinx ISE. Also, some improvements have been made to the programmable trap circuit. This circuit reads two bytes (to form the low and high halves of the address that must be trapped) using a single IO port. To control which register gets written to, there's basically a flip flop configured as a toggle. This gets reset on power-up or when the reset button is pushed, but very occasionally, the programmable trap would fail to work. I suspect there were some transient signals during the very slow rising reset signal that comes from the Spectrum, and occasionally this toggle could get flipped. Additionally, the timing was somewhat tight on when it toggled (basically the register that got filled relied on the propogation delay being sufficient within the CPLD), so the timing has been changed to be more robust - the toggle now switches on the 'leading edge' of the IO cycle instead of the trailing edge, so it will have been set several hundred nanoseconds before the Z80's write signal rises at the end of the cycle. And to add a belt and braces approach, software can also reset the toggle to guarantee its state will be known before writing to the register. The reset is performed simply by reading the IO port that is used to set the programmable trap (this read also returns the CPLD version, which is now updated to 0001 binary. The three versions are: floating bus = prototype, 0000 = first production batch which the early adopters got, and 0001 is the ones that have existed since last Saturday. The prototype is floating bus because it simply never had the version read circuit, and there are ten of them in the wild I can't have reprogrammed easily.

Winston 00:04, 4 September 2012 (BST)

The Raspberry Pi and the Spectranet

Raspberry Pi nestles amongst Spectranets at Imperica Horizons

The Raspberry Pi promises to be a great companion to the venerable Spectrum when equipped with a Spectranet :-)

I have just received mine from Farnell. I've gone and downloaded the SD card image for the Debian Squeeze distro, and put it on an SD card and gone and booted the little machine (just how The Creators Intended, using the composite out on the Pi to a CRT television...). The Pi comes with all the development stuff you need to build server applications. I've done some testing already with the TNFS (file server) program, and the Pi is now serving files perfectly to a Spectrum.

I've also done a brief test of the Capture-the-Flag server (there's some bits of code which aren't necessarily terribly portable in the CTF game server), and so far indications are good that it's just a straightforward build to make it all work. I need to get another Speccy on the network to test it properly, though. All this should be on show at RetroEuskal in Bilbao later this month, and of course at the Cambridge Speccy 30th anniversary event in September, and later on at Replay Expo in Manchester.

I intent to make some pre-built Debian packages (and a little Debian apt repository) for the Raspberry Pi programs. At the same time I'll do the same for x86 and amd64 based Debian systems.

Incidentally, on the subject of shows, I should have written about it then - but the Imperica Horizons Speccy at 30 event in London was excellent, some very interesting people gave talks including Saul Metzinger, the director of "Micro Men" (who hung out with us later at the bar at the BFI). Videos and pictures are here: http://www.imperica.com/horizons (and of course there was a talk on the Spectranet!). Eben Upton was there too to present the Raspberry Pi, since we're talking about the Pi. I have a nice pic of one of the early models nestling amongst two Spectranets (as you can see!)

Winston 22:42, 3 July 2012 (BST)

Emulating the Spectranet

The Fuse (Free Unix Spectrum Emulator) SVN trunk now includes Spectranet emulation - so if you don't have a Spectranet you can at least try it out emulated. You will have to build it from source, though, at the moment - so you'll need some kind of Unix-like development environment. It runs well on Mac OSX and Linux, and some brave souls have built it on Windows so far; if you ask in IRC on #spin you might find something out about that.

To get the Fuse source, visit Sourceforge - [1]

Once you have Fuse running, you'll need to install the firmware and save an SZX snapshot with the firmware loaded - see this guide here: [2]

Winston 10:42, 25 February 2012 (UTC)

Delinquency

OK - so I have been *incredibly* delinquent in writing any updates (a year!) But 2011 was fairly eventful, and other things in life kept me away from my projects. But the current update on the situation:

  • Production was sorted out! A fair number of Spectranets have been factory assembled. A number are in the hands of "early adopters" to shake out any bugs.
  • A manual is being written.
  • Many bugs have been fixed, thanks to early adopters.

I hope to soon have details on how you can get your hands on one.

Winston 21:39, 14 January 2012 (UTC)

Perhaps production is sorted out..

Thanks to the Zonadepruebas Jupiter Ace project, I think I've found somewhere which will do the assembly of the Spectranet for a reasonable cost. At the moment the target date is the end of Feburary.

Watch this space...

Winston 16:27, 16 January 2011 (GMT)

Argh! A hardware problem!

So I'm almost done and I've discovered a hardware problem: there's a bug within the W5100 chip which means if the reset pulse arrives at the wrong time, it won't connect to a 100Mbps network (in other words the kind of network most people have). Of course I have about 30 of the chips with the bug already, it wasn't fixed by Wiznet until the end of 2009 or so, so it's only recently chips without the bug have been around.

There is a solution but it requires changes to the PCB. It requires the W5100's reset line be controlled directly via the CPLD instead of using the Spectrum's reset signal, and it also requires that the LINK LED output from the W5100 be taken to the CPLD so that software can detect the interface state (unfortunately, the W5100 doesn't provide a register that shows the state of the PHY).

As for the software, it's almost done. TNFS now has some simple back-off rules which means it works much better on a network with packet loss or where the server can't respond in a timely way (I modified a copy of the TNFS server to deliberately respond slowly and/or drop packets). Also all of the sources have been transistioned to use GNU binutils - most of the work I did while at Retromañía during the hours of keeping an eye on the Juegodromo.

I now just need to find somewhere that'll do partial assembly of the PCBs. I think it can be quite cost effective to get the time-consuming-to-solder ICs put on the board, then I assemble the rest myself. If that doesn't work out, I'll change the flash chip to a PLCC for the next revision of the PCB which will save about 70% of the time if I construct the boards myself.

Winston 22:01, 6 December 2010 (GMT)

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