And I have been biting my lip, trying to stay our of languages wars on the net for many months now. Especially Forth wars here. Not only that but editor wars, operating system wars, tab vs space wars, goto wars, semi-colon wars, etc.
Problem is after many years of programming in many different languages I have pretty much come to hate them all!
Obvious answer is to create my own language. I was thinking of basing it on "goto" and calling it GOTO. Just to annoy people. I mean, what other construct to you need in a HLL? Sadly I find somebody beat me to it: https://esolangs.org/wiki/GOTO++
I think you're onto something there, it could become the next GOTO language from which there is no RETURN
It seems to have something to do with downloading!
Adding 'long 0' seems to make everything work. It's like some data wasn't getting downloaded at the end of the program. Adding more data gets over the problem.
I see what it is... We are sending data in base64 and sometimes there is less than 6 bits remaining to send, not making a new Base64 character. This just needs a new PNut.exe to remedy the problem.
I wonder if this will have any effect on Peter's CV-A9 problem.
Peter, add 'byte 0' at the end of your program and see if things don't improve.
The solution to this problem involves not just the PNut.exe downloader code, but its assembler/compiler, also. I'll work on this properly on Monday. For now, can you guys please try adding 'byte 0' at the end of your code/data and see if this remedies the problem, in all cases?
The solution to this problem involves not just the PNut.exe downloader code, but its assembler/compiler, also. I'll work on this properly on Monday. For now, can you guys please try adding 'byte 0' at the end of your code/data and see if this remedies the problem, in all cases?
Turns out all my code already has video/data buffers at the end of the code which would explain why they all work Ok on V27 (all boards).
This bug was tricky and only showed up on downloads that were exact multiples of 32 bytes, in length. In every other case, the assembler/compiler was padding data out to the next 32-byte boundary, creating needed overlap on the last important Base64 character. This padding was a carry-over from Prop2-Hot. When I get back to Spin2, I will take the padding out of the assembler/compiler. Had the padding not been there, all along, this bug would have showed up much earlier.
I'm really glad Ozpropdev analyzed the cause so well. This bug was just too weird to have suddenly creeped up into the cog logic.
Now, it certainly sends the whole last byte of download data.
The posted .zip file has a "PNut_v27.exe" and no "PNut_v27a.exe". I did a binary compare with the PNut_v17.exe in the .zip and it's the same as my existing PNut_v27.exe.
I'll give it a try but that doesn't explain why the same code runs on V26 though.
Good point, download trim errors should really fail the same way, unless somehow V26 has different default values in the memory ?
Maybe there are 2 issues here .....
I'll give it a try but that doesn't explain why the same code runs on V26 though.
Good point, download trim errors should really fail the same way, unless somehow V26 has different default values in the memory ?
Maybe there are 2 issues here .....
I loaded V27zz and TAQOZ with the PNut_V27a and have it it running doing all kinds of things for the past hour or more. So far no glitches that I can see.....
btw, are the CLKSET modes documented anywhere? These are the ones I know of:
I loaded V27zz and TAQOZ with the PNut_V27a and have it it running doing all kinds of things for the past hour or more. So far no glitches that I can see.....
EDIT: It's been running TAQOZ on V27zz at 80MHz for about 5 hours now so it seems stable.
Peter, thanks for trying that. So, it's working okay, apparently, but we still don't know why we can't move those SD pins around.
It's still unclear how a download change could cure a fails-after-some-time issue ?
I can see that incorrect download could give erratic starting, but less easy to explain is the 'works for a long time' (in SycCLK terms) before failing ?
I thought memory usage may have moved, which could have different default values in two builds, which could account for one starting and the other not, but if it starts OK, how can it then fail later ?
Are temperatures now cooler where Peter is ?
All one would have to do to simulate this problem is to replace their last byte of code with whatever value the RAM might contain before downloading.
I suppose if the volatile last-byte morphed a simple re-loop JMP instruction, into some form of conditional jmp, you could create a longer failure time frame ?
I loaded V27z back into the CVA9 and it all seems to work ok. Even the microSD card works but what are the pin assignments for the CVA9 after remapping?
My SDD and SDE slots are not responding now as if the old P60..P58 CVA9 pins have been remapped. I guess I could just write a one-liner to find out what they are now.
Does this mean that the original CV-A9 file might work?
This image shows the two mapping possibilities. See the text at the bottom.
Ok, so I loaded the original V27 and there is no response to PNut. On the scope it looks fine in that it generates a reset pulse ~25us and about 20ms later talks to the P2 for <100us but there is no response and so PNut reports "no Prop found...". Loading V27z and this time there is a response from the P2 about 1.5ms after the initial query and then PNut starts sending data about 11ms later with P2 responding.
Well, if you ask me, the P2 just isn't working at all as there is no response at all, not even later.
Comments
Does it exhibit the problem at the same instruction interval?
Thanks. This is a really weird problem. It seems to be unrelated to egg beater timing.
I think you're onto something there, it could become the next GOTO language from which there is no RETURN
It seems to have something to do with downloading!
Adding 'long 0' seems to make everything work. It's like some data wasn't getting downloaded at the end of the program. Adding more data gets over the problem.
I see what it is... We are sending data in base64 and sometimes there is less than 6 bits remaining to send, not making a new Base64 character. This just needs a new PNut.exe to remedy the problem.
I wonder if this will have any effect on Peter's CV-A9 problem.
Peter, add 'byte 0' at the end of your program and see if things don't improve.
The only thing that has changed is the new PNut_v27a.exe:
https://drive.google.com/file/d/1gphMOGE7VFPKCth8dWEQzXaS1syv1vLZ/view?usp=sharing
Now, it certainly sends the whole last byte of download data.
I'm really glad Ozpropdev analyzed the cause so well. This bug was just too weird to have suddenly creeped up into the cog logic.
Seems that RET only replaces Z if WCZ or WZ is specified...
Right. To affect flags, you must use WC/WZ/WCZ.
And _RET_ returns don't pop flags.
Maybe wrong PNut in the .zip?
https://drive.google.com/file/d/1gphMOGE7VFPKCth8dWEQzXaS1syv1vLZ/view?usp=sharing
Good point, download trim errors should really fail the same way, unless somehow V26 has different default values in the memory ?
Maybe there are 2 issues here .....
Yes, it's not so clear to me, either.
btw, are the CLKSET modes documented anywhere? These are the ones I know of:
0 CLKSET seems to run at 20MHZ.
EDIT: It's been running TAQOZ on V27zz at 80MHz for about 5 hours now so it seems stable.
By the way $01 sets RC slow, which is 20KHz on the real chip, but something like 600KHz on the FPGA.
I can see that incorrect download could give erratic starting, but less easy to explain is the 'works for a long time' (in SycCLK terms) before failing ?
I thought memory usage may have moved, which could have different default values in two builds, which could account for one starting and the other not, but if it starts OK, how can it then fail later ?
Are temperatures now cooler where Peter is ?
No, we're heading into summer soon.
get some sleep, this is nonsense. Something is wrong here.
Mike
I suppose if the volatile last-byte morphed a simple re-loop JMP instruction, into some form of conditional jmp, you could create a longer failure time frame ?
I have/had these pins assigned for SD cards:
My SDD and SDE slots are not responding now as if the old P60..P58 CVA9 pins have been remapped. I guess I could just write a one-liner to find out what they are now.
Does this mean that the original CV-A9 file might work?
This image shows the two mapping possibilities. See the text at the bottom.
Ok, so I loaded the original V27 and there is no response to PNut. On the scope it looks fine in that it generates a reset pulse ~25us and about 20ms later talks to the P2 for <100us but there is no response and so PNut reports "no Prop found...". Loading V27z and this time there is a response from the P2 about 1.5ms after the initial query and then PNut starts sending data about 11ms later with P2 responding.
Well, if you ask me, the P2 just isn't working at all as there is no response at all, not even later.
V27z responding normally: (ignore low-level crosstalk)