Decoding the Gameboy LCD output.

ZeroWalker
Posts: 57
Joined: Wed Nov 01, 2017 6:17 pm

Re: Decoding the Gameboy LCD output.

Post by ZeroWalker » Wed Nov 08, 2017 12:21 pm

But isn't an interruption run by the "main process" and then it just returns to where it was before?
So shouldn't an interrupt be able to run something heavy, especially if it doesn't take the time till the next interrupt?

Cause why do i need to use the main loop to check for stuff rather than just run what i wana do in the interrupt itself?

And having a double sized buffer with circular was quite neat trick, will have to try that.

I have actually been able to kinda get it all working (wit the main loop thingy though, not what i want per see).
But using 2 SPI for both bits and then sending the data didn't work out, it's too slow.
I can't merge the data before sending it as it requires too much RAM, at least if i don't somehow share the data on the buffers,
but still shouldn't matter as sending 5760 bytes seems to be far too slow (which kinda feels weird, sure it's twice the data but should only take twice as long:S

stevestrong
Posts: 1811
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: Decoding the Gameboy LCD output.

Post by stevestrong » Wed Nov 08, 2017 12:52 pm

ZeroWalker wrote:
Wed Nov 08, 2017 12:21 pm
But isn't an interruption run by the "main process" and then it just returns to where it was before?
So shouldn't an interrupt be able to run something heavy, especially if it doesn't take the time till the next interrupt?
No.
Interrupts are interrupting the "main level" (top level) CPU processes. Interrupts shall be as short/quick as possible.
A system has usually several interrupts from different interfaces which should ideally not disturb each other.

Sending 2 x 2880 bytes (unprocessed) within 16msec (1/60 Hz) is really on limit (360kBps Tx speed), but sending same amount of data only each second frame (30 Hz, 180kBps) should be doable. Of course, the receiving host should also be able to process the received data (merge the buffers and format the pixel data) within the 30Hz frame rate period, otherwise it won't make sense to send so fast.

EDIT
Or, if you have one more spare blue pill, you could send the raw data received from the GB to another blue pill (over serial or SPI3), this second pill will do data formatting and sending the processed data to (another) host, or display it on a locally attached ILI display. If you send the data over SPI3 to the second pill with 18MHz clock, you achieve 2MBps, so there will remain enough time for the second pill to process whatever you want.

ZeroWalker
Posts: 57
Joined: Wed Nov 01, 2017 6:17 pm

Re: Decoding the Gameboy LCD output.

Post by ZeroWalker » Wed Nov 08, 2017 2:46 pm

Ah i see, that explains the hard locks.

Well another problem is that i need to sync up with VSYNC, which seems harder than expected, almost never get the correct image,
and always one vertical row is corrupted (starting to think it's actually the GB though as it's actually have HSYNC broken and maybe that caused a problem there).

I actually do have another blue pill, thing is, i want the data transferred to a PC, that's the entire point of it basically.
Isn't there some method to send to a PC faster, is the debug serial the only way?

I guess i could use my Raspberry Pi or something and transfer to that, but then i would end up having to use that and i could just as well let it handle everything then.

stevestrong
Posts: 1811
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: Decoding the Gameboy LCD output.

Post by stevestrong » Wed Nov 08, 2017 8:19 pm

Are the pixel clocks generated before Vsync and Hsync? Or only after/during?
Do you have a zoomed in scope timeline of pixel clock vs Hsync?
Those already posted by you are not enough detailed.

As I told, can the PC process/format the raw data (you would transfer over serial) to a picture keeping 60Hz frame rate? I doubt.
I suggest to lower (to half) the nr of transferred frames, this way you have more time to transfer data on blue pill side and more time on PC side to process it.

ZeroWalker
Posts: 57
Joined: Wed Nov 01, 2017 6:17 pm

Re: Decoding the Gameboy LCD output.

Post by ZeroWalker » Thu Nov 09, 2017 12:51 am

Well checking my logic analyzer it seems that during VSYNC the first clock pulse occur, then 144*160 pulses occur (totally).
After that there's a short timeout, then VBLANK happens and during it the first clock pulse occur again.

I can't check HSYNC as i broke it, but looking at the pulses, i would assume that there was a timeout during the HBLANK,
cause there's consistent silence.

I have set it up so the PC handle all the setup as long as it received the data,
30fps would remove the purpose of it sadly, the point is to have it accurate.

User avatar
RogerClark
Posts: 7418
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Decoding the Gameboy LCD output.

Post by RogerClark » Thu Nov 09, 2017 12:58 am

If uploading to the PC is the problem, you could take a look at the cheap CY7C68013 boards that are used in the cheap logic analysers

They are a gereral purpose chip designed for reading 8 bits of data into a PC quickly

You'd need to compile some custom code onto the chip, from what I've read its totally do-able.

You would need a system to transfer the decoded data from the STM32 to the CY7C... chip, perhaps 8 bit wide data on port B of the Blue pill

ZeroWalker
Posts: 57
Joined: Wed Nov 01, 2017 6:17 pm

Re: Decoding the Gameboy LCD output.

Post by ZeroWalker » Thu Nov 09, 2017 2:20 am

Actually got that board, thought it had to buffer and burst the data though.

stevestrong
Posts: 1811
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: Decoding the Gameboy LCD output.

Post by stevestrong » Thu Nov 09, 2017 8:36 am

ZeroWalker wrote:
Thu Nov 09, 2017 12:51 am
Well checking my logic analyzer it seems that during VSYNC the first clock pulse occur, then 144*160 pulses occur (totally).
After that there's a short timeout, then VBLANK happens and during it the first clock pulse occur again.
OK, so you cannot send/receive each line, you have to check the end of a whole frame.
Then wait till the first Vsync (rising/falling?) occurs, then enable the SPI and DMA in the EXT interrupt (this will be short), then wait till DMA has finished to receive all bytes in the main loop, then send all data.

ZeroWalker
Posts: 57
Joined: Wed Nov 01, 2017 6:17 pm

Re: Decoding the Gameboy LCD output.

Post by ZeroWalker » Thu Nov 09, 2017 8:40 am

Basically yes, for VSYNC it seems to be Rising (as one clock pulse occur while VSYNC is active weirdly enough).
And problem is that VSYNC can change so the process actually needs to be repeated more or less,
even though it's rare the GB allows it, and obviously it will also happen if you reset the power etc.

stevestrong
Posts: 1811
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: Decoding the Gameboy LCD output.

Post by stevestrong » Thu Nov 09, 2017 8:56 am

I which way can Vsync change? The timely position?
This is not relevant, important is that the first Vsync edge activates the slave reception, and the DMA end signalizes the end of frame.

Post Reply