You really need to make a single program (or even dll) combining the debug screens with PST.
Then Pnut, PropTool and others could use all of it. And the serial port sharing could work like it does with PST now.
Maybe support two serial ports, one for Terminal and one for Debug, but basically if combined the PST is just another screen?
Another thought I have is that the SEND thing needs a corresponding RECEIVE.
Enjoy!
Mike
I've thought about a RECV counterpart to SEND, but I've had a hard time figuring it, because you cannot control WHEN anything comes, so it seems like it would be hard to make it not block execution.
After I get this voice chorus thing done, I will improve the DEBUG syntax for the graphical displays, so that the backtick (`) character keys a string that doesn't need quotes and subsequently keys number printing and expressions, so that this:
debug("`myplot fillcolor $007F7F ovalfill 100 ", sdec_(i*16-j), " 50 50 text '", i | "0", "'")
Evanh, do you know if I have the cogs ordered properly in that animation?
Huh, what? Scurries through the webpage source for a URL ... downloads vid ... views with VLC ...
Oh, I've generally assumed that incremental cog numbers see incremental slot numbers - with rollover. So, yeah, I would've drawn the cog order opposite to that.
Evanh, do you know if I have the cogs ordered properly in that animation?
Huh, what? Scurries through the webpage source for a URL ... downloads vid ... views with VLC ...
Oh, I've generally assumed that incremental cog numbers see incremental slot numbers - with rollover. So, yeah, I would've drawn the cog order opposite to that.
Only one way is correct. I will look through the Verilog to figure it out. I need to get my head around it again.
@cgracey, I'm not sure what I'm doing wrong, but I tried running your Eggbeater code and this is what I get (see screen print attachment) and P62 is blinking.
I think what you've drawn is technically correct, because cog 0 can indeed access momory 0, then 1, etc. However, I would have drawn the rotating memory to go clockwise, because theres something mentally jarring about counterclockwise movement (is this thing going to unscrew and fall off?)
If you're going clockwise with the rotor, I think it makes sense to go clockwise with the cogs too, maybe cog 1 should be near '1 o'clock' and go clockwise from there. This isn't as big a deal though
If you make the above two changes I think the LSB memory numbers end up going counterclockwise
@cgracey, I'm not sure what I'm doing wrong, but I tried running your Eggbeater code and this is what I get (see screen print attachment) and P62 is blinking.
Sorry. I need to get you the latest PNut.exe. I'll have it here soon...
I think what you've drawn is technically correct, because cog 0 can indeed access momory 0, then 1, etc. However, I would have drawn the rotating memory to go clockwise, because theres something mentally jarring about counterclockwise movement (is this thing going to unscrew and fall off?)
If you're going clockwise with the rotor, I think it makes sense to go clockwise with the cogs too, maybe cog 1 should be near '1 o'clock' and go clockwise from there. This isn't as big a deal though
If you make the above two changes I think the LSB memory numbers end up going counterclockwise
Ha, good point. I'll change it. I still need to find out if I've got it right, otherwise. Getting into that Verilog code is like committing to do something physically difficult.
I'm not sure if you need to get into the verilog. You know from experience you can read address xx0 then address xx1, from a single cog perspective (eg cog 1), so the diagram just has to match that
Duh! My bad! Maybe you should post a disclaimer "Don't try this at home!" laughing on the inside. Your examples were so cool, I wanted to play with them. In the words of Marvin, "Now, I'm so depressed."
@"Peter Jakacki" are you saying that WINE works for PNut P2 downloads with USB serial and everything nicely under Linux? Are you using Loadp2 or the loader in PNut itself?
Perhaps we might have hope for the official PropTool to work with this method as well?
I also wonder if the Mac can have similar luck... has anyone got that going yet? I might have to try it out too. This could avoid a lot of the VM overheads and a real Windows install which can be handy if anything to just avoid all the MS auto-update nonsense.
I also wonder if the Mac can have similar luck... has anyone got that going yet? I might have to try it out too. This could avoid a lot of the VM overheads and a real Windows install which can be handy if anything to just avoid all the MS auto-update nonsense.
WINE is 100% borked on MacOS because the idiots at Apple removed 32bit compatibility in 10.15. You can obviously install Linux in a VM or with bootcamp and run WINE on that, which is still probably preferable to doing the same with Windows.
@"Peter Jakacki" OT, that wallpaper in the background - is it a picture from your window of your home town view ?
Close, it reminds me a bit of some of the view around here except for one salient feature....
@rogloh - yep, WIne is much improved these days, I can run just about anything. I have USBx mapped as COMx using "ln -s /dev/ttyUSBx COMx" etc. I'm just using PNut as is, no external loaders.
Comments
Yes, and I am going to simplify the syntax used by these displays.
I will post an animation soon that I made.
Then Pnut, PropTool and others could use all of it. And the serial port sharing could work like it does with PST now.
Maybe support two serial ports, one for Terminal and one for Debug, but basically if combined the PST is just another screen?
Another thought I have is that the SEND thing needs a corresponding RECEIVE.
Enjoy!
Mike
I've thought about a RECV counterpart to SEND, but I've had a hard time figuring it, because you cannot control WHEN anything comes, so it seems like it would be hard to make it not block execution.
Here is a video of it running. This demonstrates what is hard to explain, even with a picture:
Here is the program:
_clkfreq = 10_000_000 PUB go() | i, j, k debug("`plot myplot size 600 650 update", dly(300)) debug("`myplot offset 300 300 polar -128 -32 linecolor $FFFFFF textsize 16 textstyle 1") k~ repeat debug("`myplot clear") debug("`myplot text 300 0 30 3 $FFFF7F 'The Eggbeater Interface'") if k & 16 j++ repeat i from 0 to 7 'draw spokes if RAMs are still debug(ifnot(k & 16), "`myplot linesize 12 100 ", sdec_(i*16), " to 200 ", sdec_(i*16), " linesize 3") debug("`myplot fillcolor $003F7F ovalfill 0 0 200 200") debug("`myplot text 24 0 11 '16K x 32' text 0 0 'Hub RAMs' text 24 64 11 '(address LSBs)'") repeat i from 0 to 7 'draw RAMs and cogs debug("`myplot fillcolor $007F7F ovalfill 100 ", sdec_(i*16-j), " 50 50 text '", i | "0", "'") debug("`myplot fillcolor $7F0000 ovalfill 200 ", sdec_(-i*16), " 80 80 text 'Cog", sdec_(i), "'") k++ debug("`myplot update") waitms(20)Polar coordinates made this really easy.
debug("`myplot fillcolor $007F7F ovalfill 100 ", sdec_(i*16-j), " 50 50 text '", i | "0", "'")...will be able to be typed like this...
It's a little too complex the way it currently is.
Oh, I've generally assumed that incremental cog numbers see incremental slot numbers - with rollover. So, yeah, I would've drawn the cog order opposite to that.
Only one way is correct. I will look through the Verilog to figure it out. I need to get my head around it again.
If you're going clockwise with the rotor, I think it makes sense to go clockwise with the cogs too, maybe cog 1 should be near '1 o'clock' and go clockwise from there. This isn't as big a deal though
If you make the above two changes I think the LSB memory numbers end up going counterclockwise
Sorry. I need to get you the latest PNut.exe. I'll have it here soon...
Ha, good point. I'll change it. I still need to find out if I've got it right, otherwise. Getting into that Verilog code is like committing to do something physically difficult.
I know, but you are using an old version of PNut.exe that doesn't run these latest examples. I will post it here shortly.
https://drive.google.com/file/d/1eZibHAHx_S67KOr4UFtRSD2wFH_c_2TI/view?usp=sharing
JonnyMac is right on
This .zip includes the pitchbending chorus demonstrated today on the early-adopter meeting.
Great stuff!
It was great seeing the pitch blending stuff.
Perhaps we might have hope for the official PropTool to work with this method as well?
I also wonder if the Mac can have similar luck... has anyone got that going yet? I might have to try it out too. This could avoid a lot of the VM overheads and a real Windows install which can be handy if anything to just avoid all the MS auto-update nonsense.
WINE is 100% borked on MacOS because the idiots at Apple removed 32bit compatibility in 10.15. You can obviously install Linux in a VM or with bootcamp and run WINE on that, which is still probably preferable to doing the same with Windows.
Close, it reminds me a bit of some of the view around here except for one salient feature....
@rogloh - yep, WIne is much improved these days, I can run just about anything. I have USBx mapped as COMx using "ln -s /dev/ttyUSBx COMx" etc. I'm just using PNut as is, no external loaders.