FastBasic 4.3 - With DLI!

[RALPH!]

Thank you for answers, can use ASM to set up data and character sets with some short 6502 code. Had some old Turbo Basic programs tried last year with Fast Basic. Some variables had remain as Float because need for fraction. 

Have 6502 code to control player/missile sprites that locate X Y, address and height.  Save address to erase next cycle before move.

[RALPH!]

I use 6502 code with basic so things short and fast. Machine Language can do tasks and be under few hundred bytes that Basic programs may need over 1k.

 

To do new program from start for all 6502 Assembly would consume time. Have few TurboBasicXL programs. This Fast Basic provides goid alternative. Grateful to have this language now.

[rsh]

This is really cool setup.  I'm looking for something simple like this for Action! to add color to players.  Everything I've run across requires a VBI and seems very complex... where you don't use one.  Do you have an example in Action!  Any suggestions.  I'm not currently familiar will basic.syn syntax to convert these to raw asm or Action!

[dmsc]

Hi!

10 hours ago, rsh said:

This is really cool setup.  I'm looking for something simple like this for Action! to add color to players.  Everything I've run across requires a VBI and seems very complex... where you don't use one.  Do you have an example in Action!  Any suggestions.  I'm not currently familiar will basic.syn syntax to convert these to raw asm or Action!

 

The idea is simple: use the COLRSH O.S. variable to count the current line, so that each DLI is:

DLI:
  ' Save Registers
  PHA
  TXA
  PHA
  ' Read current counter and sync
  LDX COLRSH
  STX WSYNC
  ' Read from table and store color
  LDA table,X
  STA COLBK

  ' Increment counter for next DLI
  INC COLRSH
  ' Exit DLI
  PLA
  TAX
  PLA
  RTI

 

The standard OS will clear COLRSH to 0 on each vertical blank, even when the critical flag is set, whenever the attract mode is skipped.

 

Have Fun!

 

[rsh]

11 hours ago, dmsc said:

Hi!

 

The idea is simple: use the COLRSH O.S. variable to count the current line, so that each DLI is:

DLI:
  ' Save Registers
  PHA
  TXA
  PHA
  ' Read current counter and sync
  LDX COLRSH
  STX WSYNC
  ' Read from table and store color
  LDA table,X
  STA COLBK

  ' Increment counter for next DLI
  INC COLRSH
  ' Exit DLI
  PLA
  TAX
  PLA
  RTI

 

The standard OS will clear COLRSH to 0 on each vertical blank, even when the critical flag is set, whenever the attract mode is skipped.

 

Have Fun!

 

Thank you very much.  I will see if I can get this to work. 

[rsh]

On 8/5/2020 at 11:32 PM, dmsc said:

Hi!

 

The idea is simple: use the COLRSH O.S. variable to count the current line, so that each DLI is:

DLI:
  ' Save Registers
  PHA
  TXA
  PHA
  ' Read current counter and sync
  LDX COLRSH
  STX WSYNC
  ' Read from table and store color
  LDA table,X
  STA COLBK

  ' Increment counter for next DLI
  INC COLRSH
  ' Exit DLI
  PLA
  TAX
  PLA
  RTI

 

The standard OS will clear COLRSH to 0 on each vertical blank, even when the critical flag is set, whenever the attract mode is skipped.

 

Have Fun!

 

I have messed around with this more, not sure I understand the mechanics yet...   How do we tie the line of the DLI to the player position?   I guess we are using player 2 to multiplex over the other players and change the color in the process. where does the move player2 and color change occur in the DLI?  

Edited August 10, 2020 by rsh

[vitoco]

On 3/1/2020 at 12:57 PM, dmsc said:

Quote

The 'DLi counter' you are exploiting is the COLRSH register ($4F).

Once the attract mode is triggered this is given a value from middle clock register ($13) during the VBI. (e.g. "bx db(COLRSH)>4")
Whilst in most cases just colours or sprite positions are being set and so at most will then to stop being animated and give them different colours, this is dangerous as it means that access to DATA BYTE arrays are potentially out of bounds.

As you said, if you use it as intended it does not causes problems, simply the colors would be wrong. Read accesses would be out of bounds, but normally still in RAM.

I previously forced attract mode while testing and I didn't found an issue, but today I found how bad it behaves when the updated registers are, for instance, P/M horizontal positions. Forced to keep POKEing 77,0 during gameplay loops, which is always required anyway.

[eflake]

How would you get one to move vertically (PM graphic)

Edited February 1, 2022 by eflake

[dmsc]

Hi!

On 2/1/2022 at 2:30 PM, eflake said:

How would you get one to move vertically (PM graphic)

 

If you are asking about moving P/M graphics, see the sample at:  https://github.com/dmsc/fastbasic/blob/master/samples/int/pmtest.bas#L42

 

Basically, the "MSET" erases the sprite at the old position, and the "MOVE" draws it again at the new position. Just remember to do all clearing/drawing after a PAUSE, so the process is hiden in the vertical retrace and no flicker is produced in the screen.

 

Have Fun!

[Kyle22]

nevermind.

Edited February 19, 2022 by Kyle22
FB is great.