@T3sl4co1l I use PIC18F45K22. It's running at 16 MIPS at 64MHz. I know AVR instructions have some advantages, but I think you are overstating the power of AVR. 6 MHz with instruction clock (if I remember correctly) of 3 MHz -> that's 330ns per instruction. The H clock is 15.625 kHz (rounded) - that's 64us per line. You have about 10-20% dead zone - that's at most 57us per line. So you are telling me that with 6 MHz clock, which is 0.33 us you can get 256 dots. 57/0.3333 is 171. And that's only if you have 1 instruction per dot. Can you read 171 bits and output them to a pin in 171 instruction cycles? I don't think so.
AVR is single cycle (reg-reg instructions). RAM is usually slower, and instruction store to reg, even slower (also branches, if taken).
My baseline idea would be, fill up all 32 byte registers with the next line, and transmit each one in sequence to the desired pin. Which might look something like,
PA0 = output, others = junk
MACRO FOR N = 0 TO 31
MACRO REPEAT(8)
OUT PORTA, r{N}
LSR r{N}
END MACRO
END MACRO
where "REPEAT" means, write this out 8 times, and FOR does the same thing but incrementing "N". Compile-time macros, so, the code space to write out one single line becomes huge (each instruction is one WORD, so you'd need 8 x 32 = 256 WORDs (512 bytes) to do it!).
But hey, when you have 64k of program memory and only 2k of RAM...
AVR has the nice feature of having 32 x 8 bit registers, so you could potentially store 256 bits in the registers, all at once. Maybe more, depending on how desperate you want to get -- don't forget that all those IO ports are registers too, even the FLAGS register. You could do some seriously demented stuff to the peripherals, which is fine because who needs 'em anyway?
You probably would not be able to read in much RAM/ROM during horizontal retrace, so you'd want to figure some way to make the lines change only a few bytes at a time.
Or since we're just writing all this damn stuff out as code anyway, the refresh instructions could be generated by an image compression routine that converts line-to-line changes into limited register updates, or varies the actual 'copy register to port' instructions in the program (which could take tremendously more code space as a result, however). In other words, something very much in the style of the PC-XT "full speed video" demo:
https://x86dc.wordpress.com/ Which is a pretty awesome bit of design, I must say.
Now, PIC sucks for not having registers -- but if you're going at 16 MIPS anyway, and that includes memory read/write at no cost, then it might not be too bad. In fact the faster RAM access would be to your advantage, though still limited by however much RAM there is inside.
Possible methods for loading entire pictures at a time, for either platform, might include "streaming" (continuous SPI?) from external memory, and buffering that onboard -- even going so far as to write onboard Flash so the data can be stored as instructions, if necessary. It would be slow, and it would thrash the ROM, but such drastic methods are hardly beyond the realm of the "demo" -- hiding load times (from slow peripherals such as cassettes, floppies or hard disks) has always been part of the challenge.
And again, not that you're *trying* to make an entire demo or anything... but the inner nuts-and-bolts are what count here, and I find that fascinating.
The best would be if you have SPI hardware with output shift register double buffered. Unfortunately PIC only has double buffering for receive register.
That's what I meant by "a little logic" -- you might double-buffer it yourself. It would of course be advantageous to use full port widths, too -- all you'd need is the functional opposite of a 74HC595: a latched parallel-loading register with serial out!
For working with SPI, there may be an existing 1-bit FIFO/synchronizer part that can simply be added on; clock it with the video clock, keep feeding it data, and boom, your SPI's blank pulse disappears.
There is one problem though. The thing is screaming with 16 KHz and my head is going to explode soon. I wonder can you reduce the noise... Is it coming from the beam deflection coils? Can I pot it with resin?
Heh heh... at least you know your ears are still working!....for now...
That, or the FBT. Probably more likely to succeed by adding acoustic damping foam inside the case, if you can.
Tim
Home
Help
Search
Login
Register
