Difference between revisions of "Current events"

From Spectrum
Jump to navigation Jump to search
 
(42 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Improving tape emulation ==
== New Spectranet firmware ==


A while back I added tape traps to the Spectranet, meaning you can put a TAP file on a network filesystem, and load it. It's similar functionality to what the DivIDE has, and what is available in ResiDOS, except you're loading a TAP file over the network rather than directly off an IDE device.
Spectranet firmware has been updated - the current version is labeled R544.


I decided "wouldn't it be nice if there were a default file", so if you just typed LOAD "", it would load this file. So I added this - typing LOAD "" will try to load a file called "boot" in the current directory. The file "boot" is a TAP file (just because it doesn't end in .TAP doesn't mean it's not a TAP file!) - because the format of files saved using the %save command is TAP - it's how the metadata associated with a file is stored. (I made the standard file format be TAP because then it makes it easy to transfer files from a Spectrum to an emulator and vice versa. And TAP holds all the information that's needed).
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


So what you can do is this. You can write something like a menu in BASIC, and %save it as "boot". Then when you type LOAD "", it'll load this BASIC program. Or, on a 128K machine you can use the Loader. (This unfortunately doesn't work on a +3 or +2A owing to the different way they arranged the ROMs).
How to update your firmware:


The idea of this is what I learned by watching people at RetroReunited - if they reset the Spectrum, they'd always do something like bring up the loader or type LOAD "" expecting something to happen. So I decided something ought to happen if you did do that!
%mount 0, "vexed4.alioth.net"
%load ""


Then there were a couple of bugs - well, not bugs so much, but problems with certain games. For example, Starstrike and Skool Daze do something different to many games - and if you've loaded them off tape you'll know that after the SCREEN$ image loads, they don't then start loading another block - the loader simply continues until the game is loaded. What happens, though, is the stack gets overwritten by the tape loader. With a real tape, this is harmless - the right return address got written by the tape file, so when the ROM loader returns, it goes to the right place. (Perhaps an address set up in the tape data itself). But when the tape trap fires, it's a programmable trap and enters via the NMI - and a whole lot of registers get pushed onto the stack. Additionally, the Spectranet replacement for the main rom's LD-BYTES routine (which would normally be loading the bytes off tape) needs to use the stack. Plus the original value of the Spectranet page B register is on the stack. Generally, this means bad things happen when the stack gets overwritten by the TAP file that's being loaded.
Choose "A..Firmware check/Update".  


The solution: make the NMI routine's stack live in Spectranet RAM. This way, it can't be overwritten this way. Now both Starstrike and Skool Daze load just fine (as well as probably a heap of other games).
[[User:Winston|Winston]] 18:10, 19 January 2013 (UTC)


However, I did run into an interesting problem I should have thought of - especially as I actually documented it on the wiki when I first added programmable traps! The layout of the ROM got shuffled around a little bit, and this meant the default trap for LOAD "" actually caused a trigger in the Spectranet ROM, because code now happened to execute at the same address as LD-BYTES in the main ROM. So I added a little extra logic to the CPLD to disable traps while the Spectranet ROM is actually paged. As a workaround for users of the other prototypes, I can probably find the right combination of NOPs to make the ROM not hit this address.
== ZX Breakout ==


[[User:Winston|Winston]] 21:19, 29 September 2009 (BST)
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]]


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


For a great deal of time, I've been doing everything with the Spectranet on my +3. There's a couple of good reasons for this: first, it has RGB out (and all my UHF only Speccies have serious modulator drift problems), and secondly, the floppy disc drive makes it easier to reload the Spectranet ROM if I bork it. (Otherwise, it must be loaded through the tape port while I hold the DISABLETRAP connection at 5v by hand...)
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.


But I got given a Spectrum+ last weekend, and it turns out it has a good modulator (it still drifts, they all do) but it gives good colour output on my TV. But I just got the "pixel vomit" screen when I tried to use it with the Spectranet. I had the same problem with an issue 4 board with the composite mod earlier, but I had put it down to a dirty edge connector. So I tried it on more machines, pixel vomit on all of them except my Issue 2 Spectrum. Which, once warmed up for a few minutes...also gave pixel vomit.
[[User:Winston|Winston]] 22:16, 16 October 2012 (BST)


