Difference between revisions of "Current events"

From Spectrum
Jump to navigation Jump to search
 
(82 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Extending BASIC ... with C? ==
== New Spectranet firmware ==


Yes! It now can be done. If you've been following the development of the BASIC extension tutorial, you'll see that there's C code there. No, it's not theoretical, you really '''can''' write BASIC extensions in C with the Spectranet.
Spectranet firmware has been updated - the current version is labeled R544.


Actually, making a library to do it isn't all that hard, but strings do need some special handling as ZX BASIC does not use C strings. The strings are sequences of bytes as you might expect, but they aren't null terminated, instead the ROM's string handling functions return string lengths plus a pointer to the string. This is being handled in the C library by copying the string, null terminating it, and returning a length. (Copying only as much as the buffer, of course).
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


The next thing to do with C is to develop some guidelines for making ROMmable routines. Certain things in the z88dk expect the ZX ROM to be present (the print routines, for example, use the ROM's scrolling routine even if the character printing routines belong to the z88dk). This isn't a great deal, since C routines destined for ROM which need to do things like this can use the Spectranet's print42 routine (and I probably ought to make a library that lets stdout go there).
How to update your firmware:


[[User:Winston|Winston]] 22:02, 16 October 2008 (BST)
%mount 0, "vexed4.alioth.net"
%load ""


== Developers, developers, developers, developers! ==
Choose "A..Firmware check/Update".


OK, I think it's at a stage where someone else can also have a go at doing things with the Spectranet. You just know you need an interesting project for your own Spectrum as the dark days of winter approach...so...
[[User:Winston|Winston]] 18:10, 19 January 2013 (UTC)


What I am going to do is this. I've already posted in the WOS hardware forum, but I'm going to post this into the Development forum. I'm going to loan out (on a free loan, indefinite) 6 of the prototype boards to anyone who wants to develop for it. The deal is this - tell me what you want to develop, and if there's more than 6 developers chomping at the bit I'll have to choose the 6 ideas I like the most. You will need a real working Spectrum (48K, 128K or one of the Amstrad models) since the Spectranet is not emulated. You don't need any sort of mass storage for the Speccy - already there's a method to send data to the Spectrum from another machine over ethernet, accessable on the NMI menu.
== ZX Breakout ==


This isn't a competition or anything like that for some fancy or uber-imaginative networked program for the Spectrum. Examples of some things that are fine ideas are:
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]]


* An FTP client, perhaps with the ability to run a .SNA or use tape traps to load a .TAP file off the network.
A batch of boards is currently being made, and should be back with me this week or early next week.
* A *good* IRC client, perhaps improving the rinkety-dink one I've written as a test, or perhaps something completely new
* A networked strategy game.
* A simple web browser
* A news ticker and/or weather display. (Perhaps that's a good one for demo writers - there's lots of scope for making a novel way of displaying the current weather which can make the most of the Speccy's hardware)


Pretty much anything that needs the network qualifies. (I wonder if anyone can squeeze enough performance out of the Z80 for an SSH client!)
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.


At the moment if you want to join in with development you'll have to do it in C (with the Z88DK) or in assembly language - channels/streams support is something I've got planned but it won't be there for a while. If you want a feel for the Spectranet's API (which, for the net code is a subset of the BSD socket library) you can take a look at the [[Software]] page. To contact me you can do so via the WOS forums or to my email address 'dyls (at) alioth (punto) net' (please put 'Spectranet' in the subject). Hopefully by the end of this month, there will be a few willing developers who want to hack at this thing.
[[User:Winston|Winston]] 22:16, 16 October 2012 (BST)


[[User:Winston|Winston]] 15:50, 4 October 2008 (BST)
== Failure rates, regenerating clocks ==


== The last 10% ==
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):


As usual, the last 10% is taking 90% of the time (and it doesn't help that I'm overloaded with projects at the moment). But it is getting closer, I promise!
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 need to do some tidying up (hopefully this weekend) in the code - for instance, the socket library should save and restore the memory that's paged into area A, otherwise this paging area isn't very useful as a place to put code. The library also ought to make an attempt to allow data in this area to be transferred, hiding the fact that the ethernet buffers are memory mapped from the programmer as much as possible. I've thought of a way of swapping paging area B to do this, although this obviously has an issue if the buffer crosses the boundary between paging area A and B.
I thought originally there were 9 duff flash ROMs, but one board turned out to be in my rework box by mistake (there was absolutely nothing wrong with it), one turned out to be a very small solder bridge on the CPLD shorting the chip select pin that was going to the flash and the other two actually turned out to be the RAM that was duff. Fortunately, this means I don't have to change the PCB footprint for the flash chip - I did think this was causing poor solderability but apparently not. I don't like making changes to a proven design if I don't have to.


