SpritesMind.Net

Hi,
cleaning my todo list, I released Gens KMod v0.7.3 today.

Lots of code optimization and rewrite.
Some bugs fixes (like the screenshot and input config crash!)
some requests

thanks to Dr.MefistO and AlyJ for their help on this one

available on
http://gendev.spritesmind.net/page-gensK.html
https://bitbucket.org/SpritesMind/genskmod/downloads, source included

Trello board (with bug and features "coming soon")
https://trello.com/b/paLV6jWH/genskmod

Thanks.

I've just launch it and begin debugging a game.

Cool news !
Are the GDB memory reads fixed or not ?

Stef wrote:Cool news !
Are the GDB memory reads fixed or not ?

Short answer :
No

Long answer :
unfortunatly no...these GDB bugs locked any more release so I moved them on my TODO list, later next year
I need to locate where is the real problem.
To do so, I need to handle every step : toolchain, lib, gdb, mix of version, cygwin vs mingw one
I also need to be handle to compile ddd on windows, since it seems Graz used it without problem

Imagine you're in a front of a door you were looking for so many years...but you're unable to find the key
Welcome in my nightmare

Ooooooo, awesome

Also some bugs :
*When you use arrow keys to move from sprite to sprite the GFX don't update, you have to click on each entry to make the GFX update.
*In VRAM view it seems the last tiles are not viewable, 71F is last tile that can be selected and viewed but there's 720...7FF too...

Request :
*Make plane explorer window not be always on top, the window is too big for a 1400x1050 screen, main window gets partially obscured...
*Buttons to select A or B in the plane explorer should be more convenient that drop-down menu.
*Sprite window should enlarge a little horizontally, so that you don't need to horizontally scroll to see the remaining parameters.
*Frequency in Hz to YM debug. FrequencyHz = YMsampleRate / (((2 ^ 14)-1) - FreqRegister) (both octave and note together, YMsampleRate is 68Kclock / 144)
*Music note view for PSG and YM debug. This chart gives the music note freqs and formulas to calculate them : http://www.tmeeco.eu/BitShit/MIDIfreqs.htm
*Would it be possible to update the GFX output to show the correct hardware colors ? viewtopic.php?f=22&t=2188

-----
Can you tell me what function is used to show graphics on the plane explorer, VRAM view and sprite view ? It seems that on Win98/ME plane explorer tilemap is shifted up so that only bottom (around quarter) of the GFX is seen in the big window, rest is obscured, VRAM view just flickers with garbage data and sprite view doesn't show the GFX.
Knowing the GFX functions would allow me to pinpoint a source for improvement in KernelEx project ~

Thanks for your feedback Tµee.
I'll try to fix some of them soon...or save it for a future one

Well I am very impressed, as advertised the source code built and ran immediately after checkout, good work!

I'm thinking of having a look at the functionality provided by Gens Tracer (and here for a better write up) and seeing if I could impliment something similar to KMod to help reduce the amount of emulators I use (and also add in a few of my own tweaks) but thought it worth checking if anything like that is planned, tried before or already in place but overlooked by myself?

I assume you know the functionality I mean, the ability to write a log of all the instructions the 68K has execute either from boot or when a certain memory address is touched.

Is there a full feature list / documentation hidden somewhere or is the comments in the source the best location for everything?

ryanfaescotland wrote:Well I am very impressed, as advertised the source code built and ran immediately after checkout, good work!

I'm thinking of having a look at the functionality provided by Gens Tracer (and here for a better write up) and seeing if I could impliment something similar to KMod to help reduce the amount of emulators I use (and also add in a few of my own tweaks) but thought it worth checking if anything like that is planned, tried before or already in place but overlooked by myself?

I assume you know the functionality I mean, the ability to write a log of all the instructions the 68K has execute either from boot or when a certain memory address is touched.

Is there a full feature list / documentation hidden somewhere or is the comments in the source the best location for everything?

