QuickByte Video Hardware with Character Map
rogersyd
Posts: 223
I do not have extensive experience with the P2, but am having issues running the demo code for the above quickbyte. I am attempting to run P2_CharacterMapDemo via the propeller tool (2.7.0) and see the following errors:
P2_CharacterMapDemo does not compile: line 33 "expected "," or end of line"
in p2simplevideo line 625 "expected a unique variable name". It appears that fontHeight, fontWidth, fontOffset are used elsewhere as method names in the object?
also in p2simplevideo the CASE videoFormat section of the Init method appears to have multiple alignment (tabbing) issues.
That is as far as I got this morning. Has anyone had luck running these? I see they were posted back in August, but didn't seen any comments, and couldn't find any forum threads about it... Thanks in advance for any advice.
Comments
You should use FlexProp to run those demos.
Thanks with flexprop, see these errors when i try to run the demo:
p2simplevideo.spin2:100: error: syntax error, unexpected end of line, expecting ':' or ','
p2simplevideo.spin2:104: error: syntax error, unexpected ':'
Hmm. I've just downloaded the file and don't see those errors. I wonder if having opened in PropTool things got mangled? Could you try re-downloading?
Edit: Just opened the file "P2_CharacterMapDemo.spin2" and tried again on my office PC.
I'm hoping this means when you re-download (or unzip the previous download again), that you'll be OK ?
In flexprop only the errors related to number 3 above were presented. I was able to fix those and the code compiles ok. However, at the three vga resolutions i tried, an image of sorts is displayed on the screen, but it clearly is not the intended character map. May be another tab related issue in p2simplevideo that i dont see. There is an earlier demo i found that appears to be similar and works fine, so Ill stick with that one for now. Thanks again.
I'm not sure if file handling changed between the IDE versions, but anyway-- clearly there's an issue even if I can't replicate it, and I really appreciate your feedback.
I'll make an attempt to convert the project for PropellerTool compatibility over the next week. That will take care of any odd formatting that was OS and/or IDE specific at the same time. Will update here when it's ready.
Ok re-downloaded and extracted P2-Character-Map-Code.zip from the quickbytes page. Also overwrite my existing flexprop directory with a fresh install. Opened the demo file first and only in flexprop (5.9.17 - i noticed above you are running a slightly earlier revision). Same results. I also downloaded part 2 and 3 of the quickbytes - the version of p2simplevideo.spin2 in those archives exhibits the same errors. I attached the screenshot so you can see how the tabs got all jacked up.
p2simplevideo.spin2 uses TAB characters that when removed and replaced with spaces (2 spaces for each TAB character), allows P2_CharacterMapDemos.spin2 to compile in flexprop.
I've attached the modified file...
dgately
I previously found the issues you mentioned above back in September and sent some fixes to Ken, he just hasn't had the time to update the Quick-byte yet. I was able to get the routines to work with the PropTool after some tweaking...
I've updated to the latest FlexProp 5.9.17, and yet the file still formats correctly (and compiles correctly) on my computer.
Intriguing madness!
I wonder if our "Editor Options" are any different? Especially the Tab stops setting ?
Opening the file with Notepad++ and enabling All character view, I can see the issue of course... Tabs vs spaces. (4 spaces per tab in my case)
We can see in the source that each tab is equivalent to 4 spaces. So yeah, if I change the Tab stops setting from 4 down to 2, (which I guess @dgately has based on comments above), then yeah, a lot of things go out of alignment.
Does this mean we need to mention the Tab stops setting when sharing files with FlexProp ?
If all the editors auto-convert those tabs to spaces when saving, then they would work with any editor or notepad correctly, regardless of the user's own Tab stops preferences, right?
For a language that relies on indentation, it seems pretty horrific how the formatting is locale dependant for shared resources! Although maybe I'm just doing something really wrong.
I want to look at how PropellerTool handles the same scenario, and then figure out the best way to share sources moving forward. I'm just about to share some Audio code, so will try doing that with a PropellerTool archive.
Other ideas... If I still see this tab/space mix in the sources of PropellerTool, I could have a script pass over all the sources before sharing, changing all tabs to X spaces (based on the locale Tab stops setting)... hmm... Unless that will cause other problems I've not yet thought of....
This is an interesting topic. More research needed!
Any chance to email those updates to support@parallax.com ?
I can have them updated at the QuickBytes page pronto!
(And very much thank you for saving me a bunch of time!)
Edit: If the only changes were in the file dgately posted above, then we are good to go ! I'll check that soon, and get it posted.
Ah ha!
So tried a little test with PropellerTool.... seems that does auto-convert Tabs to spaces in the saved source code.
I appreciate the file size might be slightly larger, but at first glance it seems to totally solve the locale issue.
So I think the solution is already given...
Either to use PropellerTool archives when sharing files publicly (as I believe they will always work with FlexProp too, but just not the other way around)
Or... when sharing code that needs the FlexProp features, just mention the Tab Stops setting for the Editor Settings.
(Perhaps in the future @ersmith might consider to add a #tabstops=4 type of override constant, that perhaps gets auto-added when code is saved the first time. Would that negate the issue, and allow saving files in a more compact format?)
I think that Video code was the only thing I've published with FlexProp so far, but I'll go back and check and get all prior resources fixed up.
A better solution would be to emit a compiler warning on inconsistent/tab/space usage (that is, mixed tab/space in one line or mixed tab/space between lines where it would be sensitive (i.e. inside spin functions))
Not sure about that, as any non-automated solution would add a lot of repetitive manual effort for users.
Unless the warning was smart enough to recommend the tab-stop change setting required. BUT... even then, code could have come from a variety of sources/users, with a variety of tab-stop settings in different files. Personally I'd think removing tab encoding from saved source code data altogether is the only sane way. (or as a distant plan B, have a constant stated in each file that reflects the tab-stop format used when saving).
If having tab functionality available is important when re-editing a file, perhaps the GUI could auto-replace groups of spaces that match the user's local tab-stop setting with a tab when opening a file, and then set them back to the appropriate number of spaces when saving (or copy/pasting out) again. I think that's how I'd approach things having learned from the gotchas.
Inconsistently mixed tabs and spaces - anything that could cause different results depending on your intended tab size - should cause an error, not a warning. If the compiler needs to know how big a tab is, your code is wrong: the only sane way to mix both in the same file is to use tabs for indentation and spaces for alignment, and any other mixture is insanity. In Python, an ambiguous mixture of tabs and spaces causes a compiler error.
A correctly indented file using tabs for indentation and spaces for alignment appears correctly indented and aligned at any tab stop setting. Every other way of doing it either looks wrong at certain tab stops (only tabs), or doesn't respect each user's desired tab size (only spaces).
@VonSzarvas , a compromise could be to have a command-line option that lets you specify a tab size and then downgrades the inconsistent white-space error into a warning. It should still be a warning, since it is just a band-aid.
That option already exists (and the GUI passes in the editor tab size automatically, thus the funny)
Opened an issue on the spin2cpp issue tracker: https://github.com/totalspectrum/spin2cpp/issues/305
Sorry, I guess I could have said that better. If the option isn't specified, it should throw an error when it would matter instead of just using some default value, and if it is specified, it should produce a warning in any situation where its value could make a difference.
Having reflected on too many permutations, and especially considering the sharing of code amongst multiple editors, then I stand by my previous view that the only sane way to handle the file formatting is...
This seems to remove all other issues at the root, and obviates the need for exported tabstop settings/etc, which I agree would be horrific. As would trying to support tabs in certain places, as code will always be shared, and different tab (and/or space) settings will get into code files whether that is intended, advised or otherwise. Especially in the case of tab vs space, as the difference is invisible until someone opens the file with different local settings, and Kaboom!
That said- it's just my view and I've not been a regular user of FlexProp, so only speaking (and reporting mistakes I've made) as a novice. Eric will know best for his compiler, and I'm sure has good reasons for the way things are. Although I suspect the "mixing of editors" is likely the devilish nail in all this. Like switching from Marguerita to diavola - it's all pizza, but you gotta be careful !
EDIT: BTW... Just a summary of one perspective for Eric's benefit, should he review this thread. Apologies to the thread OP for the derailment.
Nice! Thank you dgately. With this version in place the demo compiles successfully without further edits.
VonSzarvas :
Here is a screen grab of flexprop tab settings for what its worth:
Looks like yall got to the bottom of it. I appreciate the assistance. and input. Not much to add to the debate, only can say that as a casual P2 hobbyist, the nuisances between the ide/compilers, and having to try both (or all three counting pnut) to get something to compile, make for a more frustrating experience. I know eventually this will all shake itself out. The P2 journey has been an interesting one so far.
Apparently I'm mistaken, I didn't get these QuickByte demos working with PropTool (or PNut). I was able to fix the various tab issues, constant reference, PUB vs variable name conflicts. However I haven't resolved the inline PASM issues with referencing local parameters that are >16 parameters in the pass list. There are a number of routines in the p2simplevideo.spin2 file that have so many pass parameters that I can't get the inline PASM happy. This is going to take a bunch of refactoring/revamping of these routines to have these routines work with PropTool (or PNut).
It is unfortunate that there are enough "differences" between these various tool sets that make going between them a bit challenging even though they work with SPIN. This is going to be a hindrance to newbies, especially if it is not explicitly specified in the code what environment it was developed in...
To update y'all, indentation warning has been added to flexspin, thus this particular issue will have been solved. Unless one ignores the warning messages.
That's good to hear. Thanks for communicating that to Eric.
I've also added the note to the QuickBytes download page, about the required tab setting in FlexProp for that particular demo.
I have followed the above thread with this outcome:
Is the display faulty?
Try the following VideoFormat setting:
VideoFormat = video#VGA_640x480I have had the above setting work for me using the same Digital Video Output board with P2 Edge boards.
I thought it was one of the DVI settings for that little monitor. Try DVI_800×480.
VGA would use the Parallax AV adapter to an older style VGA monitor.
Thank you @"Francis Bauer" Your comment is much appreciated. With VideoFormat = video#VGA_640x480 I have an inactive dark (black) display.
I previously tried Proptool and experienced the items listed by @rogersyd :
"In-line PASM code can access the first 16 longs of parameters/results/locals via registers with the same symbolic names."
I guess some local variables would need to be changed to global variables:
PRI {++opt(!regs)} gfxText8(textStr, addr, w, h, stride, srcAddr, srcStride, fontPtr, fg, bg, buf, flags) : len | char, glyph, pix, pix1, pix2, scanLines, srcPtr, destPtr, maxBytes, maxChars, font, fontHeight, fontWidth, fontOffset
Of the last 8 local variables only two can be re positioned to be included in the "first 16 longs".
Any comments about my effort above would be much appreciated and any successes using this driver would be of interest.
Hi @kg1
Having got to the office, I can see the two choices of format for your monitor:
video#DVI_640x480
or
video#DVI_800x480
Those are compatible with the monitor you have.
Using any of the VGA modes will NOT work with your HDMI input monitor.
Hi @VonSzarvas
From the snapshot of FlexProp above initially I used video#DVI_640x480 based on the video provided by Michael Mulholland and the note in the P2_CharacterMapDemo.spin2 file: "For DVI use the #64006D "Digital Video Out" accessory, and either 640x480, 800x480 or 800x600 resolution". This code file could state: P2 Character Map Code (Requires FlexProp with Editor Options / Tab stops set to 4). Should this tab setting be checked before opening spin files? Within FlexProp and PropTool if the TAB STOPS is SET TO say 8 will the tool automatically change a spin file from a previous setting of 4 to 8 when the file is opened?
@JonnyMac As part of your standard practice, do you have recommended rules for tabs and spaces in your spin files?
In this forum has anything been written about converting spin files between tools e.g. PropellerTool and FlexProp?
A rule like: "In-line PASM code can access the first 16 longs of parameters/results/locals via registers with the same symbolic names." applying in one tool and not the other is a surprise for newcomers.
As I recall, the tabstop in FlexProp would need setting before opening the file.
Proptool doesn't have the tab "issue", and it doesn't matter what the tabs are set to. However Proptool lacks some code features that were used in the underlying video driver that Rogloh contributed to that demo, so you wouldn't be able to use Proptool anyway (as you discovered!)
I've not experimented with changing tabstops, but will have a go tomorrow. I'll download the demo files from the quickbyte and report back on my experience opening and running them with the same setup as you have.
One other thought about your display- how do you have power connected? Wondering if there's a voltage sag issue.
Previously I had both positive and both negative power cables from the back of that monitor connected to a 5V 1Amp supply, and used the DVI_640x480 setting. That worked well.
I have my preferred settings, but others may not like the amount of white space I use.
Fair warning, I do modify these from time-to-time -- always with a focus on readability.
Generally I am using a Nextion connector board:
with a 2.4A 5V source. I also checked with a directly connected PowerTech supply and increased the voltage from 5V to 5.5V. No change to the display.
I also changed DVI_640x480 to DVI_800x480. The Display is much the same as the photo above with finer lines.
My board is a Rev B?
I am now working through the spin files checking all lines and changing any spaces prior to a line of code to tabs using Notepad++. Plus I am checking the code indentation.
Just looking back through this thread:
"Proptool doesn't have the tab "issue", and it doesn't matter what the tabs are set to."
but
"So tried a little test with PropellerTool.... seems that does auto-convert Tabs to spaces in the saved source code."
Is this happening with all saves?
Repeat --> Until and Repeat --> While
With FlexProp what happens if the tabs and/or spaces do not match?
In p2simplevideo.spin2 function: gfxText8:
repeat
asm
endasm
until
can easily be upset? Are there any must have rules about tabs and/or spaces?