I'm open to suggestions on the component types and values.
You said you used 104 (== 0.1 uF) capacitors both to ground (=lowpass) and to the amp (=highpass/AC-coupling). For the former, that value is a little high and for the latter, that value is too low. If you're using one of the larger capacitor packages, you can get different values that fit onto the same spot on the PCB. However, they're somewhat more expensive: The ceramic decoupling caps cost almost nothing, 47uF SMD tantalum caps are ~50 cent.
To wuerful_21: Thanks! So, for the cap to ground, maybe I can go with a 103, then. And for the AC coupling one, I'll see what's available locally to experiment with. Although the power filtering cap is an electrolytic through-hole cap (220uF), the two bandpass caps are 1206 SMD devices. Guess I might need to increase the value of the resistor (depending on what caps I use). Presently, with the exception of some 10K resistors (mostly pull-ups), everything is 180R to keep the number of part types down on the so-called BOM (not that it matters). But I can make an exception for that audio bandpass resistor if it might help output better sound. Again, thanks for the tips. Feel free to keep those cards and letters coming.
If you want to keep the BOM low and changing the PCB slightly isn't an issue, you could put 3 180 Ohm resistors in parallel and keep the 104 to ground. That'd come out to a cutoff of ~27 kHz.
That's 1/(2Pi*60*0.1uF) for 26.5KHz, huh? Well, keeping the BOM low was mostly just me being lazy, so rather than squeeze in additional components, I'd gladly change the values. Maybe I could swap the 180R for a 560R and use a 10nF cap to ground for a 28.4KHz 3dB cutoff. Guess that'd be a nice improvement over the current cutoff of around 8.8KHz.
I'm beginning to think that the reason I'm having trouble with screen 3 is that it shares a pin with the serial interface on 30/31 that I am using for debug I/O. The reason your clock program doesn't have this problem is that it doesn't do serial I/O.
Yes, @"David Betz" I did also stumbled about that. Somewhere in the wordfire thread I was discussing this with @JRetSapDoog.
Sadly there is no solution since the video driver needs pins in a certain order.
The only other available pin is the pin 25(?) used for the IR-decoder and one will need to modify the console with some switches to use 30/31 for booting on the propplug-connector and then later 31/25(?) for a two way serial connection.
The same goes for the Quby console.
The needed change are two switches to allow pin 30 to be connected to usb or not and to connect pin 25(?) to either usb or ir. When at it one could also add a external reset switch.
But these are some simple modifications even I would be able to do, even if I am really bad at soldering.
I'm beginning to think that the reason I'm having trouble with screen 3 is that it shares a pin with the serial interface on 30/31 that I am using for debug I/O.
That sure would be pin usage contention (I've always debugged using the screens themselves or the speaker). Also, your C code seems so well organized that it's hard to see what else could be causing the problem with Screen 3.
Sadly there is no solution since the video driver needs pins in a certain order.
Sorry about that. To avoid using P30 for the blue channel, in a new hardware design, perhaps the RGB signals could be moved to the first three pins of each of the four pin groups (i.e., 0, 1 and 2) from their current positions of 2,3 and 6. As far as I know, the video sub-system with its serializer doesn't care how the pins are used. But if modifying the video driver to do that is possible, it might be above my head. Also, currently, I'm spending my free time on other aspects of the project. I guess I could see what kind of deal kuroneko would give me to do the job (he's been quite flexible/reasonable/fair in our past dealings). But I don't know if it makes sense to do yet another version of the console considering the current limited interest. Besides, debugging for most games can be done in other ways on the current consoles. But if starting over from scratch, I'd certainly give consideration to the way that you programmers prefer to use the console.
To David, have you been able to confirm your suspicion yet? I mean, have you tried running things without your debugging link to see if the colors are correct? By the way, I don't have any problem color-wise for Screen 3 due to keeping the PropPlug plugged in for uploading to hub RAM or the EEPROM, but I'm not using it for debugging.
To David, have you been able to confirm your suspicion yet? I mean, have you tried running things without your debugging link to see if the colors are correct?
Yes. It works fine if I don't try to use 30/31 for debugging output.
Great! Then there's no more need to pour over the C code to look for what's not there. Good job on figuring it out. Sorry about the pin usage hampering debugging. But actually, I guess that you can continue to use your debugging link and just ignore the colors on Screen 3 (though poor fg/bg color contrast will likely make it difficult or impossible to view the text on that screen). In actual game play or play testing, you hopefully won't need that kind of debugging link. In fact, I would guess that you won't need console debugging as much in the future anyway now that you've got a working game framework in C. Of course, some debugging will still be needed as you add features to a game, but perhaps you can get by will using one or more of the screens for that (as well as the speaker). And you can always go without Screen 3 temporarily. Anyway, I'm glad that you figured it out.
Now that I got past my dim screen issue I spent a little time to make use of custom characters for game tiles. Here is a minor update that uses a mostly solid block for maze walls. To do this I wrote a simple program that reads an ASCII file containing tile definitions and converts them to the funny format required by the tile driver. As usual, the code is all in GitHub.
Ah, solid walls! Cool! A night-and-day difference, in my opinion. The walls made of text characters--even the letter O--didn't cut it for me. But the new walls are super. I like what you've done with the place. And your redefined font character is great, and it's quite a bit better than a totally solid block would be.
I don't know if you need that text line. You might be able to make the maze larger and use an overlay panel for any text messages. Frankly, I don't know what those numbers mean. They seem confusing and distracting; though I just thought about them for a few seconds or times. They look like counts of some sort; perhaps they are debugging counts.
Also, I'd get at least a third color on the screen, too. Perhaps the things in the maze could be colored differently than the walls. And of course the text messages, if you really need them, could be in a different color. To have any text or information, one needs a minimum of two colors, like binary. But monochrome can be a bit boring, so a third color would spice things up. Yellow text or green text would work well on the blue background, for example.
Regarding the easy mode, I wasn't sure how to get out of it once I activated it. I think I tried pressing the same letter and then starting a new game. But it doesn't matter, as I was able to reload to get the monster back. By the way, is the only difference between the beginner mode and the normal mode the lack of the monster?
I got what appeared to be a garbage screen at one point. It had mostly '@' signs, a few M's and a few other symbols laid out in a grid with no wall characters. I took a picture if you want it. I think it happened after starting a new game just after deliberately running into a bomb I had dropped. But I tried doing that again and it didn't happen again.
I'm curious about one thing: Why does the player move two spaces in any direction upon pressing an arrow key? I realize that it speeds up play a bit, but it seems really counter-intuitive to me (though it's the only way I've played the game). I think I'd like to try a version where the player only moved one space at a time.
Anyway, the walls are great. They make all the difference. Thanks for posting.
I don't know if you need that text line. You might be able to make the maze larger and use an overlay panel for any text messages. Frankly, I don't know what those numbers mean. They seem confusing and distracting; though I just thought about them for a few seconds or times. They look like counts of some sort; perhaps they are debugging counts.
The numbers on the text line indicate how many of each object exist in the game and how many have been discovered. And, in the case of clubs and bombs, how many the play has left to use. However, I think you're right about the status line taking up too much space. Maybe I could overlay the bottom border of the maze with reverse video text. That way the maze could be bigger.
Also, I'd get at least a third color on the screen, too. Perhaps the things in the maze could be colored differently than the walls. And of course the text messages, if you really need them, could be in a different color. To have any text or information, one needs a minimum of two colors, like binary. But monochrome can be a bit boring, so a third color would spice things up. Yellow text or green text would work well on the blue background, for example.
You're probably right about that. I'll think about how I can use different colors more effectively.
Regarding the easy mode, I wasn't sure how to get out of it once I activated it. I think I tried pressing the same letter and then starting a new game. But it doesn't matter, as I was able to reload to get the monster back. By the way, is the only difference between the beginner mode and the normal mode the lack of the monster?
I'm not sure the beginners mode is working correctly. The difference is supposed to be that the player starts out with some clubs and bombs in his/her possession. Otherwise, the player doesn't have any until he/she discovers them in the maze.
I got what appeared to be a garbage screen at one point. It had mostly '@' signs, a few M's and a few other symbols laid out in a grid with no wall characters. I took a picture if you want it. I think it happened after starting a new game just after deliberately running into a bomb I had dropped. But I tried doing that again and it didn't happen again.
I got that too once or twice. I'm not sure what caused it. I'll have to look into it.
I'm curious about one thing: Why does the player move two spaces in any direction upon pressing an arrow key? I realize that it speeds up play a bit, but it seems really counter-intuitive to me (though it's the only way I've played the game). I think I'd like to try a version where the player only moved one space at a time.
My only explanation for the way the player moves is that is the way it was done in the original game that I copied. It does have one interesting feature though. The monster moves one space at a time so if it gets right next to the player, the player can jump over it in one move and escape.
Anyway, the walls are great. They make all the difference. Thanks for posting.
Thanks! I'll look into making icons for some of the other game features as well.
However, I think you're right about the status line taking up too much space. Maybe I could overlay the bottom border of the maze with reverse video text. That way the maze could be bigger.
Yeah, and maybe the outer maze walls could be on the screen borders, even though they are partially obscured by the screen bezels in your version of the console (or they could even be double wide around the edges). If done, the blue background would only be visible inside the maze. But I'm not completely sure if doing this would enhance the appearance (and it might detract). It could make the maze even bigger, though, which is probably a good thing. And as for reverse video, that could be done on the upper line of a doubly-thick wall at the bottom edge. Perhaps that'd be the only wall that with double thickness.
As for jumping over the monster, I didn't know that was possible. I guess it keeps one from being trapped in a corridor, but I figured avoiding being trapped was part of the game. Guess a club could be good in that situation. One could wield it to, for example, exchange places with the monster. Anyway, I think I still lean to moving one space at a time, as that may seem more intuitive and would kind of make the maze seem bigger.
Oh, I forgot to mention last time that I'd try to avoid making the user press capital letters as much as possible. For example, when "cheating," I think I'd use "w/W' to reveal the walls. Anyway, Monsta is really shaping up. I guess he's been working out.
I imagine that would take a lot of careful measurements followed by a lot of precise scoring with a knife, sixteen cuts in all. And you'd probably have to rig up some kind of insert to provide support while scoring. It might make more sense to make your own bezel cap. I've made a few out of cardboard stock and also plastic. It's a lot of work, though, with about two hours of laying out and cutting. Then the pieces need to be assembles somehow, such as via tape. I'm not recommending it, just saying.
By the way, there are only 15 rows, and you're losing about half of the first row and the last row with "your" bezel cap. The same applies to the first and last columns. And if I'm not mistaken, Monsta only uses 37 columns for the maze instead of 38. So, I think I'd use C38 (if your maze generation algorithm doesn't object) and add two more rows to your maze before I'd go butchering bezels. You could use inverse video solid squares for the middle portion only of the bottom wall of the maze to display any messages, as you've mentioned. That would allow you to keep a bit of blue border around the maze, which does look nice. Those two changes will expand the maze, which is already fairly big (even though not on an 80-column terminal). I like the way it looks: big but not too big. And if the player moves only one tile at a time, that may also make the maze feel bigger.
And if I'm not mistaken, Monsta only uses 37 columns for the maze instead of 38.
The maze generator requires both dimensions to be in the form 2n+1 so I can't use an even number of columns or rows. This is because each cell in the maze has a left wall and a right wall. That means that, for example, if you have a 5 character wide screen, the cells are laid out like this:
Wall - cell - wall - cell - wall
Hence the 2n+1 where n is 2 in this case. The same applies to the vertical dimensions.
Hence the reason I said "if your maze generation algorithm doesn't object" in parentheses. Anyhow, where there's a will, there's usually a way. For example, perhaps a column could be randomly inserted using the results of your current maze generator algorithm (moving everything over to the right one tile to make room for the column to be inserted). Then perhaps some rules could be used to determine whether each cell of the added column would be a wall character or a space, wherein the rules would have to be designed so as to avoid "breaking" the maze by creating closed areas (essential independent mazes) or ugly "quadrants" (2x2 matrices of all spaces or all wall characters).
For example, discounting the first and last rows that would use all wall characters, if a cell being added had spaces on both the left and right sides, then it should probably be a space to avoid blocking a potentially essential path. And if the new cell had wall characters on both sides, then it could probably be either a wall character or a space (since extra vertical paths don't hurt), though perhaps it could be randomly weighted towards being a wall character. But if the cell being added had a space on left side and a wall character on the right, or vice-versa, then I guess cells in the preceding row would have to be inspected to make sure one wasn't forming a "quadrant," which might be a little tricky, assuming it's possible.
Well, I haven't geometrically analyzed such column insertion to prove that it's always possible without creating "quadrants," but I'm guessing it is. And *if* one can always do it manually (which I don't know for sure), then it should be doable programmatically. Now, I'll admit that there are times that such a method might be visibly detectable as something being inserted. For example, a long vertical path would require alternating space and wall characters to be inserted. Anyway, even if inserting a column is feasible, it'd probably break the elegance of the maze generator (even though it would come afterwards or be a separate method), and you'd probably prefer to spend time on other aspects. But if something can be centered (the whole maze in this case) with some effort, I'll often go the extra mile.
The first Quby bezel caps that I made only encroach a tiny bit on the visible area of the screen. And the next time I have bezels laser cut, I'll likely expand the openings slightly to fully show the screen (as you and Mike have requested), which is almost the case now. But I wouldn't be surprised if the metal screen bezels occasionally show up depending on how precisely things are glued (and even cut, as well as the error introduced by differences in the thickness of the MDF).
Still, it's quite a bit easier to control the tolerances of how things fit with the Quby design than the bigger version with the snack bowl. It's rather challenging to keep four connected bezels aligned, as any error in one will likely throw off the others. And while I used jigs to do the routing work, there's still some slop (Quby doesn't require router work). So, I defaulted to letting the bezels encroach a bit, as that seemed preferable to sometimes seeing the ugly metal bezels along one or more sides (now, if the metal bezels showed evenly along all four sides, that might be okay).
Tolerances always come into play, and the consoles were not made to the tight tolerances that injection molding equipment allows (or even CNC machines for the frame, etc.). Fortunately, the laser cutters do a good job with the bezels, but there's still some variability in the thickness of the stock. But I'll try to make all 40x15 characters visible (or all 640x480 pixels). Having said that, I think it's a potentially a poor design decision for most text based games to use the borders for text, as having margins provides for more comfortable viewing. And that was part of my rational for letting the cap bezels encroach, which I've mentioned before.
So, if you're wondering which system to design/code for, I guess it would be Quby, wherein the borders will hopefully be unobstructed. But one should generally still try to have margins where possible. For example, if I were displaying paragraphs of text--which could benefit from as many columns as possible, I'd probably still avoid using the first and last columns in order to provide margins, as the text would crowd up against the MDF bezels otherwise. And the same likely applies to the rows, too.
Thanks for your response. It would be nice to have the entire screen visible even if I do choose to have a border. That would let me have the outside walls of the maze be the border characters so I wouldn't have to waste some of the 38x13 visible character positions for the outside walls. I will try that with my WordFire console. Hopefully at least a little of those border characters will show which might be enough to suggest the outside walls.
Right, assuming that you can overcome the 2n+1 limitation of the maze generator algorithm. Anyway, even with your bezels, perhaps being able to see, for example, half of a border wall is enough (people can understand that they can't go beyond the bezels). However, I'll admit that there is sometimes some variability in terms of the viewing areas from screen to screen with the snack bowl version of the console. So what might be acceptable on one screen might be obscured too much on another. If I were you, I'd get together with Mike and file a class action suit. :nerd:
Or just make my own enclosure. I'm not sure I'm up to that though. I guess there is no reason I couldn't just use the console without the bezels installed at all if I really want to use the entire displays.
If I were you, I'd get together with Mike and file a class action suit. :nerd:
Obviously, you're kidding about this and I doubt either of us would attempt this anyway. Besides, you were up front with this limitation. It isn't something we only learned after purchasing the console.
Naked as a jaybird? Maybe some vinyl tape bezels? Well, if you go without the cap, be sure that the screens don't fall out, as they are just lightly taped in.
Yeah, laughing with you (hopefully) not at you. I think I did a good job at fabricating the consoles overall and providing them at a decent price. And, yeah, I believe that I did mention the limitation(s) somewhere (perhaps in the other thread prior to your purchase), but I'm glad that you remembered.
You could just cut the bezels out of foam or carpet tiles or plastic or corrugated material or whatever and duct-tape them together from the inside. That would at least help a bit to keep the screens from falling out should the tape give way. Light materials like that tend to bow outwards a little towards the middles of the lower sides, but it's not too objectionable. Plus, if you wanted, you could use little tabs that tuck fasten underneath. Hey, maybe you could do leather crafting and hand-stitch bezels to have a premium-deluxe console. Now this time, I'm not entirely kidding, as I can imagine such a design but can't fabricate it.
I can't fabricate anything that will look decent. My first plan is to stick with what I have and I don't see why that would ever have to be changed. On the other hand, my son could probably make a replacement bezel. I'll have to check to see if he has time or interest in helping with this.
I was going to mention your son (as you've mentioned him in a PM or an email), but I didn't want to push the problem off on him. I don't know if he'd lean towards modifying the existing bezels or fabricating something new. Another possibility down the road might be gutting your console for a discounted version of Quby, but I'm probably not ready to offer that at this point. But it's something that I'd consider. Too bad shipping is rather expensive, though. In your case, I could probably just send the bezels (either glued or not) along with the PCB with empty sockets, letting you transfer over the IC's and screens with their driver boards and cables. And you or your son could easily throw together a wooden stand to save on shipping costs. Of course, you'd sacrifice the recessed snack bowl. But you could still set the same bowl on top of Quby.
Thanks for the offer but I think I'll stick with the console I already own possibly with some modifications. Actually, I'd rather come up with replacement bezels so I don't have to destroy the nice ones you provided with the console. That way I could always go back to the original state.
Comments
You said you used 104 (== 0.1 uF) capacitors both to ground (=lowpass) and to the amp (=highpass/AC-coupling). For the former, that value is a little high and for the latter, that value is too low. If you're using one of the larger capacitor packages, you can get different values that fit onto the same spot on the PCB. However, they're somewhat more expensive: The ceramic decoupling caps cost almost nothing, 47uF SMD tantalum caps are ~50 cent.
Sadly there is no solution since the video driver needs pins in a certain order.
The only other available pin is the pin 25(?) used for the IR-decoder and one will need to modify the console with some switches to use 30/31 for booting on the propplug-connector and then later 31/25(?) for a two way serial connection.
The same goes for the Quby console.
The needed change are two switches to allow pin 30 to be connected to usb or not and to connect pin 25(?) to either usb or ir. When at it one could also add a external reset switch.
But these are some simple modifications even I would be able to do, even if I am really bad at soldering.
Mike
I don't know if you need that text line. You might be able to make the maze larger and use an overlay panel for any text messages. Frankly, I don't know what those numbers mean. They seem confusing and distracting; though I just thought about them for a few seconds or times. They look like counts of some sort; perhaps they are debugging counts.
Also, I'd get at least a third color on the screen, too. Perhaps the things in the maze could be colored differently than the walls. And of course the text messages, if you really need them, could be in a different color. To have any text or information, one needs a minimum of two colors, like binary. But monochrome can be a bit boring, so a third color would spice things up. Yellow text or green text would work well on the blue background, for example.
Regarding the easy mode, I wasn't sure how to get out of it once I activated it. I think I tried pressing the same letter and then starting a new game. But it doesn't matter, as I was able to reload to get the monster back. By the way, is the only difference between the beginner mode and the normal mode the lack of the monster?
I got what appeared to be a garbage screen at one point. It had mostly '@' signs, a few M's and a few other symbols laid out in a grid with no wall characters. I took a picture if you want it. I think it happened after starting a new game just after deliberately running into a bomb I had dropped. But I tried doing that again and it didn't happen again.
I'm curious about one thing: Why does the player move two spaces in any direction upon pressing an arrow key? I realize that it speeds up play a bit, but it seems really counter-intuitive to me (though it's the only way I've played the game). I think I'd like to try a version where the player only moved one space at a time.
Anyway, the walls are great. They make all the difference. Thanks for posting.
You're probably right about that. I'll think about how I can use different colors more effectively.
I'm not sure the beginners mode is working correctly. The difference is supposed to be that the player starts out with some clubs and bombs in his/her possession. Otherwise, the player doesn't have any until he/she discovers them in the maze.
I got that too once or twice. I'm not sure what caused it. I'll have to look into it.
My only explanation for the way the player moves is that is the way it was done in the original game that I copied. It does have one interesting feature though. The monster moves one space at a time so if it gets right next to the player, the player can jump over it in one move and escape. Thanks! I'll look into making icons for some of the other game features as well.
As for jumping over the monster, I didn't know that was possible. I guess it keeps one from being trapped in a corridor, but I figured avoiding being trapped was part of the game. Guess a club could be good in that situation. One could wield it to, for example, exchange places with the monster. Anyway, I think I still lean to moving one space at a time, as that may seem more intuitive and would kind of make the maze seem bigger.
Oh, I forgot to mention last time that I'd try to avoid making the user press capital letters as much as possible. For example, when "cheating," I think I'd use "w/W' to reveal the walls. Anyway, Monsta is really shaping up. I guess he's been working out.
By the way, there are only 15 rows, and you're losing about half of the first row and the last row with "your" bezel cap. The same applies to the first and last columns. And if I'm not mistaken, Monsta only uses 37 columns for the maze instead of 38. So, I think I'd use C38 (if your maze generation algorithm doesn't object) and add two more rows to your maze before I'd go butchering bezels. You could use inverse video solid squares for the middle portion only of the bottom wall of the maze to display any messages, as you've mentioned. That would allow you to keep a bit of blue border around the maze, which does look nice. Those two changes will expand the maze, which is already fairly big (even though not on an 80-column terminal). I like the way it looks: big but not too big. And if the player moves only one tile at a time, that may also make the maze feel bigger.
For example, discounting the first and last rows that would use all wall characters, if a cell being added had spaces on both the left and right sides, then it should probably be a space to avoid blocking a potentially essential path. And if the new cell had wall characters on both sides, then it could probably be either a wall character or a space (since extra vertical paths don't hurt), though perhaps it could be randomly weighted towards being a wall character. But if the cell being added had a space on left side and a wall character on the right, or vice-versa, then I guess cells in the preceding row would have to be inspected to make sure one wasn't forming a "quadrant," which might be a little tricky, assuming it's possible.
Well, I haven't geometrically analyzed such column insertion to prove that it's always possible without creating "quadrants," but I'm guessing it is. And *if* one can always do it manually (which I don't know for sure), then it should be doable programmatically. Now, I'll admit that there are times that such a method might be visibly detectable as something being inserted. For example, a long vertical path would require alternating space and wall characters to be inserted. Anyway, even if inserting a column is feasible, it'd probably break the elegance of the maze generator (even though it would come afterwards or be a separate method), and you'd probably prefer to spend time on other aspects. But if something can be centered (the whole maze in this case) with some effort, I'll often go the extra mile.
Still, it's quite a bit easier to control the tolerances of how things fit with the Quby design than the bigger version with the snack bowl. It's rather challenging to keep four connected bezels aligned, as any error in one will likely throw off the others. And while I used jigs to do the routing work, there's still some slop (Quby doesn't require router work). So, I defaulted to letting the bezels encroach a bit, as that seemed preferable to sometimes seeing the ugly metal bezels along one or more sides (now, if the metal bezels showed evenly along all four sides, that might be okay).
Tolerances always come into play, and the consoles were not made to the tight tolerances that injection molding equipment allows (or even CNC machines for the frame, etc.). Fortunately, the laser cutters do a good job with the bezels, but there's still some variability in the thickness of the stock. But I'll try to make all 40x15 characters visible (or all 640x480 pixels). Having said that, I think it's a potentially a poor design decision for most text based games to use the borders for text, as having margins provides for more comfortable viewing. And that was part of my rational for letting the cap bezels encroach, which I've mentioned before.
So, if you're wondering which system to design/code for, I guess it would be Quby, wherein the borders will hopefully be unobstructed. But one should generally still try to have margins where possible. For example, if I were displaying paragraphs of text--which could benefit from as many columns as possible, I'd probably still avoid using the first and last columns in order to provide margins, as the text would crowd up against the MDF bezels otherwise. And the same likely applies to the rows, too.
Yeah, laughing with you (hopefully) not at you. I think I did a good job at fabricating the consoles overall and providing them at a decent price. And, yeah, I believe that I did mention the limitation(s) somewhere (perhaps in the other thread prior to your purchase), but I'm glad that you remembered.
You could just cut the bezels out of foam or carpet tiles or plastic or corrugated material or whatever and duct-tape them together from the inside. That would at least help a bit to keep the screens from falling out should the tape give way. Light materials like that tend to bow outwards a little towards the middles of the lower sides, but it's not too objectionable. Plus, if you wanted, you could use little tabs that tuck fasten underneath. Hey, maybe you could do leather crafting and hand-stitch bezels to have a premium-deluxe console. Now this time, I'm not entirely kidding, as I can imagine such a design but can't fabricate it.