Note: The LUT filling code is normally before the field loop.
But, it was put inside the loop so the palette could be changed dynamically by other cogs...
I got the examples working last night. They look amazing.
I was playing around with some of the settings and have two questions.
If I use a different bmp file, how can I determine where the color mapping address starts?
Also, on this line of code: rdfast ##800*480,PB, if I change the value to just ##800 (and not multiply by 480) I thought I would just get the first line of the bmp redrawn over and over, but it appears that I get the first 64 lines of the bmp file drawn before it repeats, why is that?
I think the color map always starts at the same place, at least in most cases.
As I recall there is a pointer to it in the header, but usually there's no metadata in these, so it's always the same.
The first rdfast parameter is how many longs/words/bytes to read before it starts reading from the beginning again.
[1] First, thanks to Rayman for taking the initiative to update these video drivers again to generalize them to work in any cog (though I've only played with the VGA (640x480) one at this point).
[2] Next, for VGA_Simple1a, when I ran this on the Edge Breadboard, I noticed that it apparently only works for basepins 0, 8, 16 and 24 on Port A (the situation is bascially the same on Port B, but let's ignore that). That is, it doesn't seem to work when using basepins 4, 12, 20 and 28.
The VGA adapter that Parallax offers is hardwired for use with basepins 0, 8, 16 or 24, not the second group of basepins mentioned above. So, that would make it harder for one to notice this situation (assuming that it's not something specific to my setup).
But I made a board to test things when using basepins 4, 12, 20 and 28 and it didn't produce any output on the screen (the screen reported no signal present). Then, switching to the Edge Breadboard, I used an oscilloscope to check the hsync pins for both groups of pins and only saw a +31KHz hsync signal on pins P0, P8, P16 and P24 when using basepins 0, 8, 16 and 24, respectively. But no such signal was present on P4, P12, P20 and P28 when using basepins 4, 12, 20 and 28, respectively.
Looking at the code, I wasn't sure about the five lines that add in "basepin<<17" to m_bs, m_sn, m_bv, m_vi and m_rf. I was worried that those were "clobbering" some of the bits that configure the streamer. So I removed the "basepin<<17" part. Then I was able to see video (the bird image) and the +31KHz hsync signal for any of the eight possible basepins for Port A. But I don't know if that is the right way to address the problem. Need to investigate further.
[3] Last, when I do see an image on the little monitor that I'm using, no matter with or without the "basepins<<17" part, the image is steady and colored correctly, but it appears that the first 24 lines or so of the image (compared to the image when viewed in MS Paint) are being skipped, which leaves the last 24 lines of the screen black. I haven't investigated this yet, but I have seen the whole screen being used (all 480 lines of it) with another spin2 program. So I'm not sure what's up with that, but it's of less concern to me at present than item [2] above.
Anyway, I just got my Edge two weeks ago (sadly, my Eval board was lost about a year ago during a move), so I've just started playing again. I wish I could say "that it's all coming back to me now" but I never actually had it back then ("it" being a sufficient understanding of the P2). "Starting all over again is going to be rough," but it will also be fun. Apologies for the song references.
The standard VGA has been written to run with bases of 0,8,16,24 etc (ie banks of 8) where VS is the 5th pin. I modified it to run with banks of 4 and moving the VS to the pin just prior to the bank of 4. There is a link to this thread in my RetroBlade2 what now thread.
I believe the <<17 part sets the %ppp bits in the streamer command like this from the manual:
In every mode, the three %ppp bits in D[22:20] select the pin group, in 8-pin increments, which will be used as outputs or inputs, for up to 32-pin transfers. The selection wraps around:
%ppp : 000 = select pins 31..0
001 = select pins 39..8
010 = select pins 47..16
011 = select pins 55..24
100 = select pins 63..32
101 = select pins 7..0, 63..40
110 = select pins 15..0, 63..48
111 = select pins 23..0, 63..56
For modes which involve less than 8 pins, lower-order %p bit(s) in D[19:19..17] are used to further resolve the pin number(s).
So, if you don't do it, I guess maybe it could work on pins 31..0.
Looks like basepin=4 should have worked as is because that would have just set you in 8-bit LUT mode, which is the correct mode for this example: 0111 dddd eppp 1000
These ppp bits are a little strange for this mode, because we are only using 4 pins... These are designed for flexibility with modes that use up to 32 pins.
In this particular case, it looks like we could either set the ppp bits to 000 if using pins 0..31 or 100 if using pins 32..63.
Hi, guys. Thanks for your comments. Sorry for the late reply. I still need to digest things and do some more testing, but prompted by your feedback and guidance, I investigated further and believe that using addition to bring in "basepin<<17" appears to conflict with using base pins with 4 = %100 in the binary: 4, 12, 20 and 28. I don't see a code tag option yet with the new forum software (nor a preview mode), so I don't know how to show a fixed-width font (I quickly tried adding code tags and pre tags, in square and angle brackets, respectively, around my text, but to no avail). So I took a screen shot of the text that I wanted to show. In the screen shot, the two notes in the captured text describe where things appear to conflict for specifically using pin 4 as a base pin for 8bpp VGA. I expressed everything in binary to make the inspection more direct. The screen shot text refers to the following code snippet from the VGA driver:
There's more that I could say about the matter, as I don't understand some things in the documentation, but this will have to suffice for now. And as for the screen shift, it's in the vertical direction, not horizontal. But that's one of the things that I still want to investigate. I'll update you here if I resolve that matter (and as I mentioned, an earlier driver from a year ago or so fills the screen just fine, so hopefully there's a way to make it do so for the current VGA code (though I seem to recall that the sync timing is the same)).
By the way, in my case, I want to stick to using a VGA driver (with its 5 pins), so it's possible that a "standard" might not apply in my particular situation. There won't be any need for testing/using HDMI or other types of video signaling for the particular board that I have in mind. And I already had a PCB made to do some initial testing. But I may redesign the board to make it use a different base pin arrangement if there's a good reason to do so (that is, not use pins 4, 12, 20 or 28 as base pins).
However, I do plan to keep any video signals on Port A, so I don't think there's any need to change the pin group (which seems more like a moveable pin window, to me). However, at this point, I haven't even given a moment's thought to whether the "RDFAST ⇢ RGB ⇢ Pins/DACs" video modes (LUMA8, RGBI8, RGB8, RGB16 and RGB24) would work with my setup. Even if they do, I'll probably stick to using 1, 2, 4 or 8 bpp VGA. Too tired right now to think about that, though, as I just got out of the P2 Zoom meeting. Thanks again for your useful comments and great analysis.
Oh, thanks for moving the LUT color pallet code into the vertical blanking loop, Rayman, for possibly changing it on the fly all at once for a specific color. That may be quite desirable. And Clusso99, thanks for telling me about your RetroBlade2 thread. I plan to check that out after I get some rest. To you both, don't feel compelled to respond to this post (though please do if you want to), but I did want you to know that I both read and appreciated your comments.
As i said, it’s an easy fix. I just did the same to the vga in baggers spaceinvaders. There’s about 4 lines to be changed. The 4 pins HS, B, G, R are the 4 sequential pins. VS can actually be any pin - i have used base-1 if on a 4 pin boundary else base + 4 if on an 8 boundary.
Good to know, Cluso. Thanks! Yes, I'm using vsync on pinbase-1 as well, and there's no problem with vsync, as it's handled separately (not by a DAC channel). I checked it with a scope the other day, and it was sitting at just under 59.94 Hz. I recall that rogloh once mentioned the possibility of putting vsync right below hsync and I liked that (keeping the sync signals physically adjacent, though mostly just for aesthetics and routing), so that's what I did. But vsync can be anywhere (on any pin). In fact, when I used the scope to check for the presence of hsync on various base pins, I often kept vsync at the same place for convenience, and naturally the DAC channels were none the wiser (didn't care). So maybe I won't need a new board right away. Thanks for your additional feedback. --Jim
I've just added an example that shows how to use a USB mouse with the Parallax 7" HDMI LCD.
It just changes a single pixel to black at the cursor location (so hard to see!).
The USB driver is a slightly modified version of the @garryj code.
Modified to automatically update cursor location in the main cog.
Note: This USB code has also been modified to return the keyboard scan codes (for gaming purposes).
But, you would normally get keyboard input using the functions in the original code.
When these bitmap based examples start up, it takes about 4 seconds before the bitmap display appears. Since the bitmap file is preloaded into the binary file, is it the binary that is taking so long to load? Or is the initialization process of the HDMI code (or VGA for those examples) taking that amount of time?
I see that too... I think it's the time it takes the electronics on the back of the display to recognize the HDMI input. Seems to take about 3 seconds...
HDMI is notoriously slow at detecting inputs... Even slower if the pointless copy protection feature is enabled, can take some 10 seconds to handshake that nonsense.
Comments
But, it was put inside the loop so the palette could be changed dynamically by other cogs...
Couldn't see from the code which pins had hsinc, vsync, r, g, b.
I see the base pin setting but not the order of the pins.
Dave
hsync=basepin
blue=basepin+1
green=basepin+2
red=basepin+3
vsync=basepin+4
Doesn't have to be that way though. VSync can be on any pin.
hsync and RGB have to be together though with basepin on a multiple of 4.
https://www.parallax.com/product/7-hdmi-display-800-x-480/
Thank you...thank you!
I’ve got some time this weekend to play around with these. Should be fun!
I was playing around with some of the settings and have two questions.
If I use a different bmp file, how can I determine where the color mapping address starts?
Also, on this line of code: rdfast ##800*480,PB, if I change the value to just ##800 (and not multiply by 480) I thought I would just get the first line of the bmp redrawn over and over, but it appears that I get the first 64 lines of the bmp file drawn before it repeats, why is that?
As I recall there is a pointer to it in the header, but usually there's no metadata in these, so it's always the same.
The first rdfast parameter is how many longs/words/bytes to read before it starts reading from the beginning again.
[1] First, thanks to Rayman for taking the initiative to update these video drivers again to generalize them to work in any cog (though I've only played with the VGA (640x480) one at this point).
[2] Next, for VGA_Simple1a, when I ran this on the Edge Breadboard, I noticed that it apparently only works for basepins 0, 8, 16 and 24 on Port A (the situation is bascially the same on Port B, but let's ignore that). That is, it doesn't seem to work when using basepins 4, 12, 20 and 28.
The VGA adapter that Parallax offers is hardwired for use with basepins 0, 8, 16 or 24, not the second group of basepins mentioned above. So, that would make it harder for one to notice this situation (assuming that it's not something specific to my setup).
But I made a board to test things when using basepins 4, 12, 20 and 28 and it didn't produce any output on the screen (the screen reported no signal present). Then, switching to the Edge Breadboard, I used an oscilloscope to check the hsync pins for both groups of pins and only saw a +31KHz hsync signal on pins P0, P8, P16 and P24 when using basepins 0, 8, 16 and 24, respectively. But no such signal was present on P4, P12, P20 and P28 when using basepins 4, 12, 20 and 28, respectively.
Looking at the code, I wasn't sure about the five lines that add in "basepin<<17" to m_bs, m_sn, m_bv, m_vi and m_rf. I was worried that those were "clobbering" some of the bits that configure the streamer. So I removed the "basepin<<17" part. Then I was able to see video (the bird image) and the +31KHz hsync signal for any of the eight possible basepins for Port A. But I don't know if that is the right way to address the problem. Need to investigate further.
[3] Last, when I do see an image on the little monitor that I'm using, no matter with or without the "basepins<<17" part, the image is steady and colored correctly, but it appears that the first 24 lines or so of the image (compared to the image when viewed in MS Paint) are being skipped, which leaves the last 24 lines of the screen black. I haven't investigated this yet, but I have seen the whole screen being used (all 480 lines of it) with another spin2 program. So I'm not sure what's up with that, but it's of less concern to me at present than item [2] above.
Anyway, I just got my Edge two weeks ago (sadly, my Eval board was lost about a year ago during a move), so I've just started playing again. I wish I could say "that it's all coming back to me now" but I never actually had it back then ("it" being a sufficient understanding of the P2). "Starting all over again is going to be rough," but it will also be fun. Apologies for the song references.
The standard VGA has been written to run with bases of 0,8,16,24 etc (ie banks of 8) where VS is the 5th pin. I modified it to run with banks of 4 and moving the VS to the pin just prior to the bank of 4. There is a link to this thread in my RetroBlade2 what now thread.
I believe the <<17 part sets the %ppp bits in the streamer command like this from the manual:
In every mode, the three %ppp bits in D[22:20] select the pin group, in 8-pin increments, which will be used as outputs or inputs, for up to 32-pin transfers. The selection wraps around:
%ppp : 000 = select pins 31..0
001 = select pins 39..8
010 = select pins 47..16
011 = select pins 55..24
100 = select pins 63..32
101 = select pins 7..0, 63..40
110 = select pins 15..0, 63..48
111 = select pins 23..0, 63..56
For modes which involve less than 8 pins, lower-order %p bit(s) in D[19:19..17] are used to further resolve the pin number(s).
So, if you don't do it, I guess maybe it could work on pins 31..0.
As for the left part of the screen being missing, maybe see if the monitor has an "Auto-Adjust" feature. Or, turn it off and then back on...
Looks like basepin=4 should have worked as is because that would have just set you in 8-bit LUT mode, which is the correct mode for this example: 0111 dddd eppp 1000
These ppp bits are a little strange for this mode, because we are only using 4 pins... These are designed for flexibility with modes that use up to 32 pins.
In this particular case, it looks like we could either set the ppp bits to 000 if using pins 0..31 or 100 if using pins 32..63.
Ray,
Not sure if you realise, or used Chip's code as a base, but he has a mask to enforce 8bit base alignment.
Hi, guys. Thanks for your comments. Sorry for the late reply. I still need to digest things and do some more testing, but prompted by your feedback and guidance, I investigated further and believe that using addition to bring in "basepin<<17" appears to conflict with using base pins with 4 = %100 in the binary: 4, 12, 20 and 28. I don't see a code tag option yet with the new forum software (nor a preview mode), so I don't know how to show a fixed-width font (I quickly tried adding code tags and pre tags, in square and angle brackets, respectively, around my text, but to no avail). So I took a screen shot of the text that I wanted to show. In the screen shot, the two notes in the captured text describe where things appear to conflict for specifically using pin 4 as a base pin for 8bpp VGA. I expressed everything in binary to make the inspection more direct. The screen shot text refers to the following code snippet from the VGA driver:
'Fix assembly for this basepin
m_bs := $7F010000 + basepin2<<17 + 16 'before sync
m_sn := $7F010000 + basepin2<<17 + 96 'sync
m_bv := $7F010000 + basepin2<<17 + 48 'before visible
m_vi := $7F010000 + basepin2<<17 + 640 'visible
m_rf := $7F080000 + basepin2<<17 + 640 'visible rfbyte 8bpp LUT->DAC
There's more that I could say about the matter, as I don't understand some things in the documentation, but this will have to suffice for now. And as for the screen shift, it's in the vertical direction, not horizontal. But that's one of the things that I still want to investigate. I'll update you here if I resolve that matter (and as I mentioned, an earlier driver from a year ago or so fills the screen just fine, so hopefully there's a way to make it do so for the current VGA code (though I seem to recall that the sync timing is the same)).
By the way, in my case, I want to stick to using a VGA driver (with its 5 pins), so it's possible that a "standard" might not apply in my particular situation. There won't be any need for testing/using HDMI or other types of video signaling for the particular board that I have in mind. And I already had a PCB made to do some initial testing. But I may redesign the board to make it use a different base pin arrangement if there's a good reason to do so (that is, not use pins 4, 12, 20 or 28 as base pins).
However, I do plan to keep any video signals on Port A, so I don't think there's any need to change the pin group (which seems more like a moveable pin window, to me). However, at this point, I haven't even given a moment's thought to whether the "RDFAST ⇢ RGB ⇢ Pins/DACs" video modes (LUMA8, RGBI8, RGB8, RGB16 and RGB24) would work with my setup. Even if they do, I'll probably stick to using 1, 2, 4 or 8 bpp VGA. Too tired right now to think about that, though, as I just got out of the P2 Zoom meeting. Thanks again for your useful comments and great analysis.
Oh, thanks for moving the LUT color pallet code into the vertical blanking loop, Rayman, for possibly changing it on the fly all at once for a specific color. That may be quite desirable. And Clusso99, thanks for telling me about your RetroBlade2 thread. I plan to check that out after I get some rest. To you both, don't feel compelled to respond to this post (though please do if you want to), but I did want you to know that I both read and appreciated your comments.
@JRetSapDoog
As i said, it’s an easy fix. I just did the same to the vga in baggers spaceinvaders. There’s about 4 lines to be changed. The 4 pins HS, B, G, R are the 4 sequential pins. VS can actually be any pin - i have used base-1 if on a 4 pin boundary else base + 4 if on an 8 boundary.
Good to know, Cluso. Thanks! Yes, I'm using vsync on pinbase-1 as well, and there's no problem with vsync, as it's handled separately (not by a DAC channel). I checked it with a scope the other day, and it was sitting at just under 59.94 Hz. I recall that rogloh once mentioned the possibility of putting vsync right below hsync and I liked that (keeping the sync signals physically adjacent, though mostly just for aesthetics and routing), so that's what I did. But vsync can be anywhere (on any pin). In fact, when I used the scope to check for the presence of hsync on various base pins, I often kept vsync at the same place for convenience, and naturally the DAC channels were none the wiser (didn't care). So maybe I won't need a new board right away. Thanks for your additional feedback. --Jim
I've just added an example that shows how to use a USB mouse with the Parallax 7" HDMI LCD.
It just changes a single pixel to black at the cursor location (so hard to see!).
The USB driver is a slightly modified version of the @garryj code.
Modified to automatically update cursor location in the main cog.
Note: This USB code has also been modified to return the keyboard scan codes (for gaming purposes).
But, you would normally get keyboard input using the functions in the original code.
Ray,
When these bitmap based examples start up, it takes about 4 seconds before the bitmap display appears. Since the bitmap file is preloaded into the binary file, is it the binary that is taking so long to load? Or is the initialization process of the HDMI code (or VGA for those examples) taking that amount of time?
Just curious...
dgately
I see that too... I think it's the time it takes the electronics on the back of the display to recognize the HDMI input. Seems to take about 3 seconds...
HDMI is notoriously slow at detecting inputs... Even slower if the pointless copy protection feature is enabled, can take some 10 seconds to handshake that nonsense.