Difference between revisions of "Current events"

From Spectrum
Jump to navigation Jump to search
 
(121 intermediate revisions by the same user not shown)
Line 1: Line 1:
== A solidification of the plans ==
== New Spectranet firmware ==


[[Image:Spectranet-wip.png|thumb|300px|right|Click here to see the work-in-progress. Make sure you download the full resolution image and zoom in if you actually want to see anything useful]]
Spectranet firmware has been updated - the current version is labeled R544.


While I've been away, I've not quite '''completely''' left things alone.
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


For example, I had quite a bit of time in planes and stuck in airport terminals. My 12in. Apple PowerBook is not only small - fitting neatly into a pocket of my backpack (I've never seen the need for a laptop bag, they scream 'Steal Me!') - but also runs [http://geda.seul.org/tools/gschem/index.html gschem] just fine.
How to update your firmware:


So I passed the time on the plane from Houston to Salt Lake City and back making symbols for the memory and the W5100, and also experimenting with transforming a schematic into a netlist and PCB layout with my own symbols. Then, I made the CPLD symbol, and on the plane from Houston to Gatwick, started on the schematic proper. I nearly missed the plane from Gatwick back to the Isle of Man, I got so engrossed.
%mount 0, "vexed4.alioth.net"
%load ""


If you go to the image on the right, make sure you download it and zoom in fully, it's about 3000x2000 pixels or so - with so many pins on the chips the schematic gets a bit large. On this schematic, I'm explicitly showing power pins (often, people omit them from schematics). There are no less than 3 voltages used - 5v, 3.3v and 1.8v, as well as analogue 3.3v and analogue 1.8v - no less than 5 power nets. Also, there's a bit more than the usual decoupling used, so I want to show this explicitly. (I'll modify gschem's 74245 symbol to include power). It's a work in progress and not yet complete; in particular, I've not yet decided the pin assignments for the CPLD, nor the precise details of the reset circuit, and I need to finalise the ROMCS circuit (and have it compatible with the Spectrum +3). The through port is not shown on the schematic (and I don't intend to show it, except for indicating where A15OUT should connect).
Choose "A..Firmware check/Update".  


Once the final prototyping is complete, and I've tested the basic socket library (to shake out any hardware problems I've not yet discovered), the next step will be the PCB. I intend to make 10 prototypes, using PCB Train as a board maker (the same board maker used for Papaya Labs DivIDE). My plan for the PCB is to make it pretty small - around 10cm by 5cm - if I can keep it short, then the through port can be just on the back of the PCB. This may require a 4 layer board.
[[User:Winston|Winston]] 18:10, 19 January 2013 (UTC)


While in Houston, I visited [http://www.epohouston.com/ EPO] - it's a handy component shop with all sorts of interesting stuff. I picked up a few 74HCT245 ICs while I was there - if you read down to some older entries here, you'll see the problems encountered with when 0xFF is read from the W5100 - which doesn't have the oompf to drive the Spectrum's long bus (with all the parasitic capacitance that implies). The '245 allows me to separate the Spectrum's bus from the W5100's data I/O pins, so the W5100 is only driving the lines to that one chip, with nice high impedance FET inputs. Putting the '245 on the breadboard completely solved the problem, even after removing all the 4.7k pull up resistors. I've decided I'll use the '245 rather than putting a bidirectional buffer into the CPLD, since the bidirectional buffer uses a heap of macrocells (about 25!) I could use for something that would take several chips to implement.
== ZX Breakout ==


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


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


[[Image:Specnet_proto.jpg|thumb|right|400px|The current breadboard prototype - W5100 module on the right]]
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.


So with the hardware (mostly) working, the next step is to write the basic socket library - first for assembler and C. As already mentioned, it's my intent to broadly follow the way the BSD socket library works, since that's really the standard. Even Microsoft didn't re-invent the wheel on that one, they provide the same interface. People are familiar with it, it's flexible that it works with every piece of hardware in the world. When I say "broadly follow", I'm aiming for a subset of the library (particularly for the asm version). The C version will have the same function prototypes as the real thing. By contrast the asm version will have the same functions (socket, listen, connect, bind, send, recv... etc) but with some parameters missing. For example, the family argument to socket is irrelevant to the asm version - an asm program isn't portable anyway, and the socket library only understands AF_INET sockets, so there's no point using the family argument - and people using the asm interface rather than the C one probably care enough about performance that checking useless arguments will be an impediment.
[[User:Winston|Winston]] 22:16, 16 October 2012 (BST)


The rationale for modelling the BSD interface for asm (and replicating it for the Z88DK) rather than simply wrapping the W5100's hardware features is that if the hardware changes, then software doesn't have to change too. Or even the TCP/IP stack changing (you don't have to use the W5100's TCP offload, you can use your own stack running on the Z80).
== Failure rates, regenerating clocks ==


The other part of the abstraction is to provide a jump table for all the ROM functions. At the cost of a dozen or so CPU cycles, the table does two things:
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):


