VGA itself isn't too bad; the hard part, that cost another couple of weeks, was wrestling with cpu unknowns. This level of chip is so powerful/complex that they just don't seem able to document it well enough; there is quite literally thousands of pages in the reference guides and ARM general guides, but they never quite seem to get to the nitty gritty. So while I was detecting and clearing the TCIF flag (interupt ackowledge) in the DMA ISR, I apparently needed to detect and clear TCIF1, which wasn't mentioned anywhere that I saw :/ I likely just missed it in the sea of charts.. that one character, that cost so much time..
Anyway, so now I'm using per-raster-line DMA, nice and simple. (The whole code that dfoes VGA is probably 2-3 pages, very short, just all fiddly timings and registers
); the DMA can be configured to follow a clock, so release each byte from the FIFO when the timer ticks.. so once you get the pixelclock timer set up just-so and attached to DMA, just fire it off. The DMA is pretty neat; I didn't even bother (this round) with trying the options yet.. burst on one end or the other, and fifo settings.. I've fiddled last week and you could just make it _go faster_, but we're already slowing it down with timer to keep it nice. Good to know we can go faster still
(and imagine .. could recode standard-C library memcpy and memmove and strcpy and so on, to use DMA if the length is worth the cost; ie: for a string, with 'strcpy', ou dont' want to pre-count the length, too expensive; but a strncpy(), or a memcpy(), you are given the length; if your length is say 1K or more, or whatever, it'd be worth (possiby) setting up a timer and DMA and doing that, and letting it go for 'free' on hardware, relieving the cpu; but then you end up with javascript like callback chains ("I'm done!") or having code not worry about it; usually after a memmove you want to use the new buffer immediately, and not do a 'while not done, spin' loop; but in some special cases, like blitting to screen or sending audio out to headphone jack or other cases, you just want to memmove out a buffer, having it magicly use DMA would rock. Hence my routine is dma_memcpy(), but I need to add a couple flag-bitvalue vars, so yo can specify bolleans to 'increment source pointer yes/no' and so on.. a nice general purpose dma memcpy.. sweet!
The rate of release versus the rate of raster gun on the CRT makes the pixels .. so if you speed up the pixelclock, you get higher horizontal resolution up to monitor capacity; you slow it down, you get pixel doubling/tripling/blurring depending how you set it; so halving the timer should double your pixels.. for free
Now, I could set up the DMA 'circular' (repeating forever), and then just halt/restart the timer at each line; this would save on timer setup/start time (moving image more to the left), and would allow almost cpu-less operation.. the isr has 1 line to stop/start the timer at the right times, and no calcualtion; the loss there is pixel doubling vertical resolution -- right now the ISR enters, and it divides the linecount by 2 and jumps to the right part of the framebuffer array. If your fb matches your display 1:1, you could do the pure dma/timer/isr trick and it'd be glorious.. but risky; if the timing isn't just-so, I image so blur at the bottom and top or page, possibly out of sync the whole image more and more over time; with per-line dma, you know its pretty darned close.
I really should link the hsync and dma timer together, so that XXuS after hsync it wakes the DMA timer, to get a perfectly timed ikage (each line precisley same start point, every time), but so far it seems bullet proof sharp on my monitor, so I'm not going to sweat that additional level of timing chaining.
..
Right now though, the priority to fix on VGA is performance; the main loop is just 'while(1);' and its all interupt driven as Crom intended; if you expand the while() to do _stuff_, even really long lasting stuff, it shoudln't bollox the image at all, since interupt has priority.. but somehow it _Does_; if I do image blitting of any significance in the loop, the image gets messy at the top; I need to busy up crazy in the main loop and see if it blows the whole screen up, but I think it does; doesn't add up. Even if my main loop is "while(1){ nop }" you woudl think the main loop is '100% busy', and ISRs taking over and its perfectly fine; how does that differ to busy blitting loop in there, to the cpu? But it does.
Of interest..
i) Adjusting the mhz rate on the chip between 120 and 168 doesn't break the image; it should completely blow it up, unless it just luckily happens that I'm cutting from 640x480 to 800x600 by changing the rates; I couldn't be that lucky, could I? So jhanging the cpu speed is possibly changing some of the clocks but not all (I need to go over the timer dependancy chain again) .. I may not be speeding up all of the chip!
ii) I'm using volatiles too much; volatile is maybe slowing down some of these operations too much, but shoudln't break this even if, I think.. still.
iii) .. what else .. something else is screwing with the same timer as DMA maybe, or otherwise holding up the DMA? Theres not a lot in that code, but I dont' really understand the ARM Cortex M3/M4 arch that well.. just too expansive to grok it all yet, so I'm probably missing something.
Anyway, if its still an issue soon, I'll clean up the code to a simpler test case, and post it for some help.. but I'll keep at it. ie: I need this chip to be able to poll joystick in main loop, and I'd really like if it coudl take some reasonably high freq interupts from GPIO and not flicker. ie: this defines how z80 talks to it .. if z80 can talk memory bus to it, that would be outstanding; if it has to talk OUT/IN that works too, but a little lesser. Or do I need to use z180 (boo
, and hook up I2C or something instead ... etc, all depends on how much performance I have to burn.
Always the details, with simple resolutions after enough head pounding
..
Sad that it is hard to even discuss some of these encryption issues without getting red taped; the foundation of cryptology is that it must be open; if your protocol is fully documented to the attacker, and holds up, then it counts; if it doesn't hold up in that regard, it is a failure; security through obscurity is no security at all. So chit chat must be encouraged.. assholes
jeff
