SKPIC32-based 256-color Video Experimental Game

Works done? Proud of it? Show off here! Let's see what you've built can help inspire others.

SKPIC32-based 256-color Video Experimental Game

Postby Brian Griffin » Thu Jul 26, 2012 12:39 pm

Project Name: SKPIC32-based 256-color Video Experimental Game

Author/Designer: YH

Project Description: Primitive 256-color video generation using double-buffering, at 256x240 resolution (Nintendo Entertainment System uses that for the screen size). The video DAC at the end of the PMP Data port is using the format RRRGGGBB.

Pixels are pumped through the Parallel Master Port using DMA (Direct Memory Access) module.

Due to a port and some graphical changes, the hit-detection scheme in the game is faulty. It is just for a showcase and not an actual playable demo. Another different game will be written.

Sound module will be added later. This is an experiment to prove that the a combination of PMP and DMA can also drive VGA signals, apart from LCD modules.

System (SKPIC32) is run at 80MHz, and 80MHz peripheral bus. Unfortunately, even with the double buffering, minor screen tearing is present because the main bus is very occupied. (It could be also noise as many jumper wires are used) Some other advanced microcontrollers provide different bus and direct RAM connections to the video system. (That's also why you have those AGP and PCIE in your computers too)

Photo:

screenshot1.jpg
Screenshot of gameplay.


screenshot2.jpg
Minor crawling/drifting of pixels.


screenshot3.jpg
In game menu.


Video:

Compiler: MPLAB X IDE (latest), MPLAB XC32 v1.00.

Source code: Attached.

Schematics:
schematic.jpg
Schematics of the project. (Error in PMD bus line in schematic - should be 8 instead of 7)


References:

1.) Programming 32-Bit Microcontrollers in C, Lucio di Jasio.
2.) http://www.zipfelmaus.com/nokia6100lcd_en/ (BMP to RGB8 converter)
Attachments
skpic32-vga2.X.zip
Source Code.
(205.6 KiB) Downloaded 463 times
PIC - UIC00B from Cytron (replacement for my broken PICKit 2), Pickit 3, MikroC for PIC
dsPIC - MikroC for dsPIC, mikromedia board (dsPIC33)
AVR - AVR Dragon
Parallax - Prop tool
User avatar
Brian Griffin
Enthusiast
 
Posts: 403
Joined: Mon Jan 17, 2011 9:36 am

Explanation of the Horizontal Scanlines

Postby Brian Griffin » Thu Jul 26, 2012 1:05 pm

For those who are curious on how the stuff on the screen is shown, it is best described in another post.

Like televisions, the lines are 'drawn' across the screen for a number of times until it reaches the bottom of the screen, and then goes back up, and process continues indefinitely.

1.) On each line, there is a high horizontal pulse interval which is triggered by the Output Compare 3.

2.) Then after a while, came the Output Compare 4. This triggers the DMA to stream the first 256 horizontal pixels from a picture array into the PMDIN or the Data bus. The intervals between each pixel are determined by the strobes of the PMP which can be set in the PMP configuration registers. On this one, it could be around 60ns per pixel. The DMA (Direct Memory Access) is used because the system can transfer data from RAM to other peripherals without the intervention of the CPU. Therefore, the response is very rapid since the main CPU doesn't have to do anything to transfer it. (apart from responding to interrupts and such)

3.) In that Output Compare 4 interrupt, wait for the DMA to complete the transfer. Because only 256 horizontal pixels are shown, a terminating zero is placed after the transfer is complete to tell the monitor that the active video line has ended.

4.) Process repeats to 1 and for 240 times before the next Vertical Sync occurs.

CODE: SELECT_ALL_CODE
                             |<--------Active Video Line, 25.17us------------->|
 HSYNC         <- OC3         |<- OC4, start DMA and stream pixels.             |<- approx 25.17us.
---------|   |-------------------------------------------------------------------------|
         |___|                                                                         |__... next line.


