32x24, 2 color 8x8 driver
potatohead
Posts: 10,261
Something is funky with the screen addressing. I'll need to fix it, but I'm done for the night. Cheers!
It does show the streamer modes a little. Have fun!
It's character, or text mode, meaning you can write strings right to the display buffer, and it's got a small font.
[img][/img]
It does show the streamer modes a little. Have fun!
It's character, or text mode, meaning you can write strings right to the display buffer, and it's got a small font.
[img][/img]
1632 x 1913 - 833K
Comments
Once you do put chars on the screen, everything is just fine. Displays all of 'em, in order, etc...
I've done something late night that I'll probably see next time I look.
I must digest this and see if I understand any of it. This is totally usable for debuggering stuff!
Good, job, Potatohead!
As you have found out, the sample text marks where it put the screen. I've also left some test code in. I'll remove it on my next pass.
I've never been a fan of serial. I like char mode much better.
It works by reading all the char values from the screen, then it fetches their pixels from the font, and it writes them into the scanline just before the streamer puts it on the screen.
So the streamer is displaying the ones already done, while the COG is prepping the next scanline.
The cool part is the hub ops interleave with what the streamer is doing nicely. At this low bitrate, there is a lot of time for the cog to use the hub. Eggbeater or turbine seems nice and fast compared to p1, which could not do this in one cog at 50mhz
And no delicate hub access time hassles. Just do it. Now, I do wonder about some address combos. This driver does not seem to be maxing that out, but some more testing is needed to really understand. For me anyway...
I've been pulling you program apart, taking out the test code and rearranging just so I can find out why it works so well when you subtract $88 from the screen buffer address. I haven't found anything that explains it.
I did set up actual buffer space in hub for linerame and lineramo - you were just pointing to $900 and $920. I tried local instead of moving for your pointer loading. None of my changes made any positive difference.
It's a fun detective project and is forcing me to read about streamers and learn how video stuff works, so it'should all good.
It does work very well on my little 7" monitor. Once we find the glitch,it will be a handy debug tool.
One puzzling question, when you go into dochar, you load up numchar with 28, why not 32 since you are doing 32 characters per line? It works but I don't see why.
Funny, I never did try all 32 in the main call. Might work. I will have some time tonight to poke at the screen issue and investigate the vsync issue we have all been having.
Maybe it makes sense to expand it to 40 chars too. All fun, and thanks for the sleuthing.
I'm puzzled on the screen address.
I went ahead and adjusted blanking and sync values. I think the blank lines are at the wrong blanking level... or the side borders are. See comments in the code. They are matched up now.
Does this one display well for you?
I didn't have any luck with the vsync. Need to use my scope.
Time play with some API stuff!
Baggers is weaving modes and such into one driver. At some point, when that one gets rocking hard, this will need to be based off that one.
As I have time, I'm also going to use this one as a base to fix whatever is going on in the vsync, because there is tearing there, and it's not gonna impact a modest display, but anything that wants to use most of the frame, or interlace is going to have issues on many screens. We gotta deal with that at some point. I'm a little stumped myself.
The other little, minor thing is the timing beat with the colorburst. Chip indicated it's math precision that causes that. I want to improve the signal in that regard too. Right now, we can't do single pixel line art, or fine pitch dot patterns very well. All else is fantastic though! Of course. component and VGA are nuts now. All good! (well, we just gotta go mooch the component coefficients from the hot chip and get that done)
Any of that can be merged with Baggers work, when it makes sense.
Thanks for putting a text mode together - this certainly has many great uses!
Won't be hard to fetch code, use editor, do stuff. No worries here.
i've still got problems with my selfmade R2R ladder (at DE0).
My R values are :
8x 110 ohm
7x 65 ohm
and 130 ohm (to ground)
is this correct ?
maybe someone could have a look because i'm not the "video guru" :-)
No need to wait! It's just an alias. The FDS driver I wrote is already using that technique. The new alias will be nice, though (from a readability and documentation perspective).
Better yet, think "continuation". RESI will likely show up in every I/O driver that must maintain state across interrupt calls. Instead of storing/loading state and performing a lookup/jump every time the ISR is called, you can write the ISR in a linear fashion. It's much more concise, understandable, and faster!
Boy, that picture is strange. I'll have to feed this into my HDTV.
You might try a monochrome one. Replace the colorburst with the sync level present there. I can modify a copy of this later, maybe late tonite.