Difference between revisions of "Current events"

From Spectrum
Jump to navigation Jump to search
 
(52 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Manic Miner ==
== New Spectranet firmware ==


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


Manic Miner was loaded over the network!
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


After a long gap of not doing any work at all on the Spectranet (thanks to being away in Scotland for a week, then having too much other work to do, then supporting my Dad in the Pre-TT classic and then in the sidecar TT races (if you don't know, motorcycle racing - the Isle of Man TT is the world's biggest and best known road race, run on public roads)...well, not much has been done since the last time I updated this page.
How to update your firmware:


I've made up for it this weekend, with quite a lot of productive work done (although some of it frustrating), including:
%mount 0, "vexed4.alioth.net"
%load ""


* Finding a pretty serious bug in [[sendto]] which resulted in the source port getting set wrong and one byte of the MAC address getting overwritten, if a source port was set. (This may be the cause of the woes some have reported with DHCP)
Choose "A..Firmware check/Update".  
* Turning the prototype TNFS code into a VFS ROM module. All now called via the new VFS layer. Although the TNFS module is part of the default Spectranet ROM, it's actually just another ROM module, apart from having a couple of system variables for its own use in the sysvars area in 0x3F00, it's no different to a ROM module written by a 3rd party (and therefore can act as example code, too).
* Turning the prototype BASIC extensions code for filesystems, into something that calls the proper VFS calls (and therefore will work with any filesystem, not just the TNFS).
* Then turning the BASIC extensions into a ROM module.
* Fixing a serious bug in the module loader utility (the utility that loads new ROM modules over the network and flashes them into the ROM). This bug caused any module larger than 1K in size to get corrupted.


There's still quite a bit to do, but at least you can now turn the Speccy on, go into BASIC, mount a file system, and load and save files, list directories, change directory etc.
[[User:Winston|Winston]] 18:10, 19 January 2013 (UTC)


As a proper test, I loaded all the bits of Manic Miner (the BASIC loader, the SCREEN$ and the game code) via the tape port, then saved them over TNFS - modifying the BASIC loader to use %load instead of LOAD. So if I now %load "manic" - Manic Miner loads over the network. It's a very important milestone that the first real piece of Spectrum software has now been stored on a network file system and loaded back.
== ZX Breakout ==


There are now several layers involved. Closest to the user, are the BASIC extensions - %cat, %load, %mount etc. These parse the BASIC entered by the user, and in turn call the appropriate system call. For example, when saving a file, the BASIC interpreter sees the save command, gets the arguments to find out what's being saved - then calls open/write/close to save the file and returns to BASIC. In turn, the open/write/close system calls go via a dispatcher, which figure out what should actually receive these calls - which will depend on the mounted filesystem. Once handed off to the filesystem module, this then does whatever it needs to write the file - in our case, sending TNFS commands to the server to open, write, then close the file. The important thing here is that the dispatcher isolates the BASIC extensions from TNFS. Or any user program that uses the filesystem system calls from the actual underlying filesystem.
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]]


[[User:Winston|Winston]] 18:37, 7 June 2009 (BST)
A batch of boards is currently being made, and should be back with me this week or early next week.


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


As I said last time, the current job is to integrate what's been done on the network filesystem into ROM. But I want to do it "right", as in, not limit the implementation to my network filesystem.
[[User:Winston|Winston]] 22:16, 16 October 2012 (BST)


So I've started on the framework that will allow *any* filesystem to be plugged in. It doesn't even have to be a network filesystem - indeed, the example code for the upcoming tutorial won't be a network filesystem, it'll be something rather simpler.
== Failure rates, regenerating clocks ==


The VFS (virtual filesystem) layer consists of three sets of function calls, which are accessed by a jump table. The three groups are filesystem related functions - for example, mkdir, opendir, open, umount etc. Then the file descriptor level functions - read, write, seek, close, poll - then the directory related functions, readdir and closedir. Each one of these groups has some sort of "handle" associated with it, for the fS level functions, the filesystem mountpoint itself determines which ROM module gets the call. The file descriptor does the same for file level operations. Incidentally, the file descriptors are out of the same pool as are sockets - so if someone makes a filesystem with something that can be polled, you can poll everything for potential inputs without caring whether they are sockets, files, or whatever. Just like unix fcntl. Just like unix fcntl, you can then go and read() or write() to them without caring what they are, it's just a stream of bytes. (Of course, you can still take the shortcut of using send/recv on things you know are sockets, it'll save a few CPU cycles by not having to look in the file descriptor vector table).
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):


