User Tools

Site Tools

Trace: • vbasic_tutorial
vbasic_tutorial

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
vbasic_tutorial [2020/10/12 09:30] – [Transferring VASYL data] silverdrvbasic_tutorial [2022/12/04 12:01] (current) – [Transferring VASYL data] silverdr
Line 11: Line 11:
  
   * general BASIC programming at somewhat lower level((Mandatory for sound and graphics)), where the built-in programming aids like full support for haxadecimal numbers, 16-bit PEEKs and POKEs, as well as LO/HI functions come in very much handy. Even without BeamRacer installed   * general BASIC programming at somewhat lower level((Mandatory for sound and graphics)), where the built-in programming aids like full support for haxadecimal numbers, 16-bit PEEKs and POKEs, as well as LO/HI functions come in very much handy. Even without BeamRacer installed
-  * adding stunning visual effects to BASIC programs thanks to full VASYL assembly support((Obviously requires BeamRacer expansion installed in order to see them inaction))+  * adding stunning visual effects to BASIC programs thanks to full VASYL assembly support((Obviously requires BeamRacer expansion installed in order to see them in action))
   * rapid prototyping of timing-sensitive visual effects for award winning demos or games, testing which would normally require a lot of boilerplate code   * rapid prototyping of timing-sensitive visual effects for award winning demos or games, testing which would normally require a lot of boilerplate code
   * verification and debugging of VASYL programs thanks to built-in VASYL memory monitor/disassembler   * verification and debugging of VASYL programs thanks to built-in VASYL memory monitor/disassembler
Line 33: Line 33:
 > But why not to simply issue a ''DLOFF'' in the first line instead? > But why not to simply issue a ''DLOFF'' in the first line instead?
  
-Please note that the ''DLOFF''/''DLON'' combination does not reinitialise all of the chip's internal structures. ''DLOFF'' is best suited to //temporarily// stop already running displaylist processing. Like when we need to change displaylists at runtime. +Please note that the ''DLOFF''/''DLON'' combination does not reinitialise all of the chip's internal structures. ''DLOFF'' is best suited to //temporarily// stop already running displaylist processing. Like when we need to change displaylists at runtime. Obviously ''DLON'' alone is also indispensable once everything is ready to roll.
  
 ==== Parallelism ==== ==== Parallelism ====
Line 44: Line 44:
     * VIC registers     * VIC registers
   * turn off displaylist processing with a ''DLOFF'' statement whenever you need to modify displaylists, which may also be modified by VASYL from within the displaylist itself   * turn off displaylist processing with a ''DLOFF'' statement whenever you need to modify displaylists, which may also be modified by VASYL from within the displaylist itself
-  * keep eye on potential parallel use of VASYL ''PORTx'' (and related ''ADRxL/H'', ''STEPx'') registers - neglecting this can lead your program into lalaland in no time!+  * keep a close eye on potential parallel use of VASYL ''PORTx'' (and related ''ADRxL/H'', ''STEPx'') registers! Neglecting this can lead your program into lalaland in no time!
  
 The least error-prone approach is to set the displaylist and other VASYL memory data in their entireties, before starting displaylist processing with ''DLON'' statement. But we know that it is often unfeasible so having the above points in mind may save you lots of debugging time. The least error-prone approach is to set the displaylist and other VASYL memory data in their entireties, before starting displaylist processing with ''DLON'' statement. But we know that it is often unfeasible so having the above points in mind may save you lots of debugging time.
Line 73: Line 73:
   * ''1000-1999'' hold code that is executed in parallel while the displaylist is already running   * ''1000-1999'' hold code that is executed in parallel while the displaylist is already running
   * ''2000-'' get filled with subroutines as needed   * ''2000-'' get filled with subroutines as needed
- +This lines numbering scheme is of course just an example of the author's proven preference. The real takeaway here is:
-Obviously this lines numbering scheme is just an example of the author's proven preference but the real takeaway here is:+
  
   - initialise things upfront   - initialise things upfront
   - never forget to configure the "conveyor(s)" you're going to use   - never forget to configure the "conveyor(s)" you're going to use
   - never forget to close the displaylist off with a ''VEND''   - never forget to close the displaylist off with a ''VEND''
-  - actually starting displaylist processing may help in some cases ;-)+  - actually starting displaylist processing with a ''DLON'' may help in some "nothing works" cases ;-)
  
 ===== Common patterns ===== ===== Common patterns =====
Line 103: Line 102:
 </code> </code>
  
-Here above lines 110 to 999, when executed, will assemble and store our displaylist in VASYL memory starting at address $0000. The same approach works well for much larger programs too.+Here above lines 110 to 999, when executed, will assemble and store our displaylist in VASYL memory starting at address $0000. The same approach works well for much larger programs too but displaylist programs can also be prepared separately and stored/loaded as needed from storage medium like disk drive for example. We'll cover these more advanced techniques later.
  
 ==== Transferring VASYL data ==== ==== Transferring VASYL data ====
Line 162: Line 161:
 </code> </code>
  
