|
|
| Line 1: |
Line 1: |
| == ZXI == | | == Significant redesign == |
|
| |
|
| (Edit: Corrected port numbers)
| | [[Image:128debug1.jpg|thumb|right|300px|BASIC streams fail on the 128K toastrack]] |
|
| |
|
| 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:
| | 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). |
|
| |
|
| * 0x003B - Page A memory selector
| | However, these plans were dashed. |
| * 0x013B - Page B memory selector
| |
| * 0x023B - Programmable trap register
| |
| * 0x033B - Control register
| |
|
| |
|
| The Spectranet CPLD performs a full 16 bit decode.
| | [[Image:128debug2.jpg|thumb|right|300px|When my bench looks like this it generally means there's big trouble]] |
|
| |
|
| [[User:Winston|Winston]] 20:23, 27 June 2010 (BST)
| | In the photo (top right) you can see the half-loaded menu with the rather strange "8 End of file" message with a flashing K cursor stuck to the end of it. This first came to light at the Vintage Computing Festival when Chris Smith gave me a transistor to fix one of my two dead toastrack 128K Spectrums, and the games menu wouldn't load. (So on that machine, I loaded the Twitter client and left it, as we went to lunch. I was very surprised when I came back and found people playing games - what had happened is the menu intermittently worked, and got more reliable as the machine warmed up, but I didn't know that then). At the VCF, I didn't have any time to actually analyze it and we were going to get some lunch, anyway, and I was speculating there may be an incompatibility in the 128K's ROM. Andrew Owen thought not, he didn't think there would be anything that would break channels and streams - he suggested "put the ROM in your +3 and see if it works", so I did. And it worked fine. |
|
| |
|
| == The VCF, and gone off solder paste ==
| | 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:Stencil.jpg|thumb|right|300px|Spectranet solder paste stencil]] | | [[Image:128debug4.jpg|thumb|right|300px|Thurlby-Thandar LA4800 logic analyzer showing ZX bus activity]] |
| | [[Image:128debug3.jpg|thumb|right|300px|Close-up of the screen]] |
|
| |
|
| 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).
| | 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. |
|
| |
|
| 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
| | 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. |
|
| |
|
| == Twittering ==
| | 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. |
|
| |
|
| You may recall some time ago we did a Spectrum twitter client (at the CSS meet in a pub in Oxford). It was of course a hack over a pint of beer.
| | 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. |
|
| |
|
| Finally, I've written a proper Twitter client that uses the Twitter API and accepts a login/password/tweet. This is of course something to be shown at the VCF which is now less than a week away! If you're not going to be able to get to the VCF, there's a video about it on YouTube ( http://www.youtube.com/watch?v=-ECnN7jdgA4 ) so you can see what it's like. The client itself uses a small HTTP library which is unsurprisingly called "libhttp" which I finished off last week. The HTTP library handles the basics of the HTTP protocol - processing headers, response codes, sending POST and GET requests etc. It's still a bit basic (no cookie handling, for instance) but I've tested it with a few sites and obviously it works with Twitter. If I weren't having server problems (again) you would be able to see it in SVN right now...
| | 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. |
|
| |
|
| In other news, components are arriving for the new revision of the PCB - I got a package full of goodies from Farnell, I got the solder paste stencils back from the USA, and the PCBs have been shipped - hopefully they'll arrive before the VCF so I can have a couple of brand new ones on show.
| | 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. 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. |
|
| |
|
| [[User:Winston|Winston]] 14:18, 13 June 2010 (BST) | | [[User:Winston|Winston]] 17:19, 4 July 2010 (BST) |
|
| |
|
| == D'oh == | | == ZXI == |
|
| |
|
| I got a Spectrum 128K (toastrack) today, so I began to test it with the Spectranet, and it didn't work very well.
| | (Edit: Corrected port numbers) |
|
| |
|
| While investigating, I thought I'd check for an intermittent CPU M1 line, so I hooked the oscilloscope up to pin B24 on the edge connector (with the Spectranet connected). Normally, I put in a little "breakout board" to make it easier to connect the probe, but since pin B24 is on the top side, I could just hook the probe onto the Spectranet's edge connector.
| | 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: |
|
| |
|
| It turns out that M1 was fine. It just wasn't fine when I removed the probe and it briefly touched pin B23... which is the 12 volt line.
| | * 0x003B - Page A memory selector |
| | * 0x013B - Page B memory selector |
| | * 0x023B - Programmable trap register |
| | * 0x033B - Control register |
|
| |
|
| I now only have three working Spectranets :-( Fortunately, the only IC to use M1 is the CPLD (which now functions as a space heater instead of as programmable logic), but it's also killed the Spectrum 128K's M1 line.
| | The Spectranet CPLD performs a full 16 bit decode. |
|
| |
|
| [[User:Winston|Winston]] 20:47, 1 June 2010 (BST) | | [[User:Winston|Winston]] 20:23, 27 June 2010 (BST) |
|
| |
|
| == Stencils == | | == The VCF, and gone off solder paste == |
|
| |
|
| A problem with constructing the hardware is that it takes about an hour to paste the board, place the components, then reflow... but then three hours finding all the open circuits where the solder didn't quite reflow properly because there was too little paste, or one pin of a chip was a little bit lifted. (The short circuits, by contrast, are mostly easy to find with a magnifying glass). I'm spending too long doing continuity tests from tiny little pins on TSOP and TQFP devices.
| | [[Image:Stencil.jpg|thumb|right|300px|Spectranet solder paste stencil]] |
|
| |
|
| The solution to this is hopefully a 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). |
|
| |
|
| Courtesy of a post on the Sparkfun Electronics forums, I've discovered a firm in the United States that makes laser cut kapton stencils, and they can go down to 0.4mm pin pitch (the pitch of the W5100, 0.2mm pads with 0.2mm spaces). It's 3 mil (3 thousandths of an inch - electronics is rife with mixed imperial and metric units) thick. They fill effectively an A4 sized sheet of kapton with solder paste stencils, as many as will fit from your design. To use the stencil you line it up with the board, then put some paste on top, and squeegee it across. The paste goes into the holes cut into the stencil (underneath which are the pads). When done, remove the stencil, and you have paste laid down accurately and measured on each pad. That's the theory, at least.
| | 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 |
| | |
| Hopefully with a little bit of practise this means the components will solder perfectly first time and just work. Not only will it mean less time spent putting paste down by hand, but hopefully eliminate the hours of debugging trying to find the bad connections.
| |
| | |
| And it's really pertinent right now because I've just spent over two hours chasing open circuits (all to the flash chip, which has the smallest pads).
| |
| | |
| The company making the stencils is here - http://ohararp.com/Stencils.html
| |
| | |
| [[User:Winston|Winston]] 20:44, 27 May 2010 (BST)
| |
| | |
| == "Production boards" ==
| |
| | |
| Well - it's happened.
| |
| | |
| The first 10 production boards were sent to the PCB factory last night, I should get them within the next 3 weeks or so.
| |
| | |
| There are not many changes from the prototype PCB:
| |
| | |
| * "Disable all" jumper corrected so it actually makes a change on the appropriate CPLD pin. (The error was on the schematic, carried through to the netlist and onto the PCB). The only PCB bug that I've found.
| |
| * Four mounting holes added
| |
| | |
| I managed to get the mounting holes in (they are the same size as the plastic clips on the RJ-45 connector, and will take either a plastic clip or a small screw) without having to make the PCB any bigger. The two screw holes on the left of the board were easy - I just added plated holes of the appropriate size, and connected them to the ground plane. The other two caused tracks to get re-routed, something that always makes me nervous just in case I miss something! The PCB software helps me verify everything got reconnected - I can select a pin on one of the chips on each track I changed, and check that everything in the netlist still shows up in green. But I still think of all those expensive coasters I'll end up with if I've missed something... Those two right hand mounting holes either need a plastic clip, or if using a metal screw, an insulated washer between the PCB and the screw head due to the proximity of tracks. While the solder mask should prevent contact, it could easily wear through when tightening a screw and you then end up with a track shorted to ground.
| |
| | |
| I'm also assembling one of the last prototype PCBs I have left, and I found that I've run out of some components (specifically 150uF tantalum capacitors for the 3.3v voltage regulator), and used the last 74HCT1G125 IC that I have, so I need to re-order these so they are here when the new PCBs arrive.
| |
| | |
| I hope to have at least 5 working boards for the Vintage Computing Festival - four for the machines I'm demonstrating, and hopefully the fifth to connect to Chris Smith's Harlequin.
| |
| | |
| [[User:Winston|Winston]] 22:57, 25 May 2010 (BST)
| |
| | |
| == Roadmap ==
| |
| | |
| I've not updated this in a long while - this is partly because of the troubles I've had with this web server, and partly because I've just been insanely busy. So here's a round-up of recent events, and what's to come... | |
| | |
| === Retro Rewind, April 2010 ===
| |
| | |
| Retro Rewind, organized by sscott on the Retro Gamers forum was a great success. The venue was superb - held at Sheffield Hallam University's Student Union - lots of machines, lots of stuff on offer, and of course I had two Spectrums equipped with the Spectranet. Visitors certainly appreciated the quick and easy loading of files over the network from the file server. I wrote a menu program in BASIC, which demonstrates the BASIC extensions as well as BASIC streams working to build a menu and load games from the network filesystem. Visitors just had to type LOAD "" and they were away. Simple and fast! It was good to meet up with various forum members once again, and meet some new people (I was kindly given an Acorn A3010 by woody.cool of the RG forums, and I bought my first Amiga, an A1200 - complete with a heap of games. I've not had time to really play with it though).
| |
| | |
| === Getting ready for the VCF ===
| |
| | |
| The next event is the Vintage Computing Festival. It's at the historic Bletchley Park, and judging by how fast the hotels are filling, is going to be a very well attended event. I hope to have four Spectrums with the Spectranet, and with a bit of luck Chris Smith's Harlequin with a Spectranet too. Again, the MicroVAX will be the file server. I'm hoping to have internet access here so people can IRC from a Spectrum, and perhaps even update Twitter from a Spectrum. I need to build two more Spectranets before this will happen (I have three working - one of them I repaired tonight, the 25 MHz crystal had gone bad which really surprised me). If you're coming to the VCF, come and see the Spectranet and have a play with it!
| |
| | |
| === Making more Spectranets ===
| |
| | |
| After the VCF is done, I have one more thing to do on the software side (make sure that TNFS loading copes with dropped packets) and then I think it's time to actually get some Spectranets into people's hands. I intend to build 10 at first. Before I get more PCBs made I need to find a good place to put at least three plated holes in the PCB to allow it to be mounted in a box. I've talked once or twice with Rich Mellor of RWAP software, who does the DivIDE Plus - I may see if he fancies doing some "value add" and packaging it up nicely and then selling the whole device through his site. Once the VCF is over and done with it shouldn't take too long to get the first Spectranets made (I'll probably put these for sale myself as a "beta" - after all, they don't really have terribly wide testing - all I can say is they work well with my network switches and my Spectrums). I'd like to be in a position to start building these by the time I get back from RetroEuskal in July, if not before. Expected price for assembled units will depend somewhat on the dollar/pound exchange rate, the PCB being the most expensive single component (almost half the cost).
| |
| | |
| === RetroAcción ===
| |
| | |
| I have had the great honour to be invited to join RetroAcción, a Spanish society for the preservation and demonstration of retro hardware and all things related. They organize both RetroEuskal in Bilbao and Retromañía in Zaragoza, and exhibitions like "Del pincel al pixel" (Paintbrush to Pixel) celebrating the fantastic arkwork of Alfonso Azpiri, who did a great deal of artwork "back in the day" for Spanish games on the Spectrum. So I'll be off to RetroEuskal again, and hopefully Retromañía, but this time as part of the organization, not just someone coming to chat about his project! I'm very excited to be going again - I had immense fun at RetroEuskal last year, not to mention eating far too much.
| |
| | |
| === Documentation ===
| |
| | |
| "Documentation is the castor oil of programmers. Managers know it must do programmers good, because they hate it so much"
| |
| | |
| But if I want anyone to be able to develop for the Spectranet, I have to do more documentation, in particular, how to use BASIC - what I hope is that the BASIC extensions make network programming accessible to everyone - so tinkering with networks is not just the preserve of asm and C programmers (for whom tutorials and socket library documentation already exists). But the BASIC streams module needs documenting first. Other things are needed like at least a "Getting started" sheet to ship with the device, so people know what the jumpers do, how to configure it, etc.
| |
| | |
| [[User:Winston|Winston]] 21:04, 13 May 2010 (BST)
| |
| | |
| == Surprises ==
| |
| | |
| Doing further testing of ZX BASIC stream support has been very fruitful in shaking out bugs in the core socket library.
| |
| | |
| *Edit*
| |
| I had thought this bug had existed for the lifetime of the Spectranet and further more... but no, it was a regression I'd put in a couple of weeks ago (duh!). A new check for the socket going dead during the "wait for data loop" in the buffer unload routines was put in the wrong place, with the result that it caused a race condition.
| |
| *End edit*
| |
| | |
| The regression was this. When receiving it was checking for the socket buffer being in the RST state before checking to see whether there was data to unload (and also an unbalanced stack, which what actually caused the crash - if it left due to the RST state it wasn't popping a value that had recently been pushed). In the case of a short enough piece of data, the remote end was closing down - and the resultant race was either the code would have passed the check for RST and started to check to see if there was a buffer to unload, or the RST condition became set a little bit sooner, so the code saw the status had gone to RST and exited before checking to see if there was more data to be unloaded from the ethernet buffer. Up until now, the RST flag in the hardware had always been set just after we'd checked it, so the buffer would get copied correctly. But for some reason, the W5100 was beating the code tonight (even though the code in question hadn't changed, and therefore took the same number of T-states).
| |
| | |
| The fix to the core socket library code fixed this particular problem with BASIC streams. Now to find the next bug...
| |
| | |
| [[User:Winston|Winston]] 22:46, 2 March 2010 (GMT)
| |
| | |
| == Back to BASICs ==
| |
| | |
| ZX BASIC is slow. Very, very slow. But this slowness, it turns out, has its uses.
| |
| | |
| I noticed that somewhere along the way I forgot to actually get the streams module into an anywhere near finished state (while it works, it lacks certain very important features that are needed for the Spectranet to be useful to the BASIC programmer). It's been an interesting shake-down for the base socket library, which I had thought was done and dusted many months ago...
| |
| | |
| All the tests that I had used, basically the Spectrum could keep up. The tests were written in C or raw assembler. So were real programs, such as the network filesystem and the IRC client. For general networking, the Speccy does seem to cope quite happily with keeping up - it's never pulling in too much data at once, and never really gets behind. As you may have seen, the raw socket library goes fast enough to show full motion video. But BASIC is another matter entirely, and presents a number of interesting challenges.
| |
| | |
| First, messages end up piling up in the W5100's buffer as the BASIC program can't even keep up with another Spectrum. I've been doing most the testing with a server program to test the new control/status stream that's available to BASIC. This revealed a couple of bugs in the low level routines that load and unload the ethernet buffers (the "wait for data" or "wait for buffer space to fill" loops could hang, because they didn't actually check that the connection went away in the meantime). It also revealed bugs in the poll routines. The W5100 has several status bits for the interrupt register, but they all get cleared when you say "I've handled the interrupt for socket N". This meant if you used poll to check whether there was data waiting (but the socket had also closed), when you went to poll again, the closed interrupt flag had also cleared. Now in a machine code program that may check all the flags at once and know to read and then close, that's fine. But the BASIC interface only handles one flag at a time - so the read would end up clearing the close flag, and the BASIC program would never get the message that the socket had also been closed. So the poll routines now also check the status register so that they reliably return a closed flag always.
| |
| | |
| The extra challenges put up by BASIC are this. Essentially, BASIC doesn't really map onto the way the socket library really works. The socket library only cares about bytes - it has no concept of "records". But the BASIC INPUT# routine is very much oriented around the concept of a "record", or at least a carriage return terminated string. This means the streams module buffers incoming data, fills the BASIC INPUT buffer until it hits a CR, and exits. Since it may read 256 bytes (and these 256 bytes may contain what BASIC considers are a dozen actual records) we may do a [[recv]]() once, and INPUT# is actually executed several times for the one call to recv() as the buffer is emptied. As far as the socket library is concerned, if you call [[poll]]() at this stage, there's nothing waiting, and correctly it returns with all the flags cleared. Or it may have even noticed the connection has gone away, and so return the closed flag. But as far as BASIC is concerned, it's not over yet. There may not be anything more to come along the network... but there may be still stuff waiting to be emptied from the buffer. So the poll routine for the BASIC control/status channel must not just call the socket library's poll, but also check the state of all the stream buffers.
| |
| | |
| All this writing is coming to one final point: I want to get the BASIC streams support into a ...umm...basically demonstrable state before I make a video of "Progress so far". Soon, I hope, really soon...
| |
| | |
| [[User:Winston|Winston]] 21:16, 15 February 2010 (GMT)
| |
| | |
| == Porting and optimizations ==
| |
| | |
| The simple portable TNFS server is (I think) pretty much done, except for an 8 bit version. I've tested it on Mac OSX (64 bit intel), Linux (32 bit intel), OpenBSD (64 bit SPARC), Windows XP (32 bit Intel). Windows of course gave all the problems, its POSIX interfaces are annoyingly ever-so-slightly-different to the Unix world (for example, "open" requires an extra flag O_BINARY to work - I notice that Python fell into this trap too), and the socket interface on Windows needs extra things that are not needed for Unix types. And all the header files are different. But at least it works now!
| |
| | |
| I've also worked a little on the optimization of the network file system routines. The read routine was essentially double buffering the data (reading the block off the network into a Spectranet buffer, then copying it to wherever it was supposed to finally land). This has been changed so that the header is first decoded, then the remainder of the data (the actual block of data read() is supposed to return) is copied directly to its destination from the W5100's buffer. This probably saves around 8,000 T-states per 512 byte block read. It certainly seems faster when loading a 128K snapshot file, although it probably only saves 2/3rds of a second (a 128K snapshot loads in about 2 secs).
| |
| | |
| Now I probably ought to make that video I've been going on about for the last 3 months...
| |
| | |
| [[User:Winston|Winston]] 17:18, 31 January 2010 (GMT)
| |
| | |
| == Portable network fileserver ==
| |
| | |
| The current job is a portable fileserver program for the simple TNFS protocol.
| |
| | |
| The server program I have used to test the filesystem is something I hacked together using perl, for reasons of expediency. However, to make it simple for Windows users (and don't have a perl interpreter by default), and also as a basis for a fileserver for 8 bit systems, I'm writing a lightweight server in C. It'll also be better for "retroservers" like the MicroVAX that I have. Although the perl server runs on the VAX with adequate speed, a server written in C will run a lot faster. The idea is to have something very portable and small and simple. The architectures I intend to test with the first version will be sparc64 (big endian, 64 bit), VAX (little endian, 32 bit), Win32 (x86, little endian, 32 bit), macppc (32 bit big endian) and mac on intel (x86_64, 64 bit little endian). The endianness matters for testing because 16 and 32 bit integers are encoded as 16 and 32 bit values in the datagrams as little endian values (most 8 bit systems seem to deal with 16 or 32 bit values in a little endian manner).
| |
| | |
| My goal at the moment is to make the "simple" TNFS server. This TNFS server is for LAN use, so that someone may share files between their PC and a Spectrum. It doesn't include things like authentication and authorization. The idea is that the user sets the server up to share a specific directory tree and it works a bit like ResiDOS - it lets you access files within. A later goal is to find out what I need to use for ESXDOS on the Spectrum, and make a Speccy version of the fileserver, so it can serve files from a DivIDE. All the protocol level stuff should be portable, as will the network code. Filesystem level stuff will probably need some Speccy-specific #asm sections - given that ESXDOS is brand new it may be some time before the z88dk gets ESXDOS support for its base I/O libraries. (However, ESXDOS does have a POSIX like interface which should mean it won't be too bad to port).
| |
| | |
| Later, I may make a proper "multiuser server" (that is, it'll integrate with the host OS authentication and authorization methods). However, I'll only do this for Unix. The last time I touched Windows at this level was with NT 4.0 and lots of things have changed with Vista and newer, so someone more familiar than me with the Windows security model would have to take that up.
| |
| | |
| == The snapshot manager ==
| |
| | |
| [[Image:Snapman.jpg|thumb|300px|right|Snapshot manager work in progress]]
| |
| | |
| Unfortunately "real life" problems have kept me away from doing serious work with the Spectranet software for a week or three, so I'm well behind where I expected to be. However, I still managed to get the first pass of the snapshot manager working. At the moment it's rather rudimentary, but it does at least have a scrollable file/directory browser, and it can load and save snapshots. It is invoked via the NMI menu (and is a ROM module). I am also moving the snapshot code itself to this module - for testing, this had lived in the BASIC extensions module. Hopefully, by next week I'll have the current firmware in a state where it's worthy of making a video update on what the Spectranet does so far.
| |
| | |
| The other feature I need to add is a rename system call for filesystems in the base ROM. This will need a slight rearrangement of some internal functions because the jump table is full, and there are some functions that can be combined or moved elsewhere to free up entries (I don't really want the jump table to take up more than 256 bytes). Also I need to write a portable TNFS server (the current one is in Perl, and although this is portable enough, Windows users generally don't have a perl interpreter, and most importantly - a Spectrum will never have a perl interpreter and I want the Spectrum itself to be able to be a file server for the ultimate retro network). Then after that, get some new hardware made for those who want one!
| |
| | |
| [[User:Winston|Winston]] 23:05, 28 December 2009 (GMT)
| |
|
| |
|
| == Older News == | | == Older News == |
|
| |
|
| | * [[Old news (Jan 10 - June 10)]] |
| * [[Old news (July 09 - Dec 09)]] | | * [[Old news (July 09 - Dec 09)]] |
| * [[Old news (Jan 09 - Jun 09)]] | | * [[Old news (Jan 09 - Jun 09)]] |
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
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. 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.
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
