bB wish list

[bogax]

  There are things I wish you could do (more directly) in bB
  And there are common idioms that I think it would be useful to have built in
  Things that are not hard to do now but could be more convenient

 

  Karl G suggested in another thread some facility for multidefinition sprites for animations and such

 

  Ranged random numbers is another that comes up frequently

 

  Computed bit indexes

 

  Maybe transposed tables so you could specify values in sets for eg the sound registers and have them go into seperate tables

 

  Perhaps some built in division-by-a-constant routines similar to mutiplication by a constant

 

 

  My wish list is more nuts and bolts

 

  I'd like more direct access to the CPU registers and flags

  It would be nice if the registers were more fully integrated in to the syntax
  But even a few assembly instructions would help

 

  ACC = [expression]  do the normal thing but suppress the assignment just leave the result in the accumulator

 

  var = mem[XREG]     do the normal thing but suppress the loading of x

 

  TAX, TXA, LDX, STX

 

  so you could do something like

 

  ACC = [expression] : TAX : Px = tablex[XREG] : Py = tabley[XREG]

 

  without generating a lot of extranious load and store instructions

  (of course XREG = [expression] would be nicer)

 

  Some dedicated if constructs for testing flags would be nice

 

  if CARRY then ...  or  if !CARRY then ...   no predicate expression, just test the carry flag
  (likewise for the z, n, v flags)

  I generally like the way macros work, although I like to hide the callmacro key word with a def statement
  But using macros gets messy when trying to let the assembler know what it needs to know about what bB knows

  Perhaps I need a preprocessor ...

  I'd be curious to see other's wish lists

[KevKelley]

The only thing I could think of which I don't know if it would be wishlist worthy would be maybe a simpler or easier way to determine collision detection with a copy of a sprite.

 

Or if that is easier, then also making it simpler to do something like shoot a copy and then eliminate it.

 

So let's say if you have a game where you have 3 copies of a sprite and you shoot the middle one, make it easier to switch to to the 2 wide spread copies of a sprite.

 

I'm sure if I knew more or was more proficient in programming I would come up with more.

Edited February 28, 2021 by KevKelley
Elaboration

[+Random Terrain]

At one time batari was thinking about adding the ability to easily create nybble variables without the user needing to jump through a dozen flaming hoops. I don't know what the plan was. Maybe something like the following?
_

   dim _Flying_Monkey = a(lo)
   dim _Smelly_Socks = a(hi)

_
After DIMing, _Flying_Monkey and _Smelly_Socks would act like normal variables, but they would roll over from 15 to 0 and 0 to 15 in the other direction. bB would take care of the calculations and the user could use nybble variables without any worries. There are a lot of times when a full variable isn't needed, and a simple way to use nybble variables would be very helpful.

 

If someone starts working on batari Basic again, I hope nybble variables will be near the top of the to-do list.

[Mr SQL]

It would be cool to see an "old-school" mode for bB where no ASCII Art or compiler directives are required (either default directives or via a keyword language intrinsic) to allow competition in classic BASIC programming languages and more importantly to make learning easier for people who have used classic BASIC from the 70's and 80's.

 

It might be possible to add an old-school mode via the IDE.

 

Adding a print@ command for printing semi-graphic bit patterns at specific playfield positions would complement the set pixel x,y commands and is great for learning concepts visually like this bitwise example.

 

 

20 hours ago, bogax said:

I'd like more direct access to the CPU registers and flags

  It would be nice if the registers were more fully integrated in to the syntax
  But even a few assembly instructions would help

 

  ACC = [expression]  do the normal thing but suppress the assignment just leave the result in the accumulator

 

  var = mem[XREG]     do the normal thing but suppress the loading of x

 

  TAX, TXA, LDX, STX

 

  so you could do something like

 

  ACC = [expression] : TAX : Px = tablex[XREG] : Py = tabley[XREG]

 

  without generating a lot of extranious load and store instructions

  (of course XREG = [expression] would be nicer)

 

  Some dedicated if constructs for testing flags would be nice

