ZX Spectrum Next in Flux

The place for codemasters or beginners to talk about programming any language for the Spectrum.
Post Reply
User avatar
Cosmium
Berk
Posts: 39
Joined: Tue Dec 04, 2018 10:20 pm
Location: USA

ZX Spectrum Next in Flux

Post by Cosmium » Tue Feb 05, 2019 5:16 am

Like others I've been following the development of the Next for a while now and things have been moving quickly. In fact it seems more like a constantly moving target! So I'm a bit confused and have some questions:

Does anybody know if this is this the way it's going to remain? i.e. there will be no 'fixed' hardware or should I say firmware (or distribution?) like it was for the original Spectrum, and instead it will be constantly evolving with new features being added periodically? While it's exciting to have new features added periodically, I can imagine it creating some potential problems.

Developing for the Next is certainly intriguing, but what does this mean for the software developers? Will new firmware features be compatible with previous versions, so programs and games written for it now will work just as well on next year's (or month's!) version? Come to mention it, will they look dated in a year because they're not using new feature XYZ that's been added in the interim?

Also, who is adding these new features and how?! I presume it's something to do with the FGPA being reprogrammable, with the FGPA meaning "Field-programmable gate array", and this is how the Z80 and other next hardware features were implemented. I notice that the Z80 has been modified with some additional instructions (which is nice :) ), but I notice too that they have been in flux with some added and some not. Is there going to be a de facto "this is it" in terms of finally settling on the processor instructions available? Are the COPPER and DMA capabilities settled now too?

There's a recent Next update talking about doubling the number of hardware sprites available, and a new "Tilemap Mode". With these significant new additions in combination with the 8 bit per pixel "Layer 2" screen, is there any reason to be using the standard Spectrum (ULA?) screen at the same time since it seems rather limited and dated by comparison. I'd be interested to know the typical role of each layer in a Next game. At least until the next Next update... ;)
0 x

Alcoholics Anonymous
Berk
Posts: 36
Joined: Mon Oct 08, 2018 2:36 am

Re: ZX Spectrum Next in Flux

Post by Alcoholics Anonymous » Tue Feb 05, 2019 8:04 am

Cosmium wrote:
Tue Feb 05, 2019 5:16 am
Does anybody know if this is this the way it's going to remain? i.e. there will be no 'fixed' hardware or should I say firmware (or distribution?) like it was for the original Spectrum, and instead it will be constantly evolving with new features being added periodically? While it's exciting to have new features added periodically, I can imagine it creating some potential problems.
It is not in a finished state yet but there will be a point when the zx next spec will be finished. There is a list of features that was envisioned some time ago that evolves as development realities affect it and feedback from the community modifies things somewhat. For example, the tilemap was something envisioned a long time ago, was discussed in the community and the form it eventually took was determined by the spectrum architecture. The recent updates to the sprite engine like 4-bit sprites was in the original design spec but things like anchored and relative sprites came from the community. So there is a rough plan as to what a zx next is but the details can change as they are implemented. What eventually gets in and makes the final zx next spec is also determined by what can fit into the fpga.

The development is a purely volunteer effort and is done in spare time which really affects how quickly things can get done. The effort now is to try to get as many of the kickstarter goals fulfilled and as many of the envisioned major features as possible into the manufactured cased nexts. Since the likely build date is fast approaching, I really doubt that a final zx next spec can be reached before the cased nexts are shipped. So what will happen instead is successive versions will be released and end users can update themselves. It's a very easy process that involves pressing a couple keys and waiting a couple of minutes. It's also expected more people from the community will become involved in determining what that final spec is.

This is an fpga computer which means the hardware can be anything someone may want to build. In fact there are at least 30 free slots in the flash to hold alternate cores; you can expect things like amstrads, sam, c64, arcade, etc to become available and it's possible someone will supply their own vision of a next generation zx machine. But by having an official zx next target, what a zx next is should remain well defined.
Developing for the Next is certainly intriguing, but what does this mean for the software developers? Will new firmware features be compatible with previous versions, so programs and games written for it now will work just as well on next year's (or month's!) version?
Yes backwards compatibility will be maintained as much as possible. There is commercial next software out there already that was written a year ago and they continue to work. Only minor changes have been made that affect functional differences with previous cores.

