Difference between revisions of "Current events"

From Spectrum
Jump to navigation Jump to search
 
(36 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Saving snapshots ==
== New Spectranet firmware ==


A couple of weeks ago, I implemented snapshot loading. A pre-requisite for snapshot saving was to fix the NMI problem, once that was out of the way, I could go forward with snapshot saving. Again, so far, just 48K snapshots have been implemented. The stress test so far was to save a snapshot while playing Exolon, so I could skip the boring bits (the first 7 or so levels)...
Spectranet firmware has been updated - the current version is labeled R544.


There's a number of interesting things about making the Spectrum be introspective about its state. There are a number of things that cannot be read directly - most importantly for us, interrupt mode and whether interrupts are actually enabled. To find this out, what has to be done is this: use the RETN instruction to restore IFF1 (i.e. restore interrupts back to the state they were when the NMI button was pressed), then... wait.
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


To detect interrupt mode 1, I have a delay loop that lasts long enough that at least one interrupt happens. The Spectranet ROM has an interrupt service routine at the normal place - all it does is update a counter, just like the FRAMES sysvar which the main ROM ISR keeps updated. The counter gets reset, then the delay loop runs, then the counter is examined. If it's nonzero, we know interrupts are enabled and we are in IM 1. Also there is another interrupt service routine for IM 2. To make this work, a vector table is created in Spectranet RAM. If the IM 2 ISR is called, it sets the appropriate value in the snapshot header that's being built. If we see IM 2 set in this byte, then we know interrupts are enabled and we are using IM 2. (IM 0 can't be used on a standard Spectrum - I don't test for it at all, indeed, IM 0 would present quite a few difficulties on a Spectrum).
How to update your firmware:


Of course, it's entirely possible that interrupts are actually disabled. So if we've not detected IM 1 or IM 2, we know interrupts were disabled. At this stage, the IM 1 and IM 2 tests are run a second time, but interrupts are explicitly enabled with EI.
%mount 0, "vexed4.alioth.net"
%load ""


Then the state can be saved to the filesystem, then it all has to be restored, and the NMI routine finally exited back to where we were.
Choose "A..Firmware check/Update".  


I wrote a couple of small test routines to make sure the snapshot code was working correctly (and help discover what bugs I had put in the code!) - these were just simple short programs to show that all the register values were correct, and that the interrupt mode remained as it should have been. Much more needs to be developed - the issue of 128K snapshots, the ability to load .Z80 as well as .SNA. I also need to think about whether I want to put the snapshot code in its own module or not (at the moment it lives in the BASIC extensions module, owing to the %loadsnap command living there). Additionally, some kind of sane snapshot management on the lines of the ResiDOS task manager so that snapshots are easy to use outside of BASIC. I also need to see whether I can shoe-horn three flip flops into the CPLD to allow the border colour to be detected - the only way of knowing the border is to monitor output to port 0xFE.
[[User:Winston|Winston]] 18:10, 19 January 2013 (UTC)


* Edit - I got the shoehorn out, and yes, the three flip flops did fit. Just! So the correct border colour is saved in the snapshot, too.
== ZX Breakout ==


[[User:Winston|Winston]] 22:55, 3 November 2009 (GMT)
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 session of hardware debugging ==
A batch of boards is currently being made, and should be back with me this week or early next week.


[[Image:Hwdebugging.jpg|thumb|right|300px|Debugging the NMI problem - JTAG leads and two scope probes connected]]
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.


To cut a long story short: the problem of multiple NMI triggering that I wrote about yesterday was caused by the CPLD falsely decoding an NMI instruction.
[[User:Winston|Winston]] 22:16, 16 October 2012 (BST)


The longer version: I spent about three hours this evening banging my head against the problem. There were multiple things over which to bang my head: lack of resources remaining in the CPLD and simple solutions that should work not working. I decided to make the Spectranet generate the NMI signal like the DivIDE does - keep NMI low until the next instruction fetch after the NMI. That should have been fine, but it took a lot of rejigging things to be able to get one more flip flop on the CPLD. I sacrified the read of the status bits that I've never actually found it necessary to read. Then after exhaustive fitting by the Xilinx ISE fitter (that took long enough I managed to watch a half hour TV programme while it was running), it didn't really work. The second flip flop, theoretically at least - could only be triggered when an NMI event occurred, but it seems that it could latch sometimes in the chaos of power up (even when explicitly held in reset while the Spectrum's reset was active... but you don't have to scroll down far to find out the realities of the verrrry sllooooow rise of the Spectrum's reset signal, and the problems it caused me).
== Failure rates, regenerating clocks ==


After many iterations of this, I came up with something that should have worked, but in fact guaranteed a double NMI triggering. It made no sense. However, putting the 'scope on a fairly long time base (1 millisecond) showed what was happening - it really WAS double triggering. On a hunch, I stopped RETN from resetting the "I'm in an NMI right now" flip flop (whose purpose is to prevent double triggering of the NMI by switch bounce) and lo and behold, no double NMI.
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):


I looked at the RETN decoder. It certainly looked right - decode the M1 cycle, then the other half of the instruction. Theoretically, nothing but RETN could trigger it.
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


Then I thought - why am I bothering to decode RETN anyway? Why not release the flip flops when we unpage? I couldn't think of any reason.
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.


So I deleted the entire RETN decoder. I also deleted the bits that was giving an NMI pulse until M1, and went back to the old behaviour. Now it works perfectly, and I've freed up a whole heap of CPLD resource (well, perhaps not a heap, but enough that I could put some new, useful function in the CPLD that I may want in future). And it proves for certain that yes - there must have been an NMI signal bounce, and the Z80 that I have is behaving how the manual says it should. Who cares why RETN was being decoded when it shouldn't - that circuit has ceased to be. (Actually I am very curious on why the same code and the same CPLD did not get false RETN decodes on the +3, but did on the rubber key machine).
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.


Later, I remembered why the RETN decoder was there - in the first incarnation of the NMI menu, it used the Spectrum keyboard scan/key decode routines by calling them in the Spectrum ROM, and had to unpage to do that, well within the time the NMI switch could still be bouncing as the user's finger leaves it. So the NMI event latch needed to remain set while the ROM routine was called, so instead of being reset by pageout, it was reset by RETN. However, problems with doing this on a Spectrum +3 meant that I put the key scan routines into the Spectranet ROM, so the NMI menu hasn't called any Spectrum ROM routines in quite a while.
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]


