Update 42 - New graphics mode

This section is for discussing everything about Next hardware and latest updates.
User avatar
TheSMoG
Posts: 31
Joined: Mon May 29, 2017 5:07 pm

Re: Update 42 - New graphics mode

Post by TheSMoG » Mon Jan 28, 2019 12:52 am

I do apologize for the delay. Life happened as always.
It's all there now, new distro, new info (both on Next Reg and as a new page describing the new graphics mode), please enjoy :)

(And do not forget that the git has always the latest and greatest)

Cheers!
Phoebus R. Dokos
ZX Spectrum Next Manual author/editor
TBBlue Distribution Maintainer Latest images & TBBlue git repo on gitlab.com
WASP/ZXnextHUB Member
All Sinclairs All The Time :D :lol:

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

Re: Update 42 - New graphics mode

Post by PiyoTaro » Mon Jan 28, 2019 9:18 am

Congratulations on the implementation of "Tile Map Graphic".
(Additional note: About 80 digits character tile map map is implemented) Although I speculate on specs, high-resolution graphics in the world of ZXSpectrum (I imagine displaying the kanji text first, but there are also 'GAIN GROUND' or 'Bonanza Bros.' and a high resolution arcade game ) Has come out of the possibility.

https://www.facebook.com/groups/specnex ... 222969133/
My impression of seeing presentation articles and demonstration movies on FaceBook. (However, at this point, this extension has already been announced on the Official website along with "sprite").

I think that the explanation is insufficient for "to display a layer with a horizontal width of 320 dots on a horizontal width 256 dot screen". Please add the word "Sprite function has XY coordinate expanded and it can be displayed on the Border color area, the new layer is the same rule as sprite".
Also add a picture that explains how to see the "New aspect ratio" image on the HDMI screen (16: 9) and VGA screen (4: 3).

P.S.
Not only did it make it easier to port the Application of the game console with the implementation of the tile map graphics, but also because the display area of ​​the layer became large, it seems that the screen design of the Arcade game (with the CRT display installed vertically :D ) can be ported as it is .

---
Other requests:
About the prescaler function of "ZXNDMA".
Is it possible to "transfer data at audio frequency in 14 MHz mode"? I got a reply saying "Improvement is done" in past forum posts of this forum, but the document in Gitlab has not been revised.
Also, I also posted that "buffer size on Z80 memory map" can be reduced if 'interrupt function' is implemented in DMA.
Last edited by PiyoTaro on Mon Jan 28, 2019 11:26 am, edited 1 time in total.

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

Re: Update 42 - New graphics mode

Post by PiyoTaro » Mon Jan 28, 2019 11:24 am

* There was an update of the official website today. I think that it is better for the discussion place to move to a new thread. *

Not only did it make it easier to port the Application of the game console with the implementation of the tile map graphics, but also because the display area of ​​the layer became large, it seems that the screen design of the Arcade game (with the CRT display installed vertically :D ) can be ported as it is .

Information required for design: Number of colors available in tiles, number of color palettes. Tile map position on screen, scroll register.
TBBLUE V.1.03 – CORE 2.00.26, FIRMWARE 1.10C, NEXTZXOS 2.00B! SPRITES! TILEMAP! OH MY!
January 27, 2019 Phoebus Dokos
  • NEW TILEMAP MODE
    which adds two ultra fast 40×32 and 80×32 “tile” maps achieving 320 x 256 or 640 x 256 resolutions respectively in a very ULA compatible way. More info in the tilemap.txt document in the c:/docs/extra-hw/tilemap folder in the distribution, the tbblue repo site (see link above) as well as here: https://www.specnext.com/tilemap-mode/
  • NEW Sprite Engine
    rewritten from scratch by the Unbreakable™ Allen Albright allowing for 128 sprites total (wot?), 100 (say again?) sprites per line (for regular sprites; your experience will vary based on what features you enable), 4-bit colour, scaled AND anchored sprites (oh yeah!)
“TILEMAP” MODE
January 27, 2019 Phoebus Dokos

General Description
The tilemap is a hardware character oriented display that comes in two resolutions: 40×32 (320×256 pixels) and 80×32 (640×256 pixels).
The display area on screen is the same as the sprite layer, meaning it overlaps the standard 256×192 area by 32 pixels on all sides. Vertically this is larger than the physical HDMI display which will cut off the top and bottom character rows (making the visible area 40×30 or 80×30) but the full area is visible on VGA.