-sends another dataset $1F00 thereto.+sends another dataset $1F00 thereto. In order to make ''VDATA'' more versatile than regular ''DATA'', we made it accept binary values in three forms: 
 + 
 +  * decimal numbers ranging from ''0'' to ''255'' 
 +  * hexadecimal numbers ranging from ''$00'' to ''$FF'' 
 +  * [[wp>Little-endian|LE]] strings of hexadecimal values (as seen in the last example above)
  
 Using ''VDATA'' is an order of magnitude faster than plain ''DATA'' ''READ''ing and ''VPOKE'''ing. It is best suited for up to medium-sized datasets. OTOH there are times when you want to send larger sets of data to VASYL RAM. Typical example would be graphics/bitmap data, which needs to be placed in VASYL memory before it can be used as source for the Programmable Bitmap Sequencer for instance. Storing all those bits in ASCII encoded form of a BASIC program might be((Size dependent, of course)) possible but surely a far cry from efficient use of available resources. Chiefly BASIC RAM but also LOADing and processing time((ASCII encoded binary will be over twice the actual binary size in the **best** case)). Using ''VDATA'' is an order of magnitude faster than plain ''DATA'' ''READ''ing and ''VPOKE'''ing. It is best suited for up to medium-sized datasets. OTOH there are times when you want to send larger sets of data to VASYL RAM. Typical example would be graphics/bitmap data, which needs to be placed in VASYL memory before it can be used as source for the Programmable Bitmap Sequencer for instance. Storing all those bits in ASCII encoded form of a BASIC program might be((Size dependent, of course)) possible but surely a far cry from efficient use of available resources. Chiefly BASIC RAM but also LOADing and processing time((ASCII encoded binary will be over twice the actual binary size in the **best** case)).
Line 223: Line 226:
 > OK but what if my data is larger than the 4KiB available at 49152??  > OK but what if my data is larger than the 4KiB available at 49152?? 
  
-The answer is either you find a buffer large enough to hold all your data at once or you need to ''LOAD'' the data in chunks not larger than the available buffer. I would strongly recommend the latter approach - split the file into as many smaller ones as needed and then ''LOAD'' and ''COPY'' them one by one. This will always work regardless of the size of your BASIC program.+The answer is either you find a buffer large enough to hold all your data at once or you need to ''LOAD'' it in chunks not larger than the available buffer. I would strongly recommend the latter approach - split the file into as many smaller ones as needed and then ''LOAD'' and ''COPY'' them one by one. This will always work regardless of the size of your BASIC program.
  
 > But wouldn't it be much better to simply ''OPEN'' the file and read its content byte by byte and use ''VPOKE'' to send it to VASYL? > But wouldn't it be much better to simply ''OPEN'' the file and read its content byte by byte and use ''VPOKE'' to send it to VASYL?
Line 233: Line 236:
  
   - adapt the way you handle data transfer to VASYL memory to the amount of data you need to move there   - adapt the way you handle data transfer to VASYL memory to the amount of data you need to move there
-  - it does not pay to ''LOAD'' a few bytes. Using DATA or ''VDATA'' will be more efficient and less error-prone+  - it does not pay to ''LOAD'' a few bytes. Using ''DATA'' or ''VDATA'' will be more efficient and less error-prone
   - when dealing with large amounts of data, the most efficient way is to ''LOAD'' it in chunks not larger than the available buffer size. Up to 4KiB in practice   - when dealing with large amounts of data, the most efficient way is to ''LOAD'' it in chunks not larger than the available buffer size. Up to 4KiB in practice
   - steer clear of using memory areas other than the 4KiB of free RAM available at $c000. You'll thank me once we meet :-)   - steer clear of using memory areas other than the 4KiB of free RAM available at $c000. You'll thank me once we meet :-)
Line 290: Line 293:
 5603 REM **************************** 5603 REM ****************************
 5610 PRINT "PATCHING KERNAL..."; 5610 PRINT "PATCHING KERNAL...";
-5620 VCFG1,$E000,1 : REM $E000 +5620 VCFG 1,$E000,1 : REM $E000 
-5630 VCFG2,$E000,1 : REM KERNAL ROM+5630 VCFG 2,$E000,1 : REM KERNAL ROM
 5640 COPY #1,#2,$2000 5640 COPY #1,#2,$2000
-5650 VCFG1,$E000,1 : REM $E000 +5650 VCFG 1,$E000,1 : REM $E000 
-5660 VCFG2,$E000,1 : REM KERNAL ROM+5660 VCFG 2,$E000,1 : REM KERNAL ROM
 5670 COPY #2,#1,$2000 5670 COPY #2,#1,$2000
 5680 POKE $E882,$11 : REM PATCH SCROLL 5680 POKE $E882,$11 : REM PATCH SCROLL
-5690 POKE1,53: REM SWITCH TO RAM KERNAL+5690 POKE 1,53: REM SWITCH TO RAM KERNAL
 5700 RETURN 5700 RETURN
 </code> </code>
Line 305: Line 308:
 === VDATA revisited === === VDATA revisited ===
  
-In previous sections we discussed how easy and efficient it is to configure a "conveyor" and then use ''VDATA'' statements to quickly move data into VASYL RAM. What we didn't mention though is the fact that we can use the ''#2'' conveyor to make VDATA (and many other "V" statements) talk to computer's main memory. Remember this famous example from page 71 of [[http://www.zimmers.net/anonftp/pub/cbm/c64/manuals/C64_Users_Guide.pdf|Commodore 64 Users Guide]]? Yeah - who can forget it, right?+In previous sections we discussed how easy and efficient it is to configure a "conveyor" and then use ''VDATA'' statements to quickly move data into VASYL RAM. What we didn't mention though is the fact that we can use the conveyor ''#2'' to make VDATA (and many other "V" statements) talk to computer's main memory instead. Remember this famous example from page 71 of [[http://www.zimmers.net/anonftp/pub/cbm/c64/manuals/C64_Users_Guide.pdf|Commodore 64 Users Guide]]? Yeah - who can forget it, right?
  
 <code> <code>
Line 351: Line 354:
 Here we have a relatively small dataset so the difference is adequately small too. But the more data you need to process, the more clearly pronounced the difference becomes. Here we have a relatively small dataset so the difference is adequately small too. But the more data you need to process, the more clearly pronounced the difference becomes.
  
 +TBC
vbasic_tutorial.1602520253.txt.gz · Last modified: 2020/10/12 09:30 by silverdr