The zx next core contains a core version indicator that can be queried by the running program. When the cased nexts are shipped, the core will be at a specific version number and as later cores are released, new software using new features can check if the machine they are running on is up to date and can inform the user to update and quit if it isn't.
Come to mention it, will they look dated in a year because they're not using new feature XYZ that's been added in the interim?
Most of the time I don't think so. You can do a lot right now and make a game look very good. And as always, how good a game is has a lot to do with the game itself rather than just the graphics. Most of the display related features are implemented now, though they may continue to be tweaked somewhat given feedback from the sw developers.
Also, who is adding these new features and how?! I presume it's something to do with the FGPA being reprogrammable, with the FGPA meaning "Field-programmable gate array", and this is how the Z80 and other next hardware features were implemented.
The FPGA is like a programmable ULA. The ULA was a field of fixed sub-circuits from which the designer created a circuit by running wires between the sub-circuits. 35 years ago those wires were actual metal poured onto the top layer of pre-fabricated ULA chips at the factory. Once out of the factory you couldn't change the circuit. Fast forward to today and you have an FPGA which is also a field of sub-circuits from which the designer creates a circuit by running wires between sub-circuits. Except now the wires are programmable and, in the next's FPGA, those wires are routing fabric (horizontal and vertical lines) with connections between them made by pass transistors controlled by a single SRAM bit each. The FPGA configures itself by loading those bits into the controlling structures serially at power up. The programming of FPGAs is done at a higher level now using VHDL or Verilog with the manufacturer's tools "compiling" the hardware design into that bitstream. So today you have a device that can be any hardware and can be programmed to a different function at any time.
I notice that the Z80 has been modified with some additional instructions (which is nice :) ), but I notice too that they have been in flux with some added and some not. Is there going to be a de facto "this is it" in terms of finally settling on the processor instructions available? Are the COPPER and DMA capabilities settled now too?
What ends up in the Z80 will be determined by how much FPGA space there is. Right now there are higher priorities than the Z80. It's also possible the copper and dma functionality may be extended, again the limitation is FPGA space. But these things will remain backward compatible.
With these significant new additions in combination with the 8 bit per pixel "Layer 2" screen, is there any reason to be using the standard Spectrum (ULA?) screen at the same time since it seems rather limited and dated by comparison.
Yes! The ULA is not going to be an appendix in new software. Of course it is possible to write sw without using it but I think the people who get the most out of the next will be using it. Right now, next sw is using the timex 512x192 mode for proportional text (~100 chars per line it looks like), the hi-colour mode has been used in music sw, the ula is used as fast plot for unlimited bullets and score panels (layer 2 is expensive in terms of cpu), the ula acts as stencil for the tilemap, and the ula acts as brightener/darkener for layer 2 in slu modes 6 & 7. That's just some of the things going on now. But because the ula is so cheap to use in cpu (and it now scrolls, which helps in combination with other layers) I think it will always be attractive to use.
2 x

User avatar
Cosmium
Berk
Posts: 39
Joined: Tue Dec 04, 2018 10:20 pm
Location: USA

Re: ZX Spectrum Next in Flux

Post by Cosmium » Tue Feb 05, 2019 7:46 pm

Thanks for the detailed response, AA. That's explained a lot!
the ula is used as fast plot for unlimited bullets and score panels (layer 2 is expensive in terms of cpu), the ula acts as stencil for the tilemap, and the ula acts as brightener/darkener for layer 2 in slu modes 6 & 7. That's just some of the things going on now. But because the ula is so cheap to use in cpu (and it now scrolls, which helps in combination with other layers) I think it will always be attractive to use.
Interesting to hear how the standard ULA (the original) Spectrum screen can be useful for small software sprites and scores/lives display etc., and that layer 2 is CPU intensive - presumably because byte per pixel means more memory writes (/reads) ? I didn't know there was the facility to scroll the original screen - only thought it applied to layer 2 and the new tilemap mode, so that's welcome news.
0 x

Alcoholics Anonymous
Berk
Posts: 36
Joined: Mon Oct 08, 2018 2:36 am

Re: ZX Spectrum Next in Flux

Post by Alcoholics Anonymous » Thu Feb 07, 2019 3:23 am

Cosmium wrote:
Tue Feb 05, 2019 7:46 pm
scores/lives display etc., and that layer 2 is CPU intensive - presumably because byte per pixel means more memory writes (/reads) ?
Yes - the traditional spectrum display is only 6912 bytes but the layer 2 display is 48k. Like the ULA display, there is a contention going on with layer 2 so even though the zx next's z80 can run at 14MHz, it gets slowed to 7MHz while the hardware generates the 256x192 area of the display. So the speed is effectively slower than 14MHz with layer 2 enabled.

If you look at how many cycles a contended 3.5MHz spectrum has for its 6912 bytes compared to how many a contended 14MHz zx next has for its 48k layer 2, the spectrum is much less burdened. So the display throughput of raw cpu on layer 2 is less than the spectrum on its ula. Of course the next has things like hardware scrolling and hardware sprites that compensates (and more) for that but hw doesn't help if what you want to do doesn't fit well with the hw functions.
I didn't know there was the facility to scroll the original screen - only thought it applied to layer 2 and the new tilemap mode, so that's welcome news.
At the moment the scrolling is by pixel vertically but only by character horizontally. Later on it will be by pixel horizontally as well and the scroll register takes on pixel scroll amounts in anticipation of this.

Anyway I'd say just dig in -- it is a machine that is a lot of fun to program :)
0 x

Post Reply