Anyone coding anything?
- Thread starter slinga
- Start date
Yes.... I found the link script from the example I took it from:
Code:
org $06010000
text group
uncached_data group cache($20000000)
bss group bss
section .text,text
section .data,text
section uncached,uncached_data
section .bss,bss
include prog.obj
inclib libgcc.lib
inclib libc.lib
inclib libsn.lib
regs pc=__SN_ENTRY_POINTI did not knew where this "uncached" came from and so I did not use this special link script. Could I modify the SGL one?
Although I should be using uncached regions for some stuff, It's not necessary in all cases. I think it's because the cache got refilled completely(cache is small and the code accesses much memory while rendering).
Some WIP info on the Saturn voxel-renderer:
I implemented parts of the renderer on SCU's DSP and although I've got some experience (patch processing geometry engine, unfinished), it was a really tough job.
The DSP performs any preparation ops, and computes input data for partitioned render work, e.g. prepares dual CPU usage. Reads inputs(only move and turn speed) and writes outputs on his own.
I made a PC program which performs exactly the same ops I want the DSP to do. So I could debug and compare values using dspsim.exe(SCU DSP simulator). That works fine.
But problems arise, when I invoke it in a Saturn program. Seems to be the SH2 -> DSP communication. Can't trigger the DSP end for some reason. I also had a look at SBL's SPR and MTH libs, which both can use DSP (note: DSP must end with interrupt, otherwise DSP_CheckEnd() doesn't notice). Debugging is really difficult. All emulator are crap(my PC too) for this task, my commslink is broken, just can burn CD...
I will have to finish my GUI lib first, in order to debug efficiently on Saturn.
Next thing will be a little dual CPU lib(could be used for 32X, too). The slave is not always working, yet. I really wonder, why SEGA didn't do such thing. The SGL event system would be usable, if the events were computed by both CPUs.
VBT, maybe we should work together on this. You may find it useful for your emu. BTW: if you have to convert any image data the emu produces, you could use the DSP for that!
Hey, that's cool!
What do you mean, the DSP or the dual CPU lib?
As for the dual CPU lib, I ask everyone:
What needs should it fullfill?
Anyone got suggestions how to do it?
Let me start with the SGL event system. It's a double chained list of events, that are processed in sequence, again and again. Each event got a structure to be used for local data and it got links to previous and next events, so that values could be communicated between them this way.
The only advantage using SGL events is that the event list can be changed at runtime. The lack, in my opinion, is that events cannot be processed in parallel.
To exploit the max Saturn power, using SGL's slSlaveFunc() is not sufficient.
The slave CPU is invoked by the master. In the best case, repeatedly calling slSlaveFunc() creates a work list for the slave, but when the master is busy, the slave has to wait for work in idle mode.
Another thing is that it is an advantage to allow one CPU to already start processing the next frame (instead of waiting idle), while the other CPU finishes this frame (no inter frame dependecies). Of course we must ensure that CPUs don't pass each other several times, e.g. one is working on frame n, the other one on frame n+5.
Both CPUs share the same resources, so I say first step is to move away from master -> slave.
I propose a work list similar to the SGL event system, with the main difference that we can group independent events together for parallel processing. Imagine a flowchart, a graph or an event list, that at some places splits up into multiple parallel paths.
Both CPUs should not fight for every single piece of work, instead a processing list is set in advance for both CPUs, which is only updated at certain positions in the list and which includes points where communication to the other CPU is necessary.
This reduces CPU <-> CPU communication. We would need some sort of meter, a variable or something that gives a hint on workload difference of the CPUs, such that we can determine which and how many work pieces are shifted from the overloaded CPU to the other for the next frame.
Anyone got knowledge in workload balancing?
Connections in the work list between events may get some predicate that determine how to proceed. Something like
Code:
- just proceed your list, or
- wait for other CPU, or
- wait while (other CPU has NOT passed certain point)
then take this path, or
- if (I finished (my part of an event group) first)
let the other CPU know and proceed path 1
else proceed path 2Furthermore for some applications it may be necessary that certain events can only be processed by a certain CPU. So every event should have this property set, especially for workload balancing.
As for workload balance: it shouldn't be reduced to the library. The lib rejects whole events from busy to idle CPU. But an application has more (faster) possibilities to that.
An example: in my voxel demo, I render the screen in 2 pieces, left one on slave, right one on master. So I would have only 2 parallel events. You see there is no smart way for the lib to reject events. Of course I could divide the screen in more pieces(the DSP already can, hehe), but in cases like this, additional work is waisted just to perform this division.
Instead the app can easily balance work by varying the size of both screen pieces. The CPU which finishes earlier got it's screen piece increased, the other one decreased.
But how much I can vary, that must be told by the lib.
So we need an interface for workload balance between lib and app.
In the above case, it may be necessary to tell the lib that it should not perform the balance on his own in this region.
Noticed the similarities to petri-nets? Maybe a subset.
VBT and everyone who's interested: what do you think?
These are good news, I´m still waiting.....The last new in your web is in 2/11/2003. I´m very impressed with your work in the SX Saturn Dev Contest and I would like to see more progress in your projects becouse I´m very interested in the emus.
Only a question....Are You going to continue the development of NES emu?
Greetings
.Hope you had some nice holidays, vbt 😀 .
Personally I think the speed of your SMS emu is good.
If you could increase the compatibility a little bit to make Sonic playable :thumbs-up: .
BTW: thanks for the birthday greetings last year, hehe. I've never looked into that topic before :sigh .
Personally I think the speed of your SMS emu is good.
If you could increase the compatibility a little bit to make Sonic playable :thumbs-up: .
BTW: thanks for the birthday greetings last year, hehe. I've never looked into that topic before :sigh .
*bump*
"Anyone coding anything?"
Well, I got a ton of ideas for little 3d games and found out that It's my best option to use my Texture Coordinate stuff to ease texturing (why inventing the wheel twice?).
Well, unfortunately this involves finishing my 4th TC demo first (okay, I don't need to, but I should, I think). I didn't want to dig very deep in that direction again, so it hurts to find the motivation. Things are getting really complex and all I could do was to clean and improve the sourcecode structure.
Yesterday, I found a more up-to-date Rockin'-VR demo which allows user interaction. I almost got to the point to continue this project a little, little bit. Almost
. Instead I tried to find out the track format of SEGA Rally. Quite interesting, but my hacking knowledge is bad.
I would like to do a source and binary release for both, Rockin'-VR and the Texture Coordinate stuff.
EDIT:
I just thought that with the Texture Coordinate stuff and the filebrowser that I used in a handfull of releases, I got solutions available for two main problems that I had on my ToDo list in Rockin'-VR back in 2001/2002. Isn't this funny?
Well I really enjoy looking through the old sourcecode (though all the lacks it might have, I just got to know C in that time). I'll add the filebrowser, but texture support...not now.
"Anyone coding anything?"
Well, I got a ton of ideas for little 3d games and found out that It's my best option to use my Texture Coordinate stuff to ease texturing (why inventing the wheel twice?).
Well, unfortunately this involves finishing my 4th TC demo first (okay, I don't need to, but I should, I think). I didn't want to dig very deep in that direction again, so it hurts to find the motivation. Things are getting really complex and all I could do was to clean and improve the sourcecode structure.
Yesterday, I found a more up-to-date Rockin'-VR demo which allows user interaction. I almost got to the point to continue this project a little, little bit. Almost
. Instead I tried to find out the track format of SEGA Rally. Quite interesting, but my hacking knowledge is bad.I would like to do a source and binary release for both, Rockin'-VR and the Texture Coordinate stuff.
EDIT:
I just thought that with the Texture Coordinate stuff and the filebrowser that I used in a handfull of releases, I got solutions available for two main problems that I had on my ToDo list in Rockin'-VR back in 2001/2002. Isn't this funny?
Well I really enjoy looking through the old sourcecode (though all the lacks it might have, I just got to know C in that time). I'll add the filebrowser, but texture support...not now.
I've just realized how much unreleased VMU code I have laying around. Haven't touched VMU code for 3 years, until today. It's been cool!
So soon I will release binary & source of my latest VMU thing I've been working on, plus binary of a new B-movie😉 I created today. Oh, along with that, I think I'll add 2 more great homebrew VMU games of other authors to my website, too.
The two Saturn homebrew refreshs are almost finished. Just some bugfixing to be done on one of them and whooo, we'll have 2 new Saturn source releases.
So soon I will release binary & source of my latest VMU thing I've been working on, plus binary of a new B-movie😉 I created today. Oh, along with that, I think I'll add 2 more great homebrew VMU games of other authors to my website, too.
The two Saturn homebrew refreshs are almost finished. Just some bugfixing to be done on one of them and whooo, we'll have 2 new Saturn source releases.
slinga
Established Member
I'm working on SpriteHelp, a program to make using sprites on saturn easier. Basically you run the program in a directory of bmp files and it will automatically create the C files for you. I have it reading and parsing bmps properly, I just have to figure out how to write the data in the proper format.
I remember you were talking about that. Good to see you working on a Saturndev tool 🙂 .
With regard to make using sprites easier on Saturn, you should mind all those many ways to convert sprites, that we already have (SegaConverter, 3DEditor, BGCON, and a couple of homebrew tools). Ensure it's easier than with those tools.
I would like too see binary output in addition to C output. Maybe you can add the SBL RLE compression tool into the package and use it (or some custom compressor with decompressor on Saturn).
Please try to support Color Lookup Table format sprites. Note that the table can contain both, RGB and palette format sprites. This feature has got potential in saving VRAM.
What else? Hmm, maybe you could use a 3rd party image reading lib (like paintlib) or a 3rd party tool (ImageMagic or similar) to support multiple input formats.
Oh, that's importand: transparent color support. Along with that, you could support the end code, too. The end code can speed up display of sprites with transparent pixels.
Keep it going!
BTW: as for binary output of mixed sprites (CLUT and normal), you might have to take care about alignment of data.