As for the strongest candidates to put into the CPLD - the interrupt functions that were dropped, perhaps (the W5100 interrupt line is connected to the CPLD, but it isn't even made available to a status register read, owing to the lack of CPLD resources).
[[User:Winston|Winston]] 18:12, 29 September 2012 (BST)


[[User:Winston|Winston]] 20:04, 31 October 2009 (GMT)
== Spectrum30 ==


== Another hardware bug found... ==
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).


Or at least, certain "bad interactions" with some Z80 processors.
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:Spectranet-nmi.jpg|right|thumb|300px|Spectranet NMI - goes low and stays low until RETN]]
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.
[[Image:Divide-nmi.jpg|right|thumb|300px|DivIDE NMI - goes low until (probably) the subsequent M1 cycle]]


It started last week. I'm beginning to implement snapshot saving, and I just wanted to sanity check things (make sure the NMI button didn't crash games, and that kind of thing). And...it did crash games. It even crashed Manic Miner. Since the NMI button only (is supposed to) result in one new entry pushed onto the stack - which is unavoidable - it shouldn't crash Manic Miner, which doesn't do anything particularly fancy and is not tight on stack space.
[[User:Winston|Winston]] 22:39, 19 September 2012 (BST)


First, I investigated the software. No problems found - I wrote a little test to do a "before" and "after" register test, to make sure no registers had been disturbed - none had. I looked at the code, and couldn't see anything that would cause a crash on NMI return. However, I noticed one curious thing - there would be a noticeable delay before the NMI menu came up (on the order of 1/4 second or so) at times when Manic Miner was running. Occasionally, I saw the NMI menu half paint, the screen clear, then the NMI menu repaint. That to me said an obvious double (or more) triggering. The really odd thing was it hardly ever happened when sitting in BASIC, or running a program to try and test the conditions before and after NMI. However, with a game loaded, multiple NMI triggering would happen '''all the time'''.
== 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.


Fortuitously, I had managed to obtain a digital storage oscilloscope. It arrived yesterday. So the first real use of the new scope - see if the NMI signal was "bouncing" and causing multiple NMIs. First, a bit of background to how the Spectranet makes an NMI - basically, when you hit the switch, there's some debounce logic in the CPLD (which is very, very simple - basically a flip flop that goes low until the CPLD decodes a RETN instruction). The output of this flip flop is an open drain pin on the CPLD, which pulls down on the NMI line on the Spectrum. The Z80's NMI is level triggered, and it '''should not''' trigger again until the NMI signal has returned high. What I guessed was happening was that the NMI was going low and then "bouncing", instead of staying at 0v, perhaps crossing the logic 1 threshold of the Z80 numerous times before settling. However, within seconds of connecting the new 'scope, that was proven to be unequivocally untrue - the signal was as perfect as can be. (See the picture to the top right). I decided to have a look at the DivIDE, and see what its NMI signal looked like, since I hadn't heard any complaints about crashes being caused by the DivIDE's NMI button. Sure enough, it gets returned back to a logic high level. I suspect the M1 cycle subsequent to the NMI being triggered probably resets the DivIDE's NMI output (it resets between 15 and 23 T-states after being asserted). You can see the NMI output of the DivIDE in the picture on the bottom right.
Also, you'll be able to play Spectank (see http://www.youtube.com/watch?v=6fEvuENABZY )


The upshot of this is I've got to squeeze more logic into the already pretty full CPLD to reset the NMI output but do it in a way that it can't be reinvoked until the RETN instruction has been seen on the bus. And again, the reason I had never seen this problem is because it's not a problem on the Spectrum +3. I can invoke the Spectranet's NMI as often as I like while playing Manic Miner, and it never crashes - so obviously, different Z80s behave a bit differently to an NMI signal that's held low for a long time.
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.


[[User:Winston|Winston]] 21:30, 30 October 2009 (GMT)
[[User:Winston|Winston]] 00:04, 4 September 2012 (BST)


== Snapshots ==
== The Raspberry Pi and the Spectranet ==


A feature that I found would be important at RetroReunited (on talking to a few other people) is the ability to snapshot - to be able to load and save snapshots to a filesystem.
[[Image:Spectranet-and-pi.jpg|thumb|right|300px|Raspberry Pi nestles amongst Spectranets at Imperica Horizons]]


To start, I've done the easy one - load from a 48K .SNA file. Surprisingly, this worked first time. There's a BASIC command to do it now, named %loadsnap. (Ultimately, it'll detect the kind of snapshot, and do the right thing). For loading, I intend to support at least 48K and 128K .SNA files, and probably .Z80 files too. For saving, I'll just support .SNA because it's the most straightforward to support, and should do the job fine for nearly all uses.
The Raspberry Pi promises to be a great companion to the venerable Spectrum when equipped with a Spectranet :-)


This also requires an overhaul of the NMI menu. Snapshotting will be done from the NMI menu as you'd expect, but it's going to be done from a module. Currently the NMI menu is hard coded in the utility ROM. What it needs to do is to go through all the ROM modules, to see if they have an NMI action (in which case, print an string and allow a jump to the address of whatever routine will handle the NMI).
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.


Incidentally, as for the next "Spectranet World Tour" event, I'm already planning for the Vintage Computer Fair, which will be held at the historic Bletchley Park next June. I intend to have a LAN of at least 4 Spectrums set up and running, plus the VAX fileserver I had at RetroReunited.
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.


[[User:Winston|Winston]] 18:55, 25 October 2009 (GMT)
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.


== Making streams usable ==
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!)


After much work here and there, BASIC streams support now is a bit more worthwhile. Not only does it support TCP sockets, but now also reading/writing files on a file system, as well as reading directories. A brief summing up of what's been done to make streams into something practically useful:
[[User:Winston|Winston]] 22:42, 3 July 2012 (BST)


* Bug fixes. The TNFS module wasn't freeing up file/directory descriptors on close (whoops!)
== Emulating the Spectranet ==
* Better memory management in the streams module itself (of the memory allocated by BASIC's MAKE-ROOM routine)
* File and directory support
* Lots and lots of testing!


Supporting files and directories, is I think quite a big thing. It means the BASIC programmer can take advantage of any filesystem module that's written - for instance, write a HTTP filesystem, and BASIC can use it. Write an FTP filesystem, and BASIC can use it. Write an IDE filesystem for an attached DivIDE, and BASIC can use it - and no programs have to be modified. This of course was the original intention of streams in the BASIC ROM, but the support was never finished back in the day. I hope the Spectranet can show the true beauty of what was actually intended back in the day.
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.


There are other things I need to support, and I want to try and support without a proliferation of BASIC extensions, by means of streams. I still need to write a control stream which can be opened to find status of other streams. The syntax of INPUT# is actually quite handy for this kind of thing. For instance, imagine we have a stream that can stat (find information) on a file. A line in BASIC could be written as such to use a control stream to do this. Imagine the "stat" command returns the size in bytes, followed by the type of file, followed by the permissions...
To get the Fuse source, visit Sourceforge - [http://fuse-emulator.sourceforge.net/]


INPUT #4, "stat /path/to/some/file";size;t$;p$
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]


(It's a pity that BASIC only allows single characters for string variable names).
[[User:Winston|Winston]] 10:42, 25 February 2012 (UTC)


The other thing that I've made streams support is EOF (end of file) handling not by returning an error to BASIC (which makes your program bale out with the unhelpful error '8 End of file', at which point your program has stopped and left all the channels open...) The usual idiom in a language like C for reading a file or something you fully and correctly expect to stop reading at EOF looks something like this (in C-like pseudocode):
== Delinquency ==


filehandle=fopen("/path/to/file", "r");
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:
while(data = read(filehandle))
{
    do_stuff();
}
fclose(filehandle);


And handily, when we hit EOF (or some other error condition) the while loop exits, and we get to close the file handle and do whatever else we need to do. Normally, Spectrum BASIC does not allow this - you just end up fallling over with 8 End of file. However, Spectranet streams support now allows you to at least do this - using the %oneof (on end of file) command:
* 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.


  10 %fopen #4,"filename","r"
I hope to soon have details on how you can get your hands on one.
  20 %oneof 100
  30 INPUT #4;a$
  40 ...do something ...
  50 GO TO 30
100 %close #4


As a demonstrator and aid to testing it works as I meant it to, I wrote a small games menu program. It reads a list of games and their filenames from a file, then allows you to press a key to launch whichever game you choose (the game, of course, is in a .TAP file). This also brought up a few other issues...
[[User:Winston|Winston]] 21:39, 14 January 2012 (UTC)


The most significant is that when you %fopen (or %connect or %opendir or whatever) a stream is that some memory must be allocated to store the stub that makes a call into the Spectranet streams module to actually do the work. Memory management in the ZX ROM is fairly basic, to say the least - you can call MAKE-ROOM to make some space somewhere (for streams, just below the BASIC program itself in memory), and RECLAIM-1 to free that memory. However, I can't just call RECLAIM-1 whenever a stream gets closed without a great deal of shuffling stuff around - and the other complication is that if someone else has done a MAKE-ROOM, my code won't know about it. This means calling RECLAIM-1 automatically when a stream is closed something that may tread on someone else's code. So at the moment, the Spectranet streams module just keeps a note of what memory it has allocated, and tries to reuse it (for instance, if you open a stream and close it, RECLAIM-1 doesn't get called, but the streams module knows it allocated space for the stub, so the next time you open a stream, it just reuses this already allocated space for the new stub). Instead, if the programmer wants this room reclaimed by the ZX ROM, they explictly need to tell the streams module to do it. The programmer, after all, is the only person who will know if they did other non-Spectranet streams stuff there. Most of the time, the room will never need to be permanently reclaimed. But there are instances where it's essential.
== Perhaps production is sorted out.. ==


In the case of my games loader, if you don't actually reclaim the room - many games just won't load - they die with "M RAMTOP no good" when they try CLEAR xxxxx. So, when a game is selected in my BASIC game loader menu, the command:
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.


%reclaim
Watch this space...


is executed, which makes the streams module deallocate all memory from the original value of PROG to whatever the latest value of PROG was when it made the last call to MAKE-ROOM.
[[User:Winston|Winston]] 16:27, 16 January 2011 (GMT)


What's next? Probably a poll stream (in which you can do INKEY$# without actually reading off a character, which will tell the programmer which stream has stuff ready to read), and a control stream to allow other more complex things to be done with INPUT#. I also intend to make a video this weekend, showing what's been done so far.
== Argh! A hardware problem! ==


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


== Improving tape emulation ==
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).


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.
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 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).
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.


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).
[[User:Winston|Winston]] 22:01, 6 December 2010 (GMT)


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!
== The last 10% that takes 90% of the time ==


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.
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:


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).
# 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)


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.
A big item, though, will be writing a manual for the standard modules (BASIC extensions, etc).


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


== The Analogue World ==
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!


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...)
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)


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]] 19:34, 2 November 2010 (GMT)


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.
== Concentrate! ==


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'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:


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.
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).


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


== At long last, addressing +3 BASIC ==
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!


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.
[[User:Winston|Winston]] 21:39, 16 September 2010 (BST)


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.
== Argh ==


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.
[[Image:Redspectranet.jpg|thumb|right|300px|It took all day to get here, but the new Issue 1 board works and has been tested]]


This is how I'm going to do it.
Well, the solder paste stencilling decidedly failed to work as planned. Basically, a day of disasters.


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).
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.  


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.
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 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".
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.


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).
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]] 19:55, 17 September 2009 (BST)
[[User:Winston|Winston]] 20:40, 18 July 2010 (BST)


== The Spectranet world tour continues! ==
== Significant redesign ==


[[Image:Speccyandvax.jpg|right|thumb|400px|Spectranet setup at Retro Reunited, with the VAX fileserver]]
[[Image:128debug1.jpg|thumb|right|300px|BASIC streams fail on the 128K toastrack]]


First Oxford, then Bilbao, now Huddersfield!
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).


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!)
However, these plans were dashed.


Which brings me on to more recent developments.
[[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]]


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.
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.


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.
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.


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.
[[Image:128debug4.jpg|thumb|right|300px|Thurlby-Thandar LA4800 logic analyzer showing ZX bus activity]]


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


== RetroEuskal, and BASIC streams ==
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.


No updates for about a month, but I've been a bit busy!
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.


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...
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.


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).
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.


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


10 %connect #4, "some.computer.com", 2000
[[User:Winston|Winston]] 17:19, 4 July 2010 (BST)
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!
== ZXI ==


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.
(Edit: Corrected port numbers)


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


== A whole lot of new excitement ==
* 0x003B - Page A memory selector
* 0x013B - Page B memory selector
* 0x023B - Programmable trap register
* 0x033B - Control register


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!)
The Spectranet CPLD performs a full 16 bit decode.


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!
[[User:Winston|Winston]] 20:23, 27 June 2010 (BST)


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.
== The VCF, and gone off solder paste ==


Other than that, I've fixed a couple more bugs that I discovered in the base ROM.
[[Image:Stencil.jpg|thumb|right|300px|Spectranet solder paste stencil]]


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!)
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).


[[User:Winston|Winston]] 21:58, 7 July 2009 (BST)
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

Retrieved from "https://spectrum.alioth.net/doc/index.php?title=Current_events&oldid=378"