I've also been doing quite a bit of documentation recently (as you will have seen if you follow 'Recent Changes') including things like a nice memory map diagram. Some more must be done, though - for instance, documenting how to extend BASIC (fairly low priority at the moment) and how to write a ROM module (much higher priority).
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.


What I want to do next is get the socket library paging sorted out, then once that's done, I think it's in a fit state for someone else to try and write some programs for it too. So continue to watch this space. I would like to make an announcement on the availability of development boards at the end of September if possible, since the long dark winter nights are coming and perhaps people will be looking for a new project for their beloved rubbery friend!
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]


[[User:Winston|Winston]] 21:00, 11 September 2008 (BST)
[[User:Winston|Winston]] 18:12, 29 September 2012 (BST)


== Getting ready for the Steve Ballmer Monkey Dance ==
== Spectrum30 ==


It's time to get ready and do a Ballmer impression: "Developers...developers...developers...developers..." - you've probably seen the video. But soon, that's what the Spectranet will need.
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's mainly an issue of documentation: so that people who fancy doing development know where to start, I need to get a basic user guide out for the development boards (things like 'what does jumper J1 do', and 'how do I set the IP address', and "how do I flash a new ROM" etc.) Also the tutorials - I need the tutorials and basic socket library API documented so that people who are otherwise great Spectrum developers, but who've not done much with netcode, know where to start. You'll note if you look at 'Recent Changes' on the wiki I've been doing some of this over the weekend (including a minor re-org of the front page).
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).


It's my intention to do the following, once I feel I can release some boards for development. The deal is this: I'll make a permanent, free loan of a prototype board to anyone who's interested in developing something. If the developer can't continue for whatever reason, then they just pass the board onto the next person. The requirements for the developer who wants to take advantage of the free loan is to have something they want to develop, and also have a real Spectrum to hand - no emulators emulate this board yet, so a developer must have a real, serviceable Spectrum to hand. (What reduces the pain is that even now, before I've even developed the network filesystem, you CAN load programs over ethernet, making it fast and easy to test your code on the real machine). If demand outstrips supply, I'll choose whatever I consider the most interesting projects are. Hopefully, I'll have at least half a dozen boards I can lend to people (5 currently exist, and I hope to make a couple more soon). I'll be making an announcement on the World of Spectrum forums (and here, of course) when I get to that point. But it should be pretty soon.
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.


[[User:Winston|Winston]] 20:50, 17 August 2008 (BST)
[[User:Winston|Winston]] 22:39, 19 September 2012 (BST)


== BASIC extended ==
== 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.


I've put the infrastructure in place for BASIC extensions in the ROM this weekend.
Also, you'll be able to play Spectank (see http://www.youtube.com/watch?v=6fEvuENABZY )


By default, BASIC is not extended. The code in the fixed ROM page (page 0, mapped to 0x0000-0x0FFF) contains the functions required to handle RST 8 traps, interpret new commands, and dispatch them to the routine that carries out the actions - but unless some other ROM module (or code in RAM for that matter) adds a command to interpret, it simply returns control back to the Spectrum's RST 8 routine. To make it easy to extend BASIC, all a programmer needs to do is pass a 6 byte structure to the ADDBASICEXT routine. The structure contains the error code the extension responds to, a pointer to the string that makes up the command keyword, the ROM page (if required), and the address to call to handle the new command. When RST 8 is trapped, the code in the main ROM goes through this table to see if a new command is to be invoked. If it finds one, it pages the required memory page (if specified) and then calls the address in the table.
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.


The purpose of the extensions is to allow for things such as a network file system. Not everyone will have mass storage, and the Spectranet is expected to do something useful as a stand alone expansion. If you look at the [[Spectranet]] article here, you'll see one of my goals is to provide a simple network filesystem.
[[User:Winston|Winston]] 00:04, 4 September 2012 (BST)


At this point it's worth introducing how the Spectranet is expanded. There's 128K of flash ROM, of which only 16K is reserved for system usage - the rest can be used by other developers to provide ROM modules. Using the ADDBASICEXT routine, these can now also provide extra commands. Each 4K page of ROM can have a vector table associated with it, allowing things such as power-on/reset time initialization etc. The core Spectranet modules will also use this mechanism - although they might live in the reserved area of the flash memory, they don't behave much differently.
== The Raspberry Pi and the Spectranet ==


The fixed 4K ROM area is now almost filled - with the BASIC extension infrastructure in place there's only a couple of hundred bytes left for code...so I'll have to use these wisely.
[[Image:Spectranet-and-pi.jpg|thumb|right|300px|Raspberry Pi nestles amongst Spectranets at Imperica Horizons]]


The next bit to look at is channels and streams so that networked programs can be written in BASIC. A channel in the context of the BASIC ROM is a device that's expected to always be there, so channels don't really match what sockets do, so there will have to be a little trickery involved. My ideas so far are to create a channel on boot and open a stream to it right then - Andrew Owen suggested channel 15 would be best for this. This would form the control channel. BASIC programs would be able to open and close sockets by sending data to stream #15, which would be a pipe to a small parser that would interpret the data that was sent. The Spectranet ROM code would then handle creating a channel that connected to a socket, then opening a stream attached to this channel. This way, RST 8 traps wouldn't be needed to handle channels/streams at all - all that would be needed is a lightweight wrapper in RAM that dispatches the calls to the right bit of ROM via the CALL 0x3FF8+ entry points. Avoiding RST 8 traps for basic functionality such as this ensures that something useful can be done in case another board traps RST 8 - only one peripheral can be an RST 8 trapper at any one time!
The Raspberry Pi promises to be a great companion to the venerable Spectrum when equipped with a Spectranet :-)


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


