Hi Chip, I believe, that is what you and many in the forum are working for. It will happen. LEGO once were simple blocks. Then special functions appeared, like roof stones. Then complete stories existed, like pirates or star wars. But in the end the children will create their own stuff from bricks.
If HP had offered the scientific calculators in a low price version, UPN would be common. If you take a look at Peters progress in Tachyon, I imagine the moment, PII is available, a self contained IDE is in existence!
Some buttons would be nice. Up, down, while clicked. One day that will be fun to create. I like the free app Pixleformer, works great to export to bmp, import in your 1bit app, export as .dat
So USB mouse will be easy on the real chip with no usb interface?
The real chip has USB pin sets on every odd-even pair of pins.
I wonder how many of those pairs, a P2 could realistically drive ?
As a Host talking to Keyboard or Mouse type peripherals, the P2 can choose the payload and phase, so it comes down to just how many bytes are needed per 1ms frame (or even groups of frames).
eg a single COG could sequentially phase multiple USB pairs, up to what ? 3?,4?,?
Just got to testing out something...
Made last entry in button object (located in hub) the address of a hubexec routine.
When button clicked main cog just jumps to that address.
Seems weird, but appears to work:
Form1Button1
long 1 '0 type=button
long 80 '1 left
long 200 '2 top
long 80 '3 width
long 50 '4 height
long black '5 border color
long sForm1Text4 '6 string
long black '7 text fore color
long gray '8 text back color
long VarFont'FontData '9 font pointer
long red '10 mouse over border color
long yellow '11 mouse down border color
long mOnForm1Button1 '12 on-click code
DAT 'Form exec1
mOnForm1Button1
wrlong #20,ptra[2] 'x1
wrlong #50,ptra[6] 'x2
wrlong #10,ptra[3] 'y1
wrlong #30,ptra[7] 'y2
wrlong #red,ptra[4] 'color
mov PA,#DrawFilledRectangle_
call #MainGraphicsCmd
RET
also just thinking about setq and communications between cogs through the hub...
I'm thinking that if, for example, the usb code is repeatedly using setq to write 3 longs of status and another cog is using setq to read 3 longs then you don't have to worry about reading in an incomplete update.
What I mean is that you won't get a new x value with an old y value.
At least, I'm thinking this is true...
I've been advocating for builtin CRC instructions for a good long while now. It's dumb to waste memory and/or cycles on CRC when it can be done so easily in Verilog.
I've been advocating for builtin CRC instructions for a good long while now. It's dumb to waste memory and/or cycles on CRC when it can be done so easily in Verilog.
I think one of the issues here, was that there is not one single, universal CRC, but instead there are many....
IIRC, USB and Ethernet use the same algorithm, with simply a different modulus value. My original thought was to simply allow the program to specify the starting modulus, then it would be applicable to many uses.
IIRC, USB and Ethernet use the same algorithm, with simply a different modulus value. My original thought was to simply allow the program to specify the starting modulus, then it would be applicable to many uses.
I've started copying what I've seen others do and do a JMP instead of a CALL to a subroutine that ends in RET. Seems like it saves an instruction (RET) in a lot of cases...
I don't think we could do this with P1, right?
Also...
When things go wrong I wonder if I've hit the 5-deep (right?) CALL stack limit. Hasn't been the actual problem so far though...
Think of it as a head/tail thing. If you are using a series of subroutines to complete a task, and you're at the end of a routine where you know you want to eventually return to the "head" routine, that would be the "tail" routine that uses the jmp. The jmp target could be a subroutine that does some cleanup task, which could include calling other subroutines. When the cleanup routine encounters its exit ret, the stack address will be that of the "head" routine.
Just got option buttons working.
Ran out of room in main cog and had to push some mouse up event handling out to the hub.
It's really remarkable how you can just cut and paste code between cog and hub and it works.
I know there are some things that don't work in hub.
I forgot what they are, but I must not be using them cause it seems to work...
This might lead to less optimized code though...
I was in the process of reducing code size when I just decided to move it to hub.
Don't feel the need to optimize hub code as much...
Seems like you couldn't reuse FunctionName in other parts of code if you JMP to it. How would it know where to return to? Am I missing something?
There are strict caveats in the use. (which is why I keep a commented RET in code where this is done)
In the example above, ThisFunction is called from somewhere, and then only where you have a CALL immediately followed by a RET, you have a choice to JMP and use the RET in FunctionName, to return to the caller of ThisFunction. You do have CALL-RET balance.
Both ThisFunction & FunctionName can be called from anywhere in main code, like normal.
There are enough caveats to bite novices here, & this trick is not edit / cut-paste friendly, so I tend to favour an assembler/compiler that do this an option optimize.
( even that has issues, as someone right on the stack limit, with opt-on, would have stack issues with opt-off, yet most expect opt-off to be safer and less bug exposed... )
Comments
It would be neat if the world could rediscover the fun of programming on and for a system which is both fully understandable and totally controllable.
If HP had offered the scientific calculators in a low price version, UPN would be common. If you take a look at Peters progress in Tachyon, I imagine the moment, PII is available, a self contained IDE is in existence!
The draw object loop was incrementing by bytes instead of longs:
'Draw Form objects mov mo,ptrb add mo,#9'8 +1 for font mFormObjectLoop rdlong ptrb,mo cmp ptrb,#0 wz,wc if_z RET call #mDrawFormObject add mo,#1 jmp #mFormObjectLoopThe #9 should be #9*4 and the #1 should be #4.
It highlights red on mouse over and yellow on mouse down...
For certain values of 'USB mouse' and 'easy', yup, a SW +Smart Pin solution looks do-able.
The real chip has USB pin sets on every odd-even pair of pins.
I wonder how many of those pairs, a P2 could realistically drive ?
As a Host talking to Keyboard or Mouse type peripherals, the P2 can choose the payload and phase, so it comes down to just how many bytes are needed per 1ms frame (or even groups of frames).
eg a single COG could sequentially phase multiple USB pairs, up to what ? 3?,4?,?
Made last entry in button object (located in hub) the address of a hubexec routine.
When button clicked main cog just jumps to that address.
Seems weird, but appears to work:
Form1Button1 long 1 '0 type=button long 80 '1 left long 200 '2 top long 80 '3 width long 50 '4 height long black '5 border color long sForm1Text4 '6 string long black '7 text fore color long gray '8 text back color long VarFont'FontData '9 font pointer long red '10 mouse over border color long yellow '11 mouse down border color long mOnForm1Button1 '12 on-click code DAT 'Form exec1 mOnForm1Button1 wrlong #20,ptra[2] 'x1 wrlong #50,ptra[6] 'x2 wrlong #10,ptra[3] 'y1 wrlong #30,ptra[7] 'y2 wrlong #red,ptra[4] 'color mov PA,#DrawFilledRectangle_ call #MainGraphicsCmd RETI'm thinking that if, for example, the usb code is repeatedly using setq to write 3 longs of status and another cog is using setq to read 3 longs then you don't have to worry about reading in an incomplete update.
What I mean is that you won't get a new x value with an old y value.
At least, I'm thinking this is true...
Shows both 5b and 16b needed for USB and 32b for Ethernet ....
I've started copying what I've seen others do and do a JMP instead of a CALL to a subroutine that ends in RET. Seems like it saves an instruction (RET) in a lot of cases...
I don't think we could do this with P1, right?
Also...
When things go wrong I wonder if I've hit the 5-deep (right?) CALL stack limit. Hasn't been the actual problem so far though...
You mean where you have a final call, immediately before a return ? instead it becomes
Seems like you couldn't reuse FunctionName in other parts of code if you JMP to it. How would it know where to return to? Am I missing something?
Ran out of room in main cog and had to push some mouse up event handling out to the hub.
It's really remarkable how you can just cut and paste code between cog and hub and it works.
I know there are some things that don't work in hub.
I forgot what they are, but I must not be using them cause it seems to work...
This might lead to less optimized code though...
I was in the process of reducing code size when I just decided to move it to hub.
Don't feel the need to optimize hub code as much...
Can the return value of a subroutine be in the carry flag?
I was going to try that but then think remembered that flags also get pushed and popped from stack..
It would be unusual to save flags on the stack, as it is common to return with values in the flags.
In the example above, ThisFunction is called from somewhere, and then only where you have a CALL immediately followed by a RET, you have a choice to JMP and use the RET in FunctionName, to return to the caller of ThisFunction. You do have CALL-RET balance.
Both ThisFunction & FunctionName can be called from anywhere in main code, like normal.
There are enough caveats to bite novices here, & this trick is not edit / cut-paste friendly, so I tend to favour an assembler/compiler that do this an option optimize.
( even that has issues, as someone right on the stack limit, with opt-on, would have stack issues with opt-off, yet most expect opt-off to be safer and less bug exposed... )
If you want to restore the flags on return simply add WC and/or WZ effects to the RET instruction