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.
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.
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.
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.
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
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.
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.
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)
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.
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 deterministicallymission 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.
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.
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
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.
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.
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.
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.
Comments
https://www.virustotal.com/gui/file/88f01b193669267e4e129fe313c9d38e7c7318de91f5290621525dbb67397772/detection
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.
Isn't the presentation next week?
It's in 15 minutes:
https://us02web.zoom.us/meeting/register/tZEkdOGrqj0iGtGi_bYFEwjWOPxPaj3sAO6u
Whew! Let's hope it sticks.
So far so good . Fingers crossed
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.
Peter and I had a discussion after the zoom meeting and has some ideas. He'll post that probably on the P2D2 thread initially.
_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)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.
Awesome!
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.
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.
@"Bob Lawrence (VE1RLL)"
Downloaded the Pnut "v" version had to tell Windows Defender to run anyway so far so good.
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
Great Job!
Thank you and you're welcome!
C.W.
So... how soon before the v34v compiler features make it into Propeller Tool?