Difference between revisions of "Current events"
| Line 1: | Line 1: | ||
== The Analogue World == | |||
For a great deal of time, I've been doing everything with the Spectranet on my +3. There's a couple of good reasons for this: first, it has RGB out (and all my UHF only Speccies have serious modulator drift problems), and secondly, the floppy disc drive makes it easier to reload the Spectranet ROM if I bork it. (Otherwise, it must be loaded through the tape port while I hold the DISABLETRAP connection at 5v by hand...) | |||
But I got given a Spectrum+ last weekend, and it turns out it has a good modulator (it still drifts, they all do) but it gives good colour output on my TV. But I just got the "pixel vomit" screen when I tried to use it with the Spectranet. I had the same problem with an issue 4 board with the composite mod earlier, but I had put it down to a dirty edge connector. So I tried it on more machines, pixel vomit on all of them except my Issue 2 Spectrum. Which, once warmed up for a few minutes...also gave pixel vomit. | |||
There was obviously some problem with initialization. First, I checked the Spectrum had actually come out of the RESET state by checking the voltage of the RESET line, it was indeed 5 volts. (The Spectrum's RESET circuit is very high impedance, and the CPLD will prevent it from working at all, so it's buffered before reaching the CPLD). I checked various other things, checked that the clock signal was present (recently, I made changes to the clock circuits in the CPLD), I checked that the voltage was adequate, and everything obvious. Then I started up Xilinx ISE and started going through the CPLD design. | |||
One thing I had in mind was the slowness of the reset circuit on these machines - it's just a simple R/C circuit, and I had thoughts that perhaps it was possibly resulting in a bit of "jitter" in the CPLD as the voltage passed through the threshold oh so slowly. I tried all sorts of things to eliminate them - they'd always work the first five or six times (solved it! I thought each time...), but then would inexplicably fail. (As the Spectrum warms up, the R/C reset circuit gets slower). The one place I didn't think to look after banging my head on the table for two days was the memory paging registers in the CPLD. I had forgotten they get reset too (they don't actually need to be reset), and didn't even look at that part of the circuit - until out of complete frustration I had deleted the entire RESET net in the CPLD... | |||
What is happening is the RESET level reaches the Z80's logic high threshold long before it reaches the logic high threshold for the 74HCT1G125 buffer, which feeds the CPLD's reset input. So the CPLD is being held in reset for quite a long time after the Z80 starts running - at least 100,000 T-states! The best fix is to just get rid of the reset circuit from the memory paging registers, but with a few Spectranets already out there with people who don't have the kit to program the CPLD, well, a huge delay loop in software was the pragmatic approach to take. And of course, now it works perfectly on all my Spectrums. | |||
[[User:Winston|Winston]] 20:20, 26 September 2009 (BST) | |||
== At long last, addressing +3 BASIC == | == At long last, addressing +3 BASIC == | ||
Revision as of 19:20, 26 September 2009
The Analogue World
For a great deal of time, I've been doing everything with the Spectranet on my +3. There's a couple of good reasons for this: first, it has RGB out (and all my UHF only Speccies have serious modulator drift problems), and secondly, the floppy disc drive makes it easier to reload the Spectranet ROM if I bork it. (Otherwise, it must be loaded through the tape port while I hold the DISABLETRAP connection at 5v by hand...)
But I got given a Spectrum+ last weekend, and it turns out it has a good modulator (it still drifts, they all do) but it gives good colour output on my TV. But I just got the "pixel vomit" screen when I tried to use it with the Spectranet. I had the same problem with an issue 4 board with the composite mod earlier, but I had put it down to a dirty edge connector. So I tried it on more machines, pixel vomit on all of them except my Issue 2 Spectrum. Which, once warmed up for a few minutes...also gave pixel vomit.
There was obviously some problem with initialization. First, I checked the Spectrum had actually come out of the RESET state by checking the voltage of the RESET line, it was indeed 5 volts. (The Spectrum's RESET circuit is very high impedance, and the CPLD will prevent it from working at all, so it's buffered before reaching the CPLD). I checked various other things, checked that the clock signal was present (recently, I made changes to the clock circuits in the CPLD), I checked that the voltage was adequate, and everything obvious. Then I started up Xilinx ISE and started going through the CPLD design.
One thing I had in mind was the slowness of the reset circuit on these machines - it's just a simple R/C circuit, and I had thoughts that perhaps it was possibly resulting in a bit of "jitter" in the CPLD as the voltage passed through the threshold oh so slowly. I tried all sorts of things to eliminate them - they'd always work the first five or six times (solved it! I thought each time...), but then would inexplicably fail. (As the Spectrum warms up, the R/C reset circuit gets slower). The one place I didn't think to look after banging my head on the table for two days was the memory paging registers in the CPLD. I had forgotten they get reset too (they don't actually need to be reset), and didn't even look at that part of the circuit - until out of complete frustration I had deleted the entire RESET net in the CPLD...
What is happening is the RESET level reaches the Z80's logic high threshold long before it reaches the logic high threshold for the 74HCT1G125 buffer, which feeds the CPLD's reset input. So the CPLD is being held in reset for quite a long time after the Z80 starts running - at least 100,000 T-states! The best fix is to just get rid of the reset circuit from the memory paging registers, but with a few Spectranets already out there with people who don't have the kit to program the CPLD, well, a huge delay loop in software was the pragmatic approach to take. And of course, now it works perfectly on all my Spectrums.
Winston 20:20, 26 September 2009 (BST)
At long last, addressing +3 BASIC
The Spectrum +3 brought some good enhancements to the world of the Speccy (even if a bit flawed - oh for a 3.5in disc instead of the unusual Amstrad 3in unit), but also some irksome compatibility issues. Not only is it incompatible with any peripheral with a ROM which wasn't +3 aware (i.e. anything designed before the +3) due to the change in the edge connector, but the other problem is the way the BASIC interpreter in 128K mode breaks with what happened with the toastrack 128 and the grey +2. In those machines, all the BASIC interpretation was still strictly done by the original interpreter. But in the +3, some work is done in a different ROM - including the RST 8 error handler.
So when you trap an error to extend BASIC, it suddenly doesn't work even though you've made your device electrically compatible with the +3.
I want the Spectranet to smoothly support all of the original machines - that is the rubber 48K machine up to the +3, and anything with a compatible edge connector and compatible ROMs. I want it to smoothly support +3 BASIC as well as 128K BASIC without forcing USR 0 mode.
This is how I'm going to do it.
On power up, the Spectranet will find out whether it's on a machine with the +3 ROMs. This can be done by looking at the first 6 bytes of ROM 1, which contain the string "Syntax" on a +3. It will store this in a Spectranet system variable (i.e. in the 0x3F00 system variables area in the Spectranet's own static RAM).
When the error trap fires, it'll see if this flag is set, and if so, will check to see whether we're in USR 0 mode or in 128K BASIC mode. This can be done by checking for the presence of the paging routine, which is kept where the printer buffer used to be in RAM. USR 0 mode and 48K mode wipes this routine out - so we can use this to tell that we're in 128K BASIC. If we are in 128K BASIC, ROM 3 (the original syntax ROM, and where the ROM routines that the Spectranet BASIC extensions use) will be paged for the duration of the BASIC extension, then restored when we exit, either due to successful completion or some sort of error.
I suspect I'll hit some bumps in the road while doing this (I hit a few while writing the detection routine yesterday). But the upshot of this is that BASIC support for all the machines should "just work".
Also, this week, I've implemented the "default file" concept. If you type LOAD "", it will load the first BASIC block it sees in a file named "boot" in the current working directory (TAP format, as the Spectranet's BASIC filesystem support uses TAP as its container format). This even works with the 128K Loader. What it's doing is trapping the tape loading routine and opening the file "boot" if it's present, and then setting up normal tape traps to load this TAP file. The upshot of this is that the next retro party I go to, it'll be really easy for people to just load stuff over the network - just LOAD "", or on a 128K machine, select the Loader, and away you go. (I'll write a little menu program in BASIC for navigating to the various programs).
Winston 19:55, 17 September 2009 (BST)
The Spectranet world tour continues!
First Oxford, then Bilbao, now Huddersfield!
The Spectranet was on show (with all the latest code enhancements) at Retro Reunited, on the 12th/13th September. The Speccy was paired up with a MicroVAX as a fileserver. (The VAX was also the DNS and DHCP server, unfortunately the hotel had no "wider LAN" with these things, nor an internet connection other than WiFi. I could have set up my old PowerBook to be a router on WiFi, but owing to a shortage of TVs, I only had one Speccy on the network so decided to show off the network filesystem rather than the IRC client!)
Which brings me on to more recent developments.
Since the last update, I've added more code to the BASIC streams support, so you can now write a server program in ZX BASIC. Also, I've made the mount command for mounting filesystems MUCH better - instead of passing half a dozen parameters, which was rather clumsy, you now supply just two - the mount point, and an URL for the filesystem you want to mount, in the usual format - proto://user:passwd@host/some/path . The default protocol at the moment is TNFS, so if you just specify an IP address or hostname, it does an anonymous TNFS mount of the root on that host.
Also, I've now added the ability to mount more than one filesystem at a time - up to four filesystems can be mounted simultaneously. If the filesystems are TNFS, then only one network socket is used for the lot, since TNFS is a very low resource UDP protocol.
What was clear from Retro Reunited is that one of the priority developments for the BASIC module is to add a "default" file to load (this will of course work with the Loader on 128K machines). Of course, people just casually playing stuff - for example, at a show like this, may just want to start the Speccy and have it load a menu of games. The other big feature I think people would like is the ability to save snapshots to a filesystem - a bit like the Multiface - hit the NMI button, then save a snapshot to any of the mounted filesystems.
Winston 22:11, 14 September 2009 (BST)
RetroEuskal, and BASIC streams
No updates for about a month, but I've been a bit busy!
First, I had the grand challenge of demonstrating the Spectranet at RetroEuskal - held inside Euskal Encounter (the second largest LAN party in Spain, with 4096 network ports - most in use). Fortunately, the DHCP client worked fine with the Euskal Encounter DHCP servers, and braved a very busy network segment with vast quantities of broadcast traffic (mostly DHCP requests and ARP who-has requests). The demonstration went well, and people even seemed to understand my undoubtedly heavily accented Spanish...
Secondly, one of the things I'd been working hard on so that I could demonstrate it at RetroEuskal was BASIC streams. I got the prototype code done just in time, and tested it with things like an SMTP client written in ZX BASIC (yes! It worked!). So far, you can write TCP client programs in BASIC. Writing servers is going to take a bit more effort (it'll need a separate control channel so that you can peek at the state of things without reading).
It's now possible to write a program like this in BASIC:
10 %connect #4, "some.computer.com", 2000 20 INPUT #4;"Tell me> ";a$ 30 PRINT "Remote computer said: ";a$ 40 PRINT #4; "You said: ";a$ 50 IF a$="q" THEN GO TO 100 60 GO TO 20 100 PRINT #4; "Bye!" 110 %close #4
Once accessability from BASIC and the network filesystem is done, basically, the base software is actually finished. The end is in sight!
On the hardware side, I'm thinking of getting some PCBs made, with the aim of making sure my modifications for "production" are good. There's one bug that had to be fixed (which won't affect normal users), plus I want to try and make a small mod to the routing of the ethernet traces from the magjack to try and get rid of a couple of vias, sometimes the W5100 has trouble getting a stable connection on reset, and I want to eliminate that from my enquiries. Also I want to put another jumper in so the user can select the voltage source for the 3.3v regulator - either the 5V from the Spectrum (works on all models), or the 9V (48K only) - the reasoning, to lessen the load on a rubber key Speccy's 7805 regulator.
Winston 21:33, 6 August 2009 (BST)
A whole lot of new excitement
Just over a week ago, you may have seen the news that the Speccy made its first tweet on Twitter. The client was hacked together in the Gloucester Arms in Oxford, over a pint of Black Beauty (you do get some odd looks with a Speccy on the pub table, but it was the CSS meet!)
But other than that, more exciting times: I've put together a basic automounter (it needs much more work to do what I eventually want it to do), so that filesystems may be mounted at boot/reset time. So the Spectrum can now be powered on, and you can immedately start using the network filesystem. Also, a comprehensive "%info" command has been added to the Spectranet BASIC ROM module which gives information on files. For generic non-Spectrum files (and directories) it just shows the basics, such as filesize (and I intend to show file mode too). But for Spectrum files (the native format being used is TAP), it lists the contents - so, if you have a complete TAP file for a game for instance, it'll show all the blocks that are contained in the TAP file. Also, for testing, I wrote a program in BASIC to give a game loader menu, and then load the game from a TAP file. I wrote it on a real Spectrum, and trusted the TNFS code enough to save it over the network!
There are some games that don't seem to load properly - I need to investigate whether this is just a +3 incompatibility, or whether there are bugs in the tape traps.
Other than that, I've fixed a couple more bugs that I discovered in the base ROM.
Next I want to add support for BASIC streams. (Andrew Owen will like that of course!) For the time being, I intend to add a few commands using the RST 8 trap for opening a socket - it has been suggested that a control channel can be used for sending commands, but that involves a lot of extra work and I'd like to have at least TCP client streams working to demo at RetroEuskal (now wouldn't it be nice to do a Twitter client in ZX BASIC!)
Winston 21:58, 7 July 2009 (BST)