== Starting on the last bits of the ROM ==
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.


There's one last piece of base ROM infrastructure that I think needs to be in place before I hand out prototypes as 'developer boards' - the RST 8 trap.
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 a go at this thorny issue quite a while ago, and got frustrated with it. I'm not familiar enough with the Spectrum ROM is the main stumbling block. Things are a bit easier now, though - Garry Lancaster gave me some information that makes things a bit clearer, and I've re-read the IF1 ROM disassembly a few more timss.
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!)


What I've done is to put a bit of code into the RST 8 routine to call code anywhere in memory, so I can load experimental code into RAM (over the network, naturally!) rather than flashing the ROM each time I want to try something new. So far, basically, my experimental code (which runs from RAM) is mostly what the IF1 ROM does. Error handling now works - after a minor struggle, but by looking at Garry's notes and fiddling with the code, eventually it seemed to work OK. I have two problems though: for a while, I had successfully parsed commands working OK - but now they've stopped (it hangs on return). Also, successful parsing crashes +3 BASIC hard, even though error handling works - so exiting back to the Spectrum ROM obviously needs to be handled a bit differently on the +3. I suspect there's a problem with which ROMs are paged in. I've been unable to test on a 128K+ (toast rack) because mine's broken at the moment and I've not found a schematic for the machine (the 128K service manual at WOS only has schematics for 48K machines!)
[[User:Winston|Winston]] 22:42, 3 July 2012 (BST)


What I ultimately want to do is draw up a fairly detailed spec on how RST 8 should be handled, and then write it from scratch to avoid infringing Amstrad's copyright on the IF1 ROM. This requires me to get a pretty thorough understanding of what is actually going on.
== Emulating the Spectranet ==


Also, discussions on the WOS forum about the need for RST 8 trapping at all have occurred. To summarize: Andrew Owen says that all basic network functions (i.e sockets) can be done using channels and streams - so why have RST 8 traps at all? Andrew has made a convincing argument that the socket library can be implemented in BASIC this way. However, I think RST 8 traps are still needed for "application" functionality - for example, extra commands for a network filesystem, or to launch an FTP client etc. So I think the infrastructure should be there and working in the core ROM. I strongly agree with Andrew on using channels and streams for the socket library - it's simply the proper way to do it and it will avoid complications with other peripherals if accessing the socket library from BASIC does not need to use RST 8. I will have to see if he wants to write that code now. Perhaps I can bribe him with a free prototype board :-)
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.


Aside from that, I am going to see if I can fit in a software enable/disable bit for RST 8 trapping into the CPLD - I meant to have one all along, but it got forgotten somewhere along the way. It might not fit though!
To get the Fuse source, visit Sourceforge - [http://fuse-emulator.sourceforge.net/]


[[User:Winston|Winston]] 20:31, 17 July 2008 (BST)
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]


== The last tweaks ==
[[User:Winston|Winston]] 10:42, 25 February 2012 (UTC)


After the previous session of butting heads with the CPLD, I decided to see what logic could be cleaned up. This resulted in the removal of the 0x0000 trap - since it's conditional on reset being pressed (or the power up reset), it's not needed - the trap can be done just on reset instead. This freed up enough room in the CPLD for complete 16 bit I/O port decoding.
== Delinquency ==


