JMG,
It'll be a dice roll on the HubRAM rotation latencies. EDIT: Although, I do note the RDLONG 0,ptrb there at line 38, it should make things consistent ...
... The reason there is any uncertainty, at all, is probably due to serial receiving in relation to the egg beater...
I wonder how that " it failed 5 times in 20 downloads" varies over many resets, of the same download ?
Ideally, you want every reset exit to be the same, and to have no dice effects, as bugs that (eg) vary with download, but not reset, are much harder to find.
There is a PC involved here which is sending serial to the Prop2. That is where the timing uncertainty is coming from. If we were booting from a Flash, there would be no source of uncertainty.
In looking at the code and trying it out, I found the problem:
xcont #10,#0 'do streamer instruction to start interrupt sequence
...needs to become something like...
xcont #100,#0 'do streamer instruction to start interrupt sequence
You were just running out of time to do the first XCONT before the streamer buffer fully emptied, then requiring TWO, not just one, XCONT to carry on the show.
Thanks Chip!
That did the trick.
This highlights that for OBEX2 we might have to split of code for all the different variants.
As demonstrated here, code that runs on one P2 variant may not work properly on another.
Change the line to COGATN #%10 instead and see if that works. As you have it now, the cog is setting its own ATN flag.
The COGATN value doesn't change the symptom at all.
It doesn't seem to matter if the cog tries to ATN itself.
You could use a NOP instead of COGATN and the results are the same. It's a case of timing being cut too close. Just increase the XINIT #10 to #100 and you'll have a lot more head room.
You could use a NOP instead of COGATN and the results are the same. It's a case of timing being cut too close. Just increase the XINIT #10 to #100 and you'll have a lot more head room.
By increasing the value from #10 to #11 is enough to solve the timing issue.
I like to live on the edge but that was a bit too close
P.S. Apologies to the COGATN instruction for my finger pointing.
You could use a NOP instead of COGATN and the results are the same. It's a case of timing being cut too close. Just increase the XINIT #10 to #100 and you'll have a lot more head room.
By increasing the value from #10 to #11 is enough to solve the timing issue.
I like to live on the edge but that was a bit too close
P.S. Apologies to the COGATN instruction for my finger pointing.
I would make it large, just to be safe, and to allow you more time, in case you added some more instructions.
This highlights that for OBEX2 we might have to split of code for all the different variants.
As demonstrated here, code that runs on one P2 variant may not work properly on another.
That's not necessary, at all. Just don't cut your timing so close, then one size fits all. Maybe it would be good policy to design software on the 16-cog version, just to avoid these possibilities. Better yet, just be aware of what is happening, time wise, and avoid the whole potentiality.
This highlights that for OBEX2 we might have to split of code for all the different variants.
As demonstrated here, code that runs on one P2 variant may not work properly on another.
There may be some HUB-sync cases where that can happen, but they should be rare.
I'm more curious about why this did not always work ?
jmg,
You can't reset and have your P2 PASM code loaded without downloading it again. There's no flash/eeprom on the P2 FPGA emulation setup (at least that I am aware of), even if there is something on the board for it, the P2 ROM doesn't have anything setup to save it off to flash/eeprom and then boot from their on reset yet.
jmg,
You can't reset and have your P2 PASM code loaded without downloading it again. There's no flash/eeprom on the P2 FPGA emulation setup (at least that I am aware of), even if there is something on the board for it, the P2 ROM doesn't have anything setup to save it off to flash/eeprom and then boot from their on reset yet.
OK, I'll rephrase the question.
After the hard-reset which launches the boot loader, each COG has an effective soft-reset that executes the first opcode of code inside that COG.
If that soft-reset step is repeated, is the problem stable from there, or not ?
I wasn't getting the fact that when the cog loads itself, its hub relationship is deterministic at the start of the program.
I realize what the problem is now. When an XCONT is used to start the streamer, as opposed to an XINIT, there is some variability, based on what the streamer was doing before. The streamer should be cold started by giving a command via XINIT, then XCONT can be used set up the next command for when the command given by the XINIT runs out. So, to make this interrupt work, you must do an XINIT to get the streamer started, then do an XCONT to buffer the next command for when the command begun by XINIT finishes. When the command given by the XCONT begins to execute, the 'transfer buffer empty' event will occur.
I changed the code, between the first and last instruction listed here:
loc adrb,#@current_video_line
xinit #11,#0 'do streamer instruction to start interrupt sequence
xcont #10,#0 'if the #11 and #10 sum to less than 21, it fails!!!
mov ijmp1,#field 'set up streamer-empty interrupt
setint1 #8 'after both XINIT and XCONT, enable the interrupt
jmp #game_engine
Now, if D's in the XINIT and XCONT instructions sum to less than 21 this will fail every time. If they sum to 21, or more, it always works.
Comments
It'll be a dice roll on the HubRAM rotation latencies. EDIT: Although, I do note the RDLONG 0,ptrb there at line 38, it should make things consistent ...
There is a PC involved here which is sending serial to the Prop2. That is where the timing uncertainty is coming from. If we were booting from a Flash, there would be no source of uncertainty.
It doesn't seem to matter if the cog tries to ATN itself.
Thanks Chip!
That did the trick.
This highlights that for OBEX2 we might have to split of code for all the different variants.
As demonstrated here, code that runs on one P2 variant may not work properly on another.
You could use a NOP instead of COGATN and the results are the same. It's a case of timing being cut too close. Just increase the XINIT #10 to #100 and you'll have a lot more head room.
I like to live on the edge but that was a bit too close
P.S. Apologies to the COGATN instruction for my finger pointing.
I would make it large, just to be safe, and to allow you more time, in case you added some more instructions.
That's not necessary, at all. Just don't cut your timing so close, then one size fits all. Maybe it would be good policy to design software on the 16-cog version, just to avoid these possibilities. Better yet, just be aware of what is happening, time wise, and avoid the whole potentiality.
I'm more curious about why this did not always work ?
When this is in Download -> fail-mode, is it always failing, on every reset, until a fresh Download rolls the dice again ?
You can't reset and have your P2 PASM code loaded without downloading it again. There's no flash/eeprom on the P2 FPGA emulation setup (at least that I am aware of), even if there is something on the board for it, the P2 ROM doesn't have anything setup to save it off to flash/eeprom and then boot from their on reset yet.
After the hard-reset which launches the boot loader, each COG has an effective soft-reset that executes the first opcode of code inside that COG.
If that soft-reset step is repeated, is the problem stable from there, or not ?
Maybe that needs to be proven too. Will that Flash-boot
a) Always work
or
b) Always fail ?
A system that gives differing debug outcomes, based on download-run debug, vs Flash-start debug, seems less than ideal to me ?
When a download was successful the code worked as expected with no issues.
I wasn't getting the fact that when the cog loads itself, its hub relationship is deterministic at the start of the program.
I realize what the problem is now. When an XCONT is used to start the streamer, as opposed to an XINIT, there is some variability, based on what the streamer was doing before. The streamer should be cold started by giving a command via XINIT, then XCONT can be used set up the next command for when the command given by the XINIT runs out. So, to make this interrupt work, you must do an XINIT to get the streamer started, then do an XCONT to buffer the next command for when the command begun by XINIT finishes. When the command given by the XCONT begins to execute, the 'transfer buffer empty' event will occur.
I changed the code, between the first and last instruction listed here:
loc adrb,#@current_video_line xinit #11,#0 'do streamer instruction to start interrupt sequence xcont #10,#0 'if the #11 and #10 sum to less than 21, it fails!!! mov ijmp1,#field 'set up streamer-empty interrupt setint1 #8 'after both XINIT and XCONT, enable the interrupt jmp #game_engineNow, if D's in the XINIT and XCONT instructions sum to less than 21 this will fail every time. If they sum to 21, or more, it always works.