Commander X16

yock1960 wrote: ↑Fri Apr 05, 2024 11:17 am A question for anyone using this, or anyone that cares to comment. Currently, Pascal-iSh has a limit to program code size of 4096 p-codes. This is includes p-code as well as data that is contained within the Pascal-iSh source code, such as strings or any initialized array. I've increased this maximum in steps, from the original limit of 2000 in the original source code. The current limit is predicated on the fact that by design, each p-code has the potential to be associated with a corresponding word of data, not all of this data is used with any given p-code, but is there nonetheless. So, 4096 p-code requires 8192 bytes of data, which is 1 bank of high ram. To go beyond 4096, is to require an additional bank of high ram. This is not a difficult thing to do, but doing it comes at a cost in program execution speed, since now the interpreter must check the value of the program counter at the start of the p-code interpreter loop so as to know which bank to switch into the low ram 'window'. Until just recently, I have not come very close to exceeding the 4096 limit, but obviously, a program with a large amount of initialized data, has this potential. Coding the interpreter to do this check shows about a 5% speed hit. Pascal-iSh is already slow. As this is already a moot point, since this project is more of a personal 'voyage' than anything really useful, it probably doesn't matter. Still, as an exercise, in the imaginary world that this would actually be used by anyone, does it make sense to implement an increase in the p-code maximum to 8192? This would be the last increase, as to go beyond would be even more expensive from an execution speed perspective and I doubt that anyone would ever code such a massive program in Pascal-iSh! Additionally, I think that if(when) I add file read/write capabilities, it would reduce the 'footprint' of programs with large data sets, where an array could be initialized from a file with a read loop, rather than being encoded within the source, which is somewhat expensive in terms of p-code required. This would perhaps stave off the need to increase to 8192....this is perhaps an incorrect assumption, since I'm not sure of the 'overhead' that file usage will require...

ahenry3068 wrote: ↑Fri Apr 05, 2024 11:25 am
The interpreter is written in BASIC, correct ? 5% isn't that great, bank switching isn't near that expensive at the hardware level so that hit is probably mostly BASIC overhead. Go ahead and implement the 8196 increase and send me the source for the interpreter. Flag the part that does the Bank check prominently with REMARKS in the source. Tell me what string to search in the editor for that section. I'll see if I can do up an ML sub for that section that mitigates that 5% hit by some amount. I'll include the ML back in the source as Data and write a sub to POKE it for you. Is your program currently using any of the Golden Ram area ($400-$7FF) ? ? That's where the ML code will live in memory.

yock1960 wrote: ↑Sun Apr 07, 2024 8:04 am

ahenry3068 wrote: ↑Fri Apr 05, 2024 11:25 am
The interpreter is written in BASIC, correct ? 5% isn't that great, bank switching isn't near that expensive at the hardware level so that hit is probably mostly BASIC overhead. Go ahead and implement the 8196 increase and send me the source for the interpreter. Flag the part that does the Bank check prominently with REMARKS in the source. Tell me what string to search in the editor for that section. I'll see if I can do up an ML sub for that section that mitigates that 5% hit by some amount. I'll include the ML back in the source as Data and write a sub to POKE it for you. Is your program currently using any of the Golden Ram area ($400-$7FF) ? ? That's where the ML code will live in memory.

No, all code is either Prog8 or assembly. I did a small assembly snippet for the check, to use the correct bank for the first or second bank of data, it helped some, putting the speed 'hit' from just over 5% to just under versus the straight Prog8 code.. Prog8 is pretty good, but I guess all compilers have a bit of overhead, since they can't make assumptions in all cases.

I had a thought yesterday, about somehow incorporating some method to implement a type of 'memory model' system into the 'works', where you could basically 'have your cake and it eat, too', have the 'speed' for smaller projects, but the ability to have bigger projects, that will necessarily be slower. I would like to do this without having a bunch of different executables, or somehow 'shielding' users from such messiness...but haven't thought on that enough yet.

ROM_BANK = 1