The idea of streaming the pixels into PMP while the system is doing other stuff is feasible, but due to the fact that the PIC32 has only one big bus for all the operations, it is impossible to do this without jamming/stalling the system. Other advanced microcontrollers contain a seperate bus exclusively for streaming pixels from RAM to another port.
PIC - UIC00B from Cytron (replacement for my broken PICKit 2), Pickit 3, MikroC for PIC
dsPIC - MikroC for dsPIC, mikromedia board (dsPIC33)
AVR - AVR Dragon
Parallax - Prop tool
User avatar
Brian Griffin
Enthusiast
 
Posts: 403
Joined: Mon Jan 17, 2011 9:36 am

Re: SKPIC32-based 256-color Video Experimental Game

Postby robosang » Sat Jul 28, 2012 7:26 am

Woh woh.... that is amazingly interesting 8-)

How come you are so fast in developing thing? You must be squeezing the SKPIC32 :mrgreen:
robosang
Expert
 
Posts: 1239
Joined: Wed Jun 10, 2009 5:37 pm

Re: SKPIC32-based 256-color Video Experimental Game

Postby Brian Griffin » Sat Jul 28, 2012 8:21 am

robosang WROTE:Woh woh.... that is amazingly interesting 8-)

How come you are so fast in developing thing? You must be squeezing the SKPIC32 :mrgreen:


Thanks for compliment. It takes many weekends to do it actually. Plus, in my work I learned a lot of TV signals, so I'm taking advantage of it. :)
PIC - UIC00B from Cytron (replacement for my broken PICKit 2), Pickit 3, MikroC for PIC
dsPIC - MikroC for dsPIC, mikromedia board (dsPIC33)
AVR - AVR Dragon
Parallax - Prop tool
User avatar
Brian Griffin
Enthusiast
 
Posts: 403
Joined: Mon Jan 17, 2011 9:36 am

Re: SKPIC32-based 256-color Video Experimental Game

Postby gadgetng » Sat Jul 28, 2012 2:06 pm

:shock: really advanced for me.
Thanks for sharing.
gadgetng
Discoverer
 
Posts: 97
Joined: Tue Jul 24, 2012 11:20 am

Re: SKPIC32-based 256-color Video Experimental Game

Postby takao21203 » Mon Jul 30, 2012 4:18 pm

Impressive. Myself I have only advanced to understand the basics for the parallel Master port present on the 18F PICs.

I have read about the DMA subsystem in the datasheets, but it looks more complicated to me than the PMP.

I want to use 320x200 16bit TFT LCD, together with 18F PIC.
For this purpose I have prepared a 512K RAM board.

However, there is a GAL required, as well bus transceivers, since the PMP only works for 8bit, where the LCD needs 16bit. Voltage levels are different as well. As it looks, the wiring required is extensive.

You use DMA for full-screen refresh? Is this correct? I am intending to use scrolling on the LCD, means only a fraction of the display RAM is updated each time.

Comparing the possible transfer rates of PIC 18F, and 68000, the plan to use 68K was abandoned more or less for the time being, since even 18F PIC seems to be faster many times.

Your project is a motivation for me to continue work on my LCD board!

P7300305.jpg
User avatar
takao21203
Discoverer
 
Posts: 111
Joined: Mon Mar 19, 2012 7:52 pm
Location: Ireland, Europe

Re: SKPIC32-based 256-color Video Experimental Game

Postby Brian Griffin » Mon Jul 30, 2012 4:42 pm

takao21203 WROTE:Impressive. Myself I have only advanced to understand the basics for the parallel Master port present on the 18F PICs.

I have read about the DMA subsystem in the datasheets, but it looks more complicated to me than the PMP.

I want to use 320x200 16bit TFT LCD, together with 18F PIC.
For this purpose I have prepared a 512K RAM board.

However, there is a GAL required, as well bus transceivers, since the PMP only works for 8bit, where the LCD needs 16bit. Voltage levels are different as well. As it looks, the wiring required is extensive.

You use DMA for full-screen refresh? Is this correct? I am intending to use scrolling on the LCD, means only a fraction of the display RAM is updated each time.

Comparing the possible transfer rates of PIC 18F, and 68000, the plan to use 68K was abandoned more or less for the time being, since even 18F PIC seems to be faster many times.

Your project is a motivation for me to continue work on my LCD board!