I did think I was going to have to sacrifice the RETN decode for this because things are so tight, but fortunately this turned out not to be the case (the RETN decoder could be replaced by a bit of logic to unlatch the NMI condition latch off the status/control register - and requiring the programmer to read the status/control register, reset the NMI condition latch bit and then write it out again, but decoding RETN is a much more elegant way to do this).
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:


Incidentally, the programmable trap is now documented here: [[Trapping execution]]
* 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.


[[User:Winston|Winston]] 10:04, 7 July 2008 (BST)
I hope to soon have details on how you can get your hands on one.


== Final hardware features, and some documentation ==
[[User:Winston|Winston]] 21:39, 14 January 2012 (UTC)


Updates haven't been so thick and fast the last couple of weeks, because I've taken a little time off the project. I find if I use all my spare time on a project ad infinitum, I end up getting burned out on it, so I need to take a break every so often and do other stuff.
== Perhaps production is sorted out.. ==


However, this is good time for reflection. One piece of reflection was 'what to do for the last execution trap'. To recap, one function of the CPLD is to intercept CPU instruction fetches at certain addresses, and page in the Spectranet memory. It does this, for example, if RESET is detected (the reset button or power up), and the CPU executing code at memory location 0x0000. This is so the Spectranet can do its initialization. Similarly, there's a trap for 0x0066 (NMI), 0x0008 (RST 8 - so new BASIC commands can be added). There's also a trap at 0x007C which does the reverse - unpages the Spectranet memory, so the Spectrum's current main ROM gets paged back in. Having some time to reflect about the last trap address to implement - I decided, wouldn't it be a lot better if it wasn't fixed, and the programmer could set it? After all, simplifying the memory pager freed up an I/O address that could be used to program the trap address...
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.


After some thought, I decided the best way to implement it was instead of controlling paging, this trap instead fires an NMI. This means you can trap '''any''' address - execution in ROM or RAM - it doesn't matter! This is because firing an NMI won't depend on the program counter being in the lower 16K, the only place Spectranet memory can be paged. By firing an NMI, even if the trap address is in RAM, it doesn't matter - because the CPU will set PC to 0x0066, and the fixed NMI trap can take care of the paging. This gives the greatest degree of flexibility.
Watch this space...


So how do you tell if the NMI was caused by someone pressing the button, or by an execution trap? Simple - examine the return address, which will be the first thing on the stack. If it's set to the next instruction after your trap, it was your programmable trap that caused the NMI. Anything else, and someone pressed the NMI button. Ah! But there's a finite chance that someone could press the button just at the moment the trap would occur, you may cry. Well, in that case - who cares - the NMI would have fired anyway, and it effectively just means that code traps have a higher priority than the NMI button.
[[User:Winston|Winston]] 16:27, 16 January 2011 (GMT)


Implementing this did cause a bit of a headache, though - I ran out of CPLD resources. Strangely, not macrocells, product terms or function block inputs - but it got into a state where essentially (as I understand it) the software can't route the logic network. So I told the fitter to make exhaustive attempts at fitting it into the device... which resulted me playing a lot of 'Elite' on the BBC Micro while waiting for it to churn. It still didn't fit.
== Argh! A hardware problem! ==


Sacrifices therefore had to be made.  
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.


I had another trap set up for 0x0038, the maskable interrupt, together with some conditional logic. This trap would only be entered if the W5100 had asserted the INT line (which isn't directly connected to the Spectrum's Z80 - it goes through the CPLD first so to be gated) and the programmer had set the INT_ENABLE flip flop in the CPLD. However, the maskable interrupt trap has turned out to be rather less needed than I originally thought, when I started on the project - it's not been used. The trap was provided as an easy way to tell the difference between a W5100 interrupt and the 50Hz ULA interrupt, however, if someone wants to do interrupt driven things, they can do an IM2 routine and check the state of the W5100's interrupt register. The 0x0038 trap wouldn't save much - and it certainly wouldn't be anywhere near as useful as a programmable trap that could be set for any memory address.
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).


Even with the 0x0038 trap and its associated I/O pins gone, the fitter still can't fit the design into the CPLD using the default settings - it has to have a few tries before it comes up with a configuration that fits. Unfortunately, there is one CPLD function that's still needed - complete 16 bit port decoding...hopefully that can be shoehorned in (currently, only the lower half of the address bus is decoded for I/O). So no more new hardware features, without using an XC95144. (I could make it really fancy with an 95144).
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.


