User Tools

Site Tools

Trace:
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/11/03 05:44] – 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 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
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 :-)
vbasic_tutorial.1604411069.txt.gz · Last modified: 2020/11/03 05:44 by silverdr