rogerjowett wrote: ↑
Wed Apr 03, 2019 7:02 pm
is there a technical manual coming for it?
There is technical information available for most things now. But keep in mind the core is not finished and will likely continue to be developed after the cased nexts are already delivered. The features that are in now represent 90% of everything and whether other things arrive depends a lot on fpga space.
These are in addition to the links ped7g supplied:
The last link shows the registry which is a field of bits that control various behaviours of the system. What makes the copper compelling is that it can change this state independently of the cpu and synchronized with the display generation.
This doesn't list every feature of the next, only radically new things. It doesn't mention layer 2 (except in the registry) or the banked memory model and it doesn't mention the "standard" zx spectrum peripherals that have been added. The timex ula, eg, (timex hi colour, hi res), scrollable ula screen, turbosound (ay x 3), four 8-bit dacs, joysticks, kempston mouse, etc. I agree it would be helpful to have a technical manual that listed everything.
does the DMA support full screen animations at 50 frames per second? that would be 50x48kb =2.5mb per second from the sd memory device is this possible?
This was answered on fb; I'll just quote here for others:
The next implements a divmmc interface for the sd card. This interface uses the cpu clock to time transactions with the sd card. 16 cpu cycles are needed to pass each byte to/from the sd card. So at 14MHz, the peak transfer rate is 875000 bytes per second. The peak transfer rate can be achieved by streaming from an unfragmented file.
As for streamed video, Kev Brady has already demonstrated video at 320x192 resolution with 256 (512?) colours and 8-bit sampled audio. The video/audio stream is decompressed as it is loaded and data is written to the layer 2 screen as well as sprites on the layer 2 edges to get 320 pixels wide.
I'm not sure about the vertical resolution (it looks little less than 192 pixels) and I'm not sure if he's using a dynamic or fixed palette.
Just to add, because the sd card interface needs to see 16 cycles for each byte transferred, the dma cannot improve the transfer speed from the sd card. The Z80 instruction INI at 16 cycles already achieves the fastest transfer rate.
why not 9 dma one for each channel of the 3 x ay8912 chips - like the amstrad cpc+ had
At the moment there is one dma channel. The dma is quite important in games so committing it to do audio only can take away from screen activity. An alternative that has been / is being used is to use the copper to generate audio instead which is less convenient and takes some more programming effort because the copper's speed and screen geometry varies with video timing which can be different from machine to machine depending on what display device the user has set up.
The next has four 8-bit dacs arrange as two left channels and two right channels. A pseudo-mono channel exists in hw as well but what it really does is write the same value to one of the left channels and one of the right channels. This is called "covox" in Russia and the mono channel is sometimes called the "specdrum". Despite the tendency for the scene to invent flamboyant names, these are just dacs
Anyway, no special provision has been made to assist sending sampled audio through the AYs because it's much better to use the dacs.
28mhz z80 is this confirmed?
Out of reach in the current core.
14MHz is the max and as mentioned, this is slowed to 7MHz while layer 2 pixels are fetched from memory.
what is the copper please?
A very simple co-processor with 1k instruction space that operates independently of the cpu and is synchronized with the display generation. It can do two things: wait for a specific position in the display given by vertical pixel and horizontal byte or write a value to the registry.
The registry is a field of bits that controls the behaviour of the hardware and is described here:
The copper can be used to change anything there including changing colours, moving sprites, generating mono 8-bit audio, changing screen modes, changing layer priority and so on.
if it does and it has hardware sprites why not include some 3d hardware like texture mapping too?
The sprites allow stretching in the vertical and horizontal directions by integer multiples only 1x, 2x, 4x, 8x. Getting it to stretch at fractional amounts is another step up in complexity. Additionally, allowing transformations on the vertices would mean the orientation of the sprite's rectangular shape would change and this would complicate the drawing further.
There is a balance trying to be achieved in the zx next design -- we're limited by fpga space and the next is supposed to be a "what-if" machine. Could we have done this back in the day? For the most part yes with perhaps performance and scale reduced in a few areas and a bigger budget than Sinclair was known for
Would textures have been done bitd? Most likely not.
A blitter has always been on the wishlist. With a blitter (a specialized dma device), doing scalable textures might be possible. There was also a proposed ldir instruction variant that was proposed to do scaled copying to layer 2 but that has not made it in. Whether this will happen again depends on fpga space.
and finally when can i include my links to my full screen animation running on the sam coupe in sim coupe and the other links please?
You've posted already I think:
https://www.specnext.com/forum/viewtopi ... 8868#p8868
That's the right place for it. The rest of the forum is for on-topic posts about the next.