Tile Definitions
Each tile, identified by tile number, is 8×8 pixels in size with each pixel four bits to select one of 16 colours. A tile definition occupies 32 bytes and is defined in X major order with packing in the X direction in the same way that 4-bit sprites are defined.
The 4-bit colour of each pixel is augmented by the 4-bit palette offset from the tilemap in the most significant bits to form an 8-bit colour index that is looked up in the tilemap palette to determine the final 9-bit colour sent to the display.

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

Re: Update 42 - New graphics mode

Post by Ped7g » Mon Jan 28, 2019 12:41 pm

PiyoTaro wrote:
Mon Jan 28, 2019 11:24 am
...
Information required for design: Number of colors available in tiles, number of color palettes. Tile map position on screen, scroll register.
Is that a question? As part of that in answered in the rest of your post, although not all of it, so let's summarize:

- tiles graphics is 4-bit (16 offsets into palette, but one offset is transparent, so "15 opaque offsets" is probably better way of thinking about it)
- the tile can have either custom attribute (when 2-byte tile mode is used), or global tile-attribute (used for all tiles, which are defined as 1-byte map only). The tile attribute contains another (top) four bits, completing the 8-bit palette *offset*.
- there are two new palettes, in the same way how ULA/Layer2/Sprites have two 256-item palettes of 9b colours, there are two new palettes dedicated to tile mode

In other words, each tile has "16 colours (1 is transparent)" from one of the 16 (sub)palettes (of 9b colours) for tiles (with two such set of 16x16 palettes available by simple 1-bit switch in NextReg making the other one active)

The final 9-bit colour of tile pixel emerges as: tile_palette[activeTilePalette][tile_attribute_pal_offset_4b | tile_pixel_4b] - if (tile_pixel_4b != transparent tile index), otherwise pixel is considered transparent, and other layers or fallback colour will be displayed.

That final 9-bit colour, if not transparent, is another input into layer composing, taking account of layer priorities (tile is paired with ULA, into the layer mixer they produce basically single pixel value/input, think about it as ULA pixel in older cores, the tile-vs-ULA is resolved ahead of that old composing).

Tile map position - it's like text-mode, in the sprite coordinates [0,0] .. [319,255] (80x32 has double X resolution, so X*2 everywhere).