The new programmable trap is programmed very easily:
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.


* Send the LSB of the address to trap to port 0x80ED (note this port number is going to change)
[[User:Winston|Winston]] 22:01, 6 December 2010 (GMT)
* Send the MSB of the address to trap to port 0x80ED (the same port)
* Enable programmable traps by setting bit 4 of the control register (0x80EF)


Other than this, if you've been watching 'Recent Changes' (note you can get an RSS feed for this) you may have seen some tutorial pages coming together. Before I can start handing out prototypes to people who want to develop, I need enough documentation available that people can easily get up to speed with doing things with the hardware. So far, I've done an overview tutorial, plus two practical tutorials - how to make a simple TCP based server and client.
== The last 10% that takes 90% of the time ==


I also built the fifth board, which went pretty smoothly - I got much better at using the right amount of solder paste.
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:


[[User:Winston|Winston]] 19:25, 5 July 2008 (BST)
# 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)


== Number 4 - The Problem Child ==
A big item, though, will be writing a manual for the standard modules (BASIC extensions, etc).


I just assembled the fourth prototype board, and it's been The Problem Child. It was the first assembled 'all in one go', and it didn't really go very well.
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.


First, the flash got misaligned on its pads (so the whole chip was slightly lower than it should have been on the board, and missed its pads, so pin 1 was on pad 2 and so on, with pin 16 sitting on solder mask). So that had to be hot air'd off, cleaned up, and resoldered. I think this was probably the root of many problems - that area of the board went through three reheats and I think it unsoldered a couple of pins on the CPLD (they were on the flash side of the board), and also the flash still didn't solder well - there was one pin that was not making contact. Testing all the pins to find the bad contact is slow and laborious - I spent longer hunting for bad solder joints than I did assembling it in the first place.
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!


Then there was a bad joint on the RD pin of the W5100, although I didn't think that would be the case (I tested pretty much everything before trying the RD pin, because a software readback showed what was written - correctly!) Looking at it closely with a magnifying glass it's also very slightly misaligned, which didn't cause any problems till I resoldered the offending pin, which then formed a short with its neighbour (the RESET pin), and I couldn't clear the short until I stuck the point of a needle between the pins to force them apart.
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)


It took about an hour to put the paste on, and set the components in place, then put hot air on it to solder. It took four hours to actually get it working.
[[User:Winston|Winston]] 19:34, 2 November 2010 (GMT)


But it works now. Oh for a pick and place machine.
== Concentrate! ==


[[User:Winston|Winston]] 22:05, 21 June 2008 (BST)
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:


== Paging Mr. Memory ==
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).


In rearranging some of the ROM code (mainly, moving data out from flash page 0 and putting it in page 1 instead, to free up more space for code), it was also time to complete some memory management routines - a method to do calls to other pages ('sideways calls' as such), and also do things like push the last page on the stack, so it can be restored at the end of a routine. For example, the 42-col print routine needs to restore the page that was in page A after it gets done using the character set data.
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.