For the purposes of keeping things simple and reasonably fast, an FS module must be one (or more) ROM modules. The ROM module itself contains a valid address for a MOUNT function (which allows itself to be identified as a filesystem module), and a jump table to all the FS related functions. The entry points at 0x3Exx are used to get there - basically, the VFS entries are actually CALL instructions rather than JP, and the VFS dispatcher figures out what to look up in the module jump table by examining the return address (and removing it from the stack because you don't actually want to return to the jump table!). File/mount/directory handles, instead of having an address, just have a ROM number associated with them - this ROM is paged into paging area B, and the appropriate jump table entry is entered. All this once again proves how useful EX (SP), HL is. It's one of those things you use so infrequently you've forgotten about it, but it's so useful in instances like this :-) (Actually, I hadn't forgotten about it, it's a useful function for writing functions called by C code in asm).
5 duff flash ROMs (one died on a board I had been using for demos for some time)
2 duff static RAMs
1 duff W5100
1 duff CPLD


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


== Saving and loading over the net ==
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.


Saturday saw me save the first BASIC program over ethernet, and now you can load and save both BASIC and CODE files. There are still some details to implement (such as LINE for BASIC programs). As I said last time, I adopted the TAP format for the metadata parts of files that are loaded/saved with the normal %LOAD and %SAVE commands. (%ALOAD and %ASAVE save and load raw files with no metadata, which is often a useful thing to do). After saving a BASIC program and a SCREEN$ image, I validated that the files had been created correctly, by using Fuse to load them - as they are TAP files, well, an emulator just loads them via its normal tape traps.
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]


