TS2068 screen behaviour changed ?

[FrancoisL]

Hi,

I just updated my z88dk folder with the latest nightly build for MacOS

I have noticed a change in behaviour for the TS2068. Before, with my previous z88k build (that was quite old) the screen would be in hi resolution by default, as per the wiki description.

Extended mode:
zcc +ts2068 -create-app program.c


Now, for a text only program, the screen default in zx spectrum low resolution with the same command line as above.

But there's more. I also have a small program with graphics. This time, the screen does indeed go in hi resolution, again with the same command line. (Why ? maybe because I do a clg() ??)

The graphics are plotted correctly in hi-res. But the text is wrong, being written with a space between each characters.

Before, everything was working correctly.

I will do more testing to try to understand better what is going on.

Francois

[dom]

Yes. I changed the behaviour in issue 1069: https://github.com/z88dk/z88dk/issues/1069

The change added support for all the screen modes of the ts2068 and allowed changing screen mode using the same calls used in other platforms. There?s a description of the screen modes and parameters on the wiki page:
https://github.com/z88dk/z88dk/wiki/Pla ... mex-TS2068

It looks like I missed out binding graphics support into the same set of variables - in your example clg changes the screen mode directly without informing the text printer - so I?ll sort that out when I get a chance.

[FrancoisL]

Hi Dom,

Thank you for your reply.

Using the function:

console_ioctl(IOCTL_GENCON_SET_MODE, &mode);

works perfectly.

I have notice another problem with the build. The drawto() function does not start from the latest plot point as before. If I do:

draw(0,0,100,100);
drawto(200,10);

the second line starts from 0,0 instead of 100,100. I guess it applies to the zx-spectrum too.

Best regard,
Francois

[dom]

I've had a look at the draw() problem - it looks the line is drawn backwards - so in your example it starts at 100,100 and ends up at 0,0. This only applies to targets with a width > 256 pixels.

I've committed (hopefully) a fix.

[FrancoisL]

Hi Dom,

Yep, it works correctly now. Thank you. I now have all I need.

That being said, here is my wish list for the future.

It would be nice if the graphic commands would adapt to the mode chosen with console_ioctl(). Right now it would seems that whatever graphic mode is declared with console_ioctl(), the graphic command used are those for a 512x256 screen resulting in scrambled output in mode 0,1 and 2 (And possible data corruption in mode 0 as stuff is being written in the 0x6000 to 0x8000 memory area)

I know that the solution for mode 0 is simple: just compile for the spectrum target. But it would be nice if it was possible, for an application, to switch modes and still be able to produce graphics i.e. part of the application needs hi-res, later some other part needs hi-color, etc.

Also, clg() should leave the graphic mode as is since it is now handled by console_ioctl(). As of now, clg() will always switch to hi-res, even if the mode was specified as 0,1 or 2.

I guess it is just a question of calling the right function in the right library. That would imply a larger application if all those function are linked into the final program.

Again this is all nice to have. I am just telling my point of view. Maybe someone sees thing differently.

Francois

[dom]

I completely agree with you - having the graphic primitives follow the screen mode is the right thing to do.

The other ports with multiple modes, CPC, PC6001 other MC6847 machines have the primitives following the mode, so the TS2068 should too. I'll pick it up next and sort it out.