Update 41 and "2.00.X."

This section is for discussing everything about Next hardware and latest updates.
Post Reply
PiyoTaro
Posts: 135
Joined: Thu Jun 01, 2017 11:13 am

Update 41 and "2.00.X."

Post by PiyoTaro » Tue Dec 18, 2018 6:05 pm

Several months have passed since someone told me "specifications have already been confirmed."
But "Firmware version 2.00.X." was released in this update. :lol:

There was a big addition to the graphics function that I could say "specification change".
  • Firmware update
    Phoebus, Garry, Allen and Jim have been hard at work getting the firmware improved with the extra time created by the keyboard delay. There are a lot of updates and new features already added to 2.00.X, and we are planning on shipping the Next with this core out of the box. Check out the partial features set:
  • L2 Priority colours: By setting the first bit of the second byte in a palette entry, this colour now overprints everything regardless of the order of layers, thus providing for a non-cpu time cost solution for environmental masking.
    Darken/Brighten modes (by implementing layer colour mixing) has been implemented. SLU modes (111 and 110) with lighting and shadow effects requiring no CPU time also.
  • The sprite engine has been redesigned from the ground up allowing for up to 64 sprites per line, 4 bit colour sprites and up to 4x scaling on the X and Y axes.
  • NextReg 0x03 writes with bit 7 set now accepted in any mode to change timings (bits 6-4), NextReg 9 bit 3 disables the Kempston mouse port ($DF) and read of NextReg 0x3 bit 7 now returns the next palette byte to be written (0=RRRGGGBB, 1=B-low) and NextReg 0x15 bit 5=1 enables clipping in over border mode for the sprites.
Lampros Potamianos
https://www.facebook.com/groups/specnex ... 965437859/

Now that the news about the new core features are out, I am posting this small demo that showcases the new 4bit sprites and the lifting of the 12 sprite per line limit. Note that 4bit sprites are not monochrome, they use a palette of 16 colors, these just happen to use a greyscale palette. This demo uses multiplexing to display 192 sprites on the background (plus 9 for the ball). Then it shuffles the sprite patterns randomly, forming effectively a character map. This allows for a variety of games to be developed that would be very difficult to do otherwise.
Addendum (2018/12/19 4: 00 JST)
Yesterday, the latest article of the official facebook was not displayed.
Therefore, I did not see the update announcement and the movie of the new sprite function demo.
There is some speculation on my post
Last edited by PiyoTaro on Tue Dec 18, 2018 7:52 pm, edited 2 times in total.

PiyoTaro
Posts: 135
Joined: Thu Jun 01, 2017 11:13 am

Re: Update 41 and "2.00.X."

Post by PiyoTaro » Tue Dec 18, 2018 6:08 pm

The sprite engine has been redesigned from the ground up allowing for up to 64 sprites per line, 4 bit colour sprites and up to 4x scaling on the X and Y axes.
There was a big specification change in the "sprite engine".
From the sentence, the sprite display limit number can be increased to 64 or 4 bit color mode addition can be read. Is "4x scaling" similar to "sprite rotation, mirror display"? I hope to connect multiple sprites.

Expectations when applying to games were posted to the Facebook of "official gaming group".
Kev Brady
2018/12/7 4:11

Look what's coming to the Next!!! 😀
https://www.facebook.com/groups/ZXSpect ... 805330387/
Kev Brady
13hours ago

I can now reveal that the Atic Atac tribute is in a resolution of 320x224 as it uses the updated core mentioned in Kickstarter update 41 :)

Peter Ped Helcmanovsky
Sorry, I don't understand this, is that some new gfx mode, or is this full screen resolution (including border), or what does it mean? (or does it use completely different core, like it is not "next" actually, but other computer)

Kev Brady
The latest core that has been in development over the weeks has improvements that allow all 64 sprites to be on the same line so it is now possible to make games that display graphics in the border :)