The TNFS stuff is still rather slow, some optimization needs to be done (such as when a block of data is being read by F_tnfs_read, it should be read directly into the memory that it's destined for - at the moment, it reads it into a buffer in Spectranet RAM, which then has to get copied one more time. However, it's not really a priority at the moment. But it means I've got enough to be going on with.
[[User:Winston|Winston]] 18:12, 29 September 2012 (BST)


The next thing I want to do is to integrate this with the ROM; currently all this code is just being run at address 32768 so it can't really realize its full potential.
== Spectrum30 ==


What I plan to do is implement a simple "VFS layer" (virtual filesystem), and then something that resembles "fcntl" in unix, such that you can plug in any kind of filesystem layer (whether that be TNFS, FTP, HTTP or whatever) - and code that uses the Spectranet functions for opening, reading, and writing gets directed to the right actual driver to move the data around. This will need a slight tweak to the existing socket code, so that each file descriptor has a vector table associated with it. For sockets, the vector table will only get used by using the generic read() and write() fcntl calls, given that send/recv only ever works with sockets, there should not be a performance impact on simple socket based netcode that uses send/recv rather than read/write. I may also need to shuffle some "secondary" functions out of ROM 0 to make room (I'm thinking of the 42 column print routine, given its data already lives in ROM 1). There needs to be enough room in ROM 0 to put the dispatcher routines for all the core network filesystem calls - i.e. open, close, read, write, opendir, closedir (etc).
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).


In other news I've been invited to talk about the Spectranet at [http://retroaccion.org/node/82 RetroEuskal] '09 in Bilbao. I hope my spoken Spanish gets a bit better by then - and I intend to bring a Spectranet and Spectrum with me! (I wonder how I'll get treated by airport security when they see a rubber key Speccy in the tray instead of a laptop...)
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).


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


== The BASIC loader, and some future plans ==
[[User:Winston|Winston]] 22:39, 19 September 2012 (BST)


Today I succeeded in loading the first BASIC program over TNFS.
== 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.


There was quite a bit of groundwork to be done to manage this - first, I had to understand how the ZX ROM sets everything up so that a BASIC program appears in the right place, with all the bits loaded. [ftp://ftp.worldofspectrum.org/pub/sinclair/books/CompleteSpectrumROMDisassemblyThe.txt "The Complete Spectrum ROM disassembly"] is extremely handy in this regard - since it explains in quite a bit of detail in the assembly comments how the various ROM routines work.
Also, you'll be able to play Spectank (see http://www.youtube.com/watch?v=6fEvuENABZY )


I also needed to decide how "ZX native" files should be formatted for loading. For the ALOAD command, this didn't matter, because this just loads whatever bytes happen to be in the file straight into memory completely unmolested. However, files specifically for the Spectrum need to have some metadata associated with them; normally this is contained in the tape header (or disc header, if you have some kind of disc, such as a floppy, or microdrive header, or whatever). Unlike a disc though, from the point of view of the Spectrum, a file is just a stream of bytes that is opened and read. The TNFS server sorts out how to actually find the file on disc (whatever that may be), so physical filesystem metadata is not needed. Eventually I came around to the idea of...why not just make the TNFS ZX header format a TAP file?
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.


This has a few good points that I can think of. Lots of things can generate a TAP file, and if when saving something from a Spectrum to the network filesystem, if it gets saved as a TAP file, then any emulator can load it, already extant tools can do things to it etc. The beauty of TAP is its simplicity, and that you can do things like just concatenate the files together. Further thoughts that I have is when a file is loaded, tape traps should be enabled, so if you %LOAD "somefile", and it's a BASIC program followed by machine code (as is the usual way for something on tape) it just loads it all unmolested - so you don't have to do anything to convert a TAP file for direct use on the network filesystem, and it all loads with a single %LOAD command. (This will require some smarts in the loader, for instance, to decide whether the file should be closed, it'll have to see if there's more to come. Once all bytes are loaded, then close the file).
[[User:Winston|Winston]] 00:04, 4 September 2012 (BST)


There's nothing stopping more headers being recognised, perhaps the raw format for a file on a ResiDOS volume, or TZX (where the standard ROM loader only is used for all parts of the TZX).
== The Raspberry Pi and the Spectranet ==


I've also been thinking about how to integrate TNFS into the ROM. Originally I had thought that the ROM would just have a bunch of very low level things - file descriptors not being common, for example - and letting the C library make it all look unified. But I'm starting to think that perhaps the Spectranet ROM should provide a sort of fcntlish like interface, so you can read/write any file descriptor without caring if it's a socket, a file or whatever. This has the advantage that it would be possible to, say, write an FTP ROM module whereby the TNFS BASIC commands work via the FTP module (or HTTP, or whatever) without needing to write new interpreter - the read or write operation would just find the real function to call via a vector table which any module could install. This way you could even use the Spectranet ROM to run a module to access a local filesystem, for example, a standard DivIDE interface, or a simple CF interface - the flash ROM and 128K RAM of the Spectranet could be used to enhance these other devices.
[[Image:Spectranet-and-pi.jpg|thumb|right|300px|Raspberry Pi nestles amongst Spectranets at Imperica Horizons]]


Still, I'm not going to worry about that until the basic TNFS implementation is complete and debugged (I'd rather not have to try and debug and develop both things at once!)
The Raspberry Pi promises to be a great companion to the venerable Spectrum when equipped with a Spectranet :-)


But after all this rambling, I feel like I've made an important milestone in loading a BASIC program successfully over the network, using commands just as a normal user would.
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.


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


== TNFS - Loading files ==
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.


I had hoped to get a great tranche of work done on the Spectranet software on the long weekend, but it was not to be. The entire weekend got eaten up doing maintenance work on various machines (not computers, machines of the oily petrol-burning variety, where you always skin your knuckles on something sharp when the socket driver slips).
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!)


However, I did get the first bit of data loaded via the BASIC commands. I implemented the simplest of the commands, the %ALOAD command (Abitrary LOAD), which works similar to LOAD "file" CODE, except it just loads whatever's on the filesystem rather than examining a header and deciding whether it's BASIC, CODE, an array etc., and where in memory to put the file. As such, an address after CODE is mandatory. Loading a couple of .SCR files downloaded from WOS showed it was working.
[[User:Winston|Winston]] 22:42, 3 July 2012 (BST)


