"Audio nonsense" in action. I will add all these examples ( I made several of them) to the example folder in the next version. Cleaning up in progress....
0.32
Cleaning is now complete, the code is much more readable now, the runtime procedures are alphabetically sorted.
I added dir, cd, mkdir and delete commands. Now you can browse the SD directory tree using these commands and delete the garbage if needed.
Having these commands I managed to cleanup the examples, so now I can put then there.
In the attached zip, there are:
a binary itself, to flash,
a bas and media folders, to put into the SD - bas folder contains 25 examples /simple Basic programs ; media contains wave and envelope definitions to play
a simple (unfinished) manual
I still have to add some commands to make this fully playable: it lacks a keyboard input, except inkey$, print to files (print #), on expr goto/gosub, read and data, but I think it is fun as it is even now.
To play, you need a EC32, HDMI at 0, audio at 14, 15, USB at 16
Of course the interpreter can be recompiled with other pins. They are defined near the start of each driver. Use newest flexprop and enable -DFF_USE_LFN
Amazed at the rapid progress...much respect.
So there is already a precompiler? I thought that was going to be a future development but I imagine it being easier to implement as you go.
That, what is executed, is already translated to function numbers and a reverse Polish notation, so the runtime only calls the functions one by one, as they are saved in the precompiled line. And these function don't get parameters, they are pushed onto the stack before.
There may be an optimizer added, that can detect operations that can be done at the interpreting phase, for example sin(2+2) : it can be converted to sin(4) at the interpreting time (now it is not, it is compiled to 2,2,add,sin)
This kind of intermediate code can be also translated to pure asm. Maybe, in the far future. There is a lot to implement, and the interpreter is now fast enough to be fully usable (try to run graphtest.bas or breakout.bas)
Do you have anything that have an external RAM connected to it, that can be accessed by Rogloh's driver? I don't remember now what the KISS module have on board and if there is a possibility to attach a PSRAM chip to it
I will try to restore Eval (or anything) +4bit PSRAM support (that only needs to change several lines in the video driver)
framebuf and blit commands added.
framebuf returns the pointer to the frame buffer, that may be needed to do blit
Blit copies the rectangle from one place in the memory to another. May be used in the full form:
The interpreter in this version is intended to run with a HDMI monitor/screen and an USB keyboard. The goal was to convert the EC32 to an independent computer that can be programmed without any external PC.
I think about using this for a (robot, etc) control purposes so there will be (1) autorun feature (2) a possibility to free cogs and pins from unneeded drivers. Autorun I will add maybe today, drivers handling is planned after the 1.0 (or when I will do the next version of our robot, that already has a HDMI screen - and USBnew driver allows to use its touch interface too)
The last one is not heavily used now, it only does a 200 Hz clock and services mouse and joystick input, but I plan to add a GUI like PicoMite that works in the background
2 cogs still free.
I think about something that can allow dynamic loading/unloading the drivers. For example the keyboard and HDMI, while needed for programming, may not be needed by the program itself, so it can stop these cogs and load what it needs.
Starting a new cog is intended to add before 1.0. Unloading cogs... in the future. There are still 2 of them free.
Also, adding new things is/may be a result of playing and testing.
I have this UVC robot. It now uses standard, non-PSRAM Edge and it needs pins. While it already uses HDMI, audio and USB, the PSRAM needs 18 pins. The robot uses P40-P55 for its 8 ultrasonic distance sensors. However this Basic gives the possibility to control the robot via its touch screen (after adapting usbnew - to do) and program/control it without anything except a keyboard.
Maybe add a P1 to control the ultrasonic (and maybe something else, it has 32 pins) and connect it to a P2 via a serial connection?
The project is now stuck, we did several prototypes that are used in a hospital, and I don't know if the project will continue
If there is a /sd/bas/autorun.bas file, it will be executed automatically at the start of the interpreter.
The program can have brun in it, so it may be something like that:
10 i=0 : waitms 500
20 i=i+1: waitms 10 : a$=inkey$ : if a$<>"" then goto 40
30 if i>100 then brun player33.bin : else goto 20
40 mode 0 : new
The program will start with the interpreter and wait 0.5 seconds to give the time for USB to init. Then it will loop another second waiting for a key
If any key pressed in this time, the program will end. If not, it will run the binary /sd/bin/player33.bin.
So reset-wait-got a player or reset-keypress-got a Basic.
Edit: I updated the "new" command so it can be called from inside the program. It cleans the program and immediately ends it, leaving the "ready" prompt.
Some BASICs had a "REM" statement for remarks / commenting. Do you plan that token too? Was just thinking it might be useful if porting existing code so any comments can be left intact.
EDIT: ignore, looks like the examples in your zip file above do include REMs so seems you probably do already support it if these examples work. It just wasn't in the documented list of commands.
@Mickster said:
Yikes, all those cogs. Maybe I'm not going to be able to eliminate my Mites after all, unless I go with two P2s per system.
Supply chain is improving and now it's possible to use the Armmite H7 again which is quite a beast with MMBasic.
Craig
What do you need these cogs for?
I think about configurable and downloadable drivers (=you don't need hdmi/audio/usb, you unload it and load something else). The minimum needed to run is 3 - main, housekeeper, PSRAM
I have still 2 free cogs.
The housekeeper cog is intended to do a lot of background stuff in the future, that's why I added it now to only read the mouse and joystick position. As it is now it is the wasted cog, but better to have it now, than add it later.
For me (and my robot) the problem is not the available cogs, but these 18 pins, that PSRAM needs. The robot uses 16 pins for ultrasonic distance sensors... maybe I will add a P1 there - if there will be the next iteration of this robot.
Yes your housekeeper COG could be handy for IO, if you include useful bus interfaces such as SPI, I2C, ADC/DAC stuff somewhere in the future and have it managed independently by this COG, freeing your interpreter to run faster while IO transactions could happen in parallel or would need to be frequently polled but not bogging it down etc. Also still having those two free COGs can do quite a lot including more custom IO for other sensors, or additional sound/video perhaps.
This is a fairly decent default configuration for an interactive retromachine, perhaps less so for generalspecialized embedded control unless you free those extra COGs which as you say you can do. But I feel that type of application is not the main target for this type of system anyway. With useful pin control and the P2's inbuilt smartpin capabilities it obviously could still do some of them however.
High-end PLCs will work just like that. Where the I/O updating is synchronised with the ladder loop. Low-end is all single core hardware and therefore the I/O updating is just in sequence with the ladder loop, alternating.
I bought a Logitech Extreme 3Dpro joystick. While it was listed on the USBNew compatibility list, the new version of it that I bought was invisible to the driver.
A quick post in the topic marked as Logitech 3D Pro joystick and P2 Edge, ( that I discovered later is placed in the P1 forum - why?) and a quick Wuerfel21' s answer (comment out this, delete that) made the joystick to be visible again.
This is the analog joystick with a rotating handle, so it has 3 axes, and also 12 buttons and a hat. "Stick" and "strig" Basic's commands works with this, but they are intended to be a "digital" returning one of 9 available position codes.
Having the real hardware I was able to implement 'padx','pady','padz' and 'padh' functions that returns "analog" values from the joystick. I didn't want to confused with signed, unsigned, -32768 vs 32767 and shortint vs longint, so padx,pady and padz return the float in range -1.0 to +1.0.
Hat is a digital thing that returns 9 positions, so they are left intact
The version I pushed several minutes ago has also implemented read,data and restore, the last big language construction I planned before promoting the interpreter to the beta phase, however, there are still strange bugs in this that I have to find. While integers are read OK, strings and floats... not always.
@Wuerfel_21 said:
Glad that the joystick thing was sorted out, will have to change that upstream and in the emulators.
That update brought to life the Vakoss wireless gamepad too. It now works.
The 0079/181C one? Can you confirm that the button map matches the standard?
Edit: maybe try this 8bitdo SN30 Pro USB
No, that one is far more cursed. It connects but then NAKs all reads. Even Windows (7) often doesn't work with it. Though Linux gets it right every time. Maybe I can figure out what that's doing.
Also, it apparently has so much inrush current that hot-plugging it into one of @Rayman 's boards causes various fun hard crashes.
It reports 15 buttons, 4 axes, 1 hat
Right buttons: 1 (up) - bit 4 (16) ,
2 (right) - bit 1 (2) ,
3 (down) - bit 0 (1) ,
4 (left) - bit 3 (8)
There is no bit 2 (4)
There iis no bit 5 (42)
Back buttons: right up - bit 7(128) ,
right down bit 9 (512),
left up bit 6 (64)
left down bit 8 (256)
Select bit 10(1024),
Start bit 11(2048).
There is no bit 12 (4096)
Left joystick pressed bit 13 (8192),
Right joystick pressed bit 14 (16384)
Analog button, no reaction
Left buttons=hat. Nothing 15, up 0, right 2, down 4, ,left 6
Left joystick x,y
Right joystick z (left<->right), rz (up<->down)
I wanted the "load", "run" and "brun" to be simple in use so when the interpreter encounters
load program
it treats "program" as a literal string and tries to open it. If failed, it tries to add 'bas' at the end and
load program.bas
This has a side effect. that i encountered implementing "copy" (copy file1, file2)
I cannot do
10 a$="program.bas"
20 load a$
It tries to open a file named "a$", and then "a$.bas"
The workaround that I applied was : the copy, delete, etc, needs strings as arguments, so if you want to use a string variable, tell this using "$" suffix
Now,
delete filename
means: find the file called "filename" and delete it
but
delete filename$
means: the file name is in the string variable filename$, so read the variable, then delete the file.
The program from the upper part of the post now works
I used the audio editor to look at the audio file produced by csave. It didn't look right. There are bugs in csave somewhere. As this is only a toy and nothing important, I decided to disable it for now. Coginit and playsample left, and also forgotten setcolor.
The audio driver also doesn't behave as expected. Paula philosophy is good for Amiga modules. They are (normally) sampled at 32x base frequency and have a lot of harmonics. All these theories about harmonic aliases apply there.
However, for a sine or triangle wave, there are hearable and annoying high frequency aliases near the Paula's channel sample frequency. (eg 100 Hz, 12700 Hz, 12900 Hz - while using freq*128 as the sample rate). Going over 20 kHz to get rid of these hearable aliases makes the frequency granularity too coarse.
The audio driver for the "audio nonsense" simple wave synth has to be written (near) from scratch, immediately after the interpreter go beta, using a standard, interpolated, phase accumulator based sampling algorithm.
Comments
"Audio nonsense" in action. I will add all these examples ( I made several of them) to the example folder in the next version. Cleaning up in progress....
0.32
Cleaning is now complete, the code is much more readable now, the runtime procedures are alphabetically sorted.
I added dir, cd, mkdir and delete commands. Now you can browse the SD directory tree using these commands and delete the garbage if needed.
Having these commands I managed to cleanup the examples, so now I can put then there.
In the attached zip, there are:
I still have to add some commands to make this fully playable: it lacks a keyboard input, except inkey$, print to files (print #), on expr goto/gosub, read and data, but I think it is fun as it is even now.
To play, you need a EC32, HDMI at 0, audio at 14, 15, USB at 16
Of course the interpreter can be recompiled with other pins. They are defined near the start of each driver. Use newest flexprop and enable -DFF_USE_LFN
@pik33 👍😎👍
Amazed at the rapid progress...much respect.
So there is already a precompiler? I thought that was going to be a future development but I imagine it being easier to implement as you go.
Craig
That, what is executed, is already translated to function numbers and a reverse Polish notation, so the runtime only calls the functions one by one, as they are saved in the precompiled line. And these function don't get parameters, they are pushed onto the stack before.
There may be an optimizer added, that can detect operations that can be done at the interpreting phase, for example sin(2+2) : it can be converted to sin(4) at the interpreting time (now it is not, it is compiled to 2,2,add,sin)
This kind of intermediate code can be also translated to pure asm. Maybe, in the far future. There is a lot to implement, and the interpreter is now fast enough to be fully usable (try to run graphtest.bas or breakout.bas)
I don't have the prerequisites....only have bare-bones Edge modules and KISS modules.
🤔😐
Craig
Do you have anything that have an external RAM connected to it, that can be accessed by Rogloh's driver? I don't remember now what the KISS module have on board and if there is a possibility to attach a PSRAM chip to it
I will try to restore Eval (or anything) +4bit PSRAM support (that only needs to change several lines in the video driver)
framebuf and blit commands added.
framebuf returns the pointer to the frame buffer, that may be needed to do blit
Blit copies the rectangle from one place in the memory to another. May be used in the full form:
blit source_fb_ptr, x1,x2,y1,y2,pitch1, dest_buf_ptr,x3,y3,pitch2or shortened
blit x1,y1,x2,y2,x3,y3to blit inside the main framebuffer only
With blit, 50 fps rainbow is possible on EC-32. Timings are tight, the blit itself needs 18.5 ms. No way to do this with 4-bit PSRAM.
The camera struggled with the focus
Can this interpreter be run using just a serial connection to the P2 or do I have to have the monitor and keyboard attached?
The interpreter in this version is intended to run with a HDMI monitor/screen and an USB keyboard. The goal was to convert the EC32 to an independent computer that can be programmed without any external PC.
I think about using this for a (robot, etc) control purposes so there will be (1) autorun feature (2) a possibility to free cogs and pins from unneeded drivers. Autorun I will add maybe today, drivers handling is planned after the 1.0 (or when I will do the next version of our robot, that already has a HDMI screen - and USBnew driver allows to use its touch interface too)
Hey @pik33, so how many COGs are you using right now?
6 cogs used now.
The last one is not heavily used now, it only does a 200 Hz clock and services mouse and joystick input, but I plan to add a GUI like PicoMite that works in the background
2 cogs still free.
I think about something that can allow dynamic loading/unloading the drivers. For example the keyboard and HDMI, while needed for programming, may not be needed by the program itself, so it can stop these cogs and load what it needs.
Starting a new cog is intended to add before 1.0. Unloading cogs... in the future. There are still 2 of them free.
Also, adding new things is/may be a result of playing and testing.
I have this UVC robot. It now uses standard, non-PSRAM Edge and it needs pins. While it already uses HDMI, audio and USB, the PSRAM needs 18 pins. The robot uses P40-P55 for its 8 ultrasonic distance sensors. However this Basic gives the possibility to control the robot via its touch screen (after adapting usbnew - to do) and program/control it without anything except a keyboard.
Maybe add a P1 to control the ultrasonic (and maybe something else, it has 32 pins) and connect it to a P2 via a serial connection?
The project is now stuck, we did several prototypes that are used in a hospital, and I don't know if the project will continue
Autorun feature added.
If there is a /sd/bas/autorun.bas file, it will be executed automatically at the start of the interpreter.
The program can have brun in it, so it may be something like that:
The program will start with the interpreter and wait 0.5 seconds to give the time for USB to init. Then it will loop another second waiting for a key
If any key pressed in this time, the program will end. If not, it will run the binary /sd/bin/player33.bin.
So reset-wait-got a player or reset-keypress-got a Basic.
Edit: I updated the "new" command so it can be called from inside the program. It cleans the program and immediately ends it, leaving the "ready" prompt.
On..goto and on..gosub added.
Also, for Atari Basic compatibility with on..goxxx, comparisons now return +1 (and not -1) if true . This is used there in constructions like
10 on input>threshold gosub 1000so the comparison has to return +1 for that to work.
Tokens left to implement before beta:
Some BASICs had a "REM" statement for remarks / commenting. Do you plan that token too? Was just thinking it might be useful if porting existing code so any comments can be left intact.
EDIT: ignore, looks like the examples in your zip file above do include REMs so seems you probably do already support it if these examples work. It just wasn't in the documented list of commands.
Yes, REM , or ' , already works
The documentation needs to be upgraded.
Yikes, all those cogs. Maybe I'm not going to be able to eliminate my Mites after all, unless I go with two P2s per system.
Supply chain is improving and now it's possible to use the Armmite H7 again which is quite a beast with MMBasic.
Craig
What do you need these cogs for?
I think about configurable and downloadable drivers (=you don't need hdmi/audio/usb, you unload it and load something else). The minimum needed to run is 3 - main, housekeeper, PSRAM
I have still 2 free cogs.
The housekeeper cog is intended to do a lot of background stuff in the future, that's why I added it now to only read the mouse and joystick position. As it is now it is the wasted cog, but better to have it now, than add it later.
For me (and my robot) the problem is not the available cogs, but these 18 pins, that PSRAM needs. The robot uses 16 pins for ultrasonic distance sensors... maybe I will add a P1 there - if there will be the next iteration of this robot.
Input implemented. I don't like what I wrote, but it seems to work
Yes your housekeeper COG could be handy for IO, if you include useful bus interfaces such as SPI, I2C, ADC/DAC stuff somewhere in the future and have it managed independently by this COG, freeing your interpreter to run faster while IO transactions could happen in parallel or would need to be frequently polled but not bogging it down etc. Also still having those two free COGs can do quite a lot including more custom IO for other sensors, or additional sound/video perhaps.
This is a fairly decent default configuration for an interactive retromachine, perhaps less so for generalspecialized embedded control unless you free those extra COGs which as you say you can do. But I feel that type of application is not the main target for this type of system anyway. With useful pin control and the P2's inbuilt smartpin capabilities it obviously could still do some of them however.
High-end PLCs will work just like that. Where the I/O updating is synchronised with the ladder loop. Low-end is all single core hardware and therefore the I/O updating is just in sequence with the ladder loop, alternating.
I bought a Logitech Extreme 3Dpro joystick. While it was listed on the USBNew compatibility list, the new version of it that I bought was invisible to the driver.
A quick post in the topic marked as Logitech 3D Pro joystick and P2 Edge, ( that I discovered later is placed in the P1 forum - why?) and a quick Wuerfel21' s answer (comment out this, delete that) made the joystick to be visible again.
This is the analog joystick with a rotating handle, so it has 3 axes, and also 12 buttons and a hat. "Stick" and "strig" Basic's commands works with this, but they are intended to be a "digital" returning one of 9 available position codes.
Having the real hardware I was able to implement 'padx','pady','padz' and 'padh' functions that returns "analog" values from the joystick. I didn't want to confused with signed, unsigned, -32768 vs 32767 and shortint vs longint, so padx,pady and padz return the float in range -1.0 to +1.0.
Hat is a digital thing that returns 9 positions, so they are left intact
The version I pushed several minutes ago has also implemented read,data and restore, the last big language construction I planned before promoting the interpreter to the beta phase, however, there are still strange bugs in this that I have to find. While integers are read OK, strings and floats... not always.
Glad that the joystick thing was sorted out, will have to change that upstream and in the emulators.
That update brought to life the Vakoss wireless gamepad too. It now works.
Edit: maybe try this 8bitdo SN30 Pro USB
The 0079/181C one? Can you confirm that the button map matches the standard?
No, that one is far more cursed. It connects but then NAKs all reads. Even Windows (7) often doesn't work with it. Though Linux gets it right every time. Maybe I can figure out what that's doing.
Also, it apparently has so much inrush current that hot-plugging it into one of @Rayman 's boards causes various fun hard crashes.
It reports 15 buttons, 4 axes, 1 hat
Right buttons: 1 (up) - bit 4 (16) ,
2 (right) - bit 1 (2) ,
3 (down) - bit 0 (1) ,
4 (left) - bit 3 (8)
There is no bit 2 (4)
There iis no bit 5 (42)
Back buttons: right up - bit 7(128) ,
right down bit 9 (512),
left up bit 6 (64)
left down bit 8 (256)
Select bit 10(1024),
Start bit 11(2048).
There is no bit 12 (4096)
Left joystick pressed bit 13 (8192),
Right joystick pressed bit 14 (16384)
Analog button, no reaction
Left buttons=hat. Nothing 15, up 0, right 2, down 4, ,left 6
Left joystick x,y
Right joystick z (left<->right), rz (up<->down)
Well that seems mildly strange.
So if you put
into the bottom DAT section of the emupad test, does it match the controller on screen?
Yes, it's OK
So put that line in your PADMAP.TXT to make it work with the emulators etc.
And the device can be moved in Wiki to the working section along with its map.
I wanted the "load", "run" and "brun" to be simple in use so when the interpreter encounters
load programit treats "program" as a literal string and tries to open it. If failed, it tries to add 'bas' at the end and
load program.basThis has a side effect. that i encountered implementing "copy" (copy file1, file2)
I cannot do
It tries to open a file named "a$", and then "a$.bas"
The workaround that I applied was : the copy, delete, etc, needs strings as arguments, so if you want to use a string variable, tell this using "$" suffix
Now,
delete filenamemeans: find the file called "filename" and delete it
but
delete filename$means: the file name is in the string variable filename$, so read the variable, then delete the file.
The program from the upper part of the post now works
I used the audio editor to look at the audio file produced by csave. It didn't look right. There are bugs in csave somewhere. As this is only a toy and nothing important, I decided to disable it for now. Coginit and playsample left, and also forgotten setcolor.
The audio driver also doesn't behave as expected. Paula philosophy is good for Amiga modules. They are (normally) sampled at 32x base frequency and have a lot of harmonics. All these theories about harmonic aliases apply there.
However, for a sine or triangle wave, there are hearable and annoying high frequency aliases near the Paula's channel sample frequency. (eg 100 Hz, 12700 Hz, 12900 Hz - while using freq*128 as the sample rate). Going over 20 kHz to get rid of these hearable aliases makes the frequency granularity too coarse.
The audio driver for the "audio nonsense" simple wave synth has to be written (near) from scratch, immediately after the interpreter go beta, using a standard, interpolated, phase accumulator based sampling algorithm.