That looks similar to BBC BASIC  mixing asm and BASIC statements together with the concatenator and would be really cool.

 

[+Karl G]

On 2/27/2021 at 10:10 AM, bogax said:

Ranged random numbers is another that comes up frequently

Yeah; that would be nice. I'm not sure of a good, clean way to implement it, however. There's a different way to approximate it depending on the specifics of the range. It might be a good thing to collect into a document rather than trying to build it into the language.

 

On 2/27/2021 at 10:10 AM, bogax said:

Computed bit indexes

 

Maybe transposed tables so you could specify values in sets for eg the sound registers and have them go into seperate tables

 

I'm not positive what you mean with these two items. Could you expand on what you are wanting?

 

On 2/27/2021 at 10:10 AM, bogax said:

ACC = [expression]  do the normal thing but suppress the assignment just leave the result in the accumulator

 

  var = mem[XREG]     do the normal thing but suppress the loading of x

 

  TAX, TXA, LDX, STX

 

  so you could do something like

 

  ACC = [expression] : TAX : Px = tablex[XREG] : Py = tabley[XREG]

 

  without generating a lot of extranious load and store instructions

  (of course XREG = [expression] would be nicer)

This is an interesting idea as a way to integrate some assembly with Basic syntax, and not have to step out of the latter with an asm block.

 

On 2/27/2021 at 10:10 AM, bogax said:

Some dedicated if constructs for testing flags would be nice

 

  if CARRY then ...  or  if !CARRY then ...   no predicate expression, just test the carry flag
  (likewise for the z, n, v flags)

7800basic has the CARRY keyword that works exactly as you describe. I'd like to see this brought over to bB as well.

[+Karl G]

11 hours ago, Random Terrain said:

At one time batari was thinking about adding the ability to easily create nybble variables without the user needing to jump through a dozen flaming hoops. I don't know what the plan was. Maybe something like the following?
_

   dim _Flying_Monkey = a(lo)
   dim _Smelly_Socks = a(hi)

_
After DIMing, _Flying_Monkey and _Smelly_Socks would act like normal variables, but they would roll over from 15 to 0 and 0 to 15 in the other direction. bB would take care of the calculations and the user could use nybble variables without any worries. There are a lot of times when a full variable isn't needed, and a simple way to use nybble variables would be very helpful.

 

If someone starts working on batari Basic again, I hope nybble variables will be near the top of the to-do list.

Yeah, this would be a cool addition, I think. It sounds like a pain to implement "under the hood", but I can see the advantages for the programmer for sure.

[bogax]

2 hours ago, Karl G said:

I'm not positive what you mean with these two items. Could you expand on what you are wanting?

  f{idx} = 1  ; idx must be a number 0..7, it can't be an expression or variable, it can't even be a named constant

  if f{idx} then ...

 Tables some thing like this

  ;  v0t name of volume table
  ;  c0t name of control table
  ;  f0t name of frequency table

  data v0t c0t f0t
  v0, c0, f0  ;  sets of values defining a note/sound the (values would presummably
  v1, c1, f1  ;  be numbers and the set of values would be like 9, 12, 23 etc)
  v2, c2, f2
  etc
end

 but they'd go into seperate tables
 and you access them as if you'd put all the vx's in a table named v0t like wise the c's and f's
 so v0t[0] specifys v0, f0t[2] specifys f2
 it would be as if you'd defined tables like this

  data v0t
  v0, v1, v2
end

  data c0t
  c0, c1, c2
end

  data f0t
  f0, f1, f2