As I alluded to last time, I also wanted to make some hardware changes to the paging mechanism, which was a bit clumsy (two 8 bit page registers, one for each paging area, and a chip select register, giving a potential memory of 4MB - which is overkill. I initially did it that way on the breadboard because I'd not decided what memory I was going to put on the eventual PCB back when I started prototyping the project). However, the memory is settled, and having two registers that need to be set (one shared between the two paging areas) was clumsy, and a bit wasteful of CPU cycles. I had planned to rationalize it a while ago to just have a single 8 bit paging register for each area, using the upper two bits as the chip select, giving a maximum of 1MB of address space. Since the W5100 has 32K of buffer memory, the static ram is 128K and the flash is also 128K, this is more than adequate.
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!


Since it was going to be extremely clumsy writing the pushpage/poppage/sideways call routines with the old paging scheme, I thought that there was no time like the present to migrate to the final scheme. It went pretty painlessly - I changed all the areas of the ROM code where paging was done to use the new scheme (basically, selecting the page by passing it as a single 8 bit value in A, instead of in register pair HL) - flashed the ROM (over ethernet naturally), reconfigured the CPLD with the new logic, then reset. The hardware worked, but I'd failed to change the ROM initialization code properly in one place so it failed to run the DHCP client on startup. This was an easy fix, and with the aid of a new version of the standalone flash-over-ethernet program (sent to the +3 via the tape port, and saved to floppy), I flashed a revised ROM - and hey, everything worked.
[[User:Winston|Winston]] 21:39, 16 September 2010 (BST)


In other hardware news, I sent a Farnell order off at the start of the week and restocked a few components which I was running short of (such as 0.1uF capacitors which I use a '''lot''' of - and the 18pF capacitors I ran out of) so this weekend I'll probably assemble a couple more boards. After that I'll get the ROM into a state that I feel that people can at least develop with, and cast around for interested parties who would like to play with the board.
== Argh ==


[[User:Winston|Winston]] 20:57, 18 June 2008 (BST)
[[Image:Redspectranet.jpg|thumb|right|300px|It took all day to get here, but the new Issue 1 board works and has been tested]]


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


The third Spectranet board is up and running.
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.  


The object of this build: build more of the board at once, and see if hot air soldering of the tiny 0603 sized parts was practical.
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.


So armed with a syringe of Edsyn CR44 solder paste and my trusty B&Q hot air gun, I went to work. This board was to be assembled in two stages rather than three - the first stage, solder the CPLD, flash, RAM, reset buffer, ROMCS transistors and all the associated passives (resistors and capacitors) in one go - then program the CPLD and test the memory, then add the W5100, its 74HCT245 buffer, and all the discrete components associated with that end of the board.
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.


I was gratified that the 0603 parts didn't blow away - the solder paste seemed to have enough stiction to keep them in place. Interestingly, when the solder paste began to turn into solder, the components would all automatically centre up on their pads (except for one, which 'tombstoned' - i.e. it sat up on its end, which I corrected by pushing it over with tweezers while still having the hot air on it). One or two components had far too much solder paste which needed mopping up with braid, and of course the inevitable odd bridge on the fine pitch SMD stuff. Visual inspection after mopping up any excess showed the joints all looking good, so I added the edge connector and plugged in, programmed the CPLD and tested the memory - everything checked out OK.
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.


Next was the W5100 and buffer and all the discrete components surrounding those. They all went on trouble free, except some of the capacitors which are lined up (the three bypass capacitors near the 3.3v analogue pin on the W5100, and the pairs of 0.1uF capacitors on the 3.3v digital pins) tended to slide towards each other and stick together. This is only a cosmetic issue since they are all supposed to be in parallel, so I didn't worry too much about it - the main thing is there's a good solder joint. (The way to stop that happening would be to space the components out a little more so there's solder mask between them, or try to use less solder paste).
[[User:Winston|Winston]] 20:40, 18 July 2010 (BST)


The next board will be made all at once, since I'm getting the process down. I think the board I just did was about 2 hours work, and I"d like to get this down a bit (probably the best way will be to have a solder paste stencil made up, since putting all those dobs of paste on each pad takes some time). Unfortunately, it won't be made right away because in an ordering blunder, I forgot to restock with 18pF capacitors and I discovered I had used the last two making this board.
== Significant redesign ==


So it's back to software next week - I still have quite a few things I need to do to the core ROM code before development versions of the board can be made available, and I also want to change the memory paging scheme... but with continuing hardware successes, it won't be long now!
[[Image:128debug1.jpg|thumb|right|300px|BASIC streams fail on the 128K toastrack]]


[[User:Winston|Winston]] 23:25, 14 June 2008 (BST)
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).


== Making contact with real people ==
However, these plans were dashed.


[[Image:Zxirc.jpg|thumb|right|300px|ZX-IRC - an IRC client for the Spectrum]]
[[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]]


Another small milestone: my Spectrum +3 has made first contact with other live people over the internet. As alluded to last time, one of the example programs that will be available for people to use and developers to tinker with is an IRC client. So, ZX-IRC was born. It's only minimally functional at present - you can join channels, talk to people, quit etc. (and to amuse the administrators of SynIRC, who automatically do a CTCP VERSION request when you connect, it responds to a CTCP VERSION). I don't want to get too bogged down with it, so I'll just add a few more minor features (handle some more messages that ought to be handled, give it a proper keyboard buffer because if a message comes in when you're typing it can drop a keystroke etc.) Unfortunately, the version of z88dk that I have doesn't have an snprintf() function - but I did import OpenBSD's strlcat/strlcpy functions for safer handling of arbitrary strings arriving from the IRC server. Unfortunately, no snprintf means some of the code is a bit cluttered with lists of strlcpy/strlcat calls to build strings - but better that than having some unexpectedly long string overwriting the IM2 vector table!
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.


The next job is to make more hardware.
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.


[[User:Winston|Winston]] 21:48, 12 June 2008 (BST)
[[Image:128debug4.jpg|thumb|right|300px|Thurlby-Thandar LA4800 logic analyzer showing ZX bus activity]]