However, I had lots of problems with timeouts, although I think a lot of this was due to it really actually timing out because the server on the PC didn't respond in a timely fashion (I could see this happening in Wireshark). However, I have the feeling that there may also be a bug in the poll routine in ROM, too - which would go some way to explaining the DHCP problems that people have experienced. I will implement the proper timeout/retry mechanism (with a longer timeout value)
== Emulating the Spectranet ==


I also did a little more research on the +3 reset problem. It's very interesting - the +3 resets fine if it's not crashed, but if it's crashed it won't reset. Doing CLEAR 24999 then RAND USR 25000 from BASIC (with no program at 25000) would crash the machine (usually with attributes scrolling up the screen after a few seconds). Trying to reset the machine while the attribute vomit was scrolling up the screen didn't result in a reset - as if the Z80 hadn't got the signal at all, although the screen got cleared. It'll take the logic analyzer to figure out what is actually going on when this happens, I think. But it's bizarre nonetheless - to the RESET circuit, a crashed +3 looks no different to a perfectly running +3. The reset problem only occurs also if the crash is causing things to be drawn on the screen (attributes or paper pixels). But resetting works fine if you do it while a game is running that's drawing to the screen. It is extremely bizarre, possibly a funny interaction with the ULA when there's sufficient load on the bus (the Spectranet will put a little extra stray capacitance on all the lines that it uses or are available to the through port). I'll have to try making the +3 crash this way with a different peripheral connected and see what happens.
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.


[[User:Winston|Winston]] 23:12, 14 April 2009 (BST)
To get the Fuse source, visit Sourceforge - [http://fuse-emulator.sourceforge.net/]


== Feedback: On reset ==
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]


Another bit of feedback I got was from Radastan, who said that the Spectranet wasn't initializing on many resets on his +3. I have observed it not initializing on power on (perhaps one time in three) on a +3, but it's always initialized on my +3 when the reset button was pressed.
[[User:Winston|Winston]] 10:42, 25 February 2012 (UTC)


I've not been able to do anything over the last month on account of being 4000 miles from the nearest Spectranet, so it's had to wait until now. And now I'm puzzled after looking at the schematic for the +3 - the reset circuit for this computer is bizarre. Most Z80 systems (including the rubber keyed 48k) have a simple resistor/capacitor on the reset pin, which functions just fine. At most, some reset circuits additionally buffer this (especially if the reset signal is used elsewhere), like I did with the Z80 single board computer I made a couple of years ago. The resistor/capacitor are sized such that the reset pin is held low for long enough for everything to be reset. As the capacitor charges, the voltage at the junction of the resistor and capacitor rises (this is what's connected to the Z80 RESET pin) until it goes above the TTL threshold, and then the CPU starts to run. The Spectrum+ reset switch simply shorts out the capacitor to restart this process.
== Delinquency ==


But the +3 has lots of extra components in its reset circuit. Not just a buffer, but extra resistors and capacitors, and I'm not sure why it's been designed that way. The principles are the same, but at first glance it looks like the Amstrad engineers made a mountain from a molehill - but it's entirely possible that I'm missing something.
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:


One thing I've tested is the voltages as seen by the buffer (Spectrum reset circuits are all very high impedance and the CPLD causes them to stop functioning unless it's buffered, hence there's a tiny little 1 gate buffer between the Spectrum's RESET output and the CPLD), and the CPLD itself. The voltage during reset on the CPLD RESET pin is 0.1 volts, well below the 0.8 volts max V(IL) for the chip. So it's not voltage levels. In any case, the latch in the CPLD that holds the reset state initializes as logic low anyway at power up, so even if the RESET signal got missed altogether, the latch state will be correct. Even if the Z80 started running before the CPLD was ready, the first thing the CPLD would do would be to grab ROMCS, so in that case there would be at least some weirdness, rather than a total failure to initialize.
* 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.


So at the moment I'm stumped.
I hope to soon have details on how you can get your hands on one.


[[User:Winston|Winston]] 23:37, 2 April 2009 (BST)
[[User:Winston|Winston]] 21:39, 14 January 2012 (UTC)


== At last, perhaps a server that works... ==
== Perhaps production is sorted out.. ==


