Difference between revisions of "Current events"

From Spectrum
Jump to navigation Jump to search
 
(123 intermediate revisions by the same user not shown)
Line 1: Line 1:
== The basic socket library ==
== New Spectranet firmware ==


[[Image:Specnet_proto.jpg|thumb|right|400px|The current breadboard prototype - W5100 module on the right]]
Spectranet firmware has been updated - the current version is labeled R544.


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.
Changes:
* '''Streams module:''' Incorrect flags being set when creating a file (thanks Guesser)
* '''Streams module:''' Now ensures a sane file mode is set when creating a file
* '''Snapshot manager:''' No longer makes snapshots world writable when creating them (oops) on fileservers with POSIX permissions


The 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).
How to update your firmware:


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:
%mount 0, "vexed4.alioth.net"
%load ""


* the entry point causes the ROM to get paged in.
Choose "A..Firmware check/Update".  
* the call table means that programs that depend on these functions don't have to be recompiled/reassembled when ROM locations inevitably change.


=== What about BASIC though? ===
[[User:Winston|Winston]] 18:10, 19 January 2013 (UTC)


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.
== ZX Breakout ==


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


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.
A batch of boards is currently being made, and should be back with me this week or early next week.


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


=== Further hardware prodding ===
[[User:Winston|Winston]] 22:16, 16 October 2012 (BST)


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.
== Failure rates, regenerating clocks ==


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


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


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


=== And finally... ===
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.


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


[[User:Winston|Winston]] 18:31, 31 January 2008 (UTC)
[[User:Winston|Winston]] 18:12, 29 September 2012 (BST)


== Sending programs over ethernet ==
== Spectrum30 ==


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


It's 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] ).
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).


This should save a huge amount of time when testing things out on the hardware.
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.


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.
[[User:Winston|Winston]] 22:39, 19 September 2012 (BST)


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).
== On sale at last? ==
With a bit of luck, yes, you'll be able to buy a Spectranet at Spectrum30 ( http://spectrum30.org.uk ) in Cambridge this weekend! Rich Mellor of RWAP Software will be in charge of handling the sales.


[[User:Winston|Winston]] 23:31, 22 January 2008 (UTC)
Also, you'll be able to play Spectank (see http://www.youtube.com/watch?v=6fEvuENABZY )


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


The Spectranet just sent and received its first packets!
[[User:Winston|Winston]] 00:04, 4 September 2012 (BST)


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 Raspberry Pi and the Spectranet ==


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.
[[Image:Spectranet-and-pi.jpg|thumb|right|300px|Raspberry Pi nestles amongst Spectranets at Imperica Horizons]]


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.
The Raspberry Pi promises to be a great companion to the venerable Spectrum when equipped with a Spectranet :-)


However, there's also some bad news (although not as bad as I initially thought).
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.


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


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


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


