clock.c doesn't work on ZX81

ZX80, ZX 81, ZX Spectrum, TS2068 and other clones
Post Reply
Bolador
New member
Posts: 9
Joined: Thu Jan 30, 2020 4:56 am

clock.c doesn't work on ZX81

Post by Bolador »

Hi, (me again) learning every day (night)
following Stefano?s advice I searched clock.c https://github.com/z88dk/z88dk/blob/mas ... cs/clock.c I am trying something that may benefit from lib3d and timing routines are of interest to but i couldn't make it work on a ZX81 (EightyOne v1.6 16Kb wrx enabled)
"zcc +zx81 -oclock -startup=2 -lgfx81 -lndos -create-app -llib3d clock.c" did compile without errors, it asks for HOURS and Minutes then it hangs up leving me with the K cursor.. nothing is drawn at the screen.

in the case of "zcc +zx81ansi -oclock -startup=3 -lgfx81hr192 -lndos -create-app -llib3d -DDETAILED clock.c" I had to change it for " ... +zx81 -clib=ansi ..." ( shouldn't this be updated at the source comment?) and I got

Code: Select all

C:\descargas\CZ1000\zxtext2p>zcc +zx81 -clib=ansi -oclock -startup=3 -lgfx81hr192 -lndos -create-app -llib3d -DDETAILED clock.c
Error at file 'target/zx81/graphics_hr/_clg_hr.asm' line 32: symbol 'hr_rows' not defined
Errors in source file C:\descargas\CZ1000\z88dk\lib\config\..\..\\lib\target\zx81\classic\zx81_crt0.asm:
Error at file 'target/zx81/graphics_hr/_clg_hr.asm' line 32: symbol 'hr_rows' not defined
I compiled it for Spectrum un had no problem at all but I am trying with zx81 as is my main target..
Thanks
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

I confirm that something recently broke on the ZX81, both globe.c and clock.c are now failing.
Bolador
New member
Posts: 9
Joined: Thu Jan 30, 2020 4:56 am

Post by Bolador »

stefano wrote:I confirm that something recently broke on the ZX81, both globe.c and clock.c are now failing.
Ups.. is something with some libraries, which one? or the compiler?
Any work around in the meantime? I am just intrested in the lib3d functionality.. (I need to figure out how to use it, some tutorial would be great)
Thank you!
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

Ok, globe.c works, I was trying to use a modified variant where I put spectrum specific asm code, which obviously crashed on the zx81.
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

I think I finally found the problem, I think it is the 'circle' function failing.
The lib3d part and most of the graphics functions are in working order.
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

isin() and icos() are very simple, they take an integer value as function argument and give you back a result multiplied by 256.
So, suppose you had something like: m*sin(x), it can be replaced by isin(x)*m/256, where the first will require float variables, and the latter will be a much faster integer approximation.

The XDIV constant you see in clock.c is an extra optimization for those high resolutions where the aspect ratio needs to be corrected, you can ignore it.
User avatar
dom
Well known member
Posts: 2076
Joined: Sun Jul 15, 2007 10:01 pm

Post by dom »

The compilation issue is due to a missing -subtype= option

I've not looked too much at the ZX81 target, but if the main difference in startup is due to variables then we should embed the variables in the libraries and simplify things to stop an explosion of compilation combinations.
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

I think that the variables are only a minor part of the problem, the graphics is often bound to hw specific interrupt drivers. Even in text mode a different display sync routine is provided to preserve at least one of the two index registers. The startup options link the startup code with a specific display driver to the appropriate library.
The circle function was personalized to preserve few registers (a'). I see it is now rewritten in c?
User avatar
dom
Well known member
Posts: 2076
Joined: Sun Jul 15, 2007 10:01 pm

Post by dom »

Yes, I can see that now. I think they can still be placed in the library now that sections are available and we can call routines early, however it all looks very delicate.

The assembler version of circle still exists, I think what must've happen is that it's switched from dcircle2 to dcircle as part of the re-org. The quickest thing to do is to add:

gfx/narrow/obj/${TARGET}/dcircle2

to the graphics .lst files in target/zx81 before the @gfx/narrow/gfx_narrow.lst line - that way the code in dcircle2 will take precedence.

The C version of circle is for the 8080 machines. I guess switching to that for the ZX81 would work - at least it won't use index registers or af'
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

Thank you ! I missed the new position of the .lst files for the zx81 and thought they were gone.
I'm adding a .lst file with such exceptions (dfill2, dcircle2, etc..) I wonder it they can help the 8080 targets too.
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

Ok, I finally chose to add a common .lst file holding those exceptions needed by the zx81.
I'm following an experimental approach, thus even if in the past many exceptions were included, at the moment it includes only "dcircle2.asm".
Oddly "dfill", "liner" and others seem to work without requiring the fixed versions! I'm still trying to test them in depth, the in example xample.c demo is still not in fully working order.
Other targets may have been impacted, e.g. I need to check the KC machines.

By the way clock.c will be available again on the ZX81 (any graphics mode) after the next nightly build.

I suspect that some of the alternative functions listed in the "narrow" file library could work for the 8080 without having to rewrite them in C.
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

Dom, I'm still a bit lost with the new graphics, I've been trying to add graphics to the m100, but it hangs grabbing bkrestore somewhere.
I could be out of sync with the current tree.. the reference to ix present in bksave/bkrestore is interrupting the build process.
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

Problem found ! It was a local mess in my folders, a wrong asm file fell inside the generic graphics section and was prompty assembled in 8080 mode.
Post Reply