After a few false starts at the data centre, the server on which the wiki and SVN is stored perhaps might actually stay up now! A long litany of bad hardware has persistently kept spectrum.alioth.net relegated to my ancient UltraSPARC system that lives in the closet. The return to proper hardware has been somewhat hampered by me being on the other side of the world for practically all of March.
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.


But now it's on its proper hardware, with real bandwidth rather than my ADSL upstream. It should be much faster.
Watch this space...


Also, I will make it so that those who have prototypes can commit to SVN this week. (I'm going to have to recreate everyone's accounts first).
[[User:Winston|Winston]] 16:27, 16 January 2011 (GMT)


WebSVN is also newer and shinier, and now tarball downloads are enabled from WebSVN, so you can grab a whole directory as a .tar.gz archive. (some Windows users may need to download something to unpack them, but I think later XP and Vista understands .tar.gz)
== Argh! A hardware problem! ==


[[User:Winston|Winston]] 22:40, 31 March 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.


== The BASIC interpreter ==
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).


I've got the skeleton of the TNFS library calls done; there's still a bit to do (testing the retry mechanism, adding a few more bits to the proof-of-concept Perl server that runs on the PC) - but files can be opened, closed, read from and written to. Directories can be opened, read and closed. Chdir is actually implemented client-side (all filenames go over the wire as an absolute path). There's a few things I think I will change, for example, I think I'll simplify the way timestamps are sent (to an ISO date/time rather than seconds since the epoch) when statting a file.
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.


But now I want to get the BASIC extensions done for this, and once that's done I might do another video for YouTube, perhaps demonstrating loading a game from the network filesystem or something like that. At the moment though I have a few things more that I need to learn about the ZX BASIC interpreter to get the most from it.
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.


Actually, I've not done all that much to the code for a couple of weeks, it's been very busy at work and I've just felt too frazzled to work on yet more code when I get home, so, errmmm... I've been playing Enemy Territory instead. But I have some time off, so I'll have some more time to think about things.
[[User:Winston|Winston]] 22:01, 6 December 2010 (GMT)


[[User:Winston|Winston]] 22:38, 26 February 2009 (UTC)
== The last 10% that takes 90% of the time ==


== Bug fixes ==
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 first 3rd party bug report is in, and it's fixed :-)
# 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)


Miguel Guerreiro discovered the NMI menu crashed on exit in USR 0 mode and also with his DivIDE firmware, and correctly guessed the cause was the ZX ROM paging being incorrect. Since the Spectranet ROM no longer accesses ZX BASIC for key scan routines, the calls to rearrange ZX ROM paging were now actually not needed in the NMI menu, so they've been taken out. If you have one of the prototypes, I suggest you get the new ROM image.
A big item, though, will be writing a manual for the standard modules (BASIC extensions, etc).


There is a new page off the main page of this site - [[Downloads]]. The first files available are the ethup tool and the current ROM images. Instructions on flashing new ROMs are included.
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.


[[User:Winston|Winston]] 22:19, 4 February 2009 (UTC)
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!


== The Tiny (Or Trivial) Network Filesystem ==
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)


As has been mentioned in the past, one of the things I want to have on the Spectranet is a network filesystem - basically something that's a bit better for filesystem use than FTP, but nothing so gnarly and complicated as NFS or SMB. Not everyone who wants a Spectranet will have mass storage for their Speccy, and having a network filesystem makes it easy to load files off another computer (which, in time, I hope to be things like another Spectrum).
[[User:Winston|Winston]] 19:34, 2 November 2010 (GMT)


First, I'm making the client on the Spectrum, and a proof-of-concept server written in Perl for the server. The client, as such, is a library of calls that correspond to the sort of things you find in 'fcntl', such as open, read, write, close etc. The idea is to provide an asm interface and a z88dk interface, just as in the socket library. For TNFS, I also want to provide BASIC keywords, and possibly at some stage, ResiDOS integration (so if you have something like a ZXCF, you would be able to load a ResiDOS module which adds support for TNFS via the Spectranet, allowing the Spectrum to be able to copy files from the network to a CF card. But that's a way off).
== Concentrate! ==