== The Second Spectranet ==
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.


A key part arrived last week - a reel of solder wick (amongst a bag of other stuff from Farnell). This is a vital part of home surface mount assembly.
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.


I got busy completing the second Spectranet. Again, I did this fairly cautiously - a bit at a time - first, just having a board with the CPLD and 3.3v power circuits, configuring the CPLD, then putting the memory on, and testing the memory, and then the W5100 and its associated parts. This time, I used hot air and solder paste for all the ICs including the static RAM and the buffer for the W5100 (both of which I manually soldered last time), which was far faster, tidier, and easier. I've also got more confidence that visual inspection is enough to tell that the board can be plugged into a Spectrum. I still tested every pin on the memory after assembly for shorts and opens after doing a close inspection with the magnifying glass. I think I can spot any short and most opens now.
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.


My plan is to build the third board by putting the CPLD, memory and associated discrete components on all at once - I think the solder paste will stop the little 0603 parts from blowing away (and when it melts, the surface tension will keep things in place), test this, then do the W5100 end of the board. If that all goes well, and visual inspection is sufficient to see any possible problems, then the fourth board will be done all at once.
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 real time sinks at the moment with building the boards is:
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.


* testing for continuity/shorts manually
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).
* picking and placing the passives


As I've already said, I think the first can be eliminated by visual inspection then software testing on an actual Spectrum. The second can be sped up with a sort of 'production line' approach - lining up the tapes of discrete components in order and doing one set at a time.
[[User:Winston|Winston]] 17:19, 4 July 2010 (BST)


On the software side, I know there are some code improvements that need to be made to the C library, and I also need to test the C library using caller function call conventions (all functions are callee convention by default, this is where the function itself cleans up the stack, rather than the code that calls it, which saves quite a bit of space).
== ZXI ==


I also decided the 'major' example program for the Spectranet will be a basic IRC client. I decided on an IRC client because it's something people can use straight away, the protocol isn't complex, and it shows the multiplexing of user input and receiving data from the network. I'm only going to write the very barebones of it (for now), just enough to get on a server and chat, probably nothing like DCC for the moment. This has also let me explore a bit more of the Z88DK, for instance, using the Z88DK's IM2 support for handling the keyboard (which I did today). It's also some code that others can extend if they wish and turn into a fully featured client. Also, the IRC input and screen handling routines can be re-used for other similar types of program, such as a MUD client, or even something like AIM.
(Edit: Corrected port numbers)


But the aim of all of this is to have hopefully half a dozen development boards available for others to get their hands on by the end of the month, in a state that's immediately useful.
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:


[[User:Winston|Winston]] 23:02, 8 June 2008 (BST)
* 0x003B - Page A memory selector
* 0x013B - Page B memory selector
* 0x023B - Programmable trap register
* 0x033B - Control register


== Configuration ==
The Spectranet CPLD performs a full 16 bit decode.


[[Image:Config.jpg|thumb|right|300px|The configuration screen]]
[[User:Winston|Winston]] 20:23, 27 June 2010 (BST)


While it's all fine and dandy to have a working C library, you've also got to be able to configure the Spectranet to get on the network in the first place!
== The VCF, and gone off solder paste ==


For all my testing, my ethernet uploader program (on the Spectrum) has been just dumping in some static configuration settings into the hardware. Now the hardware can be configured properly. Part of this was writing a user interface (a simple menu based one) to allow the user to enter the usual settings - whether or not to use DHCP, and if not using DHCP, the IP address, netmask, gateway, DNS servers etc. Configuration is stored in the last 256 bytes of the 128k flash chip (page 0x1F). The configuration program therefore can't run from ROM, because trying to execute code from the ROM you're writing to doesn't work, because the CPU fetching instructions will cause the unlock sequence for the flash chip to no longer be the unlock sequence. Therefore, the configuration program must run from RAM. To do development testing, I've just been loading it at address 32768, but once fully integrated it'll be temporarily stored in the Spectranet's fixed workspace page at 0x3000.
[[Image:Stencil.jpg|thumb|right|300px|Spectranet solder paste stencil]]


Incidentally, '''all''' code that accesses main ROM functions, including standard Spectranet ROM code that's not in the main ROM (0x0000-0x0FFF) does so via the indirect call table. This has several useful properties: code doesn't have to be reassembled if the main ROM gets changed (thus changing call addresses), and most of the code will work unchanged with entirely different ethernet hardware, since it never directly accesses hardware, and all it knows about is a set of public function calls. The configuration utility is no different in that respect. The DHCP client also uses the call table. The only higher level code that doesn't is the resolver code for gethosbyname(), but that's because it's part of the main ROM.
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).


