En regardant le code généré, j'ai même constaté que :

Code: [Select]

:20->A+2-Best moins optimisé que :

Code: [Select]

:20->A
:22->B

Pourquoi le premier exemple contient -B au lieu de →B? Il est possible que ça l'affecte.

En revanche :

Code: [Select]

:12->A->Best bel et bien plus optimisé que :

Code: [Select]

:12->A
:12->B

Vous avez raison. Le deuxième exemple répète la constante, qui prend 3 octets.

Before I begin, let me clarify something about shadow registers, because I was a bit confused about this myself for a while. When exchanging registers with shadow registers, the processor doesn't move values from the active registers into the shadow registers and vice versa. There is not one specified set of "active" registers and one specified set of "shadow" registers. Instead, the processor uses a mux to simply flip its definition of which set is the active set and which set is the shadow set. So when an interrupt activates, the processor simply designates the set of registers it wasn't previously using as the set that the interrupt will use.

Anyways, the reason the grayscale routines cause problems is because they require both sets of the af register pair. When not inside an interrupt this is fine, because nothing else was using the second af register pair. But during an interrupt, the af register pair that was being used before the interrupt probably has data in it that we don't want to destroy. However, because the grayscale routine uses both of the af register pairs, this saved value for af will be destroyed. My solution was to back up the saved af register which we don't want destroyed by putting it onto the stack at the start of the routine. At the end of the routine, it is then taken off the stack and put it back into the inactive af register to live to see another day.

For that matter it might be better to make class and power whole bytes, as that would make each entry size 24 and probably make the retrieval of those two values a lot easier/smaller/faster.

Quigibo, would you go for grayscale routines that are 5 bytes and about 33 cycles larger, but work with interrupts? I may be wrong, but I believe this could be done by changing the start and end of the routines like so:

Code: (Current routine) [Select] Start: ld a,i push af di End: pop af ret po ei ret

Code: (Interrupt-friendly routine) [Select] Start: ex af,af' push af ld a,i push af di End: pop af ex af,af' pop af ex af,af' ret po ei ret

kindermoumoute, serait-il d'accord si je lis le tutoriel et souligné les erreurs que j'ai trouvé?

If you have 150 labels, your compiled code probably shouldn't fit in RAM anyways.

The two bytes that specify the size of the variable should be the 2 bytes immediately preceding the pointer returned from GetCalc(), whether using the normal or archive method. This is easy for variables in RAM, because the variable's data starts with two bytes for its size, and the VAT pointer for the variable always points right to it. However, when variables with variable names (programs, lists, appvars, and groups) are archived, the variable's name (and possibly other data, I'm not sure) is appended to the file in front of the two bytes indicating size. To correct this, Quigibo's archive variable locating routine determines the length of the variable's name from the VAT and adds that to the pointer to skip this unwanted data and to be consistent with unarchived variables. However, he forgot to check if the variable's type is a protected program, so it thinks that any protected program doesn't have this and doesn't correct for the name length.

Could buffer operations be extended to support buffer arguments? I don't think I urgently need it, but I'm sure others would like it. And since all the commands already exist, it would be best not to have to make whole new copies of all the commands with Axioms. Most of the current routines would handle it with no problem. I guess the question is how hard/time-consuming it would be for you to implement it? Variable buffers would play nice with all of the following commands.

• ClrDraw
• DispGraphClrDraw
• StoreGDB
• StorePic (the destination buffer would have to come first and in hl, so an ex de,hl would need to be added)
• RecallPic
• DrawInv
• All of the screen shifting commands
• All of the pixel commands
• Line()
• Rect()
• RectI()

EDIT: Completely unrelated, but how did you come up with 1900 and 4700 cycles as arguments to pause for approximately one second? I calculated more like 1800 and 4500 for 6.0MHz and 15.0MHz, or about 1850 and 4600 for 6.15MHz and 15.4MHz (which is about how fast my TI-84+SE runs I believe).