Starting out

[xArtx]

Funny that, I have an iOS App that does the same code section up to thousands of times,
rotating thousands of points, and a few years later can make it much faster


[ Show youtube player ]

Originally Posted by tolkien

For sure It's better to precalculate al sin() cos() you can. They are expensive CPU functions.

[xArtx]

Hi Guys
Well I have got the clock read and write working from this example:
http://amigadev.elowar.com/read/ADCD.../node01A1.html

Where the library is opened and closed (with a potential error if the library failed to open),
If you want to constantly display the time such as Amiga Workbench clock does,
is there anything nasty happening for repeated iterations the same code to update seconds?

If I understand correctly, the use of this will open a library file from disk.
Is the library kept in RAM after opening and closing it the first time?
Cheers, Art.

[davideo]

Originally Posted by xArtx

If I understand correctly, the use of this will open a library file from disk.
Is the library kept in RAM after opening and closing it the first time?
Cheers, Art.

AFAIR

Once opened all libraries remain in memory unless you flush them with "Avail flush" or your Amiga starts to run out of memory.

Also if you open the same library twice in the same program it does not open it twice but increases a counter and decreases it once closed. Only when the counter is at Zero will it close the library if required.

[xArtx]

Ok, thanks that makes sense. It’s not like my HDD LED is flashing or anything like that,
more that I don’t want to do something stupid, and then keep going on that program.

[thomas]

Originally Posted by xArtx

Where the library is opened and closed (with a potential error if the library failed to open),
If you want to constantly display the time such as Amiga Workbench clock does,
is there anything nasty happening for repeated iterations the same code to update seconds?

You should not use the ReadBattClock function unless you really want to read the battery backed up clock.

To get the system time there is GetSysTime in timer.device (number of seconds since 1978 and number of microseconds since last second) or DateStamp in dos.library (number of days since 1978, number of minutes since midnight and number of 50Hz ticks since last minute).

If I understand correctly, the use of this will open a library file from disk.
Is the library kept in RAM after opening and closing it the first time?
Cheers, Art.

First of all the library is kept in memory only once, no matter how many programs use it concurrently.

Yes, the library remains in memory after CloseLibrary. It maintains an open counter and if the counter is higher than 0, the library remains fixed in memory. Only if the use count is 0 it may be expunged by the memory system. (You can cause it for example by AllocMem(0xffffffff,MEMF_ANY); )

[thomas]

Here is an example which prints the current date and time:

#include <proto/dos.h>

int main (void)

{
struct DateTime dt;
char day[LEN_DATSTRING];
char date[LEN_DATSTRING];
char time[LEN_DATSTRING];

DateStamp (&dt.dat_Stamp);

dt.dat_Format = FORMAT_DOS;
dt.dat_Flags  = 0;
dt.dat_StrDay = day;
dt.dat_StrDate = date;
dt.dat_StrTime = time;

DateToStr (&dt);

Printf ("%s, %s %s\n",day,date,time);

return (RETURN_OK);
}

[xArtx]

Ok thanks again that answers my questions.
It appears I am tending to do things the hard way

Originally Posted by thomas

You should not use the ReadBattClock function unless you really want to read the battery backed up clock.

I assume I read the system clock which in turn, got the time from the real time clock hardware if it was present.
I really do want to write a new time to the clock though (be able to update it),
so I’ll see if that also updates the system time.

Where are you getting these samples that are ready for Dice-C?

[thomas]

I assume I read the system clock which in turn, got the time from the real time clock hardware if it was present.

ReadBattClock does not read the system time, it only reads the RTC.

The system time is maintained by timer.device. It is synchronized with the RTC once at boot time by the SetClock command in startup-sequence. After that it runs independently from the RTC.

You can set the system time by sending a TR_SETSYSTIME command to timer.device.

The RTC can be set by the WriteBattClock function.

Where are you getting these samples that are ready for Dice-C?

I develop them myself. I've been using Dice C since it became freely available and only recently switched to vbcc.

However, the examples you get from me are not specific to Dice C, they compile with all Amiga compilers.

[xArtx]

Hi again Guys
I have kept things in this thread rather than clutter the place.
So far I’ve tried to use a new device/library each sitting, and the last one was narrator.

This problem I have was present from the beginning, and don’t know how to deal with it.
Even present when running DEMO1 and DEMO2 Pong samples supplied by Thomas.
I see the difference between the two is the second waits for vertical draw time,
and possibly the second one uses bitter to draw the rectangles.

There’s screen flicker at a certain horizontal area of the screen around where the
mouse pointer is sitting in the video. It flickers in an area about 1 or 2 inches of the screen,
and I haven’t worked out how to get rid of it. It stops flickering if I stop drawing of course.

I presume something to do with raster not synchronised with drawing?
Is there a way to perhaps draw every second frame to avoid this even if the program runs slower?

[ Show youtube player ]

[thomas]