* the entry point causes the ROM to get paged in.
5 duff flash ROMs (one died on a board I had been using for demos for some time)
* the call table means that programs that depend on these functions don't have to be recompiled/reassembled when ROM locations inevitably change.
2 duff static RAMs
1 duff W5100
1 duff CPLD


=== What about BASIC though? ===
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.


First, I want to get the asm socket library thoroughly debugged since it's the basis for everything else. However, I think BASIC support is actually pretty important, since it lets any Spectrum fan have a bit of fun with networking. Ever since the days of the VTX-5000, I've known how much having a network transforms a computer... and I'd like it to be available to all, including people who aren't hardcore programmers.
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.


Incidentally, having sockets available from BASIC will I think make the Spectrum quite a handy embedded platform for the hobbyist - reasonably easy to program, and easy to make homebrew electronics for. With the built in BASIC interpreter, it makes experimentation very easy. Having network access as well just makes it that much more useful.
Looking at some new project work, I've successfully made a digital PLL in Verilog which will regenerate the Spectrum's 3.5MHz clock, that's to say it generates a clock that is in sync with the /CLK signal at the edge connector, and keeps running during periods of contention. This is important if you want to accurately be able to count the number of T-states the ULA sees. This has been tested with a real Spartan-6 FPGA too, and it works! There's a discussion about it here: [http://www.worldofspectrum.org/forums/showthread.php?t=40885 World of Spectrum forums]


I do have to find out how the BASIC parser works, but World of Spectrum has some useful resources for that such as the Complete Spectrum ROM disassembly, as well as the Shadow ROM disassembly - which has examples of how to do BASIC extensions.
[[User:Winston|Winston]] 18:12, 29 September 2012 (BST)


The BASIC extensions probably won't just be providing socket, listen, accept, send, recv... etc - rather combining some of the calls - a bit like how Perl's IO::Socket::INET allows you to open a socket to a remote host with a single call. BASIC programmers likely don't need the flexibility of keeping all these calls separate - instead, they likely want ease of use (or they'd be using asm or C!) So I plan to have a simple connection possible using no more than 4 keywords - one to open, one to read, one to write, one to close.
== Spectrum30 ==


=== Further hardware prodding ===
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).


While testing out the flash programmer, I've found that the 0xFF problem (mentioned last week) hasn't really gone away altogether. I discovered that the board was working rather slowly. Just for fun, I sent some game SCREEN$ images to the Spectrum over the network, using the program I wrote for loading programs over the network - it takes a very simple header containing memory location and length, so I could just send data with the location 16384 to send a SCREEN$. It loaded rather slowly I thought (a throughput at a guesstimate of 8k per second, which is appallingly slow). So digging through the millions of hardware registers for the W5100, I found that by default the device uses a "delayed ACK" option, which instead of acking packets as soon as they are successfully received and stored in the rx buffer, waits for a specified time before sending the ACK. What useful purpose this serves, I do not know, and it's baffling that it's apparently the default.
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).


So I turned the ACK delay off, which resulted in SCREEN$ images loading instantly. However, the old 0xFF byte problem started again, where bytes in the buffer set to 0xFF get read back as random values. Unfortunately, if I use a smaller pull-up resistor value than 4k7, it loads the Spectrum's bus too much, and all sorts of funny things happen to lower RAM. The Spectrum has a very simple bus multiplexer - just a bunch of resistors across the bus so the ULA can read off lower 16k at the same time as the Z80 reads off the upper 32k. And putting pull up resistors on the data bus causes this not to work properly, unless the pull-ups are rather weak.
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.


This didn't stop me reprogramming the flash chip for the first time though - the program doesn't contain long strings of 0xFF bytes, so even with this problem the breadboard prototype can be used for this.
[[User:Winston|Winston]] 22:39, 19 September 2012 (BST)