trampoline:
  phx
  ldx ROM_BANK ; THE ROM BANK
  stx bank_to_jmp ; VARIABLE ON ZEROPAGE
  stz ROM_BANK ; #$01
  ldx r14+1
  stx OPADDR+1
  ldx r14
  stx OPADDR
  plx
  jsr $FFFF
OPADDR = * -2
  pha
  lda bank_to_jmp
  sta ROM_BANK
  pla
  rts

ahenry3068 wrote: ↑Sun Apr 07, 2024 8:38 am

yock1960 wrote: ↑Sun Apr 07, 2024 8:04 am

ahenry3068 wrote: ↑Fri Apr 05, 2024 11:25 am
The interpreter is written in BASIC, correct ? 5% isn't that great, bank switching isn't near that expensive at the hardware level so that hit is probably mostly BASIC overhead. Go ahead and implement the 8196 increase and send me the source for the interpreter. Flag the part that does the Bank check prominently with REMARKS in the source. Tell me what string to search in the editor for that section. I'll see if I can do up an ML sub for that section that mitigates that 5% hit by some amount. I'll include the ML back in the source as Data and write a sub to POKE it for you. Is your program currently using any of the Golden Ram area ($400-$7FF) ? ? That's where the ML code will live in memory.

No, all code is either Prog8 or assembly. I did a small assembly snippet for the check, to use the correct bank for the first or second bank of data, it helped some, putting the speed 'hit' from just over 5% to just under versus the straight Prog8 code.. Prog8 is pretty good, but I guess all compilers have a bit of overhead, since they can't make assumptions in all cases.

I had a thought yesterday, about somehow incorporating some method to implement a type of 'memory model' system into the 'works', where you could basically 'have your cake and it eat, too', have the 'speed' for smaller projects, but the ability to have bigger projects, that will necessarily be slower. I would like to do this without having a bunch of different executables, or somehow 'shielding' users from such messiness...but haven't thought on that enough yet.

I was in a back and forth on asm-dev(Discord) a couple days ago with treeman0013. We came up with the following routine to allow Calling ROM routines from "Cartridge code" which is itself in ROM. This routine is first copied down to $0400. To make the BIOS call the Cartridge code sets up for it as usual (Registers and Parameters) Then stores the desired ROM call address in r14 and does a JSR $400

The "Trampoline" saves and switchs ROM banks. Does the BIOS call. Then returns to the Calling ROM code. Kind of like JSRFAR does, except with Cartridge code NONE of the ROM calls are directly available. This uses self modifying code.

The point of posting this is a similar approach can be used for "Procedural Variables" (In this code the "Procedural Variable" is r14).

Turbo Pascal on the PC had this feature and it was extremely useful. 1 example would be having a generic Shell Sort routine where "Compare" & "Swap Value" were procedural variables. That way 1 routine could sort many different Data Types. Just rewrite Compare & "Swap Value".

By using procedural variables you can avoid the use of "if thens" for calling different subroutines for different situations. Instead you've made the procedure itself a "Variable"

Code: Select all

ROM_BANK = 1

trampoline:
  phx
  ldx ROM_BANK ; THE ROM BANK
  stx bank_to_jmp ; VARIABLE ON ZEROPAGE
  stz ROM_BANK ; #$01
  ldx r14+1
  stx OPADDR+1
  ldx r14
  stx OPADDR
  plx
  jsr $FFFF
OPADDR = * -2
  pha
  lda bank_to_jmp
  sta ROM_BANK
  pla
  rts

			
%asm{{				
	lda p8v_pc+1           ;get high byte of pc (program counter)
	cmp #$10                 ;is it $10?
	bmi +                       ;if minus flag set {less than), then pc < $1000, set bank 3
	lda p8v_pc               ;else need to check low byte
	beq +                       ;if not zero, then pc > $1000, set bank 4
	lda #$04                  ;bank 4
	sta p8v_dbank
	bra ++
+	lda #$03                  ;bank 3
	sta p8v_dbank
+				
}}

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.