So far, I've started the basic functionality, and done "nominal" tests (i.e. not trying to break it) with the following calls:
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:


* mount - mount a remote filesystem
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).
* umount - Dismount the mounted filesystem
* opendir - Open a directory for reading
* readdir - Read a directory entry
* closedir - Close a directory
* open - Open a file
* read - Read from a file
* write - Write to a file
* close - Close a file


The open, read, write and close calls directly correspond to the same in C, i.e. are "system call level" rather than stdio. The z88dk, for instance, has those calls, and the z88dk stdio uses those low level calls to implement stdio.
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.


In other news, I'm probably going to get the "Issue 1" PCBs made very soon - I had hoped that I could have others do a bit of hardware testing before I committed to more PCBs, but the pound sterling is rapidly collapsing and the PCB maker charges in US dollars. Already this has significantly increased costs - I bought more W5100 chips just before Christmas in case the pound collapsed further, and unfortunately, it has. Reykjavík on Thames, indeed. If the Bank of England starts printing money as has been rumoured, even Euroskeptics are going to wish we were in the euro...
Next week I'm going to clear some time so I can at least do a few hours of Spectranet work and get the project pushed forwards a bit. R3PLAY in Blackpool and Retromañía in Zaragoza are coming up in November and I want a practically "production ready" board to be on show. It's been too long already!


[[User:Winston|Winston]] 18:04, 24 January 2009 (UTC)
[[User:Winston|Winston]] 21:39, 16 September 2010 (BST)


== Administratrivia ==
== Argh ==


A few notices. You may have already seen that the wiki and WebSVN have been unavailable pretty frequently recently. This is because the server this all runs on is dying of a suspected case of Capacitor Plague. Unfortunately, I don't have physical access to the machine.
[[Image:Redspectranet.jpg|thumb|right|300px|It took all day to get here, but the new Issue 1 board works and has been tested]]


So in the meantime, I've moved the site onto a computer at home. This means things may run a bit slow - firstly, it's having to share the pathetic 256K upstream you get with ADSL with all my other network traffic, and secondly, it's now practically running on a retrocomputer - the only spare hardware I have with sufficient memory is an old 333MHz UltraSPARC system (I don't want to run it on my PC, for one, I the fan in the new PSU on my PC is so loud I can hear it in the next room, which happens to be where I sleep). It could have been a lot worse, it could have ended up on the old VAX that I have, then you'd have had to have waited about 5 minutes for a page load!
Well, the solder paste stencilling decidedly failed to work as planned. Basically, a day of disasters.


The SVN repo isn't yet back up, but it will be shortly, so you may find some broken links in the wiki.
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.  


[[User:Winston|Winston]] 00:11, 14 January 2009 (UTC)
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.


== Through port success ==
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.


As I said last time, the NMI problem turned out to be a software bug. Gasman kindly let me use the Open ZX ROM keyboard routines under the MIT license from his GPLd OpenZX ROM project which saved me the effort of writing and debugging one. I wanted to use someone else's as it's likely to have already been debugged, and I need to start getting some of the prototypes out soon.
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.


So the board now works great with the ZX-CF plugged into the back of it, including the Spectranet NMI menu, so now my +3 has both access to a CF card and the network. I tested all the prototypes by loading the new ROM image off the CF card and programming them that way. This meant I had to cut slots in the through ports of all the PCBs, but the job's now done. (I only found out later that PCB Cart would cut the slots for me if I included them in the PCB outline).
[[User:Winston|Winston]] 20:40, 18 July 2010 (BST)


I think the combination of a ResiDOS device and the Spectranet could lead to some very good things.
== Significant redesign ==


[[User:Winston|Winston]] 19:46, 3 January 2009 (UTC)
[[Image:128debug1.jpg|thumb|right|300px|BASIC streams fail on the 128K toastrack]]


== Through port testing ==
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).


Happy new year!
However, these plans were dashed.


The first job of 2009 is to test the through port. The last time I did any testing was on the prototype-for-the-prototype (the breadboarded monstrosity that eventually got turned into the prototype PCB), with the DivIDE. Since then, I have got a ZX-CF board, which has ResiDOS, and as such is a bit more complex than the DivIDE.
[[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]]