The attachment P7300305.jpg is no longer available


The DMA subsystem isn't tough if you read it a few more times on the respective datasheet. Luckily, the PIC32 manuals are quite direct when they write those. I can't guarantee for the other datasheets though.

The full screen refresh is done manually by clearing the screen buffer. Nothing else is done there - the DMA is only used to stream pixels to the screen safely without the uncertainties of the timing due to the cache.

I saw a similar project which is done using STM32F4 - it's another processor but they have FPU inside. Unfortunately, I never got around using those - their reference manuals are a bit difficult to read.

I did not incorporate scrolling due to the memory constraints. Another alternative to all these are using tile rendering engine, but to fully imitate the NES PPU (Nintendo Entertainment System Picture Processing Unit) is a very difficult task.

Apart from all these, I've revised the code. It has less screen tearing, but the game is very wonky due to porting issues. For that, it is an exercise for the users to write a new game code inside. :D
Attachments
skpic32-vga2.X.zip
Source Code and Hex
(206.16 KiB) Downloaded 441 times
PIC - UIC00B from Cytron (replacement for my broken PICKit 2), Pickit 3, MikroC for PIC
dsPIC - MikroC for dsPIC, mikromedia board (dsPIC33)
AVR - AVR Dragon
Parallax - Prop tool
User avatar
Brian Griffin
Enthusiast
 
Posts: 403
Joined: Mon Jan 17, 2011 9:36 am

Re: SKPIC32-based 256-color Video Experimental Game

Postby takao21203 » Mon Jul 30, 2012 6:36 pm

Hmm. I have taken a quick look at everything.
How many Kbytes are used by the sprites?
Have you considered to put them into serial FLASH?

Indeed older game machines use hardware to deal with tiles.
The "bitmap", so to say, is only containing the tile numbers.

But for a horizontally scrolling game, I would also use tiles.
It's not that difficult.

Have you considered to optimize vga_draw_sprite, and vga_draw_sprite_frame?
I don't know if it makes a difference for the PIC32, but values are calculated each iteration
unneccessarily, as they don't change. Especially the horizontal loops only adds j, which is changing.

I have not yet fully understood the system. It is capable of VGA output, and also LCD output?

So the VGA data is taken from SRAM and written 50 times each second?

Do you buffer the background for the sprites?

If I write something like this, I would use generic code, which adds sprite to a list, saves background etc.
You need some kind of sprite-based game engine!

Back in time I had some books around for home computers. Some of them had hardware support for sprites!
BItmap initialization was very complicated.

What I will be able to test very soon is scrolling capabilities of these small 1.8" LCDs, if any.
For this purpose I would need a complicate keypad, however, I have my infrared interface working now.
Unfortunately only for very slow 18bit codes, so at some point of time, I will add NES gamepad.

I am working at the same topic, somehow, even it is rather in the preliminary phase.

Today I have put the infrared code into a .h file, and want to try to add it to the character LCD board,
and test it to set time!

Maybe I will try to use your alien sprites! And I need to test serial SRAM as well.
On my PIC 18f24j10 circuit, 512 bytes are taken by the palette generator. 1/2 of all the RAM!
So this needs to be moved into serial RAM.

Basically I want to use tiles, and a tiles map inside the FLASH, then scroll horizontally through this map.
Either I need to generate full bitmap each time, so complexity will be limited, or I can use some kind of scrolling.

Recently one 2.1" LCD arrived here which also could use 8-bit interface.
The 2.4" displays are 16-bit only! And capable of scrolling. Very complicated datasheet, 100s of pages.
User avatar
takao21203
Discoverer
 
Posts: 111
Joined: Mon Mar 19, 2012 7:52 pm
Location: Ireland, Europe

Re: SKPIC32-based 256-color Video Experimental Game

Postby takao21203 » Mon Jul 30, 2012 6:48 pm