There was obviously some problem with initialization. First, I checked the Spectrum had actually come out of the RESET state by checking the voltage of the RESET line, it was indeed 5 volts. (The Spectrum's RESET circuit is very high impedance, and the CPLD will prevent it from working at all, so it's buffered before reaching the CPLD). I checked various other things, checked that the clock signal was present (recently, I made changes to the clock circuits in the CPLD), I checked that the voltage was adequate, and everything obvious. Then I started up Xilinx ISE and started going through the CPLD design.
== Failure rates, regenerating clocks ==


One thing I had in mind was the slowness of the reset circuit on these machines - it's just a simple R/C circuit, and I had thoughts that perhaps it was possibly resulting in a bit of "jitter" in the CPLD as the voltage passed through the threshold oh so slowly. I tried all sorts of things to eliminate them - they'd always work the first five or six times (solved it! I thought each time...), but then would inexplicably fail. (As the Spectrum warms up, the R/C reset circuit gets slower). The one place I didn't think to look after banging my head on the table for two days was the memory paging registers in the CPLD. I had forgotten they get reset too (they don't actually need to be reset), and didn't even look at that part of the circuit - until out of complete frustration I had deleted the entire RESET net in the CPLD...
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):


What is happening is the RESET level reaches the Z80's logic high threshold long before it reaches the logic high threshold for the 74HCT1G125 buffer, which feeds the CPLD's reset input. So the CPLD is being held in reset for quite a long time after the Z80 starts running - at least 100,000 T-states! The best fix is to just get rid of the reset circuit from the memory paging registers, but with a few Spectranets already out there with people who don't have the kit to program the CPLD, well, a huge delay loop in software was the pragmatic approach to take. And of course, now it works perfectly on all my Spectrums.
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


[[User:Winston|Winston]] 20:20, 26 September 2009 (BST)
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.


== At long last, addressing +3 BASIC ==
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 Spectrum +3 brought some good enhancements to the world of the Speccy (even if a bit flawed - oh for a 3.5in disc instead of the unusual Amstrad 3in unit), but also some irksome compatibility issues. Not only is it incompatible with any peripheral with a ROM which wasn't +3 aware (i.e. anything designed before the +3) due to the change in the edge connector, but the other problem is the way the BASIC interpreter in 128K mode breaks with what happened with the toastrack 128 and the grey +2. In those machines, all the BASIC interpretation was still strictly done by the original interpreter. But in the +3, some work is done in a different ROM - including the RST 8 error handler.
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]


So when you trap an error to extend BASIC, it suddenly doesn't work even though you've made your device electrically compatible with the +3.
[[User:Winston|Winston]] 18:12, 29 September 2012 (BST)


I want the Spectranet to smoothly support all of the original machines - that is the rubber 48K machine up to the +3, and anything with a compatible edge connector and compatible ROMs. I want it to smoothly support +3 BASIC as well as 128K BASIC without forcing USR 0 mode.
== Spectrum30 ==


This is how I'm going to do it.
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).


On power up, the Spectranet will find out whether it's on a machine with the +3 ROMs. This can be done by looking at the first 6 bytes of ROM 1, which contain the string "Syntax" on a +3. It will store this in a Spectranet system variable (i.e. in the 0x3F00 system variables area in the Spectranet's own static RAM).
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).


When the error trap fires, it'll see if this flag is set, and if so, will check to see whether we're in USR 0 mode or in 128K BASIC mode. This can be done by checking for the presence of the paging routine, which is kept where the printer buffer used to be in RAM. USR 0 mode and 48K mode wipes this routine out - so we can use this to tell that we're in 128K BASIC. If we are in 128K BASIC, ROM 3 (the original syntax ROM, and where the ROM routines that the Spectranet BASIC extensions use) will be paged for the duration of the BASIC extension, then restored when we exit, either due to successful completion or some sort of error.
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.


