Current events
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)