Re: [hatari-devel] compiling with ahcc from Hatari and command line ?

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 12/09/2023 à 23:16, Eero Tamminen a écrit :
> Hi,
>
> On 12.9.2023 22.45, Nicolas Pomarède wrote:
> > Le 12/09/2023 à 20:46, Eero Tamminen a écrit :
> > > PS. I added more info to tests main readme.txt.
> >
> > thanks, I must say that compiling with ahcc was not really 
> > straightforward :)
> > One missing thing I had to change was to add this line at top of 
> > scc_ser.prj :
> >
> > .C [-iinclude]
> >
> > Shouldn't we add it to all prj files ? It seems that without it, even 
> > if prj file is in same dir as ahcc.ttp then compilation fails due to 
> > missing includes.
>
> Sure.  Mine already have:
> tests$ find -name '*.prj' | xargs grep include
> ./tosboot/disk/gemdos.prj:.C [-iinclude]
> ./tosboot/disk/minimal.prj:.C [-iinclude]
> ./natfeats/nf_ahcc.prj:.C [-iinclude -DTEST=1]
> ./autostart/sleep.prj:.C [-iinclude -DSLEEP=4 -DSECS="4"]

Hi

by the way, what is the use of sleep.prj ? I tested it with --tos none 
(because it uses the sleep() call that I wanted to use) and it seems to 
exit immediately, not waiting 4 sec for example.

> But not all of these:
> $ ls */*.prj
> autostart/sleep.prj  gemdos/gmdostst.prj   serial/mfp_ser.prj
> blitter/blitemu.prj  keymap/keytest.prj    serial/midi_ser.prj
> cpu/int_test.prj     natfeats/nf_ahcc.prj  serial/scc_ser.prj

I will modify these to add the include line

> Btw. I just noticed that Thomas' initial SCC test code already included 
> & used delay_loop(), which just increments (volatile) integer counter 
> given number of times (4 & 8 are used in the tester code).

the delay_loop is too fast and it depends on the cpu speed, so the same 
loop won't take the same absolute time for an STF or a TT. It's enough 
to add a small delay between consecutive writes to HW registers, not to 
make an accurate delay in seconds.


> Why SCC now needs delay to be so much longer (several VBLs)?

when sending data over serial line, scc_ser.c for example exit right 
after writing the last char to be sent. But at the line is 9600 bauds 
the char won't reach the receiver before several hundreds cycles.

With the rewritten SCC code I see the last 2 bytes are not received to 
the associated file because scc_ser.tos exits, so pterm exit the fake 
tos, hatari closes and the last 2 bytes are never received.

A pause of a few VBL will ensure all ongoing data are correctly received 
before exiting the test.


>      - Eero
>
> PS. There are also sincludes (for different int size), but I do not 
> think anybody is going to use those as AHCC 32-bit int support is 
> somewhat broken.