Originally Posted by xArtx

I see the difference between the two is the second waits for vertical draw time,
and possibly the second one uses bitter to draw the rectangles.

There are only two differences between the two demos. The first one is obvious: while demo1 consists of only one source file with one big main routine, demo2 uses a more modular approach. It is divided into several smaller routines and the routines are grouped by topic into several source files keeping each file as simple as possible. This is also the base for object oriented programming, keeping the data structures private and using functions (a.k.a. methods) to access them.

The second and main difference is the source for the timing. Demo1 uses INTUITICKS which only arrive ten times a second. Demo2 uses timer.device UNIT_VBLANK which occurs 50 or 60 times a second, making movement a lot more smooth.

There’s screen flicker at a certain horizontal area of the screen around where the
mouse pointer is sitting in the video. It flickers in an area about 1 or 2 inches of the screen,
and I haven’t worked out how to get rid of it. It stops flickering if I stop drawing of course.

The problem is that neither timing method is synchronized with the display. Both are based on the vertical blank pulse of course, but the interrupt routine first handles all the system needs before it calls the user program.

There is no easy way to syncronize the display with AmigaOS functions. If you look at the double buffering example in the graphics.library manual you'll become scared.

But there are some tricks to at least avoid flickering. For example if you draw the changed area of the screen first into an off-screen bitmap and then blit the finished bitmap into the screen, it does no longer flicker. It still shows some tearing effects, though.

I've changed the demo2 source accordingly.

[xArtx]

Thanks again Thomas
That does explain it well. I’ve been looking at this manual for graphics drawing,
but the samples for primitives don’t animate anything. They just draw something.
http://www.pjhutchison.org/tutorial/amiga_c.html
Would you please link to the manual/example for double buffering?
I’ve Googled a few results, but don’t know what to try. Is is something like this?
http://wiki.amigaos.net/wiki/Intuiti...doublebuffer.c
It does actually animate something which is helpful.

For the video I posted with talking time, if I stopped moving the time in a circle
and only updated the time display on seconds change, then I assume the issue
would be all but gone, and then suitable for some non-graphics oriented programs.

I’ve decided to hold off a little till I get a Gotek or some other way to get files into the Amiga easily.

[thomas]

Yes, I think this is the example or at least a similar one. I used the one from the older OS3 manual. This one is for OS4.

Basically it gives you two signals: IIRC one when you may switch screen buffers and another when the current buffer has been displayed so that you may reuse it. It was a bit difficulty to understand why these occasions are not the same and I don't remember the details.

I found an example of mine but it flickers like hell and corrupts Workbench, so it's obviously not correct. Maybe I find some time to develop a new one later this week.

[xArtx]

OS4 specific is something I should watch out for, as not good for the CD32 if OS4 is required.
Maybe something to do with the small time in vertical blanking?
I ordered the Gotek today so should be back into it soon.
Thanks for your help again, any time you do invest in samples,
I don’t tend to get frustrated and run away, but usually do dig in and finish things

[xArtx]

I have a dodgy fix, it could be applied to the Pong game, but not a screen packed with graphics.
To refrain drawing each item (text feild) if the VBeamPos is around the position you want to draw it,
but you could still move the object. For each object you might occasionally drop a frame.

I programmed both game and demo for the Digic CPU in Canon camera and didn’t have to do this.
Maybe because it’s LCD not CRT, so the scanline is really just imaginary.

There’s some problems from capturing with iPhone and uploading to YouTube,
but the CRT screen I see here is smooth always.
[ Show youtube player ]

[thomas]

Took a closer look at the example you linked and found that it is completely different from what I used. It's much more advanced and actually a complete program and not only an excerpt.

I changed the OS4 code so that it compiles on OS3 (see attachment).

Hint: you have to select "run" from the menu to see something move.

[Bastich]

Originally Posted by tolkien

For sure It's better to precalculate al sin() cos() you can. They are expensive CPU functions.

Very good advice

[xArtx]

Thanks
Going further without fixing the graphics is a bit of putting the cart before the horse,
but I started importing some local Astronomy algorithms ported to C long ago.
[ Show youtube player ]

[xArtx]

Hi Guys,
I have not run the double buffer sample.. still waiting for the Gotek,
but made a bit of a start. It’s supposed to be the user selects a location on a world map.
This one just plots a hard coded point, and the Astronomy information is correct for the point.
[ Show youtube player ]

[xArtx]

Back again
This time I want to use the serial port for GPS. Is this document still relevant?
http://amigadev.elowar.com/read/ADCD.../node009A.html

I have the GPS working with NComm so I know it’s electrically ok:
[ Show youtube player ]
It’s a 5Hz model, so most of it I’ll be trying to ignore to just get one $GPRMC sentence per second.
The idea is to set the Amiga’s clock and to display the location on the map.
Particularly where the bare CD32 unit has no battery backup clock, but the Garmin unit does.
Cheers, Art.