You can offset it per pixel, i.e. X offset 0..319 for 40x32 or 0..639 for 80x32, and Y offset 0..255 (there is typo in documentation saying 0..191, but that doesn't make sense, so I expect it to be typo).
I.e. you can move origin [0,0] pixel of the tile map to any position of screen.

Also while thinking about porting some arcade game based on tile graphics, you may also exploit the rotate/mirrorX/mirrorY flags to either optimize amount of tile graphics and create some variety, or to avoid converting arcade graphics if they were using CRT rotated (although you will probably pre-process graphics data anyway, so rotating them correctly is probably no big deal).

The tile graphics, while it's sort of "sibling" of ULA layer, is still separate layer, and you can mix it with classic ULA, or Timex hi-res (512x192) and hi-colour (8x1) graphics, although you must fit *everything* (tilemode + ULA mode) into 16k of RAM, so using Timex modes will tax you hardly on amount of memory available for tiles graphics.

It can NOT mix with LoRes 128x96 mode, as that one not only exhausts 12k of that 16k block, but also it requires the video signal to read four bytes per 8 pixels just for LoRes layer, exhausting memory bandwidth (classic ULA, 8x1 hi-colour, and 512x192 hi-res reads only two bytes per 8 pixels and there's at least 2 bytes "free" for tile mode reads (although the tile mode requires actually more reads, so there was more bandwidth left probably, but LoRes hits it already too hard not leaving enough for tilemode together)).

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

Re: Update 42 - New graphics mode

Post by Alcoholics Anonymous » Mon Jan 28, 2019 5:45 pm

PiyoTaro wrote:
Mon Jan 28, 2019 9:18 am
I think that the explanation is insufficient for "to display a layer with a horizontal width of 320 dots on a horizontal width 256 dot screen". Please add the word "Sprite function has XY coordinate expanded and it can be displayed on the Border color area, the new layer is the same rule as sprite".
If you go to the description page at https://www.specnext.com/tilemap-mode/ this is mentioned at the beginning :)
The display area on screen is the same as the sprite layer, meaning it overlaps the standard 256×192 area by 32 pixels on all sides.
Also add a picture that explains how to see the "New aspect ratio" image on the HDMI screen (16: 9) and VGA screen (4: 3).
Maybe that would be a good idea but I do hope developers will test their screens on both to see for themselves. Having said that, I will mention again that if you can, prefer VGA for your display. VGA is where the spectrum implementation is perfect (ie all the timing, etc).

The main thing to know is that hdmi does not display all the rows vertically -- it clips off the top row and the bottom row because the generated hdmi display is only 240 pixels tall. So that means you have borderless operation vertically but at the same time, if you are doing a text mode, don't be placing text in those rows. VGA shows the entire picture with a thin border on all sides.
Not only did it make it easier to port the Application of the game console with the implementation of the tile map graphics, but also because the display area of ​​the layer became large, it seems that the screen design of the Arcade game (with the CRT display installed vertically :D ) can be ported as it is .
Yes it opens up those possibilities. There is a pacman emulator for the spectrum that runs the actual pacman code. It had to squash the display vertically to fit on the 256x192 surface but it would now be trivial to do a 100% emulator on the next. I'm not sure about the utility of doing it though, other than for fun, because the zx next is an fpga computer which opens the prospect of having original arcade cores in the machine.
Other requests:
About the prescaler function of "ZXNDMA".
Is it possible to "transfer data at audio frequency in 14 MHz mode"? I got a reply saying "Improvement is done" in past forum posts of this forum, but the document in Gitlab has not been revised.
Also, I also posted that "buffer size on Z80 memory map" can be reduced if 'interrupt function' is implemented in DMA.
Yes the documentation of sprites and dma is behind. FYI, the dma was fixed so that the transfer rate set by the prescalar is independent of the cpu speed so you can do sampled audio at 14MHz and you can change speeds while the program runs without affecting the audio.

Interrupts are another thing on the roadmap but I don't think it's going to be visited before the cased nexts are made. There is a push to get the major functionality done for the cased next and then loose ends will be in further updates that users will have to carry out themselves.

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

Re: Update 42 - New graphics mode

Post by sol_hsa » Tue Jan 29, 2019 8:41 am

Yay! It's a text mode! (with very colorful text)

User avatar
TheSMoG
Posts: 31
Joined: Mon May 29, 2017 5:07 pm

Re: Update 42 - New graphics mode

Post by TheSMoG » Tue Jan 29, 2019 10:32 am

sol_hsa wrote:
Tue Jan 29, 2019 8:41 am
Yay! It's a text mode! (with very colorful text)
It's much more than that :) Allows for super fast graphics as well if you organize them properly
Phoebus R. Dokos
ZX Spectrum Next Manual author/editor
TBBlue Distribution Maintainer Latest images & TBBlue git repo on gitlab.com
WASP/ZXnextHUB Member
All Sinclairs All The Time :D :lol:

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

Re: Update 42 - New graphics mode

Post by Ped7g » Tue Jan 29, 2019 3:52 pm

TheSMoG wrote:
Tue Jan 29, 2019 10:32 am
...
Technical questions/remarks:

There is now new clip window register 0x1B for tilemode.

But 0x1C clip control still lists only S/L/U clip windows. Are there new bits for tilemode clip control? (W) reset / (R) index?

----

Global transparency $14 has in description "...and tilemap uses nextreg 0x??)"
-> it's 0x4C

-----
(R/W) 0x31 (49) => Tilemap Offset Y bits 7-0 = Y Offset (0-191)
-> should be 0-255

...that's all for now. :) Cheers...

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

Re: Update 42 - New graphics mode

Post by Ped7g » Thu Jan 31, 2019 1:57 pm

TheSMoG wrote:
Tue Jan 29, 2019 10:32 am
...
It's much more than that :) Allows for super fast graphics as well if you organize them properly
And the Tilemap clip window description doesn't explain what happens in 80x32 mode. I went ahead in wiki and *guessed* the X-coordinates are then quadrupled, let me know if I got it wrong.

Meanwhile the guess about 1C controlling also Tilemap clip window register was confirmed in test, and already is described in wiki according to the results of tests with 2.00.26.

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

Re: Update 42 - New graphics mode

Post by Alcoholics Anonymous » Thu Jan 31, 2019 3:27 pm

Ped7g wrote:
Thu Jan 31, 2019 1:57 pm
And the Tilemap clip window description doesn't explain what happens in 80x32 mode. I went ahead in wiki and *guessed* the X-coordinates are then quadrupled, let me know if I got it wrong.
Clipping windows are always applied in normal resolution. The high horizontal resolution modes (80x32 tilemap and timex hi-res) just output two pixels for every normal resolution pixel so will have twice as many pixels inside the clipping window horizontally.

For clipping I always think in terms of the standard resolution because then all the clipping windows apply to the same size pixels. If you want to know the coverage in high resolution coordinates then it would be [x1*2,x2*2+1] but as mentioned the hardware is not doing that. The hardware counts normal resolution pixels at 7MHz, and it's this x,y coordinate to which clipping is applied, and the high resolution displays are putting out pixels at 14MHz.

Post Reply