Peter Ped Helcmanovsky
Kev Brady oh, I understand now, so you are using 256x192 + sprites... well, you could already use sprites for 320x192 before, and with specific kind of graphics like the atic atac, probably the extra top/bottom areas would be able to cover with only 12 sprites too, as the whole room is more alike to <> shape, not using corners extensively. But having 64 per line in 1x scale makes this more safe, so you don't have to worry about crossing the max limit.

Kev Brady
The vertical pixel scroll needed to display 20 sprites per line in the top and bottom border so this would not have been possible with the old 12 per line limit. The PC version just fits at this larger resolution without having to change the room layout or scale/re-draw the graphics.

Peter Ped Helcmanovsky
Kev Brady I see now that... well, that could be avoided by some "artistic" way probably too, like making the bottom lines to emerge from middle toward borders during scroll, although 12x16 only 192, so jump to 256px width on pixel area is maybe too much... would it be before at least 16 sprites (covering 256px), it would be probably sufficient for nice and suggestive effect (suggesting full 320x224 res even if not really). So yeah, now I fully understand, and yeah, that change in the core is very welcome, sounds good. Also the scaling mentioned is "up to 4x" in text (and not mentioning 3x size), but Allen commented about 8x ...so I wonder what will be the precise state of HW in the end.. (IMO 1x/2x/3x/4x would be better than 1x/2x/4x/8x .. as "8x" graphics is basically attribute size already, seems a bit abundant except for some "incoming" animation which would go through 8x for brief moment).

Kev Brady
The sprite scaling is in powers of 2 so 16px, 32px, 64px, 128px in any combination for X and Y. 128 is very handy to match attribute size and I already made a list of areas that would benefit from the 8x sprite sizes :) Remember that attributes cannot be used in conjunction with LORES ula ;) The scaling is fixed point so 3x may have distorted slightly.
Addendum (2018/12/19 4: 00 JST)
Yesterday, the latest article of the official facebook was not displayed.
Therefore, I did not see the update announcement and the movie of the new sprite function demo.
There is some speculation on my post
Last edited by PiyoTaro on Tue Dec 18, 2018 7:50 pm, edited 1 time in total.

PiyoTaro
Posts: 135
Joined: Thu Jun 01, 2017 11:13 am

Re: Update 41 and "2.00.X."

Post by PiyoTaro » Tue Dec 18, 2018 6:13 pm

Addendum (2018/12/19 4: 00 JST)
Yesterday, the latest article of the official facebook was not displayed.
Therefore, I did not see the update announcement and the movie of the new sprite function demo.
There is some speculation on my post
PiyoTaro wrote:
Tue Dec 18, 2018 6:05 pm
Several months have passed since someone told me "specifications have already been confirmed."
But "Firmware version 2.00.X." was released in this update.
There was a big addition to the graphics function that I could say "specification change".
My opinion

About "trivial" specification change
Setting volume 0 on the AY modules actually makes the AY silent.
The mute function I requested as "mixer device" was installed. In addition, I also want the function to set the output voltage of the DAC to zero.
Each AY can now be made monophonic (via NextReg 0x09 bits 7: 5)
Fixed that monaural output can be output for "Turbosound Next" audio output only ABCACB stereo. Did not anyone notice?

Other requests
For DMA, what is implemented in "Pentagon" (EVO, TS-Conf) is not only the Z80's 16-bit address space but also the 24-bit address space can be specified by adding the memory bank number to ZX 128 It has become.

Also, if "FM Sound" can not be implemented, I wanted "Wave Memory Sound" like "Konami SCC" to be added to candidates as well as SID.
Even just AY-3-8912, it would have been better if there was an "effector" function to change the output waveform such as the "duty ratio".

Release of "Option core".
"DivGMX" adopts FPGA "Altera Cyclone IV EP4CE10" which has only 10320 logic cells. But it has the specification of "TS-Conf" with Sprite tile engine and GS sound.

I want a simple optional core just adding "Tile graphics" and Sprite function (also want FM sound) to Speecy's specification.

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

Re: Update 41 and "2.00.X."

Post by Alcoholics Anonymous » Wed Dec 19, 2018 2:27 am