When it comes to coding, one thing I find really tedious is writing user interface code (and the most tedious UI coding of all is writing PHP/CGI/ASP scripts for web sites, especially if someone mentions AJAX, but that's a rant for another day). So the configuration UI is simple and functional. At its core is a table based menu generator, which is a table of pointers for menu strings and function call addresses to handle the menu selection. A similar approach is used to display the current configuration settings - a table of pointers to strings, and a table of pointers to the memory that contains the actual configuration option. Doing it this way is more flexible (and I can re-use the menu generator for things like the NMI menu) and a great deal less tedious than writing a bunch of repeating asm code to display various options.
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
 
Flash memory is sort of like EPROM, except to re-write it you don't need to shine UV light at at - instead, you give it an erase command. Writing to flash, the only operation you can do is change a bit set at 1 to 0, and not the other way around. The erase operation essentially sets the sector back to all bits set to 1. The flash chip, incidentally, doesn't care if a byte has been written to before - if, for example, you write the value 10101010 to a byte, you can write it again - to 01010101, without needing to erase. The type of flash I'm using is organized into 16k erase sectors, so you don't have to rewrite the whole chip. Even so, 16k must be rewritten. What the configuration program does is copies the last 16k of flash (in which the last 256 bytes contains the configuration area) to the Spectranet's RAM. The configuration program then modifies this copied data in RAM, and when you choose 'Save and exit', it erases the last 16k sector in flash, and copies back the 16k that was copied in earler, thus preserving anything in that last 16k that someone might have put there. It uses Spectranet RAM to do all of these operations, since this won't affect any programs a user might have in the Spectrum's main memory. I want to follow the principle of 'least surprise', and this clearly includes not stomping all over a program that the user might be working on in main RAM! (And in any case, I included static memory on the Spectranet so that the ROM as well as networked programs have some extra workspace).
 
As far as general progress is concerned, I would have preferred to be a bit further on than I am now, but I'm getting really close to having something suitable for others to do some development with. I have some more solder wick now, so I'll also be making a few boards for development use this month. I also want to write at least one "real" program that does something in the real world for two reasons: provide a useful working code example, and to provide real world testing. I will probably do something reasonably straightforward like a simple IRC client, or perhaps a minimal HTTP server.
 
[[User:Winston|Winston]] 14:56, 1 June 2008 (BST)


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


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

Latest revision as of 18:10, 19 January 2013

New Spectranet firmware

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

Changes:

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

How to update your firmware: 

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

Choose "A..Firmware check/Update".

Winston 18:10, 19 January 2013 (UTC)

ZX Breakout

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

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

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

Winston 22:16, 16 October 2012 (BST)

Failure rates, regenerating clocks

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

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

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

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

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

Winston 18:12, 29 September 2012 (BST)

Spectrum30

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

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

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

Winston 22:39, 19 September 2012 (BST)

On sale at last?

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

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

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

Winston 00:04, 4 September 2012 (BST)

The Raspberry Pi and the Spectranet

Raspberry Pi nestles amongst Spectranets at Imperica Horizons

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

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

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

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

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

Winston 22:42, 3 July 2012 (BST)

Emulating the Spectranet

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

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

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

Winston 10:42, 25 February 2012 (UTC)

Delinquency

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

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

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

Winston 21:39, 14 January 2012 (UTC)

Perhaps production is sorted out..

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

Watch this space...

Winston 16:27, 16 January 2011 (GMT)

Argh! A hardware problem!

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

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

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

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

Winston 22:01, 6 December 2010 (GMT)

The last 10% that takes 90% of the time

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

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

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

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

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

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

Winston 19:34, 2 November 2010 (GMT)

Concentrate!

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

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

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

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

Winston 21:39, 16 September 2010 (BST)

Argh

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

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

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

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

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

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

Winston 20:40, 18 July 2010 (BST)

Significant redesign

BASIC streams fail on the 128K toastrack

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

However, these plans were dashed.

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

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

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

Thurlby-Thandar LA4800 logic analyzer showing ZX bus activity

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

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

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

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

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

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

Winston 17:19, 4 July 2010 (BST)

ZXI

(Edit: Corrected port numbers)

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

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

The Spectranet CPLD performs a full 16 bit decode.

Winston 20:23, 27 June 2010 (BST)

The VCF, and gone off solder paste

Spectranet solder paste stencil

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

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

Older News

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