Apple-2-SW/prog8
1
0
Fork 0
mirror of https://github.com/irmen/prog8.git synced 2025-10-11 22:17:36 +00:00
Code Issues Projects Releases Wiki Activity

tweak sys.wait() routines on various targets

Browse Source 
add warning to docs about FP usage in IRQ
This commit is contained in:
Irmen de Jong
2023-01-20 03:10:41 +01:00
parent bbf6357222
commit 32c1c19224
6 changed files with 83 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
docs/source/libraries.rst
View File

@@ -91,13 +91,15 @@ sys (part of syslib)
``wait(uword jiffies)``
wait approximately the given number of jiffies (1/60th seconds)
note: the system irq handler has to be active for this to work as it depends on the system jiffy clock
Note: the regular system irq handler has run for this to work as it depends on the system jiffy clock.
If this is is not possible (for instance because your program is running its own irq handler logic *and* no longer calls
the kernal's handler routine), you'll have to write your own wait routine instead.
``waitvsync()``
busy wait till the next vsync has occurred (approximately), without depending on custom irq handling.
can be used to avoid screen flicker/tearing when updating screen contents.
note: a more accurate way to wait for vsync is to set up a vsync irq handler instead.
note for cx16: the system irq handler has to be active for this to work (this is not required on c64)
note for cx16: the regular system irq handler has to run for this to work (this is not required on C64 and C128)
``waitrastborder()`` (c64/c128 targets only)
busy wait till the raster position has reached the bottom screen border (approximately)

8
docs/source/targetsystem.rst
View File

@@ -165,3 +165,11 @@ The Commander X16 provides two additional routines that should be used *in your
; ... do your work that uses vera here...
cx16.pop_vera_context()
.. caution::
It is advised to not use floating point calculations inside IRQ handler routines.
Beside them being very slow, there are intricate requirements such as having the
correct ROM bank enabled to be able to successfully call them (and making sure the correct
ROM bank is reset at the end of the handler), and the possibility
of corrupting variables and floating point calculations that are being executed
in the interrupted main program. These memory locations should be backed up
and restored at the end of the handler, further increasing its execution time...