CODE: SELECT_ALL_CODE
void vga_draw_sprite(unsigned char x, unsigned char y, unsigned char spriteWidth, unsigned char spriteHeight, const unsigned char* sprite, unsigned char* inputBuffer)
{
    unsigned char i, j;
    x_temp0=(x+(y*256));
    for(i = 0; i < spriteHeight; i++)
    {
        x2_temp=i*spriteWidth;
        for(j = 0; j < spriteWidth; j++)
        {
            inputBuffer[x_temp++] = sprite[x2_temp++];
        }
        x2_temp+=256;
    }
}


Eventually you know about this already. When I wrote assembler games for MS-DOS,
optimization was kind of essential, since the VGA RAM access was very time consuming already.
User avatar
takao21203
Discoverer
 
Posts: 111
Joined: Mon Mar 19, 2012 7:52 pm
Location: Ireland, Europe

Re: SKPIC32-based 256-color Video Experimental Game

Postby Brian Griffin » Mon Jul 30, 2012 7:21 pm

takao21203 WROTE:Hmm. I have taken a quick look at everything.
How many Kbytes are used by the sprites?
Have you considered to put them into serial FLASH?

Indeed older game machines use hardware to deal with tiles.
The "bitmap", so to say, is only containing the tile numbers.

But for a horizontally scrolling game, I would also use tiles.
It's not that difficult.

Have you considered to optimize vga_draw_sprite, and vga_draw_sprite_frame?
I don't know if it makes a difference for the PIC32, but values are calculated each iteration
unneccessarily, as they don't change. Especially the horizontal loops only adds j, which is changing.

I have not yet fully understood the system. It is capable of VGA output, and also LCD output?

So the VGA data is taken from SRAM and written 50 times each second?

Do you buffer the background for the sprites?

If I write something like this, I would use generic code, which adds sprite to a list, saves background etc.
You need some kind of sprite-based game engine!

Back in time I had some books around for home computers. Some of them had hardware support for sprites!
BItmap initialization was very complicated.

What I will be able to test very soon is scrolling capabilities of these small 1.8" LCDs, if any.
For this purpose I would need a complicate keypad, however, I have my infrared interface working now.
Unfortunately only for very slow 18bit codes, so at some point of time, I will add NES gamepad.

I am working at the same topic, somehow, even it is rather in the preliminary phase.

Today I have put the infrared code into a .h file, and want to try to add it to the character LCD board,
and test it to set time!

Maybe I will try to use your alien sprites! And I need to test serial SRAM as well.
On my PIC 18f24j10 circuit, 512 bytes are taken by the palette generator. 1/2 of all the RAM!
So this needs to be moved into serial RAM.

Basically I want to use tiles, and a tiles map inside the FLASH, then scroll horizontally through this map.
Either I need to generate full bitmap each time, so complexity will be limited, or I can use some kind of scrolling.

Recently one 2.1" LCD arrived here which also could use 8-bit interface.
The 2.4" displays are 16-bit only! And capable of scrolling. Very complicated datasheet, 100s of pages.


I put the bitmaps into the microcontroller because the PIC32MX795F512L has a very huge flash space.

The thing for now is capable for VGA output only. TFT requires a different code - I may try this later if I get hold of one of these.

I used double buffering. Because it's 256x240, the total for one frame is 61440. Two buffers, 122880 bytes total, or approximately 123KBytes. Not the most efficient thing in the world, I admit, but it's something to learn for people who write their first VGA code.

I can't do much scrolling because of the SRAM inside the microcontroller is not sufficient. In future I will use tile-rendering engine. Writing such engine is a tedious thing to do because of the sheer complexity inside, and all of what is inside the tile engine is very efficiend. No wonder NES is still one of the world's most cloned systems, with cheap and crappy Polystations still haunt us in 99¢ stores.

I only know that the AVRs are very good enough to drive VGA signals without overclocking. That, I don't have the time despite owning a couple of those chips.
PIC - UIC00B from Cytron (replacement for my broken PICKit 2), Pickit 3, MikroC for PIC
dsPIC - MikroC for dsPIC, mikromedia board (dsPIC33)
AVR - AVR Dragon
Parallax - Prop tool
User avatar
Brian Griffin
Enthusiast
 
Posts: 403
Joined: Mon Jan 17, 2011 9:36 am

Next

Return to Project Showcase

Who is online

Users browsing this forum: No registered users and 6 guests