PiyoTaro wrote:
Tue Dec 18, 2018 6:08 pm
From the sentence, the sprite display limit number can be increased to 64 or 4 bit color mode addition can be read. Is "4x scaling" similar to "sprite rotation, mirror display"? I hope to connect multiple sprites.
The scaling and whether a sprite is 4-bit is a property of each sprite just like the rotation and mirror bits. The sprite module has one scan line to plot all sprite pixels into before it is drawn to the display. It can do all 64 sprites at 16x16 size in that time (in fact I think it could do about 100). However if you make the sprites wider with the scaling function, each sprite occupies more pixels horizontally which means they take more time to plot during that scan line. If all sprites are 2x wide (32 pixels wide) then the limit is around 50-55 sprites per line. If all sprites are 8x wide (128 pixels wide) then the limit is around 13-14 sprites per line. And of course everything in between if you have mixed size sprites on the same line.

One of the uses of these big sprites is for masking so that's why the 128-pixel wide one was found to be desirable.

Kev has been doing a lot of impressive things with the sprites and wide display resolution this allows. Layer 2 and the ula are confined to 256x192 but the sprites have a 320x255 surface. So he's been drawing into the border area using sprites for things like his Atic-Atac conversion and the video clip he posted on fb.

The details will come soon I think. The minimum core version for the sprites is 2.00.22 which is not publicly available yet. In the meantime here are some brief notes:

Code: Select all

Sprites: Fifth attribute byte is present if bit 6 of the fourth attribute byte is set

  H N6 0 X X Y Y Y8

  4-Bit Patterns
  H = 1 means the sprite uses 4-bit patterns
  N6 = 0 chooses the top 128 bytes of the 256-byte pattern otherwise the bottom 128 bytes
         
  Sprite Scaling
  XX and YY affect scaling in the X and Y directions
  00 = *1 16 pixels
  01 = *2 32 pixels
  10 = *4 64 pixels
  11 = *8 128 pixels
                     
  Y8 is the ninth bit of the Y coordinate to allow wrapping on the Y axis
                       
  Sprites: Nextreg 0x15 bit 6 = 1 changes sprite priority so that sprite 0 is on top
  Sprites: Nextreg 0x15 bit 5 = 1 enables clipping in over border mode
  Sprites: Writing to port 0x303B with bit 7 set adds an offset of 128 to the pattern index

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

Re: Update 41 and "2.00.X."

Post by Alcoholics Anonymous » Wed Dec 19, 2018 2:39 am

About the other things... there are requests in for having the dma deal with a flat memory space and for updating the AYs.
Several months have passed since someone told me "specifications have already been confirmed."
But "Firmware version 2.00.X." was released in this update. :lol:
One good thing about the delays is that this has also postponed the date the boards get flashed :)

It's anticipated that people will develop their own cores and make them available (or not) and put them into one of the available 30 slots in the flash. This could be something like TS-config if the source is available. With the zx next vhdl being made public, it could be used to create other cores by eliminating unwanted features and/or adding new ones.

PiyoTaro
Posts: 135
Joined: Thu Jun 01, 2017 11:13 am

Re: Update 41 and "2.00.X."

Post by PiyoTaro » Wed Dec 19, 2018 8:39 am

Continued.
About "sprite function"
PiyoTaro wrote:
Tue Dec 18, 2018 6:05 pm
Several months have passed since someone told me "specifications have already been confirmed."
But "Firmware version 2.00.X." was released in this update. :lol:
There was a big addition to the graphics function that I could say "specification change".
Lampros Potamianos
https://www.facebook.com/groups/specnex ... 965437859/