end

 and your code would be something like (using the above suggested syntax,
 I'd normally do it in assembly and macros)

  note_ptr = note_ptr + 1
  LDX note_ptr
  AUDV0 = v0t[XREG]
  AUDC0 = c0t[XREG]
  AUDF0 = f0t[XREG]

[+Gemintronic]

Could a lateral solution work?  Some combination of an assembly include file with new routines and a code pre-processor that converts certain new commands into inline assembly?

 

Yeah, this is a badly explained idea that I hardly understand myself

 

Just trying to think of solutions that don't require extra attention/effort on batari or RevEng.

[bogax]

11 hours ago, Gemintronic said:

Could a lateral solution work?  Some combination of an assembly include file with new routines and a code pre-processor that converts certain new commands into inline assembly?

 

Yeah, this is a badly explained idea that I hardly understand myself

 

Just trying to think of solutions that don't require extra attention/effort on batari or RevEng.

Sure, some of it

Thats what I mean  a lot of this is not hard to do in bB
but it could be more convenient.

It does get kind of messy some times.

 

Some of it would probably better be integrated into bB

If I just want to stuff some sound registers from tables indexed with a common index
that's not too complicated

 

If I want to modify player x and y positions where the player is specified by an index
it might be doable but cost as much as it saved.

 

Some of it might just be messy

I'm not sure how you'd introduce an "if CARRY"
with out either recreating some of bB to get the bB syntax or introducing a different syntax for your if statments
That is to say I think you'd end up replacing some of bB with your preprocessor rather than just having a more
convenient way to express some of your bB code

 

Having said that I don't expect RevEng to drop what he's doing and modify bB to my specitications
(you know, "your greatest command is my slightest wish")

The most I might hope for is somthing like RevEng saying to him self
'suppressing the loading of x is would be useful without messing things up too much and
it would only take another line of code, so maybe next time'

If I knew more about how bB works I might try it myself
Except peeing in other peoples soup isn't very polite.

 

 

I do like the idea of some sort of macro prepocessor
You wouldn't risk messing up bB but it would add another layer of kruft
And I'm not sure you wouldn't just end up recreating bB
(I haven't thought about it much, certainly that wouldn't be the case for a lot of it)

How would you integrate the preprocessor in to the bB syntax?
eg in comments? or a block like PREPROCESSOR ... END

[KevKelley]

After thinking some more, another thing I had thought about that could make things interesting is perhaps a way to create a template for the game being made in an easier way.

 

I kind of touched up on this idea in another thread where I was wondering about the difficulty of moving the position of the score and life counters/status bar in the kernel do that it may appear on the top of the screen. Maybe kind of like the titlescreen editor...

 

Maybe allowing the programmer to kind of set up the parameters of their kernel in a more detailed way. I imagine this would probably be a big pain on the back end but maybe open up more for the programmers and maybe offer varying appearances for games.

 

And maybe even an easier way of doing things like the titlescreen (I have had a hard time trying to figure that thing out after multiple tries but do like the results when done).

[+Gemintronic]

I may have been thinking too VisualbB centric.  That IDE has a field for an alternative batch file to be used during the compile process.  It's the only way to successfully use VisualbB under Linux/WINE.  Anyway, inject your preprocessor into there.

 

My bB laundry list revolves around the plain, old multi sprite kernel.  None are actually requests.  Just selfish dreaming

 

Multi Sprite Kernel

* Seamless/integrated support for virtual sprites in the built in collision function

* Seamless/integrated support for playfield collision in built in collision function

* Ability to assign sprite data to more than one sprite.

*  It seems like off screen sprites still effect flickering on on-screen sprites at times.  I wonder if designating Y location 255 could tell the graphic kernel to stop processing a sprite and optimize itself accordingly.

* Find the CPU time for variable height ball/missiles.  I'd gladly sacrifice playfield and sprite resolution for this.

* Slipstream playfield background/foreground color support into the standard kernel.

* Prevent visual horizontal rebound of sprites when they cross the screen boundaries.  I.E. make them seamlessly transition from the screen and loop to the farthest relative position at the other edge.

* Special title screen mode with asymmetrical playfield and disabled sprites.  Maybe triggered by pfheight=0

* Integrated nybble variable support.  Multi sprite games are thirsty for variables!  'Specially in a QuadTari game.

* Fix the color bleeding when sprites move vertically through a multi color background.  I know this is currently only a feature in an unofficial extension.

* Managed sprite mode where player0 is swapped with whatever other sprite is going to cause flicker.  So, at least one pair of sprites will not flicker.  More RAM and CPU time but less flickery fickering bB games

 

 

[+Random Terrain]

Another thing I'd like to see is the DPC+ stack turned into variables. (Hopefully they'd be normal variables that aren't weird like those extra read/write Superchip RAM variables that have a bunch of limitations.) If I could have over 200 normal variables for making Atari 2600 games. I'd drop everything and start working on games right away.

[+Karl G]

24 minutes ago, Random Terrain said:

Another thing I'd like to see is the DPC+ stack turned into variables. (Hopefully they'd be normal variables that aren't weird like those extra read/write Superchip RAM variables that have a bunch of limitations.) If I could have over 200 normal variables for making Atari 2600 games. I'd drop everything and start working on games right away.

 

I can tell you that unfortunately this one isn't possible. DPC+ memory can be accessed by the ARM processor, and there's no way for the 6507 to read and write to them directly. The stack gives a way to do this indirectly. Effectively it lets you save your existing variables, and restore them when you need them, but there's no way to bypass the need to use the stack or something similar to access ARM memory, unfortunately.

[+Gemintronic]

12 minutes ago, Karl G said:

 

I can tell you that unfortunately this one isn't possible. DPC+ memory can be accessed by the ARM processor, and there's no way for the 6507 to read and write to them directly. The stack gives a way to do this indirectly. Effectively it lets you save your existing variables, and restore them when you need them, but there's no way to bypass the need to use the stack or something similar to access ARM memory, unfortunately.

 

Things like expanded memory management and extended memory management existed in the 286/386 days.  Perhaps with a little more code running on the ARM side something can be done to mitigate the complexity for BASIC coders.

 

Maybe something that allows you to request to store ARM variables and retrieve ARM variables.  With a special flag raised when said reads or writes have executed.  So, it doesn't have to complete right away.

 

I wonder if a routine that pretends to be an internal SaveKey could be made.  That's another half coherent idea.

[+splendidnut]

Currently, the easiest way to access/use DPC+ Memory is using a Stack like system (that's just how it's designed)... but it can also be accessed like RAM.  I kinda do this in ChaoticGrill.  It just requires that the Data Fetcher be set before every memory access.

 

DPC+ Memory access could easily be made easier without the need for complicated ARM programming.   Essentially batariBasic would just need to be modified to "hide" that the memory is not as easily accessible as regular zeropage memory.  Same with SuperChip RAM, CBS+ RAM, E7 RAM... etc.

 

A new bank-switching scheme COULD (or a new varient of DPC+) be developed that gave a "window" into extra RAM, BUT that would require one of the SD Cart developers to implement it.   OR support could be added to batariBasic to support one of the other bankswitching schemes... it just takes time/willingness of someone to do it.

 

Granted... I have limited knowledge of batariBasic, but I believe these things are possible. 

 

 

[+Gemintronic]

Perhaps something like SARA RAM where part of the variable means something.

 

Like: var37b12 would indicate which variable (var 37) in which RAM bank (bank 12) should be read or written to.  Have the 6502 kernel and ARM code do the heavy lifting of retrieving said value from the ARM resources.

 

I guess an alternative to wait state flags would be to have a function for reading/writing ARM RAM.  Said function would return 255 if still waiting.

 

In other words, I'd trade the complexity of waiting for extra variable reads/writes over dealing with low level stuff like push pop foo lang dang whatchahooty.

[+Karl G]

29 minutes ago, splendidnut said:

Currently, the easiest way to access/use DPC+ Memory is using a Stack like system (that's just how it's designed)... but it can also be accessed like RAM.  I kinda do this in ChaoticGrill.  It just requires that the Data Fetcher be set before every memory access.

 

Interesting. So perhaps some of this could be done "under the hood" in this manner. I would worry about users unknowingly adding a lot of extra code by accessing these variables frequently in their programs if bB puts in extra code "under the hood" to make it work. But, still, it's interesting.

 

@RevEng - this is not a request for you to add such a feature, but as I've not done much with the DPC+ code, I'm curious for your opinion on the technical feasibility of bB being able to be extended to do virtual ARM variables as splendidnut speculates here.

[+splendidnut]

For DPC+, if you limited it to 256 extra vars (page aligned), then for 8-bit vars, the assembly becomes:

;-- setup to read extra variables (only need to do once after end of kernel)

LDA		#extraVarPage 		;-- which 256-byte page to use in DPC+ memory
STA		DF0HI

;---- then for writing a variable:  (value to write in Accumlator)

LDX		#varIndex
STX		DF0LOW
STA		DFOWRITE

;--- OR for reading to a variable  (value read into Accumlator)

LDX		#varIndex
STX		DF0LOW
LDA		DF0DATA

 

EDIT:  mixed my reads/writes.... ugh

 

[+splendidnut]

Hmmmm.... At some point, I should dust off the C cross-compiler I was writing, and getting that ready for public consumption.

[RevEng]

So it's possible in theory to do that in bB, but it would take major overhaul to most of it. Each time a variable is accessed, used as a parameter, etc., bB will have to fetch and store to arm as needed

 

In my mind the question is, should we really abstract away all of those extra cycles and rom? A statement like "mem=mem+3" normally generates something like...

lda mem
clc
adc #3
sta mem

While with ARM memory becomes something like...

LDX		#memIndex
STX		DF0LOW
LDA		DF0DATA
clc
adc #3
LDX		#memIndex
STX		DF0LOW
STA		DFOWRITE

Which is about twice the rom and cycles. A huge chunk of the game code deals with variables, so unfettered usage of the ARM variables with this interface will eat your game's lunch. The only way to mitigate this cost is to adopt a "load memory" and "save memory" ethos prior to certain sections of your code, at which point the whole thing starts to look the current ARM stack functionality anyway.

 

[+splendidnut]

Actually, you can take advantage of the same var being read/modified/written to.  So it could be done like this:

LDX		#memIndex
STX		DF0LOW
LDA		DF0DATA
clc
adc #3
STA		DFOPUSH

Granted, for more complicated expressions, it would have to be as you wrote.

 

5 minutes ago, RevEng said:

In my mind the question is, should we really abstract away all of those extra cycles and rom?

Always a good question to ask.  The language is called Basic.  All depends on how "basic" you want to make the language for the users. 

 

[+Karl G]

4 minutes ago, splendidnut said:

Always a good question to ask.  The language is called Basic.  All depends on how "basic" you want to make the language for the users. 

 

The issue isn't with making the language too basic, but with the possibility of users running into issues where they inadvertently generate too much code "under the hood" without realizing it by the way they use variables that might seem indistinguishable from the normal bB variables. Still, it's interesting knowing how these reads and writes can be done with a lot less effort than I expected.

 

Btw, what is the cross compiler you mentioned before?

[RevEng]

20 minutes ago, splendidnut said:

Always a good question to ask.  The language is called Basic.  All depends on how "basic" you want to make the language for the users. 

As basic as it can be, without hobbling the game.

 

It's the same reason that bB lacks print statements, lacks character strings, uses one byte for regular variable types, uses fixed point vs floating point, etc. If an abstraction would be too costly in the context of the 6507, then out it goes.

 

[+splendidnut]

I wrote about it here (no public release yet):

 

Still needs quite a bit of working... but it's actually, somewhat usable.

 

[+splendidnut]

3 minutes ago, RevEng said:

uses one byte for regular variable types

So this DPC+ thing would be "somewhat" reasonable then? 

 

You could require the user to prefix the DPC+ variable access with "DPC->" or something similar.