'''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).
[[User:Winston|Winston]] 22:42, 3 July 2012 (BST)


[[User:Winston|Winston]] 17:52, 20 January 2008 (UTC)
== Emulating the Spectranet ==


== LNK... FDX... 100M... ==
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.


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.
To get the Fuse source, visit Sourceforge - [http://fuse-emulator.sourceforge.net/]


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


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]] 10:42, 25 February 2012 (UTC)


[[User:Winston|Winston]] 23:16, 16 January 2008 (UTC)
== Delinquency ==


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


[[Image:Testcpld1.jpg|thumb|300px|right|3.3 volt XC9572-xl breadboarded with ROM and RAM]]
* 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.
[[Image:Testcpld2.jpg|thumb|150px|right|The general scene]]
* A manual is being written.
[[Image:Testcpld3.jpg|thumb|300px|right|Testing with the DivIDE]]
* Many bugs have been fixed, thanks to early adopters.


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.
I hope to soon have details on how you can get your hands on one.


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.
[[User:Winston|Winston]] 21:39, 14 January 2012 (UTC)


I had actually wired up half the circuit in the week, then finished it off today.
== Perhaps production is sorted out.. ==


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


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.
Watch this space...


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.
[[User:Winston|Winston]] 16:27, 16 January 2011 (GMT)


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.
== Argh! A hardware problem! ==


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


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


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


== Major breadboarding session on the way... ==
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.


[[Image:Memmap.png|thumb|300px|right|Lower 16k memory map]]
[[User:Winston|Winston]] 22:01, 6 December 2010 (GMT)


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


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


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


[[User:Winston|Winston]] 22:41, 5 January 2008 (UTC)
A big item, though, will be writing a manual for the standard modules (BASIC extensions, etc).


== Back to work for the new year ==
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.


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


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


* 0x0000 - 0x0FFF - page 0 of flash ROM. Contains initialization code, socket library, various low level function calls.
[[User:Winston|Winston]] 19:34, 2 November 2010 (GMT)
* 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).
== Concentrate! ==


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


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


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


[[Image:Xc9572-breakout.jpg|thumb|right|400px|XC9572-XL in a TQFP-100, mounted to the breakout board]]
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!


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


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


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


[[User:Winston|Winston]] 10:28, 25 December 2007 (UTC)
Well, the solder paste stencilling decidedly failed to work as planned. Basically, a day of disasters.


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


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


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


But in this consignment, I have:
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.


* 10 Xilinx XC9572 CPLDs, in 100 pin TQFP packages. 3.3 volt types (which have 5v tolerant I/O)
[[User:Winston|Winston]] 20:40, 18 July 2010 (BST)
* 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.
== Significant redesign ==


I still need to get some card edge connectors, LaesQ suggested a suitable supplier (where he gets the connectors for the DivIDE).
[[Image:128debug1.jpg|thumb|right|300px|BASIC streams fail on the 128K toastrack]]


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.
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]] 22:51, 21 December 2007 (UTC)
However, these plans were dashed.
 
[[Image:128debug2.jpg|thumb|right|300px|When my bench looks like this it generally means there's big trouble]]
[[Image:128debug3.jpg|thumb|right|300px|Closer look at the heap of wiring and bus breakout board]]
 
In the photo (top right) you can see the half-loaded menu with the rather strange "8 End of file" message with a flashing K cursor stuck to the end of it. This first came to light at the Vintage Computing Festival when Chris Smith gave me a transistor to fix one of my two dead toastrack 128K Spectrums, and the games menu wouldn't load. (So on that machine, I loaded the Twitter client and left it, as we went to lunch. I was very surprised when I came back and found people playing games - what had happened is the menu intermittently worked, and got more reliable as the machine warmed up, but I didn't know that then). At the VCF, I didn't have any time to actually analyze it and we were going to get some lunch, anyway, and I was speculating there may be an incompatibility in the 128K's ROM. Andrew Owen thought not, he didn't think there would be anything that would break channels and streams - he suggested "put the ROM in your +3 and see if it works", so I did. And it worked fine.
 
There were a few red herrings, too. I repaired the other broken 128K machine I have, thanks to some new RAM that Jose Manuel sent me (he runs El Trastero del Spectrum - the Spectrum Junkroom) and that 128K functioned fine. I had put a new Z80 in it because the M1 line had been zapped - it now had a Mostek NMOS Z80. So I thought - it's not a Spectranet problem, obviously there's a faulty RAM chip on the other machine that's corrupting the streams stub code. Or is it... RAM failures don't usually happen with just one or two bits, usually what happens is a very large piece of RAM stops working, and it causes the whole machine to die. So I tried a different Z80, given this one had a socket - and the random failure of the games menu came back again. With an NMOS Zilog chip from 1984, the failure is infrequent but random, perhaps once every 100 or so INPUT# commands. With a CMOS Z80 from Zilog made in March 2010, the failure was rather more frequent, once every 5 or 6 INPUT# commands on average. I also tried putting a new CMOS Z80 in a rubber key Spectrum, and it caused the problem to start happening on that machine, too. This is all very well tested on rubber key Spectrums (and Pluses) with their original Z80 without a problem. The brand new CMOS Z80 in my +3 gave no problems whatsoever, it functioned perfectly.
 
[[Image:128debug4.jpg|thumb|right|300px|Thurlby-Thandar LA4800 logic analyzer showing ZX bus activity]]
 
Swapping the Z80 obviously showed it was an electronics problem, and nothing at all to do with ROMs. The first hypothesis is that it was a problem with the ROMCS circuit - the Spectranet holds ROMCS high while its ROM is paged in (to page out the ZX ROM), and releases it either because an OUT instruction has told it to, or it's executed an instruction at 0x007C (the normal exit point in the Spectranet ROM). I hypothesised that ROMCS might be being released insufficiently quickly, causing the wrong instruction to get executed occasionally. However, it didn't take much time with the oscilloscope to show that ROMCS was releasing very fast (and the ULA could then pull ROMCS to the ZX ROM down in under 100ns, which is kind of slow for an M1 cycle, but given that there's about 9 more T-states before the next instruction fetch, the Spectranet's ROMCS line was without a doubt totally beyond suspicion.
 
I have an old Thurlby-Thandar LA4800 logic analyzer. Normally, it sits for months and months, forgotten and a bit unloved. Someone told me a while ago "why do you want a logic analyzer? They are complex, expensive and you use them so infrequently that you forget how to use it, and 99 times out of 100 a digital storage scope is all you need". I didn't listen anyway, and picked the LA4800 up off an ebayer about three years ago with a collection of various pods for a couple of hundred quid. Just like whoeveritwas who said "all you need is a scope, you'll hardly use it" - this has turned out to be true. I hardly use it. But when I need it, there is nothing else that will do and it's worth its weight in gold. The LA4800 can simultaneously capture 48 channels of data, and you can make it trigger on various conditions, from simple "if you see this, trigger the capture" to a more complex sequence of events. It makes it easy to see exactly what is happening on the data and address bus and all the Z80 control lines. A logic analyzer is the only way you can find exactly where the expected code execution is going wrong on the real hardware, and what wrongness is happening. In short, it's awesome. And the LA4800 is very easy to use, a simple menu driven interface with on-screen help. I made sure I gave it a friendly pat once it had revealed to me what was going wrong.
 
Initially I was hampered by one of my 128K machines - what I didn't know is that another RAM chip was starting to go flaky on it (it has now failed completely, I have a spare but I've run out of desolder wick). The other 128K hampered me by blowing its TR4 again (and thus, you lose the display, since the TEA2000 no longer has a 12V supply). The other problem is the 128K's bus is rather marginal - it really doesn't take much extra loading on the bus to make a toastrack 128K stop functioning properly - and the logic analyzer has nice long ribbon cables, and that plus the bus breakout board plus the Spectranet was at times just too much, so the debugging lasted a lot longer than it should.
 
After doing a set of general captures to see that the Spectrum was behaving normally after the Spectranet ROM page out (it was), I set the trigger to trace the program that writes the channel stub to RAM (an earlier trace showed the Spectranet not even getting paged in on INPUT#). This showed the channel code getting written correctly (and showed me to what address, which depends on what the ZX ROM allocates for us). PEEKing that memory showed that the stub was loaded correctly. So now I could tell the logic analyzer to trigger on the address within the stub code where the CALL MODULECALL instruction lived. And there it was - the problem. The LA showed that when the call was made, the Spectranet wasn't paging in. There's some logic in the CPLD that decodes CALL instructions to 0x3FF8 to 0x3FFF, and it wasn't working.
 
The problem is this. The +3 which functions perfectly is electronically much better than the earlier Sinclair machines. It doesn't have a set of resistors as a bus multiplexer, it's done properly in the +3's ASIC. The +3 has a shorter bus with fewer chips on it, and less loading. The rise and fall times on the +3 is faster. However, the 128K machine has quite a long bus, with many chips on it, plus resistors between lower RAM and the CPU (so the ULA can read lower RAM at the same time as the Z80 writes/reads from upper RAM). There are many reasons for this, the +3 is a lot newer for a start so the cost for doing it the "nice way" had come down a lot. But the upshot is the timings are incredibly tight for the call trap to work on a machine other than a +3 or +2A/+2B, especially if the CALL instruction is in lower RAM.
 
The bad news is - it's essentially impossible to fix. The minimum time granularity I have in capturing the CALL instruction off the bus is half a T-state. If I read it half a T-state before MREQ+RD go high, this works fine on a +3, but it's unreliable on a 128K toastrack. If I read it when MREQ+RD go high, it doesn't work at all. ('''Edit''': thinking more about it, it could also be that the voltage levels aren't properly reaching either V(IL) or less likely, V(IH) for the CPLD) So with much regret - the CALL trap mechanism that has worked well with all my testing for the last couple of years will have to go. It's a shame because it meant programs didn't have to know what I/O port to use to cause the Spectranet to page in. Now I could instead trap execution at this range of addresses, but the reason I didn't is that some ROMs have code here (but none made a CALL to that address). Alternately, I could just list the ROMs that run code at these addresses as "incompatible" - I'll have to see what the various different ROMs put in this piece of RAM before I can really decide on it. ('''Edit:''' and indeed, this is what I've decided - I've changed it to an execution trap at 0x3FF8-0x3FFF, the devices I most care about don't use these addresses. No common ROM that will be paged while the Spectranet is plugged in uses these addresses, and so I won't have to change any software).
 
[[User:Winston|Winston]] 17:19, 4 July 2010 (BST)
 
== ZXI ==
 
(Edit: Corrected port numbers)
 
There's a very sensible proposal going around that all new peripherals use a certain port range to avoid clashing with older stuff (and with stuff that doesn't fully decode I/O addresses). The I/O address range is 0xhh3B, the lower eight bits are nominally for the ZX Printer (probably seldom, if ever going to be used with a newer peripheral, and an easily-made fixit board will serve if someone really does want to use a ZX Printer with a ZXI-compliant device). The upper half of the address bus is the actual port range, and we've got the full 256 ports. Two are already used by the ULA+, and now four are used by the Spectranet. The trouble is the Spectranet had a (fairly harmless, but potentially annoying in the future if a network+chip tune project were to be done) clash with the AY so I was going to have to change the port range anyway (it was 0x80E9, 0x80EB, 0x80ED etc). The new range is 0x003B to 0x033B inclusive. The relative order of the port assignment stays the same (and in any case the actual port is all abstracted away by the various Spectranet ROM library functions). The full list is now:
 
* 0x003B - Page A memory selector
* 0x013B - Page B memory selector
* 0x023B - Programmable trap register
* 0x033B - Control register
 
The Spectranet CPLD performs a full 16 bit decode.
 
[[User:Winston|Winston]] 20:23, 27 June 2010 (BST)
 
== The VCF, and gone off solder paste ==
 
[[Image:Stencil.jpg|thumb|right|300px|Spectranet solder paste stencil]]
 
Going from newest to oldest, first I thought I'd try and assemble one of the newly arrived PCBs with an also newly arrived solder paste stencil (see photo, that's a Kapton solder paste stencil for the Spectranet PCB). But I think my solder paste is now past its sell by date, it's gone rather hard and doesn't spread easily. Also the stencil lifted a bit and far too much paste went on... result, well, the workshop now stinks of isopropyl alcohol as I had to clean everything off again. So I'll get some more (probably a small pot of the stuff, rather than a syringe), plus a portable fridge to store it (the better solder paste needs to be kept cool, the stuff in the syringe I was using was fine if kept at room temperature, but this isn't true of all solder paste. Lots of people incidentally have complained that the Edsyn CR44 that I was using doesn't keep its shape as it's heated, it's probably a tradeoff you have to bear to get a solder paste that's happy being stored at room temperature).
 
Last weekend was the VCF, and this went really well - people loved the Twitter client, and I also fixed one of my toast rack machines to boot, which means I can now get on and fix the bugs that have surfaced on that machine (although I need to reassemble the workshop first, I've not had the chance yet). Indeed, the Spectranet took pride of place on the BBC News article about the VCF, and on the Register, too - BBC report here: http://news.bbc.co.uk/1/hi/technology/10364135.stm and the report at the Register is here: http://www.theregister.co.uk/2010/06/21/vintage_computer_fair/ . I also wrote about the VCF on World of Spectrum here: http://www.worldofspectrum.org/forums/showthread.php?t=30079
 
== Older News ==
 
* [[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 18:10, 19 January 2013

New Spectranet firmware

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

Changes:

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

How to update your firmware: 

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

Choose "A..Firmware check/Update".

Winston 18:10, 19 January 2013 (UTC)

ZX Breakout

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

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

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

Winston 22:16, 16 October 2012 (BST)

Failure rates, regenerating clocks

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

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

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

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

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

Winston 18:12, 29 September 2012 (BST)

Spectrum30

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

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

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

Winston 22:39, 19 September 2012 (BST)

On sale at last?

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

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

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

Winston 00:04, 4 September 2012 (BST)

The Raspberry Pi and the Spectranet

Raspberry Pi nestles amongst Spectranets at Imperica Horizons

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

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

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

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

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

Winston 22:42, 3 July 2012 (BST)

Emulating the Spectranet

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

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

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

Winston 10:42, 25 February 2012 (UTC)

Delinquency

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

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

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

Winston 21:39, 14 January 2012 (UTC)

Perhaps production is sorted out..

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

Watch this space...

Winston 16:27, 16 January 2011 (GMT)

Argh! A hardware problem!

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

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

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

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

Winston 22:01, 6 December 2010 (GMT)

The last 10% that takes 90% of the time

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

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

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

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

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

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

Winston 19:34, 2 November 2010 (GMT)

Concentrate!

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

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

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

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

Winston 21:39, 16 September 2010 (BST)

Argh

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

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

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

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

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

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

Winston 20:40, 18 July 2010 (BST)

Significant redesign

BASIC streams fail on the 128K toastrack

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

However, these plans were dashed.

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

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

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

Thurlby-Thandar LA4800 logic analyzer showing ZX bus activity

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

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

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

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

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

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

Winston 17:19, 4 July 2010 (BST)

ZXI

(Edit: Corrected port numbers)

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

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

The Spectranet CPLD performs a full 16 bit decode.

Winston 20:23, 27 June 2010 (BST)

The VCF, and gone off solder paste

Spectranet solder paste stencil

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

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

Older News

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