So - really, there's nothing for it - the W5100 is going to have to be buffered since it can't drive the Spectrum's bus properly. I put one in the CPLD design, and it uses an amazingly huge number of macrocells (about 20 for a bidirectional tristate buffer!) While I have quite a few macrocells left over at the moment, I would rather save them for things that would take lots of chips to implement. A suitable bidirectional buffer, on the other hand, is a single 74-series chip. So I may use a separate chip for the buffer. It's entirely possible that the W5100 won't have this problem when put on a proper PCB with a decent ground plane, rather than my breakout board - I can put vias under the chip for instance and give the chip a much better path to ground than it has at the moment. Also, I can get decoupling capacitors much closer to the power pins. The only trouble is I have to actually get a board made to try this out and this is expensive!
== 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.


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


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


[[User:Winston|Winston]] 18:31, 31 January 2008 (UTC)
[[User:Winston|Winston]] 00:04, 4 September 2012 (BST)


== Sending programs over ethernet ==
== The Raspberry Pi and the Spectranet ==


The first application of the prototype is to program itself.
[[Image:Spectranet-and-pi.jpg|thumb|right|300px|Raspberry Pi nestles amongst Spectranets at Imperica Horizons]]


It's a bit of a pain to have to dig out the 128k flash rom each time I want to try out some new code. So I've made a self contained standalone program (which incidentally is NOT an exemplar of how the board's programming interfaces will work - it's very rough and ready) which allows me to load a program to an arbitrary address in the Spectrum's memory and jump to it, or write that transferred data to pages 0 to 3 of the 128k flash chip (although I still need to add the bit that actually programs the flash). I also made a short perl script to send the file to the Spectrum. The server (on the Spectrum) listens on a TCP socket. The first 4 bytes contain the destination address in RAM and the length of the data. The rest of the data is the program or data being sent. The program is in the Subversion repository here ( [http://spectrum.alioth.net/svn/listing.php?repname=Spectranet&path=%2Ftrunk%2Fflash%2F#_trunk_flash_] ), with the corresponding perl script here ( [http://spectrum.alioth.net/svn/filedetails.php?repname=Spectranet&path=%2Ftrunk%2Fexperiments%2Fethup] ).
The Raspberry Pi promises to be a great companion to the venerable Spectrum when equipped with a Spectranet :-)


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


Incidentally, I've not seen a recurrence of bad register reads (yet) where the register contains 0xFF since adding the pull up resistors, so I may have been imagining it. But I'm going to keep a very close eye on the netmask readback on bootup. If the problem really hasn't completely gone away I can always buffer the W5100 via the CPLD, since I do have some spare macrocells.
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've also been adding the remaining functionality to the CPLD, adding circuits to allow the readback of certain state data. If there's enough macrocells remaining I may also make the memory pager registers read/write instead of write only since it'll give a little bit of a speedup to the paging code (since there will be no need to save the current page in memory).
I intent to make some pre-built Debian packages (and a little Debian apt repository) for the Raspberry Pi programs. At the same time I'll do the same for x86 and amd64 based Debian systems.


[[User:Winston|Winston]] 23:31, 22 January 2008 (UTC)
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!)


== First packet! ==
[[User:Winston|Winston]] 22:42, 3 July 2012 (BST)


The Spectranet just sent and received its first packets!
== Emulating the Spectranet ==


After wiring in the W5100 ethernet chip, I added the code that copies to and from the network buffers and pokes the appropriate hardware registers. It's not as straightforward as LDIRing a bunch of data into a buffer - you have to read some (big endian) registers to calculate an offset, and then check the buffer doesn't wrap - the buffers are circular. Then either LDIR it to the right place, or if it wraps around, LDIR the first part, and then set everything up to continue from the bottom of the buffer. Then poke a few more registers to tell the hardware how much you've just done, and you're away.
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.


