Board settings for Pnut.exe vs FastGUI? [solved --> Terminal window was not closed]
potatohead
Posts: 10,253
I've been running examples and coding today. (finally got more than a quick look!)
FastGUI ran with the Rev B eval board out of the box. (nice work Eric) Someone here mentioned flipping a switch, or doing something for Pnut.exe to work. Currently, it does not find the board.
What do I need to do here? Or, which doc do I need to re-read?
Either is fine
Edit: I need to power off, not just reset to load a new program via FastGUI.
BTW: The current HDMI code in the spiral thread works just fine on my Acer monitor I'm using right now. I've not gone through and tried variations on the driver Roger did just yet.
FastGUI ran with the Rev B eval board out of the box. (nice work Eric) Someone here mentioned flipping a switch, or doing something for Pnut.exe to work. Currently, it does not find the board.
What do I need to do here? Or, which doc do I need to re-read?
Either is fine
Edit: I need to power off, not just reset to load a new program via FastGUI.
BTW: The current HDMI code in the spiral thread works just fine on my Acer monitor I'm using right now. I've not gone through and tried variations on the driver Roger did just yet.
Comments
Perhaps flexgui is keeping the terminal window open, thus preventing pnut finding the board? You can remove the -t -k options from the loader if need be (that doesn't keep the terminal window open)
What OS are you using @potatohead
But, for right now, quickie P2 time, it's a P50s on Win10, recent build.
It's gotta be the terminal window. I should have known. That worked.
What I was doing was running a program, then looking at various documents, browser windows. That terminal window was near or at bottom of the window manager stack!
DOH!
Thanks!
Pnut, FastGUI working.
evanh: Got the goodies, and the current v33L file. It's been a lot of fun today. Honestly, that Goertzel demo makes me want to fabricate a slightly bigger one. Too fun.
Haven't gotten to the scope mode code yet.
Next task is to get an SD card formatted and loaded with Peter's latest.
But you know how it is. Gotta be respectful with other people's gear. I ditched the switcher idea too. That's in use, and I just don't want to futz with it right now.
I really like how lean a basic HDMI bitmap can be. Awesome sauce. I'll bet nobody else out there has that. And if one of us gets crazy, driving a handful of displays is a no brainer, save for how to manage RAM. Just like P1, this is going to be a lot of fun.
I gotta run your driver. Haven't yet, but I'm all setup. Old school mono NTSC Amber, PVM, VGA, HDMI. I don't happen to have a component display handy. Thought the PVM had one, but it's RGB. We need to test that anyway.
Also, who knew? That PVM has TTL, old school. CGA basically.
I spent a likely embarrassing amount of time playing with the Goertzel today. Too damn much fun.
Glad you have a good working environment now. If/when you do get the chance to play with NTSC and my driver, take a look at its output to see if there is something obvious I should be doing to improve the CVBS signal with better XFRQ/CFRQ/timing values or more/different xzero's etc. I didn't dig into CVBS in detail as I wanted to get this beta out for people to use and provide feedback of any problems etc. We can add a CVBS/S-video fix to the driver if required - I have 5 spare longs now. Plus I still need to add in the correct PAL colour flip values as well.
I am not sure we have a way to reset the color like we do the streamer with an xzero.
One answer might be to move the shimmer. If the color burst was done with pixels, that and the pixel clock would be stable. Colored pixels may still present artifacts, but monochrome things would not. Text, etc may be improved.
Or, we use some common frequency.
Or? Who knows. Some exploration is needed.
Re TTL: One thing I have wondered for a while is just how fast their response is. With high speed pixel clocks, "sub pixels" could potentially mix to get more color. Save that for a fun day.
You're talking about ntsc, right? I wouldn't expect even 320 pixels wide to look good. Is there a reason for such a high expectation I'm missing?
In general, non phase change color has a baseline of 160 pixels in the active area. Those will match up with the period of the color burst.
That can be pushed to 256 with only minor league artifacts. The better the signal, the more it can be pushed to a point.
Phase change, alternating on frames is good for 320 pixels, and can be pushed to 480, again with minor league artifacts. This does depend on the quality of the comb filter. It also depends on signal quality. On P2 we have better DACS.
Above that can work, but color management should be done. Think TV weather maps. Those are often done higher, but color changes are rarely at that resolution. Luma changes tend to work.
Current P2 drivers are doing phase change, alternating frame.
One exception to all this is text. The greater the color contrast, the fewer characters are resolvable. Better signals is a super big deal here.
On P1, I tried phase change, but static. No alternating frames. This works very well for text. It is a hack, just like fixed phase, 240P was on home computers back in the day.
On very good displays, like a PVM, the circuits are really good. A 640x480 display tends to be fairly good. I have one. It is crazy good. Consumer sets had much coarser CRT shadow masks and generally less performant circuits. I will have to get a photo or two.
Pro grade video is generally 720x480, full interlace, phase change, alternating phase color.
An 858 scan line is not unreasonable. Btw, the HOT chip, with its PLLs would render that perfectly. A good display would show 80 column color text in most all but the most aggressive color combinations. And it did that on composite on better consumer grade sets.
This one can too, but we are going to need to get both the color frequency domain and base pixel clocks in consistent phase, IMHO.