Decoding the Gameboy LCD output.

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

Decoding the Gameboy LCD output.

Post by ZeroWalker » Wed Nov 01, 2017 6:21 pm

Not sure what to write, but well just a simple hobbyist.

One project i have revolve around the STM32F103C8.

And there i want to read some external signals that occur at a maximum of about 4mhz.
Without much success i have been trying to use the Timers with some assistance by some posts here,
but i am not sure i am even doing it correctly.

So hence why i made an account and thought it might be a good idea to ask around here:)

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

Re: Hi, hobbyist trying things out:P

Post by RogerClark » Wed Nov 01, 2017 9:05 pm

Hi

I think you need to explain in a bit more details what you are trying to achieve

4 Mhz is a relatively fast signal to be analysing with a 72Mhz processor.

i.e this is 1/18 of the main clock frequency, and around 1/10th of the max GPIO speed.

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

Re: Hi, hobbyist trying things out:P

Post by ZeroWalker » Wed Nov 01, 2017 9:15 pm

It's to decode the Gameboy LCD output.

So basically the Gameboy outputs one pixel at 4mhz, and each pulse it checks two other inputs to get the color (DATA0/1).
Then there's HSYNC and VSYNC which are a ton slower, but you can kinda get away without those in a nutshell most of the time i think,
as you only need to know that it's 144x160 pixels.

So instruction wise, i think it might be possible, i want to basically buffer the data then send it via USB or something (as i can't stream it constantly).
And as it's only 2 bits per pixel, storage wise it should be fine.

But when i check the clocks, i could get VSYNC to work at it's 60hz interval in the timer (not sure why it works with some weird settings and others it goes weird with the count).

the 4mhz though is nowhere near where it should be i think. in about 1 second i get about 4k counts(pulses).
And technically i think it should be 144x160 (so about 20k+).

I might be thinking wrong or doing something wrong (probably both lol;p).

victor_pv
Posts: 1679
Joined: Mon Apr 27, 2015 12:12 pm

Re: Hi, hobbyist trying things out:P

Post by victor_pv » Wed Nov 01, 2017 10:11 pm

That 4Mhz signal, does it go in sync with a clock signal, so you can sample it with the level change of the clock?
Or is there a start pulse or something else? otherwise, how can the MCU know when to start sampling it?

About sampling a signal that fast, if we take that you sample at twice the frenquency, that's 8Mhz, you only have 9 cpu clock cycles between 2 samples. If you are in a loop, some cycles may be wasted as the MCU needs to load the next block of flash, which add wait states, so you will have time for 9 instructions or less, depending how tight is your loop.
If you have some way to synchronize and can sample at the same 4Mhz, then you get time for 18 instructions at max.
Another option would be to use a DMA channel triggered by a timer to sample the GPIO and save it to RAM. That would need to save at least 1 byte per sample, since the DMA can't do bit transfers, so you need a larger buffer, and then you can be packing those bits later to save space.

I would think the very tight loop may give you a better chance of fitting it in RAM, unless you use a larger MCU.

But I still don't know how many samples you need to save, and if that 4Mhz signal is async or not, so I may be way off with those ideas.

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

Re: Hi, hobbyist trying things out:P

Post by ZeroWalker » Wed Nov 01, 2017 10:22 pm

VSYNC is the start signal. Each time the VSYNC goes on (it stops) then when it goes off, it starts printing pixels, then it repeats.

I doubt (just guessing) i will be able to make it work with 4MHZ directly, i will probably need 8Mhz (but who knows).

I only have 20kb of ram i think, so sadly it's a bit less then what's needed to store one image of 144x160 at 8 bits.
I think it makes most sense to buffer one image to later send it, as VSYNC blanking is a lot longer than HSYNC.

I am not super duper picky for a start as this is my first thing ever to do with a MCU and i am very knew to electronics,
so if possible the DMA might work and then just truncate or even let it overflow or something, so the end image will still be valid, but missing pixels.

But at first i would like to simple be able to count the 4mhz pulses and print it out to serial (for debugging).
Cause currently i get far less then what i expect on it, and i doubt it's because it's inefficient (i am doing Nothing).

here's even the code (i am kinda clueless of the Timer, i basically copy pasted it as i couldn't find good documentation on it).