So I had to cut a slot in a prototype PCB (something I need to do for the rest of the boards I've made). The DivIDE works pretty much perfectly, The ZX-CF is a little more awkward. It generally works fine, but its execution trap method seems to be very aggressive and it still traps NMI even when the Spectranet traps it...'''no, update,''' scratch that -- it's actually a bug in the NMI handler. Well, not a bug as such, but after looking at the logic in the CPLD and scratching my head a bit, I remembered that to save memory in ROM page 0, I had used the ZX ROM's keyboard handler...this of course, means a call out to the Spectrum ROM, and the return comes back in via RST 8. Oops. In light of this, I probably ought to put a key scanning routine into one of the Spectranet ROM pages so it's not necessary to call the ZX ROM. I ought to do that before tinkering with TNFS any more!
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.


I already expected the RST 8 trap on the Spectranet to need disabling, with ResiDOS running - only one board should be allowed to handle RST 8. But none of these are fatal problems. The Spectranet socket library can still be called with the ZX-CF plugged into the back of the Spectranet, due to the unique design of the library entry point instruction trapping. I tested this with the IRC client - I put Spectrum IRC onto a CF card, and loaded it with ResiDOS, then connected to IRC. All this means is with the ZX-CF at least, utility programs should be stored on the CF card and loaded with ResiDOS, rather than using the Spectranet NMI button. (It should be perfectly possible to write network aware ResiDOS modules, too).
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.


The RESET trap works fine too, with the ZX-CF, because that's pre-triggered by the reset signal itself, and as such A15 is already being held high when the CPU begins executing instructions.
[[Image:128debug4.jpg|thumb|right|300px|Thurlby-Thandar LA4800 logic analyzer showing ZX bus activity]]


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


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


Initially I was hampered by one of my 128K machines - what I didn't know is that another RAM chip was starting to go flaky on it (it has now failed completely, I have a spare but I've run out of desolder wick). The other 128K hampered me by blowing its TR4 again (and thus, you lose the display, since the TEA2000 no longer has a 12V supply). The other problem is the 128K's bus is rather marginal - it really doesn't take much extra loading on the bus to make a toastrack 128K stop functioning properly - and the logic analyzer has nice long ribbon cables, and that plus the bus breakout board plus the Spectranet was at times just too much, so the debugging lasted a lot longer than it should.
After doing a set of general captures to see that the Spectrum was behaving normally after the Spectranet ROM page out (it was), I set the trigger to trace the program that writes the channel stub to RAM (an earlier trace showed the Spectranet not even getting paged in on INPUT#). This showed the channel code getting written correctly (and showed me to what address, which depends on what the ZX ROM allocates for us). PEEKing that memory showed that the stub was loaded correctly. So now I could tell the logic analyzer to trigger on the address within the stub code where the CALL MODULECALL instruction lived. And there it was - the problem. The LA showed that when the call was made, the Spectranet wasn't paging in. There's some logic in the CPLD that decodes CALL instructions to 0x3FF8 to 0x3FFF, and it wasn't working.
The problem is this. The +3 which functions perfectly is electronically much better than the earlier Sinclair machines. It doesn't have a set of resistors as a bus multiplexer, it's done properly in the +3's ASIC. The +3 has a shorter bus with fewer chips on it, and less loading. The rise and fall times on the +3 is faster. However, the 128K machine has quite a long bus, with many chips on it, plus resistors between lower RAM and the CPU (so the ULA can read lower RAM at the same time as the Z80 writes/reads from upper RAM). There are many reasons for this, the +3 is a lot newer for a start so the cost for doing it the "nice way" had come down a lot. But the upshot is the timings are incredibly tight for the call trap to work on a machine other than a +3 or +2A/+2B, especially if the CALL instruction is in lower RAM.
The bad news is - it's essentially impossible to fix. The minimum time granularity I have in capturing the CALL instruction off the bus is half a T-state. If I read it half a T-state before MREQ+RD go high, this works fine on a +3, but it's unreliable on a 128K toastrack. If I read it when MREQ+RD go high, it doesn't work at all. ('''Edit''': thinking more about it, it could also be that the voltage levels aren't properly reaching either V(IL) or less likely, V(IH) for the CPLD) So with much regret - the CALL trap mechanism that has worked well with all my testing for the last couple of years will have to go. It's a shame because it meant programs didn't have to know what I/O port to use to cause the Spectranet to page in. Now I could instead trap execution at this range of addresses, but the reason I didn't is that some ROMs have code here (but none made a CALL to that address). Alternately, I could just list the ROMs that run code at these addresses as "incompatible" - I'll have to see what the various different ROMs put in this piece of RAM before I can really decide on it. ('''Edit:''' and indeed, this is what I've decided - I've changed it to an execution trap at 0x3FF8-0x3FFF, the devices I most care about don't use these addresses. No common ROM that will be paged while the Spectranet is plugged in uses these addresses, and so I won't have to change any software).
[[User:Winston|Winston]] 17:19, 4 July 2010 (BST)
== ZXI ==
(Edit: Corrected port numbers)
There's a very sensible proposal going around that all new peripherals use a certain port range to avoid clashing with older stuff (and with stuff that doesn't fully decode I/O addresses). The I/O address range is 0xhh3B, the lower eight bits are nominally for the ZX Printer (probably seldom, if ever going to be used with a newer peripheral, and an easily-made fixit board will serve if someone really does want to use a ZX Printer with a ZXI-compliant device). The upper half of the address bus is the actual port range, and we've got the full 256 ports. Two are already used by the ULA+, and now four are used by the Spectranet. The trouble is the Spectranet had a (fairly harmless, but potentially annoying in the future if a network+chip tune project were to be done) clash with the AY so I was going to have to change the port range anyway (it was 0x80E9, 0x80EB, 0x80ED etc). The new range is 0x003B to 0x033B inclusive. The relative order of the port assignment stays the same (and in any case the actual port is all abstracted away by the various Spectranet ROM library functions). The full list is now:
* 0x003B - Page A memory selector
* 0x013B - Page B memory selector
* 0x023B - Programmable trap register
* 0x033B - Control register
The Spectranet CPLD performs a full 16 bit decode.
[[User:Winston|Winston]] 20:23, 27 June 2010 (BST)
== The VCF, and gone off solder paste ==
[[Image:Stencil.jpg|thumb|right|300px|Spectranet solder paste stencil]]
Going from newest to oldest, first I thought I'd try and assemble one of the newly arrived PCBs with an also newly arrived solder paste stencil (see photo, that's a Kapton solder paste stencil for the Spectranet PCB). But I think my solder paste is now past its sell by date, it's gone rather hard and doesn't spread easily. Also the stencil lifted a bit and far too much paste went on... result, well, the workshop now stinks of isopropyl alcohol as I had to clean everything off again. So I'll get some more (probably a small pot of the stuff, rather than a syringe), plus a portable fridge to store it (the better solder paste needs to be kept cool, the stuff in the syringe I was using was fine if kept at room temperature, but this isn't true of all solder paste. Lots of people incidentally have complained that the Edsyn CR44 that I was using doesn't keep its shape as it's heated, it's probably a tradeoff you have to bear to get a solder paste that's happy being stored at room temperature).
Last weekend was the VCF, and this went really well - people loved the Twitter client, and I also fixed one of my toast rack machines to boot, which means I can now get on and fix the bugs that have surfaced on that machine (although I need to reassemble the workshop first, I've not had the chance yet). Indeed, the Spectranet took pride of place on the BBC News article about the VCF, and on the Register, too - BBC report here: http://news.bbc.co.uk/1/hi/technology/10364135.stm and the report at the Register is here: http://www.theregister.co.uk/2010/06/21/vintage_computer_fair/ . I also wrote about the VCF on World of Spectrum here: http://www.worldofspectrum.org/forums/showthread.php?t=30079


== Older News ==
== Older News ==


* [[Old news (Jan 10 - June 10)]]
* [[Old news (July 09 - Dec 09)]]
* [[Old news (Jan 09 - Jun 09)]]
* [[Old News (July 08 - Dec 08)]]
* [[Old News (July 08 - Dec 08)]]
* [[Old News (June 08 - July 08)]]
* [[Old News (June 08 - July 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"