The code update of interest today, therefore, will the file w5100buffer.asm over here ( [http://spectrum.alioth.net/svn/listing.php?repname=Spectranet&path=%2Ftrunk%2Fexperiments%2F#_trunk_experiments_] ) - well, all of the w5100*.asm files really.
To get the Fuse source, visit Sourceforge - [http://fuse-emulator.sourceforge.net/]


It's quite a major milestone - I now have a rubber key Spectrum that talks over ethernet (somewhat). But as I keep saying, don't hold your breath: sending some packets and receiving some packets is still a long way off from having good general purpose code so that other people can use it, and other major tasks must be done - such as settle on the final hardware design, draw out the schematics, and turn this into a working PCB layout.
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]


However, there's also some bad news (although not as bad as I initially thought).
[[User:Winston|Winston]] 10:42, 25 February 2012 (UTC)


The W5100 doesn't seem to be copying the value 0xFF correctly. If, for instance, you send a bunch of data which contains just the value 0xFF repeated, when the Spectrum reads it from the ethernet buffer, roughly every 8 to 15 bytes or so, it'll get a random value instead of 0xFF. It doesn't happen with 0xFE, 0x7F (or any other value with lots of 1s) - only 0xFF. This includes register reads - so for instance, if you read back the netmask, sometimes you get something other than 0xFFFFFF00 (although for some reason, it's less random when reading back registers instead of buffers).
== Delinquency ==


Either the W5100 has a bug (unlikely, but it has been known: and Wiznet do have some errata on the chip, for instance some revisions of the chip run extremely hot), or it is suffering from ground bounce (that is, when a chip with high speed outputs tries to change a lot of them at once, it momentarily draws a relatively massive current that drags the ground up above 0 volts). If it's the former... it's game over. If it's the latter, it's just a PCB layout problem that I can fix.
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:


Unfortunately, there is only one forum that discusses the W5100. In the past I've contacted Wiznet's tech support over other issues with the chip, but English isn't their first language and I don't think I was effectively communicating with them. Also, I do not have a digital storage scope so finding out whether it's ground bounce or not will be very hard since it's a brief, transient problem. Once my username request is approved for the forum I'll try asking there - see if anyone else is using this chip on a 2 layer breakout board and has the same problems. Or perhaps they never noticed: many applications will '''never''' need to receive the value 0xFF, even less a string of them - and a problem like this would go undetected. (Had I not noticed the netmask readback being incorrect, I'd have never noticed either - and would probably right now be going berserk trying to find out why the new ROM image I transferred over ethernet had strange bugs - the chip had after all worked perfectly with the text data that I sent to test out the receive data routine).
* 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.


'''Update:''' Ground bounce, or at least trouble driving a long bus with lots of parasitic capcitance is almost certainly the problem: adding 4k7 pull up resistors to each line on the data bus made a significant improvement (data from the transfer buffers is now correctly received, regardless of the amount of 0xFF bytes, but there's still problems reading the netmask back).
I hope to soon have details on how you can get your hands on one.


[[User:Winston|Winston]] 17:52, 20 January 2008 (UTC)
[[User:Winston|Winston]] 21:39, 14 January 2012 (UTC)


== LNK... FDX... 100M... ==
== Perhaps production is sorted out.. ==


A quick update: I made up some breadboard cables, and connected the W5100 module to the setup. Aside from the breadboard now resembling a plate of spaghetti (I really ought to talk to Chris Smith of Harlequin fame about neat breadboarding!), with much anticipation, I powered the Spectrum up. When I released the RESET pin, to my relief, it came up, and appeared to work as a Spectrum should - and the LNK, FDX and 100M lights lit up on the W5100 ethernet module.
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.


I've not got as far as actually doing anything with it, merely ensuring it powers up and doesn't cause bus loading problems. The next task will be sending the Spectranet's first packet, and then make a simple program that allows me to flash the ROM with the Spectrum, over ethernet, so I'm not having to dig the flash chip out from underneath its mass of wiring each time I need to update the ROM.
Watch this space...


Incidentally, a PCB layout for the W5100 module can be found here ( [http://spectrum.alioth.net/svn/listing.php?repname=Spectranet&path=%2Ftrunk%2Fhardware%2F#_trunk_hardware_] ) in Subversion, if you fancy building your own W5100 breakout board. It's pretty much my translation of the Wiznet reference schematic to a 2-layer PCB that's optimized for home etching. (You'll need gEDA PCB. I do intend to put PostScript and Gerber versions of PCBs on the wiki in the near future).
[[User:Winston|Winston]] 16:27, 16 January 2011 (GMT)


[[User:Winston|Winston]] 23:16, 16 January 2008 (UTC)
== Argh! A hardware problem! ==


== Testing the new CPLD ==
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.


[[Image:Testcpld1.jpg|thumb|300px|right|3.3 volt XC9572-xl breadboarded with ROM and RAM]]
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).
[[Image:Testcpld2.jpg|thumb|150px|right|The general scene]]
[[Image:Testcpld3.jpg|thumb|300px|right|Testing with the DivIDE]]


I had been planning to work on other projects this weekend, and not do anything at all with the Spectrum ethernet prototype... but I shot myself in the foot with the other project (due to sloppy thinking that 5 minutes careful thought would have prevented), so I worked on the ethernet project instead.
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 goal: test the new CPLD works at all; it's a 3.3 volt chip with 5v tolerant I/O. Eveything in the Spectrum should be TTL compatible (so 3.3v is a perfectly valid logic 1), as should be typical 5 volt CMOS flash and static RAM. However, there's nothing worse than spending hours making a PCB then discovering it can't work (ever), so to the breadboard it was.
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.


I had actually wired up half the circuit in the week, then finished it off today.
[[User:Winston|Winston]] 22:01, 6 December 2010 (GMT)


It didn't work. The usual random colour attribute vomit on the screen when I powered up, which is so familiar to anyone who has either a Spectrum with bad lower RAM, or has just plugged in a faulty peripheral. So I unplugged, and checked the Spectrum still worked (which it did). I then removed the memory and the connection to the ROMCS level shifter so only the CPLD was connected - with the same result. The CPLD was powered and apparently working, so I unwired everything - sure I had a short. I rewired, and tested the Spectrum at each major checkpoint (first the address bus; OK - then the data bus; OK - then the control lines - vomit). I started removing connections to the control lines (all of them CPLD inputs - nothing actually driving a signal into the Spectrum yet), and it started to work as soon as I removed the RESET connection.
== The last 10% that takes 90% of the time ==


It turns out that the RESET line gets stuck at about 0.2 volts when connected to the RESET input on the CPLD. If you momentarily touch RESET to +5v, it un-sticks and everything works just fine. Testing the voltage level when RESET is high shows that it's sitting at 3.3v, which suggests the 5v tolerant I/O on the CPLD is done by clamping the input with a zener diode - but there must be something more to it if it causes RESET to stick low (if the 5v tolerance is just an on-chip zener and resistor, it shouldn't affect stuff until the voltage exceeds 3.3v). Still, the input impedance must be pretty high since the other I/O lines don't bother the NMOS circuits in the Spectrum. I will have to examine the Issue 4 Spectrum schematic to find out why the CPLD causes it to stick low. The fix (for now) is to add a 4k7 pull-up resistor to the RESET line - it functions fine like that.
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:


With that mystery solved, I added the flash ROM and 128k static RAM back to the circuit. I also modified the routine I've been testing the hardware with, so it resides entirely in page 0 of flash (which is permanently mapped to 0x0000-0x0FFF when our memory is paged in), and the workspace for the character printing routine into our RAM, instead of upper RAM on the Spectrum. More testing is needed (such as the paging mechanism for the memory map between 0x1000 and 0x2FFF) but that can wait until tomorrow. Test code can be viewed here ( [http://spectrum.alioth.net/svn/listing.php?repname=Spectranet&path=%2Ftrunk%2Fexperiments%2F#_trunk_experiments_] ) - I use sjasmplus, and 'testtraps.asm' assembles all.
# 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)


I also did some rudimentary compatibility testing. First, with my own diagnostics board since this is dirt simple and hopefully I can understand it if it goes wrong. Compatibility with downstream devices with their own shadow ROMs is peformed by nailing A15 high on the through port whenever we're paged in (which stops anything on the through port mapping its memory, since it will see an address >= 0x8000, rather than one in the lower 16k). This went fine - the RESET routine running from the flash on the breadboard, and then the diagnostics card getting paged in and running its tests (which all completed successfully). I tried the same thing with the DivIDE - again, it worked fine, the RESET routine running from my flash, and then the DivIDE getting initialized as normal.
A big item, though, will be writing a manual for the standard modules (BASIC extensions, etc).


I've also run out of jump wires for breadboarding (or at least, ones of a useful length). It seems a bit odd since I breadboarded an entire Z80 based computer using the wires I have now, but somehow I've managed to use nearly all of them. However, once I've done more complete testing on the memory and paging, it'll be time to plug in the W5100.
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.


But the rubber keyed Speccy in the pictures is now a 304k Spectrum, 128k of that being non-volatile. Just imagine what a huge deal that would have been in 1986! Pity NOR flash hadn't been invented then.
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!


[[User:Winston|Winston]] 20:08, 13 January 2008 (UTC)
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)


== Major breadboarding session on the way... ==
[[User:Winston|Winston]] 19:34, 2 November 2010 (GMT)


[[Image:Memmap.png|thumb|300px|right|Lower 16k memory map]]
== Concentrate! ==


I have the basic CPLD design now more or less done and simulated within Xilinx ISE, all it needs to do is actually work. So I have some pin-thru-hole flash (Am29F010) and static RAM (Mitsubishi M5M51008B), both 128kbyte, for testing the memory. The current CPLD design (which includes the pager and instruction trapper) fits easily into the XC9572 with many macrocells free. I still have a bit more to add (software enable/disable RST 8 trapping, NMI through, soft enable/disable W5100 interrupts) but there should be some macrocells left over for 'luxury items'.
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:


More on the memory map and paging mechanism on the [[Memory]] page.
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).


My plan is to test with just the flash and RAM at first, then add the W5100 breakout board, which should be a simple matter of connecting it to the data/address bus and writing a little bit of code to set it up. While theoretically the circuit is just a straightforward adding-memory-to-the-bus type of affair, I know from my testing of the W5100 with my ALIAC-2 Z80 based computer is that the W5100 seems to load the bus. The Spectrum's NMOS parts just aren't going to be as good at driving heavy loads as the ALIAC-2's CMOS parts, so it remains to be seen whether all the signal lines to the W5100 will need buffering.
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.


[[User:Winston|Winston]] 22:41, 5 January 2008 (UTC)
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!


== Back to work for the new year ==
[[User:Winston|Winston]] 21:39, 16 September 2010 (BST)


What with the usual holiday festivities, I've not really done much on the project since making the breakout board (except testing the board actually works), and doing a bit of diagnostic work on a new dead 48K Spectrum+ that someone sent me.
== Argh ==


I'm getting close to the design being settled for the memory map. The current intention is to do the following: treat all memory (including the W5100) as 4K pages, with 2 pages fixed in the memory map (so when an event happens, we're guaranteed to have a certain page of flash ROM and a certain page of workspace mapped in), and 2 pages that can be mapped from any 4K page of RAM. The memory map will look like this, when mapped into the Spectrum's lower 16K:
[[Image:Redspectranet.jpg|thumb|right|300px|It took all day to get here, but the new Issue 1 board works and has been tested]]


* 0x0000 - 0x0FFF - page 0 of flash ROM. Contains initialization code, socket library, various low level function calls.
Well, the solder paste stencilling decidedly failed to work as planned. Basically, a day of disasters.
* 0x1000 - 0x1FFF - Any 4K page of any memory.
* 0x2000 - 0x2FFF - Any 4K page of any memory.
* 0x3000 - 0x3FFF - page 0 of the onboard static RAM. Workspace, system variables, jump table.


The only decision left is this: To allow room for future expansion, the registers for the pagable areas are all 8 bit (allowing for up to 8 megabit chips - i.e. 1MB) to be used, with a 4 bit chip select register (so up to 4 memory chips - three used at present; the flash, W5100 and RAM). This requires two 8 bit registers and a 4 bit register. Alternately, I could delete the 4 bit chip select register, and generate the chip selects from the upper 2 bits of the two page registers. This would allow for up to 2 megabit chips (256K per chip). It would save some CPLD macrocells, and use one less I/O port (so only 2 I/O ports would be required).
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.  


I decided to use multiplexers in the CPLD rather than tristate buffers for the output of these registers onto the bus, since this will mean the paging address lines and chip selects would never go into high impedance state (eliminating the need for a handful of pull up resistors). The "upper bus" is never contended with any other device so there's no need for those lines to ever go high-Z.
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.


[[User:Winston|Winston]] 12:23, 3 January 2008 (UTC)
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.


== More prototyping tools: XC9572 breakout board ==
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.


[[Image:Xc9572-breakout.jpg|thumb|right|400px|XC9572-XL in a TQFP-100, mounted to the breakout board]]
[[User:Winston|Winston]] 20:40, 18 July 2010 (BST)


Christmas Eve afternoon was spent making the breakout board shown in the photo, and I had enough time before Christmas dinner to check that the board at least programmed correctly (which it did), so I don't think I screwed anything up too badly :-) This is the chip I intend to use as the CPLD on the ethernet board. It has more pins than I actually need, but the next size down is the (more expensive!) PLCC, and then to the 44 pin packages which don't have enough pins.
== Significant redesign ==


Apart from pin headers/SIL strips, everything is surface mount, using the passives I intend to use for the final board. The 3.3v power circuit (using a 3.3v low dropout regulator, no heatsink required since the current draw won't be that high) is also the one I intend to use on the final board. Decoupling capacitors are all 0603 sized which is as small as easily hand solderable. I want to get the passives down as small as possible so they don't get in the way too much when routing traces; 1206 is just a bit too big (and gave me a real headache when laying out the W5100 breakout board).
[[Image:128debug1.jpg|thumb|right|300px|BASIC streams fail on the 128K toastrack]]


I probably won't get much more done on the project over the next week or two (too many Christmas/New Year type events going on) but hopefully by the end of the month I'll have the W5100, CPLD and memory all working on breadboard and will have sent the first packet.
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).


[[User:Winston|Winston]] 10:28, 25 December 2007 (UTC)
However, these plans were dashed.


== Welcome to the wiki ==
[[Image:128debug2.jpg|thumb|right|300px|When my bench looks like this it generally means there's big trouble]]
[[Image:128debug3.jpg|thumb|right|300px|Closer look at the heap of wiring and bus breakout board]]


In order to make it easy to document ongoing hardware projects for the Sinclair Spectrum, I've put this wiki into service. At the moment, it can only be edited by me... but in future, I hope there will be others interested in collaborating on the projects here, and MediaWiki makes it easy for others to edit, too.
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.


Onto the most recent news. I've just received my order from Farnell for most of the parts needed to make the prototype ethernet boards. I intend to make a small number (about 8 or so) to allow me to develop ways to economically build boards (economic not just in money, but in time). Experience of hand-making a couple of diagnostics boards showed that this was a non-starter (it took FAR too long - a couple of hours per board at least to assemble!) so this time around, I've decided to use surface mount parts, and build my own reflow system (with a hotplate or a toaster oven - nothing expensive) to try and make the boards reasonably quick to assemble. I also intend to make a handful of prototypes, so I can get a few out to some Spectrum enthusiasts who want to be on the bleeding edge (!) and shake out any bugs.
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.


But in this consignment, I have:
[[Image:128debug4.jpg|thumb|right|300px|Thurlby-Thandar LA4800 logic analyzer showing ZX bus activity]]


* 10 Xilinx XC9572 CPLDs, in 100 pin TQFP packages. 3.3 volt types (which have 5v tolerant I/O)
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.
* 10 Am29F010 90ns 128kbyte flash memories. This is to hold the ROM code, and a set of applications to go with the board. These are in TSSOP packages.
* 10 IDT71024 128kbyte static memories. Extra workspace for networked applications. These are in SOJ (small outline, J-lead) packages.
* 3.3v linear regulator - to power the W5100 and the XC9572.
* Various surface mount passives (lots of capacitors, a few resistors, a few inductors).
* A couple of tools to make it a bit easier to do surface mount stuff (tweezers, nothing fancy)
* On back-order - 10 Tyco Mag45 RJ-45 sockets with integrated magnetics.


I already have plenty of some of the other parts - lots of 25MHz crystals, enough P and N channel discrete MOSFETs (for the ROMCS hold circuit), indicator LEDs etc.
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 still need to get some card edge connectors, LaesQ suggested a suitable supplier (where he gets the connectors for the DivIDE).
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.


The current plan of attack is to make a breakout board for one of the XC9572s, including a 3.3v regulation circuit, and breadboard a test circuit which will include a (DIP packaged) Am29F010, as well as a 1mbit static RAM, and the W5100 breakout board I built earlier. This will enable me to test that the Spectrum's bus doesn't get loaded too heavily (I've already noted that the W5100 puts some loading on the bus from earlier tests), and that the current draw isn't too high; the W5100 can use up to 180mA with the PHY at full power. Once any hardware issues are sorted out, then design the schematics/PCB for the first version of the board... then have PCB Train make 10 of them.
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.


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

Latest revision as of 19: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"