Shop OBEX P1 Docs P2 Docs Learn Events
Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i - Page 102 — Parallax Forums

Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i

199100102104105160

Comments

  • cgraceycgracey Posts: 14,131
    ozpropdev wrote: »
    cgracey wrote: »
    Can anyone check what happens on the DE2-115 that has four cogs? Does it have this return/flag problem?
    Yes, DE2-115 has the same problem.


    Does it exhibit the problem at the same instruction interval?
  • cgracey wrote: »
    ozpropdev wrote: »
    cgracey wrote: »
    Can anyone check what happens on the DE2-115 that has four cogs? Does it have this return/flag problem?
    Yes, DE2-115 has the same problem.


    Does it exhibit the problem at the same instruction interval?
    Yes, the same intervals.

  • cgraceycgracey Posts: 14,131
    ozpropdev wrote: »
    cgracey wrote: »
    ozpropdev wrote: »
    cgracey wrote: »
    Can anyone check what happens on the DE2-115 that has four cogs? Does it have this return/flag problem?
    Yes, DE2-115 has the same problem.


    Does it exhibit the problem at the same instruction interval?
    Yes, the same intervals.

    Thanks. This is a really weird problem. It seems to be unrelated to egg beater timing.
  • Heater. wrote: »
    Ouch! Peter, you got me. Hook line and sinker.

    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 ;)


  • cgraceycgracey Posts: 14,131
    edited 2017-11-19 06:58
    This problem was just too weird to be real.

    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.
  • cgraceycgracey Posts: 14,131
    edited 2017-11-19 07:11
    Ah, even 'byte 0' does the trick.

    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.
  • cgraceycgracey Posts: 14,131
    edited 2017-11-19 08:51
    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?
  • cgracey wrote: »
    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).

  • I'll give it a try but that doesn't explain why the same code runs on V26 though.
  • cgraceycgracey Posts: 14,131
    edited 2017-11-19 18:36
    I got the downloading bug fixed and posted a new update at the top of this thread.

    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.
  • cgraceycgracey Posts: 14,131
    edited 2017-11-19 16:59
    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.
  • RaymanRayman Posts: 13,767
    Ok, I think I was seeing this wrong...
    Seems that RET only replaces Z if WCZ or WZ is specified...

    ozpropdev wrote: »
    Rayman wrote: »
    Is there an easy way to get C and Z set inside a subroutine call back to main routine after the RET?
    	modcz	_set,_set wcz
    

  • cgraceycgracey Posts: 14,131
    Rayman wrote: »
    Ok, I think I was seeing this wrong...
    Seems that RET only replaces Z if WCZ or WZ is specified...

    ozpropdev wrote: »
    Rayman wrote: »
    Is there an easy way to get C and Z set inside a subroutine call back to main routine after the RET?
    	modcz	_set,_set wcz
    

    Right. To affect flags, you must use WC/WZ/WCZ.

    And _RET_ returns don't pop flags.
  • cgracey wrote: »
    I got the downloading bug fixed and posted a new update at the top of this thread.

    The only thing that has changed is the new PNut_v27a.exe:

    https://drive.google.com/file/d/19DSzQEL8lRGjxMxUVH0ZVv8GOvigR3Db/view?usp=sharing

    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.

    Maybe wrong PNut in the .zip?
  • cgraceycgracey Posts: 14,131
    edited 2017-11-19 18:37
    Sorry, Garryj. It was a cut-and-paste error in that last post. The top post had the correct link:

    https://drive.google.com/file/d/1gphMOGE7VFPKCth8dWEQzXaS1syv1vLZ/view?usp=sharing
  • cgracey wrote: »
    Sorry, Garryj. It was a cut-and-paste error in that last post. The top post had the correct link:

    https://drive.google.com/file/d/1gphMOGE7VFPKCth8dWEQzXaS1syv1vLZ/view?usp=sharing
    Thanks, Chip! Should've checked the top post -- dang Sunday morning fog ;)
  • jmgjmg Posts: 15,140
    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 .....
  • cgraceycgracey Posts: 14,131
    jmg wrote: »
    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 .....

    Yes, it's not so clear to me, either.
  • cgraceycgracey Posts: 14,131
    Peter, any luck with the new PNut?
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-11-20 14:36
    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:
    pub WP 			$3000.0000 CLKSET ;
    pub WE			$2000.0000 CLKSET ;
    pub 80MHZ		$FF CLKSET ;
    pub 40MHZ		$7F CLKSET ;
    pub 20MHZ		$3F CLKSET ;
    pub 10MHZ		$1F CLKSET ;
    pub 5MHZ		$0F CLKSET ;
    

    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.

  • cgraceycgracey Posts: 14,131
    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.

    By the way $01 sets RC slow, which is 20KHz on the real chip, but something like 600KHz on the FPGA.
  • jmgjmg Posts: 15,140
    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.
    cgracey wrote: »
    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 ?

  • jmg wrote: »
    Are temperatures now cooler where Peter is ?

    No, we're heading into summer soon.
  • cgraceycgracey Posts: 14,131
    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.
  • cgracey wrote: »
    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.

    get some sleep, this is nonsense. Something is wrong here.

    Mike
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    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 ?


  • cgraceycgracey Posts: 14,131
    Well, are there any more problems apparent anywhere?
  • 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?

    I have/had these pins assigned for SD cards:
    ( SD CARD PIN ASSIGNMENTS )
    ( CS.DO.DI.CK )
    \ &39.36.40.41	== SDC	--- unmapped BeMicro CVA9 microSD V27zz
    &61.59.58.60	== SDC	--- remapped standard SD boot pins V27z
    &57.58.59.60	== SDD	--- CVA9 ext
    &56.58.59.60	== SDE	--- CVA9 ext
    &15.14.13.12	== SDF	--- DE2-115 EXT
    

    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.
  • cgraceycgracey Posts: 14,131
    edited 2017-11-21 03:09
    Peter,

    Does this mean that the original CV-A9 file might work?

    This image shows the two mapping possibilities. See the text at the bottom.

    745 x 1329 - 1M
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-11-21 05:44
    cgracey wrote: »
    Peter,

    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)
    P2-V27z-load.png
Sign In or Register to comment.