zx spectrum next

Don't be shy, come introduce yourself with the rest of the community
User avatar
rogerjowett
Posts: 29
Joined: Sun Apr 08, 2018 7:32 pm

Re: zx spectrum next

Post by rogerjowett » Sun Apr 14, 2019 4:41 am

http://tarjan.uw.hu/zxclones_en.htm

just look at all these zx spectrum clones they robbed us - sinclair took the brazilian tk95 manufacturers to court and lost!

User avatar
rogerjowett
Posts: 29
Joined: Sun Apr 08, 2018 7:32 pm

Re: zx spectrum next

Post by rogerjowett » Sun Apr 14, 2019 4:45 am

the trouble is with the high colour demo that the sam is showing tv pictures at 50hz and youtube is converting it to 60hz so it wobbles a lot more than it would if you were looking at it on a tv

User avatar
varmfskii
Posts: 169
Joined: Fri Jun 23, 2017 1:13 pm
Location: Albuquerque, NM USA

Re: zx spectrum next

Post by varmfskii » Sun Apr 14, 2019 5:57 am

The copper is feature that can automatically manipulate the registers of the ZX Next according to the screen position being drawn. It is basically a reduced version of the Amiga's copper.

If you look in the Wiki you can find all of the extra instructions.

DMA just allows movement of data without CPU intervention. The source and destination can either be memory addresses or I/O ports. The hardware scrolling is a little limited as it only lets you move the screen origin on a torodial mapping of the screen. This means that you still need to draw the newly revealed parts of the screen.

The Pi has yet to be put to any use.
Backer #2741 - TS2068, Byte, ZX Evolution

Alcoholics Anonymous
Posts: 476
Joined: Mon May 29, 2017 7:00 pm

Re: zx spectrum next

Post by Alcoholics Anonymous » Sun Apr 14, 2019 4:50 pm

rogerjowett wrote:
Sun Apr 14, 2019 3:46 am
1. copper? what is it what can it do - the crash article said it can drive the 3x ay8912 is this correct does it do it in parallel with the z80n or is there contention with the z80?
I haven't seen the crash article but likely it was not up-to-date on things.

The copper can change nextreg state, which is a collection of hardware configuration bits. A list is here: https://www.specnext.com/tbblue-io-port-system/

The z80 and copper can both access this state and both can modify it simultaneously. The hw can only do one thing at a time but there is arbitration logic that will delay modifications by the z80 by one cycle if there is a collision.

The AY registers are not mapped to the nextreg state so the copper cannot write to the AY registers at this time. However this is in the suggestion pile. What the copper can do is change each AY to mono, change the ABC/ACB stereo mode and switch between one active AY chip and three.
2. 48kb of video ram for 256x192 with 256 colours per pixel - sam coupe had 24kb of video ram
Video ram usually implies memory used exclusively to generate video and nothing else. Frequently it is owned by a dedicated video chip and is outside the normal memory space. An example is the TMS99xx series which had its own ram and only allowed the cpu to access it through a narrow pipe; on z80 computers this was normally an io port. There are examples in the next as well. Palette memory is a separate memory space and so is sprite pattern memory.

On the spectrum (and the sam I guess), the "video ram" is bank 5 / bank 7. It's not video ram in the same sense because this is memory also mapped into the normal memory space. Since the ram is not fast enough to serve both video generation and cpu access at the same time, cpu access is slowed via contention when there is a conflict. The spectrum can generate video from two places in memory (bank 5 and bank 7) and I gather from you the sam can generate video from multiple places in ram.

On the next, layer 2 comes out of general memory as well. You can change where layer 2 video is generated from in units of 16k. You can change the source location at any time in the nextreg state (see nextreg 0x12) including between scanlines or in the middle of scanlines. The number of layer 2 screens you can have is only limited by how much memory you have.

In the current core there are two limitations. One is layer 2 can only come from the first 512k ram chip which contains 256k of ram seen by the system (the other memory contains the roms, esxdos rom, divmmc ram). So 256k would mean five independent layer 2 screens. However, this ram corresponds to 16k banks 0-15. 0-7 are the normal banks used by the spectrum for programs, system vars, etc. You may not want to use that for layer 2 screens. This limitation seems very artificial to me so I think it will be eliminated in future cores. The second limitation is a contention one. The current core's sram interface cannot serve layer 2's external ram fetch and the cpu's fetch at the same time at 14MHz. So the cpu is contended while layer 2 is fetching pixels by slowing it to 7MHz.
if you manage 28mhz then you are effectively matching the msx trubo r which although it had a clock speed of only 7mhz was in fact an r800 processor with effective 4x speed and 16bit multiplication i think too - you seem to be saying that your synthesized z80n has xtra instructions too what are they and what can they do please?
The problem with z80 successors, whether produced by Zilog or other companies, is that they are not completely compatible with the original z80.

