epson px8

[stefano]

I'm at a good point with the px8 library, the putsprite() function is now reasonably fast and most of the graphics functions are now supported. something is still based on single pixel access but the core functions do not rely on the console ESC codes anymore.

target specific functions are now available and being further ly developed

[stefano]

Ansi vt mode added, there are many improvements still possible on the native console, but it is so powerful that the viable options are confusing me.
As an example, only a 'graphics font ' can be defined by the user, (size on every single 'character code ' can vary) but it can't be used in text mode. UDGs can be defined in text mode though (char codes starting from 0xe0..), but they will be chopped to 6 bits when displayed (under some circumstance it is chopped also vertically) . Depending on the text settings the coordinates can be difficult to track because of the windowing over a vrtual screen..

[RobertK]

I have found a small bug on the PX-8 target: the undraw() function is drawing instead of undrawing. The PX-4 is not affected.

I have put a small test package fueltest_px8.zip here:
https://drive.google.com/drive/folders/ ... q6EqH_3zMr

It reproduces the fuel bar of my Deepspace game, which is first fully drawn at the bottom and then gradually undrawn.
10 pixels above I do the same undrawing in an empty area, which should have no visual effect.

On e.g. the PV2000 and PX-4 targets, it's working as it should.

[stefano]

Thanks, I will check.
For your information, if you are using the Takeda's project emulator it had a bug in the graphics CPU emulation, fixed in the late versions.

[stefano]

Confirmed, it works on the updated Takeda's emulators suite.

On which emulator are you running it on ?

The emulators often are weak in emulating the SUBCPU behavior, the commands needs to be tested one by one, often without a software base to check the overall functionalities. I had to refer to the manuals and double check the z88dk library code before bothering Takeda

fueltest.png

P.S. your test program should include <graphics.h>

[RobertK]

Hmm, I've downloaded the current Binary Archive (1/1/2024) from http://takeda-toshiya.my.coocan.jp/, the hc80.exe file is dated 2023-12-31.
I took the "adddional required files" from the "Neo Kobe emulator pack 2013-08-17".

For me it looks like this:

HX80_FuelTest_TakedaEmulator_2023-12-31.jpg

There is also two unwanted dots in the top left part of the screen, which are not present in your screenshot.

Off-topic: Is your hotmail.com mail address still valid? I sent you an email two weeks ago, please have look at it.

[stefano]

Well, this is puzzling, the Emulator copy I have is probalby older, my z88dk kit is reasonably in line with the one on GitHub, and it is running properly.

I built your program by just adding the inclusion of <graphics.h>, then:

zcc +cpm -subtype=px8ansi -create-app fueltest.c


( I will look in the "unwanted email", Outlook enjoys trashing the useful messages and promoting unsolicited stuff on top of your inbox, luckily it filters out a good quantity of phishing, too )


EDIT: Perhaps I see it ! The line empties right to left on the PX4, but fills up from left to right on the PX8 !
The subcpu operation is correct, as well as the undraw() instruction (the chessboard demo runs correctly).
Time to look for the problem (parameters order while processing some function input?).

[stefano]

Nope, it works properly here.
I see the line being filled at the very beginning, then the countdown starts and the line gets progressively deleted from right to left.

Also chessboard.c and clock.c work correctly.

Really I don't know what to say, supposing we both have an updated z88dk environment and we are using it right, I'd blame the emulator.

[RobertK]

That's weird. I've just tried it with an older hc80.exe dated 2022-12-04, and it looks exactly the same (wrong, that is).
Maybe the difference is in the ROMs we are using?
BTW, the fuel bar in my game Deepspace looks like this:

Deepspace_PX-8.jpg

I thought that I would exactly reproduce this in my test program, but eventually I ended up with a different behaviour, I don't know why.

[RobertK]

I built your program by just adding the inclusion of <graphics.h>

Ok, that made the difference. When I include graphics.h, it looks good.

And when I do the same in Deepspace, the fuel bar does not leave any dotted trail. BUT: then drawing the full fuel bar is painfully slow, I prefer the dotted trail over that.

Apart from that, I'm a bit confused as when to include graphics.h and why some things are working without it - I thought that it's needed when using graphics primitives. I just noticed that in Deepspace I include graphics.h only when using 4x6 characters, but at least drawb() works without any problem.

[dom]

Apart from that, I'm a bit confused as when to include graphics.h and why some things are working without it - I thought that it's needed when using graphics primitives. I just noticed that in Deepspace I include graphics.h only when using 4x6 characters, but at least drawb() works without any problem.

The library exports each symbol twice - eg drawb and _drawb (for sccz80 and sdcc) if you omit the header it links in the sdcc entry point. Apart from the va-args functions in classic they point to the same address.

[stefano]

I think the inclusion of graphics.h enables the callee parameter passing mode, which in theory makes the code faster and smaller. Probably the slowness in place of the expected speed has to do with the subcpu involement, e.g. it takes long to compute the line coordinates, or maybe the choke is in the parameter passing to the SUBCPU when drwaing a line.
the fact you get some output without graphics.h with a faster reaction is a clue we can investigare on, though.