I suspect I'll hit some bumps in the road while doing this (I hit a few while writing the detection routine yesterday). But the upshot of this is that BASIC support for all the machines should "just work".
[[User:Winston|Winston]] 22:39, 19 September 2012 (BST)


Also, this week, I've implemented the "default file" concept. If you type LOAD "", it will load the first BASIC block it sees in a file named "boot" in the current working directory (TAP format, as the Spectranet's BASIC filesystem support uses TAP as its container format). This even works with the 128K Loader. What it's doing is trapping the tape loading routine and opening the file "boot" if it's present, and then setting up normal tape traps to load this TAP file. The upshot of this is that the next retro party I go to, it'll be really easy for people to just load stuff over the network - just LOAD "", or on a 128K machine, select the Loader, and away you go. (I'll write a little menu program in BASIC for navigating to the various programs).
== 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.


[[User:Winston|Winston]] 19:55, 17 September 2009 (BST)
Also, you'll be able to play Spectank (see http://www.youtube.com/watch?v=6fEvuENABZY )


== The Spectranet world tour continues! ==
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.


[[Image:Speccyandvax.jpg|right|thumb|400px|Spectranet setup at Retro Reunited, with the VAX fileserver]]
[[User:Winston|Winston]] 00:04, 4 September 2012 (BST)


First Oxford, then Bilbao, now Huddersfield!
== The Raspberry Pi and the Spectranet ==


The Spectranet was on show (with all the latest code enhancements) at Retro Reunited, on the 12th/13th September. The Speccy was paired up with a MicroVAX as a fileserver. (The VAX was also the DNS and DHCP server, unfortunately the hotel had no "wider LAN" with these things, nor an internet connection other than WiFi. I could have set up my old PowerBook to be a router on WiFi, but owing to a shortage of TVs, I only had one Speccy on the network so decided to show off the network filesystem rather than the IRC client!)
[[Image:Spectranet-and-pi.jpg|thumb|right|300px|Raspberry Pi nestles amongst Spectranets at Imperica Horizons]]


Which brings me on to more recent developments.
The Raspberry Pi promises to be a great companion to the venerable Spectrum when equipped with a Spectranet :-)


Since the last update, I've added more code to the BASIC streams support, so you can now write a server program in ZX BASIC. Also, I've made the mount command for mounting filesystems MUCH better - instead of passing half a dozen parameters, which was rather clumsy, you now supply just two - the mount point, and an URL for the filesystem you want to mount, in the usual format - proto://user:passwd@host/some/path . The default protocol at the moment is TNFS, so if you just specify an IP address or hostname, it does an anonymous TNFS mount of the root on that host.
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.


Also, I've now added the ability to mount more than one filesystem at a time - up to four filesystems can be mounted simultaneously. If the filesystems are TNFS, then only one network socket is used for the lot, since TNFS is a very low resource UDP protocol.
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.


What was clear from Retro Reunited is that one of the priority developments for the BASIC module is to add a "default" file to load (this will of course work with the Loader on 128K machines). Of course, people just casually playing stuff - for example, at a show like this, may just want to start the Speccy and have it load a menu of games. The other big feature I think people would like is the ability to save snapshots to a filesystem - a bit like the Multiface - hit the NMI button, then save a snapshot to any of the mounted filesystems.
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.


[[User:Winston|Winston]] 22:11, 14 September 2009 (BST)
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!)


== RetroEuskal, and BASIC streams ==
[[User:Winston|Winston]] 22:42, 3 July 2012 (BST)


No updates for about a month, but I've been a bit busy!
== Emulating the Spectranet ==


