Wow, that's not good. Applied this nop, and what I got is a total mess. No blinking but sprites ar displayed at incorrect positions, as if someone shuffled the puzzle
Do not put NOPs in the interleave version, it is has tight timing (and also is in its own branch for a reason, haven't fully tested it on all hardware)
Without a nop, it blinks. There is another workaround: move the code to another cog.
Edit: nop removed, cog changed to #1, that was good for previous version. No blinking, but sprites still shuffled. Used master branch.
Edit2: slot_interleaved looks much worse.
Both version looks like Y coordinate of the sprite is bad. They repeats several times vertically. Slot_interleaves also doesn't display the full sprite leaving black horizontal strips. I think I put the the rest of this, including several photos, on the neoyume main topic
I can now have functions that can have parameters ( sin(x) for example)
Another change was adding a "housekeeper" cog. That cog now only waits for vblank and reads the mouse position, that's near useless, but I want to implement the idea from Picomite. They made use of the second Pico's cog to service the GUI elements: buttons, gauges, etc, in the background, so the main program has only to read the values. Such a cog can also simulate timer interrupts, vblank interrupts, etc, the only problem is the HDMI driver is not ready for more than 1 cog that access it.
The interpreter again became a full mess, that needs deep cleaning. It also needs a proper editor
Fun fact: FlexBasic doesn't like arguments greater than 4*pi for sin(). It then returns 0. The interpreter compensates this now for integer arguments using mod internally. For float values... no workaround at this moment. Also the interpreter being the retro interpreter uses standard 360 grads system instead of radians
defsprite (spritenum, x,y,w,h) converts the rectangle fragment of the screen to a sprite
sprite( spritenum, x,y) places the sprite on the screen at position x, y
Sprites are a part of the video driver, so from the Basic's point of view, these are hardware sprites.
There are 16 sprites, size up to 512x576 (driver's width limit is 512, a height is unlimited) , but as they are hub based, they eat the hub ram. Currently a 256 kB heap is declared and a memory for a sprite is allocated on this heap.
Maybe I can find a way to move the sprite memory to PSRAM...
(Video deleted. The "breakout" video below shows the sprites in the action much better)
This time the program is longer than one screen, but still less than 50 lines. It can be written better and still has some bugs in it: the ball can escape from the playfield if hit the "correct" , or rather not correct, pixel.
Here is the listing combined from 2 photos (I had to implement list startline,endline to do this)
and a result of executing this code looks like this. The audio in the background does not come from a P2 (yet) It is lft's Lunatico SID tune.
They are now only parts of the name. I have to clean the mess after this revolution and modify several runtime procedures: for-next loop works strange when fed with strings
@msrobots said:
make a foreach and iterate thru the characters of the string :-)
Mike
That would be useful for strings and arrays, but I have no arrays yet, so maybe later
I looked at this new flash FS, but it seems to collide with the SD card as it is now, leaving the clock signal low after the flash read. However I have a flash driver that can be used with the SD card, so maybe I can adapt this FS to use it instead. Or wait until it matures.
Optional line numbers need a full screen editor (see PicoMite) that I haven't yet. As it is now, there is no way to write anything without line numbers.
The internal line structure has a field, that is currently unused, called linenum_minor, that was done for this purpose. I don't know, where it will end
The variable type extensions added to the complexity of the interpreter and that's why I removed them. I have now one assign function, one getvar function and 2 tokens for them instead of 8 functions and 8 tokens, and need to adding another ones for new types. Also, the variable structure is now ready to keep more internal types. I needed it to add arrays (they are not added yet)
Instead of adding arrays, or something, I had to recover from a stupid "accident" that caused the program to stop working after I upgraded the compiler to test the new flash FS... involving restoring from the repository,, moving to the older flexprop, etc, with no results. The problem was stupid enough: installing a new flexprop and cleaning the config caused BRK debug to switch on, and the BRK debug destroyed timings of the video driver and disabled the PSRAM mailbox moved to $7FF00.
There was no "<>' and "-" operators so I had to write "0-a" instead of "-a" and make strange acrobations to check if something is not equal. Operators added, sanity restored
@pik33 said:
The housekeeper cog now clocks at 200 Hz, synchronizing with vblank every 4th tick. Mouse draw program works much smoother.
The USB driver always trys to poll at 1000Hz regardless of descriptor-set interval (except if you have a kb+mouse combo device, that goes 500Hz). You can get really smooth curves from that. I still haven't tried if it works with my logitech expensive mouse (that's actually supposed to do 1000Hz)... Maybe when I finally get a new one the old will be freed up for stupid experiments.
The interpreter is not as fast at least as it is now. While 50 Hz mouse polling gives polygons instead of curves when fast moving the mouse, 200 Hz is smooth enough to not see any polygons while drawing.
Added a flood fill to the video driver, and that enables to add this to the intepreter too. The program below allows to draw with a mouse. Left button draws, wheel changes the color, right button clears the screen, middle button/wheel click fills the shape. A mouse that sends its wheel position, is needed. In my test, Logitech M215 mouse does this, Logitech G102 also works, and one of my Auchan "quilive" mice can do it too. Other cheap mice, vakoss, gembird, titanum,etc, don't.
The arrival of arrays and the return of typed variables
At version 0.21 the interpreter got arrays. As there are now, the implementation is buggy as *, so while they works, entering a nonsense may cause the interpreter to crash instead of a proper error message. To do.
Also the way they are now serviced are very not optimal including unnecessary reading/writing into PSRAM several times while a proper way to do this is to read/write the whole header at once. Also to do
The arrays are declared in a standard Basic way
dim varname(size1,size2,size3)
There can be up to 3 dimensions of an array. If less than 3, unused dimensions are internally set to 1
An array declared this way is untyped, so this
dim a(3)
a(0)=2
a(1)=3.456
a(2)="string"
is allowed and works
However such an array allocates 12 bytes per element and while placed in the PSRAM, this space is not infinite. We declare arrays to keep a lot of data. That's why they can be typed. Names of types are (near) the same as in flexbasic: byte, ubyte, short, ushort, long or integer, single, string. There are also int64 and double reserved for the future.
The typed array have the element size determined as its data size (byte-1 byte, long - 4 bytes)
This also allows to declare a typed variable, because
dim a as ulong
became internally
dim a(1,1,1) as ulong
and creates an "array" of 1 element.
There is a known and still not corrected bug that causes strings to disappear. Now I can start to fix it by placing string literals in the PSRAM along with these arrays.
Edit: too fast a(1,2,3)=456 and print a(1,2,3) works, but b=a(1,2,3) doesn't .... to do.
Now it works. A stupid bug: while commenting out printing debug messages, I commented out too much caused several variables to be uninitialized...
@Rayman said:
Looks good! Can it control I/O pins yet?
Pinwrite implemented, to blink a led. The rest (pinread, wrpin, wxpin, wypin, rdpin, rqpin can be implemented in several minutes as this is only adding a keyword, a token, and a "do_something" procedure that in this case will call Flexprop's builtin functions.
I will add them in the next iteration.
There are gosub/return, input and file operations not implemented yet, and arrays are still buggy.
new
dim a(1,1,1) as ulong
a(100,100,100)=40
print a(100,100,100)
and yes, it will print 40, and as a side effect, a red pixel and 3 black pixels will be displayed on the screen. Of course the desired behavior is an error message
Maybe in addition to standard pin operations I can add analog read and analog write..
Pin operations now added. These are pinread, pinwrite, pinstart, pinfloat, pinhi, pinlo, pintoggle, wrpin, wxpin, wypin. rdpin, rqpin. Not yet tested, but this blinker:
I guess you could use Chip's new flash filesystem for saving/loading programs, right?
Not "as is" as it now involves smart pins to drive the flash. I have to use the version with bitbanged flash access and flash clock left at 1 after operation. That may be used along with the SD. It still has to be unmounted before using the flash, but can be then mounted again
I guess you could use Chip's new flash filesystem for saving/loading programs, right?
Not "as is" as it now involves smart pins to drive the flash. I have to use the version with bitbanged flash access and flash clock left at 1 after operation. That may be used along with the SD. It still has to be unmounted before using the flash, but can be then mounted again
It will be something like 'save F:program.bas'
There's a preliminary version of a FlexSpin VFS for Chip's file system in github now, so you'll be able to use regular BASIC open/read/write commands on flash files (and of course there's also the littlefs file system too).
Atari ST mode has a proper Atari ST keyboard click
Added "position" command that sets the cursor position before print. The X resolution is half a character that allows to center the string that has an odd length.
A mouse pointer has now a proper black outline.
String arays now work
Fixed a bug that disabled printing string literals while still printing string variables.
Fixed a bug that causes errors when : character was placed inside a string
Comments
Wow, that's not good. Applied this nop, and what I got is a total mess. No blinking but sprites ar displayed at incorrect positions, as if someone shuffled the puzzle
Do not put NOPs in the interleave version, it is has tight timing (and also is in its own branch for a reason, haven't fully tested it on all hardware)
Without a nop, it blinks. There is another workaround: move the code to another cog.
Edit: nop removed, cog changed to #1, that was good for previous version. No blinking, but sprites still shuffled. Used master branch.
Edit2: slot_interleaved looks much worse.
Both version looks like Y coordinate of the sprite is bad. They repeats several times vertically. Slot_interleaves also doesn't display the full sprite leaving black horizontal strips. I think I put the the rest of this, including several photos, on the neoyume main topic
Yes, do that, it sounds very weird. Also put full config file and flexspin version.
I can now have functions that can have parameters ( sin(x) for example)
Another change was adding a "housekeeper" cog. That cog now only waits for vblank and reads the mouse position, that's near useless, but I want to implement the idea from Picomite. They made use of the second Pico's cog to service the GUI elements: buttons, gauges, etc, in the background, so the main program has only to read the values. Such a cog can also simulate timer interrupts, vblank interrupts, etc, the only problem is the HDMI driver is not ready for more than 1 cog that access it.
The interpreter again became a full mess, that needs deep cleaning. It also needs a proper editor
Fun fact: FlexBasic doesn't like arguments greater than 4*pi for sin(). It then returns 0. The interpreter compensates this now for integer arguments using mod internally. For float values... no workaround at this moment. Also the interpreter being the retro interpreter uses standard 360 grads system instead of radians
NeoYume now works, so time to try the parameters
I started to implement a sprite machine
defsprite (spritenum, x,y,w,h) converts the rectangle fragment of the screen to a sprite
sprite( spritenum, x,y) places the sprite on the screen at position x, y
Sprites are a part of the video driver, so from the Basic's point of view, these are hardware sprites.
There are 16 sprites, size up to 512x576 (driver's width limit is 512, a height is unlimited) , but as they are hub based, they eat the hub ram. Currently a 256 kB heap is declared and a memory for a sprite is allocated on this heap.
Maybe I can find a way to move the sprite memory to PSRAM...
(Video deleted. The "breakout" video below shows the sprites in the action much better)
Impressive. This could result in much-needed exposure and acceptance of the P2
Craig
Having sprites, i had to write a "game"...
This time the program is longer than one screen, but still less than 50 lines. It can be written better and still has some bugs in it: the ball can escape from the playfield if hit the "correct" , or rather not correct, pixel.
Here is the listing combined from 2 photos (I had to implement list startline,endline to do this)
and a result of executing this code looks like this. The audio in the background does not come from a P2 (yet) It is lft's Lunatico SID tune.
The latest binary with a "manual" and a breakout.bas attached. A binary is huge due to 256 kB heap declared.
Got rid of variable types defined by the suffix. The main difference is now you can write
10 a="this is a string"
20 b$=1
and it will assign a string to a and an integer to b$
The "breakout.bas" code still works after this, and the interpreter itself can be now simpler.
well, you do not need the suffix at all then, right?
They are now only parts of the name. I have to clean the mess after this revolution and modify several runtime procedures: for-next loop works strange when fed with strings
make a foreach and iterate thru the characters of the string :-)
Mike
That would be useful for strings and arrays, but I have no arrays yet, so maybe later
I looked at this new flash FS, but it seems to collide with the SD card as it is now, leaving the clock signal low after the flash read. However I have a flash driver that can be used with the SD card, so maybe I can adapt this FS to use it instead. Or wait until it matures.
@pik33
So with these non-traditional enhancements, does this mean that line-numbers will eventually be optional?
Craig
Optional line numbers need a full screen editor (see PicoMite) that I haven't yet. As it is now, there is no way to write anything without line numbers.
The internal line structure has a field, that is currently unused, called linenum_minor, that was done for this purpose. I don't know, where it will end
The variable type extensions added to the complexity of the interpreter and that's why I removed them. I have now one assign function, one getvar function and 2 tokens for them instead of 8 functions and 8 tokens, and need to adding another ones for new types. Also, the variable structure is now ready to keep more internal types. I needed it to add arrays (they are not added yet)
Instead of adding arrays, or something, I had to recover from a stupid "accident" that caused the program to stop working after I upgraded the compiler to test the new flash FS... involving restoring from the repository,, moving to the older flexprop, etc, with no results. The problem was stupid enough: installing a new flexprop and cleaning the config caused BRK debug to switch on, and the BRK debug destroyed timings of the video driver and disabled the PSRAM mailbox moved to $7FF00.
BRK off, the program works again
The housekeeper cog now clocks at 200 Hz, synchronizing with vblank every 4th tick. Mouse draw program works much smoother.
There was no "<>' and "-" operators so I had to write "0-a" instead of "-a" and make strange acrobations to check if something is not equal. Operators added, sanity restored
The USB driver always trys to poll at 1000Hz regardless of descriptor-set interval (except if you have a kb+mouse combo device, that goes 500Hz). You can get really smooth curves from that. I still haven't tried if it works with my logitech expensive mouse (that's actually supposed to do 1000Hz)... Maybe when I finally get a new one the old will be freed up for stupid experiments.
The interpreter is not as fast
at least as it is now. While 50 Hz mouse polling gives polygons instead of curves when fast moving the mouse, 200 Hz is smooth enough to not see any polygons while drawing.
Added a flood fill to the video driver, and that enables to add this to the intepreter too. The program below allows to draw with a mouse. Left button draws, wheel changes the color, right button clears the screen, middle button/wheel click fills the shape. A mouse that sends its wheel position, is needed. In my test, Logitech M215 mouse does this, Logitech G102 also works, and one of my Auchan "quilive" mice can do it too. Other cheap mice, vakoss, gembird, titanum,etc, don't.
The interpreter got its own repository:
https://github.com/pik33/P2-Retromachine-Basic
The arrival of arrays and the return of typed variables
At version 0.21 the interpreter got arrays. As there are now, the implementation is buggy as *, so while they works, entering a nonsense may cause the interpreter to crash instead of a proper error message. To do.
Also the way they are now serviced are very not optimal including unnecessary reading/writing into PSRAM several times while a proper way to do this is to read/write the whole header at once. Also to do
The arrays are declared in a standard Basic way
dim varname(size1,size2,size3)There can be up to 3 dimensions of an array. If less than 3, unused dimensions are internally set to 1
An array declared this way is untyped, so this
is allowed and works
However such an array allocates 12 bytes per element and while placed in the PSRAM, this space is not infinite. We declare arrays to keep a lot of data. That's why they can be typed. Names of types are (near) the same as in flexbasic: byte, ubyte, short, ushort, long or integer, single, string. There are also int64 and double reserved for the future.
The typed array have the element size determined as its data size (byte-1 byte, long - 4 bytes)
This also allows to declare a typed variable, because
dim a as ulongbecame internally
dim a(1,1,1) as ulongand creates an "array" of 1 element.
There is a known and still not corrected bug that causes strings to disappear. Now I can start to fix it by placing string literals in the PSRAM along with these arrays.
Edit: too fast
a(1,2,3)=456 and print a(1,2,3) works, but b=a(1,2,3) doesn't .... to do.
Now it works. A stupid bug: while commenting out printing debug messages, I commented out too much caused several variables to be uninitialized...
0.22
I restored the sanity to save/load : these .bas files are now a plain editable text instead of being strange uneditable files.
Looks good! Can it control I/O pins yet?
Pinwrite implemented, to blink a led. The rest (pinread, wrpin, wxpin, wypin, rdpin, rqpin can be implemented in several minutes as this is only adding a keyword, a token, and a "do_something" procedure that in this case will call Flexprop's builtin functions.
I will add them in the next iteration.
There are gosub/return, input and file operations not implemented yet, and arrays are still buggy.
and yes, it will print 40, and as a side effect, a red pixel and 3 black pixels will be displayed on the screen. Of course the desired behavior is an error message
Maybe in addition to standard pin operations I can add analog read and analog write..
Pin operations now added. These are pinread, pinwrite, pinstart, pinfloat, pinhi, pinlo, pintoggle, wrpin, wxpin, wypin. rdpin, rqpin. Not yet tested, but this blinker:
works as expected.
Addpins syntax and Spin2 constants are not yet implemented, so that's why there is "64" that is equivalent of addpins 1
That's nice. I'm also a BASIC fan, although seems left in the dust by Python these days. Maybe it will come back with stuff like this?
Sometimes the first thing you want to do with MCU is blink an LED, so thanks for adding.
I guess you could use Chip's new flash filesystem for saving/loading programs, right?
Not "as is" as it now involves smart pins to drive the flash. I have to use the version with bitbanged flash access and flash clock left at 1 after operation. That may be used along with the SD. It still has to be unmounted before using the flash, but can be then mounted again
It will be something like 'save F:program.bas'
There's a preliminary version of a FlexSpin VFS for Chip's file system in github now, so you'll be able to use regular BASIC open/read/write commands on flash files (and of course there's also the littlefs file system too).
0.23b:
Atari ST mode has a proper Atari ST keyboard click
Added "position" command that sets the cursor position before print. The X resolution is half a character that allows to center the string that has an odd length.
A mouse pointer has now a proper black outline.
String arays now work
Fixed a bug that disabled printing string literals while still printing string variables.
Fixed a bug that causes errors when : character was placed inside a string