Current events
TNFS - Loading files
I had hoped to get a great tranche of work done on the Spectranet software on the long weekend, but it was not to be. The entire weekend got eaten up doing maintenance work on various machines (not computers, machines of the oily petrol-burning variety, where you always skin your knuckles on something sharp when the socket driver slips).
However, I did get the first bit of data loaded via the BASIC commands. I implemented the simplest of the commands, the %ALOAD command (Abitrary LOAD), which works similar to LOAD "file" CODE, except it just loads whatever's on the filesystem rather than examining a header and deciding whether it's BASIC, CODE, an array etc., and where in memory to put the file. As such, an address after CODE is mandatory. Loading a couple of .SCR files downloaded from WOS showed it was working.
However, I had lots of problems with timeouts, although I think a lot of this was due to it really actually timing out because the server on the PC didn't respond in a timely fashion (I could see this happening in Wireshark). However, I have the feeling that there may also be a bug in the poll routine in ROM, too - which would go some way to explaining the DHCP problems that people have experienced. I will implement the proper timeout/retry mechanism (with a longer timeout value)
I also did a little more research on the +3 reset problem. It's very interesting - the +3 resets fine if it's not crashed, but if it's crashed it won't reset. Doing CLEAR 24999 then RAND USR 25000 from BASIC (with no program at 25000) would crash the machine (usually with attributes scrolling up the screen after a few seconds). Trying to reset the machine while the attribute vomit was scrolling up the screen didn't result in a reset - as if the Z80 hadn't got the signal at all, although the screen got cleared. It'll take the logic analyzer to figure out what is actually going on when this happens, I think. But it's bizarre nonetheless - to the RESET circuit, a crashed +3 looks no different to a perfectly running +3. The reset problem only occurs also if the crash is causing things to be drawn on the screen (attributes or paper pixels). But resetting works fine if you do it while a game is running that's drawing to the screen. It is extremely bizarre, possibly a funny interaction with the ULA when there's sufficient load on the bus (the Spectranet will put a little extra stray capacitance on all the lines that it uses or are available to the through port). I'll have to try making the +3 crash this way with a different peripheral connected and see what happens.
Winston 23:12, 14 April 2009 (BST)
Feedback: On reset
Another bit of feedback I got was from Radastan, who said that the Spectranet wasn't initializing on many resets on his +3. I have observed it not initializing on power on (perhaps one time in three) on a +3, but it's always initialized on my +3 when the reset button was pressed.
I've not been able to do anything over the last month on account of being 4000 miles from the nearest Spectranet, so it's had to wait until now. And now I'm puzzled after looking at the schematic for the +3 - the reset circuit for this computer is bizarre. Most Z80 systems (including the rubber keyed 48k) have a simple resistor/capacitor on the reset pin, which functions just fine. At most, some reset circuits additionally buffer this (especially if the reset signal is used elsewhere), like I did with the Z80 single board computer I made a couple of years ago. The resistor/capacitor are sized such that the reset pin is held low for long enough for everything to be reset. As the capacitor charges, the voltage at the junction of the resistor and capacitor rises (this is what's connected to the Z80 RESET pin) until it goes above the TTL threshold, and then the CPU starts to run. The Spectrum+ reset switch simply shorts out the capacitor to restart this process.
But the +3 has lots of extra components in its reset circuit. Not just a buffer, but extra resistors and capacitors, and I'm not sure why it's been designed that way. The principles are the same, but at first glance it looks like the Amstrad engineers made a mountain from a molehill - but it's entirely possible that I'm missing something.
One thing I've tested is the voltages as seen by the buffer (Spectrum reset circuits are all very high impedance and the CPLD causes them to stop functioning unless it's buffered, hence there's a tiny little 1 gate buffer between the Spectrum's RESET output and the CPLD), and the CPLD itself. The voltage during reset on the CPLD RESET pin is 0.1 volts, well below the 0.8 volts max V(IL) for the chip. So it's not voltage levels. In any case, the latch in the CPLD that holds the reset state initializes as logic low anyway at power up, so even if the RESET signal got missed altogether, the latch state will be correct. Even if the Z80 started running before the CPLD was ready, the first thing the CPLD would do would be to grab ROMCS, so in that case there would be at least some weirdness, rather than a total failure to initialize.
So at the moment I'm stumped.
Winston 23:37, 2 April 2009 (BST)
At last, perhaps a server that works...
After a few false starts at the data centre, the server on which the wiki and SVN is stored perhaps might actually stay up now! A long litany of bad hardware has persistently kept spectrum.alioth.net relegated to my ancient UltraSPARC system that lives in the closet. The return to proper hardware has been somewhat hampered by me being on the other side of the world for practically all of March.
But now it's on its proper hardware, with real bandwidth rather than my ADSL upstream. It should be much faster.
Also, I will make it so that those who have prototypes can commit to SVN this week. (I'm going to have to recreate everyone's accounts first).
WebSVN is also newer and shinier, and now tarball downloads are enabled from WebSVN, so you can grab a whole directory as a .tar.gz archive. (some Windows users may need to download something to unpack them, but I think later XP and Vista understands .tar.gz)
Winston 22:40, 31 March 2009 (BST)
The BASIC interpreter
I've got the skeleton of the TNFS library calls done; there's still a bit to do (testing the retry mechanism, adding a few more bits to the proof-of-concept Perl server that runs on the PC) - but files can be opened, closed, read from and written to. Directories can be opened, read and closed. Chdir is actually implemented client-side (all filenames go over the wire as an absolute path). There's a few things I think I will change, for example, I think I'll simplify the way timestamps are sent (to an ISO date/time rather than seconds since the epoch) when statting a file.
But now I want to get the BASIC extensions done for this, and once that's done I might do another video for YouTube, perhaps demonstrating loading a game from the network filesystem or something like that. At the moment though I have a few things more that I need to learn about the ZX BASIC interpreter to get the most from it.
Actually, I've not done all that much to the code for a couple of weeks, it's been very busy at work and I've just felt too frazzled to work on yet more code when I get home, so, errmmm... I've been playing Enemy Territory instead. But I have some time off, so I'll have some more time to think about things.
Winston 22:38, 26 February 2009 (UTC)
Bug fixes
The first 3rd party bug report is in, and it's fixed :-)
Miguel Guerreiro discovered the NMI menu crashed on exit in USR 0 mode and also with his DivIDE firmware, and correctly guessed the cause was the ZX ROM paging being incorrect. Since the Spectranet ROM no longer accesses ZX BASIC for key scan routines, the calls to rearrange ZX ROM paging were now actually not needed in the NMI menu, so they've been taken out. If you have one of the prototypes, I suggest you get the new ROM image.
There is a new page off the main page of this site - Downloads. The first files available are the ethup tool and the current ROM images. Instructions on flashing new ROMs are included.
Winston 22:19, 4 February 2009 (UTC)
The Tiny (Or Trivial) Network Filesystem
As has been mentioned in the past, one of the things I want to have on the Spectranet is a network filesystem - basically something that's a bit better for filesystem use than FTP, but nothing so gnarly and complicated as NFS or SMB. Not everyone who wants a Spectranet will have mass storage for their Speccy, and having a network filesystem makes it easy to load files off another computer (which, in time, I hope to be things like another Spectrum).
First, I'm making the client on the Spectrum, and a proof-of-concept server written in Perl for the server. The client, as such, is a library of calls that correspond to the sort of things you find in 'fcntl', such as open, read, write, close etc. The idea is to provide an asm interface and a z88dk interface, just as in the socket library. For TNFS, I also want to provide BASIC keywords, and possibly at some stage, ResiDOS integration (so if you have something like a ZXCF, you would be able to load a ResiDOS module which adds support for TNFS via the Spectranet, allowing the Spectrum to be able to copy files from the network to a CF card. But that's a way off).
So far, I've started the basic functionality, and done "nominal" tests (i.e. not trying to break it) with the following calls:
- mount - mount a remote filesystem
- umount - Dismount the mounted filesystem
- opendir - Open a directory for reading
- readdir - Read a directory entry
- closedir - Close a directory
- open - Open a file
- read - Read from a file
- write - Write to a file
- close - Close a file
The open, read, write and close calls directly correspond to the same in C, i.e. are "system call level" rather than stdio. The z88dk, for instance, has those calls, and the z88dk stdio uses those low level calls to implement stdio.
In other news, I'm probably going to get the "Issue 1" PCBs made very soon - I had hoped that I could have others do a bit of hardware testing before I committed to more PCBs, but the pound sterling is rapidly collapsing and the PCB maker charges in US dollars. Already this has significantly increased costs - I bought more W5100 chips just before Christmas in case the pound collapsed further, and unfortunately, it has. Reykjavík on Thames, indeed. If the Bank of England starts printing money as has been rumoured, even Euroskeptics are going to wish we were in the euro...
Winston 18:04, 24 January 2009 (UTC)
Administratrivia
A few notices. You may have already seen that the wiki and WebSVN have been unavailable pretty frequently recently. This is because the server this all runs on is dying of a suspected case of Capacitor Plague. Unfortunately, I don't have physical access to the machine.
So in the meantime, I've moved the site onto a computer at home. This means things may run a bit slow - firstly, it's having to share the pathetic 256K upstream you get with ADSL with all my other network traffic, and secondly, it's now practically running on a retrocomputer - the only spare hardware I have with sufficient memory is an old 333MHz UltraSPARC system (I don't want to run it on my PC, for one, I the fan in the new PSU on my PC is so loud I can hear it in the next room, which happens to be where I sleep). It could have been a lot worse, it could have ended up on the old VAX that I have, then you'd have had to have waited about 5 minutes for a page load!
The SVN repo isn't yet back up, but it will be shortly, so you may find some broken links in the wiki.
Winston 00:11, 14 January 2009 (UTC)
Through port success
As I said last time, the NMI problem turned out to be a software bug. Gasman kindly let me use the Open ZX ROM keyboard routines under the MIT license from his GPLd OpenZX ROM project which saved me the effort of writing and debugging one. I wanted to use someone else's as it's likely to have already been debugged, and I need to start getting some of the prototypes out soon.
So the board now works great with the ZX-CF plugged into the back of it, including the Spectranet NMI menu, so now my +3 has both access to a CF card and the network. I tested all the prototypes by loading the new ROM image off the CF card and programming them that way. This meant I had to cut slots in the through ports of all the PCBs, but the job's now done. (I only found out later that PCB Cart would cut the slots for me if I included them in the PCB outline).
I think the combination of a ResiDOS device and the Spectranet could lead to some very good things.
Winston 19:46, 3 January 2009 (UTC)
Through port testing
Happy new year!
The first job of 2009 is to test the through port. The last time I did any testing was on the prototype-for-the-prototype (the breadboarded monstrosity that eventually got turned into the prototype PCB), with the DivIDE. Since then, I have got a ZX-CF board, which has ResiDOS, and as such is a bit more complex than the DivIDE.
So I had to cut a slot in a prototype PCB (something I need to do for the rest of the boards I've made). The DivIDE works pretty much perfectly, The ZX-CF is a little more awkward. It generally works fine, but its execution trap method seems to be very aggressive and it still traps NMI even when the Spectranet traps it...no, update, scratch that -- it's actually a bug in the NMI handler. Well, not a bug as such, but after looking at the logic in the CPLD and scratching my head a bit, I remembered that to save memory in ROM page 0, I had used the ZX ROM's keyboard handler...this of course, means a call out to the Spectrum ROM, and the return comes back in via RST 8. Oops. In light of this, I probably ought to put a key scanning routine into one of the Spectranet ROM pages so it's not necessary to call the ZX ROM. I ought to do that before tinkering with TNFS any more!
I already expected the RST 8 trap on the Spectranet to need disabling, with ResiDOS running - only one board should be allowed to handle RST 8. But none of these are fatal problems. The Spectranet socket library can still be called with the ZX-CF plugged into the back of the Spectranet, due to the unique design of the library entry point instruction trapping. I tested this with the IRC client - I put Spectrum IRC onto a CF card, and loaded it with ResiDOS, then connected to IRC. All this means is with the ZX-CF at least, utility programs should be stored on the CF card and loaded with ResiDOS, rather than using the Spectranet NMI button. (It should be perfectly possible to write network aware ResiDOS modules, too).
The RESET trap works fine too, with the ZX-CF, because that's pre-triggered by the reset signal itself, and as such A15 is already being held high when the CPU begins executing instructions.
Winston 17:03, 1 January 2009 (UTC)