First, I had the grand challenge of demonstrating the Spectranet at [http://www.retroaccion.org RetroEuskal] - held inside Euskal Encounter (the second largest LAN party in Spain, with 4096 network ports - most in use). Fortunately, the DHCP client worked fine with the Euskal Encounter DHCP servers, and braved a very busy network segment with vast quantities of broadcast traffic (mostly DHCP requests and ARP who-has requests). The demonstration went well, and people even seemed to understand my undoubtedly heavily accented Spanish...
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.


Secondly, one of the things I'd been working hard on so that I could demonstrate it at RetroEuskal was BASIC streams. I got the prototype code done just in time, and tested it with things like an SMTP client written in ZX BASIC (yes! It worked!). So far, you can write TCP client programs in BASIC. Writing servers is going to take a bit more effort (it'll need a separate control channel so that you can peek at the state of things without reading).
To get the Fuse source, visit Sourceforge - [http://fuse-emulator.sourceforge.net/]


It's now possible to write a program like this in BASIC:
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]


10 %connect #4, "some.computer.com", 2000
[[User:Winston|Winston]] 10:42, 25 February 2012 (UTC)
20 INPUT #4;"Tell me> ";a$
30 PRINT "Remote computer said: ";a$
40 PRINT #4; "You said: ";a$
50 IF a$="q" THEN GO TO 100
60 GO TO 20
100 PRINT #4; "Bye!"
110 %close #4


Once accessability from BASIC and the network filesystem is done, basically, the base software is actually finished. The end is in sight!
== Delinquency ==


On the hardware side, I'm thinking of getting some PCBs made, with the aim of making sure my modifications for "production" are good. There's one bug that had to be fixed (which won't affect normal users), plus I want to try and make a small mod to the routing of the ethernet traces from the magjack to try and get rid of a couple of vias, sometimes the W5100 has trouble getting a stable connection on reset, and I want to eliminate that from my enquiries. Also I want to put another jumper in so the user can select the voltage source for the 3.3v regulator - either the 5V from the Spectrum (works on all models), or the 9V (48K only) - the reasoning, to lessen the load on a rubber key Speccy's 7805 regulator.
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:


[[User:Winston|Winston]] 21:33, 6 August 2009 (BST)
* 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.


== A whole lot of new excitement ==
I hope to soon have details on how you can get your hands on one.


Just over a week ago, you may have seen the news that the Speccy made its first tweet on Twitter. The client was hacked together in the Gloucester Arms in Oxford, over a pint of Black Beauty (you do get some odd looks with a Speccy on the pub table, but it was the CSS meet!)
[[User:Winston|Winston]] 21:39, 14 January 2012 (UTC)


But other than that, more exciting times: I've put together a basic automounter (it needs much more work to do what I eventually want it to do), so that filesystems may be mounted at boot/reset time. So the Spectrum can now be powered on, and you can immedately start using the network filesystem. Also, a comprehensive "%info" command has been added to the Spectranet BASIC ROM module which gives information on files. For generic non-Spectrum files (and directories) it just shows the basics, such as filesize (and I intend to show file mode too). But for Spectrum files (the native format being used is TAP), it lists the contents - so, if you have a complete TAP file for a game for instance, it'll show all the blocks that are contained in the TAP file. Also, for testing, I wrote a program in BASIC to give a game loader menu, and then load the game from a TAP file. I wrote it on a real Spectrum, and trusted the TNFS code enough to save it over the network!
== Perhaps production is sorted out.. ==


There are some games that don't seem to load properly - I need to investigate whether this is just a +3 incompatibility, or whether there are bugs in the tape traps.
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.


Other than that, I've fixed a couple more bugs that I discovered in the base ROM.
Watch this space...


Next I want to add support for BASIC streams. (Andrew Owen will like that of course!) For the time being, I intend to add a few commands using the RST 8 trap for opening a socket - it has been suggested that a control channel can be used for sending commands, but that involves a lot of extra work and I'd like to have at least TCP client streams working to demo at RetroEuskal (now wouldn't it be nice to do a Twitter client in ZX BASIC!)
[[User:Winston|Winston]] 16:27, 16 January 2011 (GMT)


[[User:Winston|Winston]] 21:58, 7 July 2009 (BST)
== 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 (Jan 09 - Jun 09)]]
* [[Old News (July 08 - Dec 08)]]
* [[Old News (July 08 - Dec 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