nesdev.org

Hey,
I just uploaded my small SDK to GitHub:

https://github.com/mupfelofen-de/sndk

It's basically a port of Alekmaul's DevkitSnes and PVSnesLib that I wrote (above all) for myself.

Have fun.

Michael

Here is a tip: Switch to a good assembler like CA65, WLA's Linker somehow sucks, Though that's an option you choose yourself, Think about the ease of coding!

There are more bugs in the tcc816 itself than in WLA (ratio like 8:0 in my practice), and those are real problem, not a matter of personal preference.

Also, I don't think that 'replace/rework half of the tool chain' could be called 'a tip'.

Shiru wrote:There are more bugs in the tcc816 itself than in WLA (ratio like 8:0 in my practice), and those are real problem, not a matter of personal preference.

Also, I don't think that 'replace/rework half of the tool chain' could be called 'a tip'.

I apologize, It's so early in the morning on my side of the world when I wrote it, so I did not think straight,

It is an excuse for me to say this... but the main reason is, I go to youtube a whole lot, so I tend to see what new videos come early. I try to watch it so I try to stay at least on the neutral side of the webs!

How many hours per day do you sleep? You always give that excuse

Shiru wrote:There are more bugs in the tcc816 itself than in WLA (ratio like 8:0 in my practice), and those are real problem, not a matter of personal preference.

Yeah, the first thing that needs fixing if people actually want a half decent C devkit, is a half decent 65816 targeted C compiler. I wrote a library for snes-sdk and I probably ended up implementing 90% of it in assembly, and even then I'm reluctant to use it because of how awful tcc816 is at optimizing (possible to work around most bugs I've found). Can't recall WLA giving me any trouble at all.

I'm genuinely curious why someone would choose to retarget tcc of all things.

Nice work !
But why not providing all pvsneslib source code with it ?

alekmaul wrote:Nice work !
But why not providing all pvsneslib source code with it ?

Hi alekmaul,
in fact I do. All your code examples can be found in 'src/examples'.

And thanks!

PS: Will there ever be more documentation? The PVSnesLiv wiki seems to be abandoned.

PPS: Is there any "simple" solution to generate a background image at runtime with this toolchain? pixel after pixel.

Yes, you provided source code , but only for examples, not for the library itself

Regarding documentaiton, you can find it here : http://www.portabledev.com/media/SNES/PVSnesLib/doc/ , it is generated with doxygen, based on pvsneslib source code (and examples source code).
And yes, I have no time to update wiki, sorry about that (I need help if you want ).

About background, you can't put pixel per pixel info on background, it is only tile based background and I have no time to add a pixel per pixel function to do such feature.

alekmaul wrote:Yes, you provided source code , but only for examples, not for the library itself

Oh that's probably because I downloaded the sources from all around the net to create a working toolchain for myself. Well, at least in the first place till I decided to make it available for everyone.
I used your binary-only packages as a base: http://www.portabledev.com/wiki/doku.ph ... version_en

alekmaul wrote:Regarding documentaiton, you can find it here : http://www.portabledev.com/media/SNES/PVSnesLib/doc/ , it is generated with doxygen, based on pvsneslib source code (and examples source code).

Thanks!

alekmaul wrote:And yes, I have no time to update wiki, sorry about that (I need help if you want ).

Unfortunately my spare time is a little bit limited and I'm very busy with my own hardware project.

alekmaul wrote:About background, you can't put pixel per pixel info on background, it is only tile based background and I have no time to add a pixel per pixel function to do such feature.

Okay, then I need to fine another solution to this problem, hehe.

It isn't a big deal to implement a virtual raster buffer with set_pixel, using a RAM buffer - just a few lines of code, in fact, but it'll be really slow, because a full screen update (RAM to VRAM transfer) will take about 6 frames even in 16 color mode.

Shiru wrote:It isn't a big deal to implement a virtual raster buffer with set_pixel, using a RAM buffer - just a few lines of code, in fact, but it'll be really slow, because a full screen update (RAM to VRAM transfer) will take about 6 frames even in 16 color mode.

That's not a problem. I only want to transfer single static 16 color images. Any hint how to implement this (without using assembler)?

He shiru, how do you handle such thing with 16 color mode, i'm curious. You write to tile adress and map the tiles to vram ?
I think we can reduce time if we use mode 7 with low resolution (for example 128x64 only and zoom it). Will be nice to know how to do that to have a "spout" game for example

Regarding source code, last version is here : https://code.google.com/p/pvsneslib/sou ... b%2Fsource

To transfert a complete image, just take a look at Background/Mode3 example, you've got everything to do that. You only need to have your picture with correct format.

If you want to display static images, you probably don't want a raster buffer and set_pixel, you can just convert them into tiles.

If you want to draw some static images generated in software, like vector figures or something, then you need a virtual raster buffer. I would do it with a RAM buffer (using one of the RAM banks that tcc816 is not aware of), doing raster-to-tile conversion in the set_pixel function, and updating the VRAM copy of the buffer through DMA in NMI.

Mode7 can be used, sure. It'll be easier, because tile graphics format is much simpler, it is byte per pixel rather than the bitplane pairs mess.

Shiru wrote:If you want to draw some static images generated in software

That's exactly what I want. But it sounds like that I still have a lot to learn first. I will begin with a few simpler exercises first. Thanks!