For example, there are many z80 derivatives that run instructions faster. Instead of 4 cycles to run a particular instruction, they make take 1. What this does is break programs that relied on instruction speed to count time. This also breaks contention patterns between the ula and cpu. For example, demos that rely on timing won't work and things like the nirvana engine won't work. Attached hardware stops working because the bus cycles are different.

These z80 derivatives also did two things. None of them implement all the undocumented instructions. Not even the cmos z80 did that. However spectrum programmers did use some of those undocumented instructions, even insane ones they shouldn't have. That introduces some software incompatibility. Further, many z80 derivatives are a progression in the series in that they filled in the undocumented instruction space with new instructions. In the zx next, there are only a few additional instructions and they stay away from the portion of the undocumented instruction space that may have been used (hindsight is 20/20).
Last edited by Alcoholics Anonymous on Sun Apr 14, 2019 5:31 pm, edited 2 times in total.

Alcoholics Anonymous
Posts: 476
Joined: Mon May 29, 2017 7:00 pm

Re: zx spectrum next

Post by Alcoholics Anonymous » Sun Apr 14, 2019 5:11 pm

rogerjowett wrote:
Sun Apr 14, 2019 4:15 am
7. gpio any info?
Without looking now, I believe most if not all the gpios are connected to the fpga. This means you can do whatever you want with them. What will end up being done in the official zx next spec is not settled yet although there are some ideas where it will go.
8. π as in raspberry pie co processor you say well bring it on 1ghz 64bit processor with a graphics processing unit does it have a floating point calculator and a physics processor? in fact what can the GPU on the pie do exactly? how does it compare to the latest nvidia and ati vga cards please? does it have a video encoder chip so that we can encode videos of our next experiences please? - does it even have a gen lock device so we can spread next graphics all over our youtube video uploads that we make with the mpeg 2 encoder chip? if not why not?!
Video capture devices synchronize with the input signal. It's these devices that need to lock to the video signal, not the ones generating the video.

The pi0 is a separate ARM based computer with a broadcom GPU. It can generate its own video independently of the next and has its own hdmi connector.

The specs for the pi0 can be seen in the rightmost columns of this table:
https://en.wikipedia.org/wiki/Raspberry ... ifications

They say the GPU can do 25M triangles/sec and is OpenGL ES 2.0 compatible. It is a GPU designed for low power devices so it will not be something within a few generations of the latest video cards.

Regarding 3D stuff, no CPU can compete with a dedicated GPU. GPUs are structurally different and make millions of computations in parallel using many individual cores doing computations simultaneously. They are designed for 3D graphics.

Regarding recording video from the next on the pi.. maybe :) There is an upper limit set by fpga size that limits what can be done.

User avatar
rogerjowett
Posts: 29
Joined: Sun Apr 08, 2018 7:32 pm

Re: zx spectrum next

Post by rogerjowett » Fri May 03, 2019 4:06 pm

so lets get this straight the dma cannot read data from the sd memory card as doing this takes 16 tstates even at 14mhz - which is really only 10mhz - and you have the nerve to show a 2d image of castle wolfenstein 3d on one of the youtube videos be a bit more honest please?

User avatar
rogerjowett
Posts: 29
Joined: Sun Apr 08, 2018 7:32 pm

Re: zx spectrum next

Post by rogerjowett » Fri May 03, 2019 4:32 pm

24576bytes x 16 = 393,216‬ x50 = 19,660,800‬ 19.6MHz required dMA reads port to ram in 2 tstates

User avatar
rogerjowett
Posts: 29
Joined: Sun Apr 08, 2018 7:32 pm

Re: zx spectrum next

Post by rogerjowett » Fri May 03, 2019 5:03 pm

2tstates per byte 4915200 tstates someone needs to get rid of video ram contention surely?

User avatar
rogerjowett
Posts: 29
Joined: Sun Apr 08, 2018 7:32 pm

Re: zx spectrum next

Post by rogerjowett » Fri May 03, 2019 5:04 pm

24576x2 = 49152 x 2 = 98304 x50 = 4915200 4.9mhz DMA wins!

Ped7g
Posts: 79
Joined: Mon Jul 16, 2018 7:11 pm

Re: zx spectrum next

Post by Ped7g » Fri May 03, 2019 5:34 pm

You can still do the like-full-screen video by reading compressed data (especially if not aiming at 50/60fps), but if you want just to trivially push raw pixel data from SD card to RAM, then you are correct, it's too slow, even in the 14 (~10) MHz mode.

The wolfenstein3D doesn't relate to the speed of SDcard in any way. Although you are kinda right it would be not trivial to create - again I mean some "straightforward" implementation, i.e. Layer2 256 colour 256x192 classic DOOM BSP wall texturing (without ceiling/floor) = that's not possible with Next, you have to scale down on something (viewport view, or graphics mode, etc...). (DOOM BSP is faster than Wolf3D raycasting and can produce the identical visual results, so I know precisely why I wrote DOOM there, and not Wolf3D ... I did code both and improve them by my own inventions back in ~1994, just never managed to release anything commercial from that :/ ).

Post Reply