Now that the news about the new core features are out, I am posting this small demo that showcases the new 4bit sprites and the lifting of the 12 sprite per line limit. Note that 4bit sprites are not monochrome, they use a palette of 16 colors, these just happen to use a greyscale palette. This demo uses multiplexing to display 192 sprites on the background (plus 9 for the ball). Then it shuffles the sprite patterns randomly, forming effectively a character map. This allows for a variety of games to be developed that would be very difficult to do otherwise.
Addendum (2018/12/19 4: 00 JST)
Yesterday, the latest article of the official facebook was not displayed.
Therefore, I did not see the update announcement and the movie of the new sprite function demo.
There is some speculation on my post
1. Watching the demo movie, I was reminded that it is possible to substitute "Tile graphics" with sprites like the "Super Cassette Vision" console released in Japan.
However, there are only 64 sprite patterns that can be defined. If it is a specification that splits the screen with Copper and can switch sprites of 3 banks, it may be realized.
Sprites can also be displayed on the "Border Color" screen, so it seems that a landscape text screen can be realized.

2. By the way, I was looking at the official facebook comment, the number of sprite patterns can define remains 64, and the size of the sprite pattern still seems to be 16X16.

It is not clever to manage multiple sprites in order to realize "big sprites" with sprites fixed at 16X16 size.
If "relative coordinates" can be defined with attributes, the program will be easier.
Furthermore, multiple sprites are controlled with only one "representative sprite" attribute. (If you specify the "representative sprite" number, it is controlled by that attribute).

3. What everybody has forgotten.
By the way, the Sprite function of "ZXSpectrum Next" is different from the others, "sprite pattern" and "sprite" have the same meaning concept .
Therefore, the defined "sprite pattern" can not be used with multiple sprites (like text fonts). (And there was no "sprite pattern number" in the attribute.)

At "1", I said something like a text screen. But, there is no concept of using one "sprite pattern" like a text font.
And, in "2", "sprite number" is my coined word.

---
In this announcement, concrete specification has not been released yet.
Are the cores complete, but are the documents released in a state that has not yet been assembled, or are they seeking opinions on the final specifications?

JoeZX
Posts: 572
Joined: Mon May 29, 2017 9:11 pm
Location: Slovakia

Re: Update 41 and "2.00.X."

Post by JoeZX » Wed Dec 19, 2018 10:53 am

so .. increased number of sprites to 128 in total /if all 4 bit/ ? or still max hard limit 64 per frame, but now 64 per scanline /4 bit, or 8 bit, doesnt matter/ ?

User avatar
Sokurah
Posts: 60
Joined: Mon May 29, 2017 9:32 pm
Contact:

Re: Update 41 and "2.00.X."

Post by Sokurah » Wed Dec 19, 2018 11:50 am

Alcoholics Anonymous wrote:
Wed Dec 19, 2018 2:39 am
It's anticipated that people will develop their own cores and make them available (or not) and put them into one of the available 30 slots in the flash.
I've never heard about this before. What slots are this? Are they held on the FPGA (because I thought that was nearly full by now)?
Website: Tardis Remakes / Mostly remakes of Arcade and ZX Spectrum games.
My games for the Spectrum: Dingo, The Speccies, The Speccies 2 (also for arcade hardware) & Vallation.
Twitter: Sokurah

JoeZX
Posts: 572
Joined: Mon May 29, 2017 9:11 pm
Location: Slovakia

Re: Update 41 and "2.00.X."

Post by JoeZX » Wed Dec 19, 2018 11:53 am

HW configuration slots, like options menu .. one slot used-loaded at one time, eg. configuration SpecNext 256 colors gfx, SpecNext 64 colors gfx, SpecNext 256c tiled based gfx, SpecNext SID, SpecNext FM, SpecNext AY etc.

User avatar
sol_hsa
Posts: 86
Joined: Fri Jun 02, 2017 10:10 am

Re: Update 41 and "2.00.X."

Post by sol_hsa » Wed Dec 19, 2018 11:54 am

Sokurah wrote:
Wed Dec 19, 2018 11:50 am
Alcoholics Anonymous wrote:
Wed Dec 19, 2018 2:39 am
It's anticipated that people will develop their own cores and make them available (or not) and put them into one of the available 30 slots in the flash.
I've never heard about this before. What slots are this? Are they held on the FPGA (because I thought that was nearly full by now)?
The way I understand it, the FPGA contains its configuration in RAM, which is loaded at bootup; this configuration is full. The 32 slots are in flash, so you get to pick which configuration to load.

Post Reply