http://paste.awesom.eu/DDqy

EDIT:

Looking at the 4mhz signal some more i think it might be fairly easy to deduce where it's at.

The start of each line have have a wait period between the first and second pulse (about 500khz).

The end of each line till the next has a waiting period of about 17.51 khz.

If it's possible to keep track of that, i think it might be possible to simply try to do some of the bit fiddling during the wait periods between each line.

When the frame ends there's a wait period of about 864 hz which is quite huge and should be no problem doing work during this time.

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

Re: Hi, hobbyist trying things out:P

Post by RogerClark » Wed Nov 01, 2017 11:43 pm

You're right, the frame buffer is not going to fit in 20k, especially as some of the RAM is already being used for things like the USB and the serial buffers etc etc

The most similar thing that people have done so far is read data from the OV7670 camera, via DMA, and send that to a LCD screen via SPI
(The LCD screen acts as the storage)

We can achieve 320x 240 x 11 fps. The camera data is 8 bit parallel, and there are 3 control signals from the camera, V and H sync and a clock

I can't remember the clock frequency from the camera but I think its possibly 8Mhz (though its configurable by the I2C control lines to the camera)

You may want to look at the code that @stevestrong has posted to that thread and see if that helps with what you want to do.

If you need more RAM you can get F103VET boards for around $10 which has 64K of internal RAM

But for roughly the same price you can get a F4 board with more processor speed and even more RAM

The downside of the F4 is the LibMaple Core that is in my repo, only has limited support for the F4, and you'd probably need to use STM's own core, or danielef's STM32_GENERIC Core.
Both STM's and Daniel's core use the STM HAL which is different to the libmaple internal API

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

Re: Hi, hobbyist trying things out:P

Post by ZeroWalker » Thu Nov 02, 2017 12:33 am

Looking at stevestrong's code, i can't see anything that uses a timer to read pulses, only that he generates a pwm with a timer:o

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

Re: Hi, hobbyist trying things out:P

Post by RogerClark » Thu Nov 02, 2017 2:39 am

His code reads the 8 bit pixel data from the camer, which I thought was similar to what you are trying to achieve, but perhaps your data is serial ?

Sounds possibly like you could use SPI slave, but we don't have the feature in my repo; though I think Rick Kimball was using something like that to generate data for addressable pixels


I think you need to explain in detail what the format of the data you are trying to analyse e.g. is it somewhat like analog TV signals ?

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

Re: Hi, hobbyist trying things out:P

Post by ZeroWalker » Thu Nov 02, 2017 6:39 am

The data should be serial, it's quite straightforward.

Basically you start at the topleft of the image, then think of the clock (4MHz).
Each time it goes On, DATA0 and DATA1 are simply (pixel = DATA0 | << DATA1).
Then repeat until we we reach the end of the image, then repeat.

So there pixels only come from the clock, it decides basically everything.

Not quite sure how analogue TV signal works, but i think it might be fairly similar to this?

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

Re: Hi, hobbyist trying things out:P

Post by stevestrong » Thu Nov 02, 2017 8:33 am

ZeroWalker wrote:
Thu Nov 02, 2017 12:33 am
Looking at stevestrong's code, i can't see anything that uses a timer to read pulses, only that he generates a pwm with a timer:o
Indeed. A timer generates the main clock for the camera.
But the camera outputs a pixel clock (based on the input main clock).
This pixel clock is input to a capture channel of another timer of the STM32 chip.
This capture input generates a DMA trigger which forces the DMA to read and store the parallel data bits 0..7 from the camera.
In your case it would be only bit 0 and 1, but still is parallel output, if i'm correct. So one clock -> read two bits.

You could use this trick, but then you should process a complete line within the horizontal blanking interval.
Processing means put the double bits from 4 consecutive readings together into a complete byte, if needed.

Post Reply