Commander X16

yock1960 wrote: ↑Sun Apr 07, 2024 7:01 pm

ahenry3068 wrote: ↑Sun Apr 07, 2024 11:58 am I said a similiar approach. You would probably want to take out all the Banking stuff just to use this to call procedural variables.

There is a bit of overhead to the approach. But you would use it where otherwise there would be a lot of branching to select call path so your eliminating that other overhead.

Again I fall back to Pascal to illustrate the approach, you would have to go about it a bit differently in assembly or Prog8

{procedure declaration} Procedure QuickSort (function Compare(&Data1; &Data2;) : boolean; procedure SwapData(&Data1; &Data2;); &SortData; SizeData : LongInt;);

In that example QuickSort would be able to sort almost ANY Data. The quicksort routine itself would only have calls to Compare & SwapData in the procedure code itself. The functions and procedures to do the sorting and swapping would be passed in as parameters. This is VERY Powerful. In some way's it was kind of the precursor to Object oriented programming. Objects work much the same at the Machine Language level.

Perhaps too advanced for me...many years ago, when I looked at C++....it was like....this is a "bridge too far"! My brain struggles with too much indirection!

Glad to hear you've got it sorted. I really really want to check out Pascalish... I just haven't had a chance due to multiple projects and priority conflicts.

I'm going to leave you with one last example of How a procedural variable would be used. I realized I actually used the approach on one of my Basic routines. The following routine actually either copy's a rectangular area from the VERA graphics layer to a file, or takes it out of the file and puts it back to the VERA screen based on the Value of the Variable PutImage (if true the direction is from file to Screen). SET.IO & DO.FILEIO are variables that determine what ROM routines get called with SYS. "PROCEDURAL VARIABLES". So I have ONE routine where it might otherwise be TWO separate routines.

This GOSUB is called with F$= FileName_ToUse. and X1,Y1,X2,Y2 & Blitlines and BlitWidth set to the proper values to describe the screen Area to "Blit" If PUTIMAGE is TRUE (-1 in BASIC) then the direction is from File to Screen, Otherwise the direction is from Screen to File.

Example code using this is Here:viewtopic.php?t=7022

BITBLT: ADDON$=",P,W" PREFIX$="@:" IF PUTIMAGE THEN PREFIX$="":ADDON$=",S,R" FF$=PREFIX$ + F$ + ADDON$ IF PUTIMAGE THEN SET.IO=CHKIN:DO.FILEIO=MACPTR:GOTO DOSCREENBLIT SET.IO = CHKOUT DO.FILEIO = MCIOUT BLITWIDTH = (X2-X1) + 1 BLITLINES = (Y2-Y1) + 1 DOSCREENBLIT: IF Y1+BLITLINES > YLIMIT THEN BLITLINES=YLIMIT-Y1 OPEN 2,8,2,FF$ POKE X.REG, 2 SYS SET.IO IF X1 > 255 THEN BYTESPLIT POKE R0L, X1 POKE R0H, 0 GOTO POKEY BYTESPLIT: POKE R0L, X1 AND $00FF POKE R0H, INT(X1/256) POKEY: POKE R1L, Y1 POKE R1H, 0 SYS FB.CURSOR.POSITION FOR Y= 1 TO BLITLINES I=0 INLOOP: BYTES=BLITWIDTH-I IF BYTES>$FF THEN BYTES=$FF POKE A.REG, BYTES POKE X.REG, $23 POKE Y.REG, $9F POKE C.REG, $01 SYS DO.FILEIO I=I+PEEK(X.REG) IF I<BLITWIDTH THEN INLOOP SYS FB.CURSOR.NEXTLINE NEXT Y CLOSE 2 SYS CLRCHN RETURN

Well, maybe by the time you have some time for it, I'll have a few more things figured out! My biggest gripe/frustration is when the compiler hangs, which is essentially an unhandled error/stuck in an endless loop. Typically it's stuck on a white space character after the end of a line semicolon, except that shouldn't happen, because the input routine 'consumes' all white space...and yet it does... occasionally. If there's a pattern, I've yet to figure it out. I need to buckle down and figure it out, but usually when it happens, I'm debugging Pascal code and just want to get on with it...