Shop OBEX P1 Docs P2 Docs Learn Events
PNut/Spin2 Latest Version (v44 -Data Structures Added, New Methods for Memory Testing/Manipulation) - Page 26 — Parallax Forums

PNut/Spin2 Latest Version (v44 -Data Structures Added, New Methods for Memory Testing/Manipulation)

1232426282963

Comments

  • I just uploaded the latest PNut and got a bunch of red flags.
    1920 x 1040 - 121K
  • cgraceycgracey Posts: 14,133
    edited 2020-08-12 21:23
    I just posted the latest PNut_v34v. This has graphical DEBUG in it. Presentation in 40 minutes.

    I downloaded the file and the only trouble I had was that Windows was cautious because it didn't know the PNut_v34v.exe program, but 'More Info' and 'Run Anyway' got me around that. No 'virus' problem is yet apparent.
  • cgracey wrote: »
    I just posted the latest PNut_v34v. This has graphical DEBUG in it. Presentation in 40 minutes.

    I downloaded the file and the only trouble I had was that Windows was cautious because it didn't know the PNut_v34v.exe program, but 'More Info' and 'Run Anyway' got me around that. No 'virus' problem is yet apparent.

    Latest version download with no problems or virus detections.
    :)


  • cgracey wrote: »
    I just posted the latest PNut_v34v. This has graphical DEBUG in it. Presentation in 40 minutes.

    I downloaded the file and the only trouble I had was that Windows was cautious because it didn't know the PNut_v34v.exe program, but 'More Info' and 'Run Anyway' got me around that. No 'virus' problem is yet apparent.

    Isn't the presentation next week?
  • Downloaded right now. For the moment no warnings with 34v
  • cgraceycgracey Posts: 14,133
    edited 2020-08-12 21:47
    Publison wrote: »
    cgracey wrote: »
    I just posted the latest PNut_v34v. This has graphical DEBUG in it. Presentation in 40 minutes.

    I downloaded the file and the only trouble I had was that Windows was cautious because it didn't know the PNut_v34v.exe program, but 'More Info' and 'Run Anyway' got me around that. No 'virus' problem is yet apparent.

    Isn't the presentation next week?

    It's in 15 minutes:

    https://us02web.zoom.us/meeting/register/tZEkdOGrqj0iGtGi_bYFEwjWOPxPaj3sAO6u
  • It's working great now .
  • cgraceycgracey Posts: 14,133
    It's working great now .

    Whew! Let's hope it sticks.
  • @ Chip
    Whew! Let's hope it sticks.

    So far so good . Fingers crossed :)

  • Just ran Scope Debug on my brand new RevC board under V34V. Super Chip!
  • Cluso99Cluso99 Posts: 18,066
    On today's Zoom meetup, we suggested that the scope debugging should be done on a separate P2 board with VGA 1920x1080 rather that a PC. Only part of the screen needs to be dedicated to the scope part, with other section(s) being just text. This minimises the hub footprint for the screen buffer.

    Some of this code is in Delphi and some in x386 assembler. We (on the forum) could translate this to spin/pasm so hopefully Chip is going to post the code shortly :)
  • cgraceycgracey Posts: 14,133
    Cluso99 wrote: »
    On today's Zoom meetup, we suggested that the scope debugging should be done on a separate P2 board with VGA 1920x1080 rather that a PC. Only part of the screen needs to be dedicated to the scope part, with other section(s) being just text. This minimises the hub footprint for the screen buffer.

    Some of this code is in Delphi and some in x386 assembler. We (on the forum) could translate this to spin/pasm so hopefully Chip is going to post the code shortly :)

    I will get it together soon, but it probably won't be until tomorrow. I need some rest.
  • Cluso99Cluso99 Posts: 18,066
    cgracey wrote: »
    Cluso99 wrote: »
    On today's Zoom meetup, we suggested that the scope debugging should be done on a separate P2 board with VGA 1920x1080 rather that a PC. Only part of the screen needs to be dedicated to the scope part, with other section(s) being just text. This minimises the hub footprint for the screen buffer.

    Some of this code is in Delphi and some in x386 assembler. We (on the forum) could translate this to spin/pasm so hopefully Chip is going to post the code shortly :)

    I will get it together soon, but it probably won't be until tomorrow. I need some rest.
    That will be fine thanks Chip :)
    Peter and I had a discussion after the zoom meeting and has some ideas. He'll post that probably on the P2D2 thread initially.
  • cgraceycgracey Posts: 14,133
    edited 2020-08-13 01:52
    Here is a little way to see LOGSCALE mode in scope_xy:
    _clkfreq = 200_000_000
    
    PUB go() | i, j
    
      debug("`scope_xy mag size 200 range 100 samples 0 logscale")
    
      repeat i from -50 to +50
        repeat j from -50 to +50
          debug("`mag ", sdec_(i,j))
          waitms(1)
    

    LogScale.png
    466 x 489 - 15K
  • roglohrogloh Posts: 5,122
    edited 2020-08-13 01:49
    Cluso99 wrote: »
    On today's Zoom meetup, we suggested that the scope debugging should be done on a separate P2 board with VGA 1920x1080 rather that a PC. Only part of the screen needs to be dedicated to the scope part, with other section(s) being just text. This minimises the hub footprint for the screen buffer.

    Some of this code is in Delphi and some in x386 assembler. We (on the forum) could translate this to spin/pasm so hopefully Chip is going to post the code shortly :)

    Yes, the more you couple yourself now to Windows only tools the harder to port later. Looking forward to watching the recording of today's meeting.

    A separate P2 board with HyperRAM will allow a lot of possible graphics display options such as 1080p 8bpp when overclocked, but even without the extra RAM you can still get some reasonable results. For example the video driver I wrote has independent screen regions for text/graphics and different depths etc so you can also try to reduce the Hub memory use that way too.

    From a software development point of view it's actually handy to have different region types on screen and independent control of multiple buffers from different COGs, and get to resize regions dynamically etc, instead of working with just a single common frame buffer. The added large external memory when shareable by multiple COGs only makes this work even better. It can be both pretty and compelling.
  • @cgracey
    Here is a little way to see LOGSCALE mode in scope_xy:

    Awesome! :smile: The session on the Graphical DEBUGGER was extreamly interesting. Lots of new ideas to play with.

  • Cluso99Cluso99 Posts: 18,066
    edited 2020-08-13 03:02
    rogloh wrote: »
    Cluso99 wrote: »
    On today's Zoom meetup, we suggested that the scope debugging should be done on a separate P2 board with VGA 1920x1080 rather that a PC. Only part of the screen needs to be dedicated to the scope part, with other section(s) being just text. This minimises the hub footprint for the screen buffer.

    Some of this code is in Delphi and some in x386 assembler. We (on the forum) could translate this to spin/pasm so hopefully Chip is going to post the code shortly :)

    Yes, the more you couple yourself now to Windows only tools the harder to port later. Looking forward to watching the recording of today's meeting.

    A separate P2 board with HyperRAM will allow a lot of possible graphics display options such as 1080p 8bpp when overclocked, but even without the extra RAM you can still get some reasonable results. For example the video driver I wrote has independent screen regions for text/graphics and different depths etc so you can also try to reduce the Hub memory use that way too.

    From a software development point of view it's actually handy to have different region types on screen and independent control of multiple buffers from different COGs, and get to resize regions dynamically etc, instead of working with just a single common frame buffer. The added large external memory when shareable by multiple COGs only makes this work even better. It can be both pretty and compelling.
    While my PC is oldish, it is a decent Dell computer with i7-2600 4 core 3.4GHz, 8GB DRAM, 256GB SSD and 3x VGA/DVI/HDMI 24" 1920x1080 LCDs. I am running W10 Pro 1909. At home I don't run any antivirus software other than Defender.

    However, I notice that at times my PC "goes away" to do housekeeping and this is not controllable and can take many seconds (seems like minutes) before I can continue working.

    These days, most software, including Windoze and Office, Adobe (pdf viewers), the Dell, Intel and video (eg Nvidia) drivers, browsers, email software, all phone home on a regular basis to check for updates (and of course send out everything they have snooped logged). You cannot disable it, and if you do, most of it stops running.

    There is no way that today's PCs can run anything deterministically mission critical with these sorts of unplanned "strikes". Imagine trying to fly a Boeing, Airbus or a rocket with this Smile. Or control any life support medical device.
  • jmgjmg Posts: 15,140
    edited 2020-08-13 03:38
    Cluso99 wrote: »
    On today's Zoom meetup, we suggested that the scope debugging should be done on a separate P2 board with VGA 1920x1080 rather that a PC. Only part of the screen needs to be dedicated to the scope part, with other section(s) being just text. This minimises the hub footprint for the screen buffer.

    This does not need to be either/or, it can be both.

    The debug panes Chip showed are just ascii terminals, with a raised IQ, so certainly P2 could manage a simpler subset, and it can have multiple serial ports feeding in many directions.

    The PC side terminal Chip ran has a wide choice of Text size, so it may be that a P2 hosted variant, would not support all of that.

    On a PC, someone can copy/paste window info into reports and documents, (& read PDF documents, and save/share to google-drive) so P2-alone will never reach that level of document generate/scan support - but a clip-on debug display could be useful, just like a scope or meter is useful now.
  • @cgracey
    @"Bob Lawrence (VE1RLL)"
    Downloaded the Pnut "v" version had to tell Windows Defender to run anyway so far so good.
  • Jeff MartinJeff Martin Posts: 751
    edited 2020-08-13 16:31
    "Malware" Update

    Thank you to all who have reported their results here and through direct messaging.

    Summary
    * I've digitally-signed and released Chip's PNut_v34v.exe in a zip archive on the Propeller repo releases.
    * I tested downloading on Win 10, extracting, and running. Windows Defender is happy with it; no "'More Info' and 'Run Anyway'" steps needed.

    Some Simplified Details
    * I've lost track of how many hours over the last two weeks this has taken to resolve
    * Tested over the course of this time using VirusTotal, McAfee, Windows Defender, Bitdefender, and Crowdstrike
    * Found hard evidence last week for false-positive detection and submitted my results to Bitdefender group for analysis
    * They confirmed false-positive and updated their database
    * I had targeted Bitdefender because evidence indicated a number of engines share the database they use, that was confirmed by the below item...
    * The results of their fix were verified by me locally and on VirusTotal over the course of the next day; multiple engines stopped detecting malware
    * More results and doubts ensued shortly after
    * Checked Chip's development machine during this time using various tools including a Microsoft tool (can't remember name) and McAfee
    * VirusTotal's results seemed to change quite a bit over time, in both positive and negative directions
    * Checked yesterday's release of PNut_v34v.exe and .zip on VirusTotal this morning; 5 detections (that's better than the 19 of previous release) with 4 of them naming a similar, heuristically-determined, malware
    https://www.virustotal.com/gui/file/08d477ce46b738904751509852abcdedbdaf059183c79e50743617b6506e9933/detection
    * I targeted Kaspersky for this next round of false-positive verification
    * They confirmed; false-positive and seem to have updated their database
    * I signed .exe, archived into .zip, and retested both with VirusTotal and Windows Defender; down to just 1 detection now
    https://www.virustotal.com/gui/file/fac2a8b344677de71aa595691d6a68476289ea2886dc1eb814ba54babfafd7f8/detection
    https://www.virustotal.com/gui/file/3b4b5ed98e572753c81f4a327027b29272cda4bfdea599b6ed2d94383f13e3cf/detection



    1421 x 676 - 164K
    1439 x 485 - 93K
    1409 x 485 - 94K
  • Thanks Jeff. I know it has been a behind the scenes marathon with no one actually seeing how much work you put into it. I wanted to thank you on last nights zoom, but there was no time for chit-chat.

    Great Job!
  • Publison wrote: »
    Thanks Jeff. I know it has been a behind the scenes marathon with no one actually seeing how much work you put into it. I wanted to thank you on last nights zoom, but there was no time for chit-chat.

    Great Job!

    Thank you and you're welcome!
  • PublisonPublison Posts: 12,366
    edited 2020-08-13 17:03
    Just downloaded Ver V to my Windows 10 laptop. It downloaded without deleting PNut his time but extracting had an issue. Accepted "Run Anyway" and it ran fine.
  • cgraceycgracey Posts: 14,133
    Thanks for tackling this, Jeff.
  • Jeff is a behind the scenes guy that does not get enough credit on the forums. I talk to him a little off line and he his very responsive.
  • Just downloaded and scanned with Sophos Home Premium, no issues found.

    C.W.
  • Cool! Sorry it has been such a headache, Jeff.

    So... how soon before the v34v compiler features make it into Propeller Tool?
  • Working on that next. Hard to say what issues I'll run into, but I'm trying to get it integrated asap.
  • McAfee still marks it as infected. Been trying to find how to submit for false-positive analysis to McAfee but it seems they only accept that through their business service portal and requires a "grant number" which apparently is something given based on purchased enterprise products. We don't use McAfee for our "corporate" solution and everywhere I look, this seems like a solid barrier to entry.
Sign In or Register to comment.