Hi, David. I've been outside all day long but am headed home shortly, and I'll load up your file on a console after I get home and report back. However, if that 4th screen is shifted, the it sounds like the driver for it didn't start it fasr enough. I'm on my phone now, but if you haven't tried already, try starting it first or by itself. And are you partly using C language?
Yes, I'm using C although that should actually be faster than Spin. Is it possible that it can start up too fast? In any case, my biggest problem is that the colors are wrong on that display. Most of the time it comes up without any shifting. I'm more concerned about the colors than the shift at this point.
Just got home and loaded up the binary. I'm just seeing a black screen with the words "Monstra! Press start" in yellow towards the lower-left and "P M" in the middle. It's hard to tell if the screen is shifted since the background is black. What color should the background be? Also, the keyboard for that east side initializes fine, but when I press 's' or 'S' nothing happens. I know it's just a test, but is anything supposed to happen?
As for whether it could start up too fast, I don' t know. Maybe. I'd say it's a possibility. Maybe put a short delay before calling the initialization code. And if that doesn't change anything, put a very small delay in the loop to initialize the screens, if you're using a loop. Maybe you're just firing up one screen, the other ones all appear blue. I'm not sure if the other screens are blue because of the driver boards or your program, but my guess is that your program is driving them blue, as they appear to start up pretty normally. Anyway, the video driver is pure PASM and I believe that it needs those instances created pretty fast. But I suppose there's a slight possibility that they could be being created too fast, but adding a small delay--even a dummy instruction or two if it doesn't get optimized out--should tell us that.
If the brightness on that east screen is way too high, perhaps it makes a black screen look like it's lit up dimly. But there are no dim colors available out of the eight colors. So maybe it is indeed a black background. It's certainly NOT red, green, blue, yellow, purple, aqua or white. It's black. It looks black and that's the only other possibility from the resistor DAC's. Now having said that, I can see a little variability in the deepness of the black due to the backlight not being perfectly even across the screen, and that's probably the case with your setup as well (though your brightness may be much higher than mine (or the contrast might be different).
Is it possible that you've overridden the color palette and have inadvertently told the system to use black? I don't know why you'd need to touch the palette. As I recall, I hard-corded the palette into kuroneko's video driver. I mean, there are only eight foreground and eight background colors, and you can't improve on that.
The key thing to check is what happens when you boot the console with the clock program, or perhaps one of my programs. How is that screen performing then? Disregarding black for the time being, how do the colors look? Maybe you answered that before, need to check. But obviously if that screen works for the clock program or another program, then it's not a problem with the screen or the console hardware, including the Propeller chip's I/O pins. By the way, the screens were new and unused when I built the console. They still had the screen protection film on them when I sent them to you (don't know if you removed it or not). But when I tested the screens, I just looked for the eight basic colors.
Unfortunately, I don't think I paid any attention to the brightness setting. If it's off, I didn't notice. But there is a slight possibility that I might have changed the brightness inadvertently when I went into the menu system to change the screen orientation setting. Using those menus with just three or four switches is a bit like trying to set the time on one's watch and it's possible that I changed a setting without knowing it. Or maybe the brightness was set wrongly by the factory.
Or maybe the reasons that the screens don't cost and arm-and-a-leg might be because they may not measure up in some way. I've never read that or been told that by the vendor, but I do wonder. There might be two or three tiers of quality. They certainly were boxed and protected well when I received them and looked to be in pristine condition, but I did get one that had an obvious problem that QC should have found. And I have another one that has a bit of a hot/bright area when the screen is black, wherein the backlight seems to come through more than it should. Rather than risking alienating my supplier, I ate the cost of that, as well as the cost of a couple bad keyboards. Dealing with China vendors is kind of a black box for me, and I don't know what kind of quality I'm getting.
Anyway, if the brightness is too high and if it can be addressed, then it's going to take opening up the console and using a keypad and cable to adjust it. Same goes for any other settings. For example, I forget if there's a saturation setting, but probably.
If you're seeing yellow text on a black background then maybe this is a software problem on my end. All four screens should have a blue background and screen 3 should have white text. It sounds like you're seeing the same thing that I see which indicates that it isn't a hardware problem. Thanks for testing this.
As far as the keyboard goes, I only switched the video to screen 3. I'm still using keyboard 0. If you press keys on that keyboard the game should run. I just switched the screen as a quick test.
Ah, if screen 3 should have white text on blue, then, yeah, sounds like a palette problem (and sorry about the screen brightness confusing things).
And, yes, I have keyboard control when plugged into the north/0 side. I see that the walls use O's now. Sorry, I should have tried plugging in on the north side, but I was in a hurry to get back to you, having been outside for most of the day. Anyway, the reason I asked was that I wanted to make sure that the main program hadn't gone off to la-la land (even though the video and keyboard drivers were still chugging along).
So, again, you seem to have a palette mix-up in terms of the color assignments. And as far as that occasional shifting for screen three, if anything, it sounds like that screen is initializing too slowly rather than too quickly, as that could cause the shifting. If there's any way to speed up that initialization code, I'd do so. If an unrolled loop is faster than a loop--even a little--then consider trying that. Of course, you could always change the start-up order from 0..3 to 3..0 and move the problem to the north screen, just for fun.
I looked at my code and I'm pretty sure I understand what is causing the shift. I put a "clear screen" call in the loop that starts the VGA COGs. That probably slowed things down enough to cause the problem. I'll try it again tonight after fixing this problem. I don't suppose this could also have caused the color issue?
Guess we'll find out. At first glance, it seemed unlikely, but you're probably using the same palette for each screen, and I don't know what else could cause that palette to fail or be different, so maybe. Would be nice to kill two birds with one stone. Fingers crossed. But even if not, having resolved one problem will decrease conflation and make it easier to solve the other one.
As predicted, my modification to eliminate the display shifting didn't help with the color issues on screen 3. I'm not sure what to do next. All four screens use the same palette so it seems like they should all have the same problem.
Too bad. So you're "Don't suppose..." pessimism was right; I had no real idea what would happen. Yeah, weird result considering that you're using the same palette. But you know how it is with coding: there's always a reason waiting to be found (assuming no hardware bugs). Did you try reversing the driver instantiation order from 3..0 (instead of 0..3) to see if it made any difference in moving the problem to another screen? If it doesn't, then it provides more evidence that the problem is not related to starting up the screens, and you can focus more on your code.
Guess there's little chance that you used a '4' somewhere for the east screen when it should have been a '3,' as you probably use a variable or loop to generate the identifier for the specific screen. Somewhat conversely, make sure any modulo code is correct (guess it'd be modulo 4 that was called for and not modulo 3). It's possible that the screen brightness issue and the startup concerns ate up your debugging time and prevented you from looking elsewhere. Anyway, the east screen=3 is a boundary case of sorts for screens 0..3, as is north=0. Normally, the mistake that happens is that one only writes to screen 0 instead of all four, so we always need to view screen 0 if there's a problem. And sometimes things get written so fast that one doesn't see that everything's being written to the same screen, or situations like that (putting in delays can help one see what's going on there). By the way, I'd try writing screen identifiers to those other three blue screens, just to confirm that they are working correctly. And maybe try outputting to screen 3 the input parameters for whatever output method(s) you're using. *EDIT* I made some changes to this post a couple minutes after posting.
So I'd guess that it is in your C code somewhere. I made some changes to my last post with some possible things to check. If I think of anything else (more shots in the dark, perhaps), I'll let you know. Hope you figure out what's going on.
This means that my software screen 3 actually writes to the hardware screen 1. I think that proves that it isn't anything related to the numbers I'm using in my code since the dark screen doesn't move when I swap the screen pin groups.
The code that is specific to the WordFire/Quby console is in main.c and quadvga.c. The video driver (quadvga.spin) is pretty much unmodified from the one that Marko Lukat wrote. My only real change was to add the palette from JRetSapDoog's code. I hope it was okay to use the palette.
Haven't looked at C code in ages but took a quick look; haven't found anything yet. But couldn't you write a minimal C program that *only* lights up each screen in blue and outputs the screen identifier on it in white. In other words, eliminate as much of the game logic code as possible. Anyway, I'd say the area to focus on--even with your game logic--is in the routine to clear the screen to a background color (such as blue). I didn't see anything wrong on quick inspection but will try to revisit that code. But if the problem is not in the C code, then where? I've asked before, but can you confirm that the clock program is outputting correctly on screen three. I assume it is, or you would have noticed months ago, but just checking.
I always use "++i" instead of "i++" because I think it reads better. I read it as "increment i". I would think "i++" would be read "i increment" which doesn't make much sense to me. In any case, they are equivalent when used in this way. The "->" operator accesses the field of a structure.
Since you're online right now, I might as well ask: How does the sound work? Is it just sending DUTY counter output to pin 21 or is there anything special that needs to be done?
Yes, the loop should be fine. I use this type of loop all the time. Anyway, thanks for taking a look at the code. It isn't very complicated but I'm sure there is a dumb error somewhere.
On another note (pun intended), do you have any sample code for generating audio?
Nice pun. The sample games just use simple beeps or ticks, but I guess that's enough. The setup screens of some of the sample games allow one to control the sound volume from zero to deafening. For example, the CopyCats screen allows one to set the volume with the 'L' and 'H' keys, and each time you press a key, the speaker beeps (and the level indicator changes correspondingly). That code should be in the doSetup method.
I removed the comment for the frqa line, as I'm not sure if it's correct, but it said: "'Vout = 3.3 * (frqa/2^32) = 3.3 * 0.5 = 1.65V max when frqa = $8000_0000". I seem to recall that the calculation didn't seem quite right. Close maybe, but off a bit. Anyway, not sure at this point.
In addition to the DIRA's for sound and volume, in the main initialization method for the console system, there's:
'set speaker volume
ctra := %00110_000 << 23 + 1 << 9 + VOL 'counter mode = duty cycle for d/a using rc circuit (B pin is unused)
frqa := $2000_0000 'Vout = 3.3 * (frqa/2^32) = 3.3 * 0.5 = 1.65V max when frqa = $8000_0000 (can omit this line)
Hmm...guess you've got that. Well, to be honest, I don't know if the filter I used to get the sound into the TDA7052A is correct or compatible with your method of sound generation. Hopefully, but maybe not. It'd be good to find out. I've never tried any sound objects with Quby, just simple clicks/beeps. Anyway, make sure you can generate loud beeps first.
Well, I see in the other thread that you resolved the sound problem, though it doesn't sound nearly as good as the .mp3 you listened to. As to why, perhaps it's my choice of components and their values for the input filter in combination with the small speaker and it being mono. I'm open to suggestions on the component types and values.
As for the color problem with screen 3 for your Monsta game code, I still have no idea. I looked at your C code for a while, but nothing stood out. While this code is easy for you, it's kind of a big lift for me, not having touched C code for nearly a couple decades. I do see that you still have more code in the loop to configure the video pins than the corresponding spin code, but like you say, it's faster C code. Also, I know that you tried swapping screens 2 and 3 (south and east) and the color problem still persisted on screen 3; however, if it were me, I might still try using something like for (i = 3; i >= 0; --i) when configuring the video pins just to confirm that there's no difference (assuming that the loop index i is signed, I mean).
Well, I see in the other thread that you resolved the sound problem, though it doesn't sound nearly as good as the .mp3 you listened to. As to why, perhaps it's my choice of components and their values for the input filter in combination with the small speaker and it being mono. I'm open to suggestions on the component types and values.
As for the color problem with screen 3 for your Monsta game code, I still have no idea. I looked at your C code for a while, but nothing stood out. While this code is easy for you, it's kind of a big lift for me, not having touched C code for nearly a couple decades. I do see that you still have more code in the loop to configure the video pins than the corresponding spin code, but like you say, it's faster C code. Also, I know that you tried swapping screens 2 and 3 (south and east) and the color problem still persisted on screen 3; however, if it were me, I might still try using something like for (i = 3; i >= 0; --i) when configuring the video pins just to confirm that there's no difference (assuming that the loop index i is signed, I mean).
I tried doing it backwards but that didn't work since you really need to start screen 0 first since it does the sync signals. I took everything out of the loop that I could. It seems to me that it is equivalent to the Spin code now. What do you see that I have that is extra?
Yeah, that's right, at least if you want them synchronized, meaning not shifted. Wonder if you got something on screen, though, even if it was shifted. And if you did, I wonder what colors screen 3 was displaying. Now as for what I thought might be extra, I think I was wrong. So, the mystery goes on. Pardon my being in the C fog about this conversion from Spin, but is everything in the FOR loop immediately above the one you just tried changing appropriately located? Is there anything in there that should happen after the other FOR loop? And even if not, you might try moving whatever can be moved to after the other loop just as a shot in the dark, as you might stumble on to something in the process. But I'm probably just wasting your time. I don't have any other ideas for now.
Pardon my being in the C fog about this conversion from Spin, but is everything in the FOR loop immediately above the one you just tried changing appropriately located?
I tried to put everything that might take a lot of time in the earlier loop. All it really does is setup the driver initialization structures and clear the frame buffers. That should all be safe to do before starting the COGs. I'll have to keep staring at it. I'm sure once I figure it out it will be obvious. It just isn't right now. Thanks for trying to help.
Right, that's how it generally works. Maybe try staring at it while standing on your head. Or try focusing on three random things and seeing if that triggers anything.
Comments
As for whether it could start up too fast, I don' t know. Maybe. I'd say it's a possibility. Maybe put a short delay before calling the initialization code. And if that doesn't change anything, put a very small delay in the loop to initialize the screens, if you're using a loop. Maybe you're just firing up one screen, the other ones all appear blue. I'm not sure if the other screens are blue because of the driver boards or your program, but my guess is that your program is driving them blue, as they appear to start up pretty normally. Anyway, the video driver is pure PASM and I believe that it needs those instances created pretty fast. But I suppose there's a slight possibility that they could be being created too fast, but adding a small delay--even a dummy instruction or two if it doesn't get optimized out--should tell us that.
If the brightness on that east screen is way too high, perhaps it makes a black screen look like it's lit up dimly. But there are no dim colors available out of the eight colors. So maybe it is indeed a black background. It's certainly NOT red, green, blue, yellow, purple, aqua or white. It's black. It looks black and that's the only other possibility from the resistor DAC's. Now having said that, I can see a little variability in the deepness of the black due to the backlight not being perfectly even across the screen, and that's probably the case with your setup as well (though your brightness may be much higher than mine (or the contrast might be different).
Is it possible that you've overridden the color palette and have inadvertently told the system to use black? I don't know why you'd need to touch the palette. As I recall, I hard-corded the palette into kuroneko's video driver. I mean, there are only eight foreground and eight background colors, and you can't improve on that.
The key thing to check is what happens when you boot the console with the clock program, or perhaps one of my programs. How is that screen performing then? Disregarding black for the time being, how do the colors look? Maybe you answered that before, need to check. But obviously if that screen works for the clock program or another program, then it's not a problem with the screen or the console hardware, including the Propeller chip's I/O pins. By the way, the screens were new and unused when I built the console. They still had the screen protection film on them when I sent them to you (don't know if you removed it or not). But when I tested the screens, I just looked for the eight basic colors.
Unfortunately, I don't think I paid any attention to the brightness setting. If it's off, I didn't notice. But there is a slight possibility that I might have changed the brightness inadvertently when I went into the menu system to change the screen orientation setting. Using those menus with just three or four switches is a bit like trying to set the time on one's watch and it's possible that I changed a setting without knowing it. Or maybe the brightness was set wrongly by the factory.
Or maybe the reasons that the screens don't cost and arm-and-a-leg might be because they may not measure up in some way. I've never read that or been told that by the vendor, but I do wonder. There might be two or three tiers of quality. They certainly were boxed and protected well when I received them and looked to be in pristine condition, but I did get one that had an obvious problem that QC should have found. And I have another one that has a bit of a hot/bright area when the screen is black, wherein the backlight seems to come through more than it should. Rather than risking alienating my supplier, I ate the cost of that, as well as the cost of a couple bad keyboards. Dealing with China vendors is kind of a black box for me, and I don't know what kind of quality I'm getting.
Anyway, if the brightness is too high and if it can be addressed, then it's going to take opening up the console and using a keypad and cable to adjust it. Same goes for any other settings. For example, I forget if there's a saturation setting, but probably.
As far as the keyboard goes, I only switched the video to screen 3. I'm still using keyboard 0. If you press keys on that keyboard the game should run. I just switched the screen as a quick test.
And, yes, I have keyboard control when plugged into the north/0 side. I see that the walls use O's now. Sorry, I should have tried plugging in on the north side, but I was in a hurry to get back to you, having been outside for most of the day. Anyway, the reason I asked was that I wanted to make sure that the main program hadn't gone off to la-la land (even though the video and keyboard drivers were still chugging along).
So, again, you seem to have a palette mix-up in terms of the color assignments. And as far as that occasional shifting for screen three, if anything, it sounds like that screen is initializing too slowly rather than too quickly, as that could cause the shifting. If there's any way to speed up that initialization code, I'd do so. If an unrolled loop is faster than a loop--even a little--then consider trying that. Of course, you could always change the start-up order from 0..3 to 3..0 and move the problem to the north screen, just for fun.
Guess there's little chance that you used a '4' somewhere for the east screen when it should have been a '3,' as you probably use a variable or loop to generate the identifier for the specific screen. Somewhat conversely, make sure any modulo code is correct (guess it'd be modulo 4 that was called for and not modulo 3). It's possible that the screen brightness issue and the startup concerns ate up your debugging time and prevented you from looking elsewhere. Anyway, the east screen=3 is a boundary case of sorts for screens 0..3, as is north=0. Normally, the mistake that happens is that one only writes to screen 0 instead of all four, so we always need to view screen 0 if there's a problem. And sometimes things get written so fast that one doesn't see that everything's being written to the same screen, or situations like that (putting in delays can help one see what's going on there). By the way, I'd try writing screen identifiers to those other three blue screens, just to confirm that they are working correctly. And maybe try outputting to screen 3 the input parameters for whatever output method(s) you're using. *EDIT* I made some changes to this post a couple minutes after posting.
static uint32_t vconfig[] = { (0 << 9) | 0x4f, // with sync %010011_11 (1 << 9) | 0x4c, // no sync %010011_00 (2 << 9) | 0x4c, // no sync %010011_00 (3 << 9) | 0x4c // no sync %010011_00 };to this:static uint32_t vconfig[] = { (0 << 9) | 0x4f, // with sync %010011_11 (3 << 9) | 0x4c, // no sync %010011_00 (2 << 9) | 0x4c, // no sync %010011_00 (1 << 9) | 0x4c // no sync %010011_00 };This means that my software screen 3 actually writes to the hardware screen 1. I think that proves that it isn't anything related to the numbers I'm using in my code since the dark screen doesn't move when I swap the screen pin groups.https://github.com/dbetz/monsta
The code that is specific to the WordFire/Quby console is in main.c and quadvga.c. The video driver (quadvga.spin) is pretty much unmodified from the one that Marko Lukat wrote. My only real change was to add the palette from JRetSapDoog's code. I hope it was okay to use the palette.
On another note (pun intended), do you have any sample code for generating audio?
volume := volume + 1 <# 20 frqa := (volume+1) * $0300_0000 beep(25, 1000)I removed the comment for the frqa line, as I'm not sure if it's correct, but it said: "'Vout = 3.3 * (frqa/2^32) = 3.3 * 0.5 = 1.65V max when frqa = $8000_0000". I seem to recall that the calculation didn't seem quite right. Close maybe, but off a bit. Anyway, not sure at this point.
Anyways, here the code we're trying to get going is attached and discussed here: https://forums.parallax.com/discussion/comment/1451332/#Comment_1451332
Yes, it works fine with the clock program. Must be my bug but I can't find it.
In addition to the DIRA's for sound and volume, in the main initialization method for the console system, there's:
Hmm...guess you've got that. Well, to be honest, I don't know if the filter I used to get the sound into the TDA7052A is correct or compatible with your method of sound generation. Hopefully, but maybe not. It'd be good to find out. I've never tried any sound objects with Quby, just simple clicks/beeps. Anyway, make sure you can generate loud beeps first.
As for the color problem with screen 3 for your Monsta game code, I still have no idea. I looked at your C code for a while, but nothing stood out. While this code is easy for you, it's kind of a big lift for me, not having touched C code for nearly a couple decades. I do see that you still have more code in the loop to configure the video pins than the corresponding spin code, but like you say, it's faster C code. Also, I know that you tried swapping screens 2 and 3 (south and east) and the color problem still persisted on screen 3; however, if it were me, I might still try using something like for (i = 3; i >= 0; --i) when configuring the video pins just to confirm that there's no difference (assuming that the loop index i is signed, I mean).