If you want to debug ROMs, try to use Gensida. It already includes GensTracer functionality. Just set breakpoints to VDP, RAM, or ROM where you want.

Dr. MefistO wrote:If you want to debug ROMs, try to use Gensida. It already includes GensTracer functionality. Just set breakpoints to VDP, RAM, or ROM where you want.

But to use that I need IDA Pro and to get IDA Pro I need $1129! (£782!) As much as I love this I'm afraid I'm not at a point I can justify that.

I know Exodus also has debugging already implemented as well but I ran into issues with it crashing as soon as debugging was enabled so that has put me off for now. I'll possibly try it again down the line and / or after a few more releases.

Looks like there is going to be quite a bit of a learning curve to get to grips with this project though. The method of Starscream declaring the interface* SN##context and then Gens implementing it with main68k_exec and so forth isn't something I've worked with before and seems to be stopping me stepping through the code. Haven't had a chance to read STARSCREAM.TXT yet which may elaborate on things.

*interface might not be the right term here, method signature might be better but I'm pulling both of these from Java.

ryanfaescotland wrote:But to use that I need IDA Pro and to get IDA Pro I need $1129! (£782!) As much as I love this I'm afraid I'm not at a point I can justify that.

As I know, few month ago, the IDA's v6.8 version was leaked to public. =) But, sure, I don't mean, that you should search for it!

Dr. MefistO wrote: As I know, few month ago, the IDA's v6.8 version was leaked to public. =) But, sure, I don't mean, that you should search for it!

As a software developer I do my best not to search for such things because I wouldn't be that keen on people doing it to me. But when you put such a high price point on it for little people like myself who just want to develop games it becomes is harder and harder to resist as time goes on.

Perhaps I could download it as a trial and evaluate it to see if it is worth paying for (and if the evaluation takes 30+yrs then oh well) PS I know of the trial version but it doesn't cover 68K I believe.

i'm a big fan of IDA myself but it's clearly not "buyable"
if at least they sold 68k version only at a good price...


For you request, it will slow down a lot KMod, which is already very slow.
and i don't see a way to limit the slow effect making tracing an option
sorry

KanedaFr wrote:i'm a big fan of IDA myself but it's clearly not "buyable"
if at least they sold 68k version only at a good price...


For you request, it will slow down a lot KMod, which is already very slow.
and i don't see a way to limit the slow effect making tracing an option
sorry

That would be a great way to market it, rather than having it ALL for $1000 giving you mountains of functionality you will never need do it as smaller plugins for say $50.


Don't beat yourself up, KMod is really not that slow, at least not in my mind. It may not be running at real hardware speed when you add on the extra debugging functions but if you are running the debugging functionality then surely perfect emulation isn't the user's goal anyway? Throw in a toggle to turn it off and on and I'd take a tracer that pulls the process down to 1FPS!

(This is assuming of course the slow down effect isn't affecting internal clocks and measures of time and making the code behave differently than it should of course)

So I've been using this branch of Gens recently for projects, and have found it invaluable for ripping sprites, tiles, and palettes from VDP VRAM, and for general debugging. However, I think there is a bug in the CRAM dumping code. Dumping the entire CRAM generates a 512 byte (not 128 byte?) file, and I think the colors are not appearing correctly in palette editors (at least when attempting to view it with RetroGraphicsToolkit). Also, attempting to rip some whole sprite pieces > 1x1 under Debug>VDP - Sprites sometimes omits tiles in the output file (especially if tiles are v/hflip'd).

Is the outputted CRAM file just raw VDP RGB333 color entries, or are there other bits of extra data in the dump? (Not sure how KMod formats its CRAM dump files...)
EDIT: Screenshot of CRAM

ryanfaescotland wrote: Throw in a toggle to turn it off and on and I'd take a tracer that pulls the process down to 1FPS!

(This is assuming of course the slow down effect isn't affecting internal clocks and measures of time and making the code behave differently than it should of course)

it was my first idea but it means there is an "if" every call !
perhaps I'll need to test it...