Page 1 of 1
Reading From Vram - How?
Posted: Thu Apr 14, 2005 4:00 pm
by ooPo
I'm trying to read from vram, but I'm having some trouble. Here's what gsuser_e.pdf says to do:
(wait for the GIF to become ready)
1) Enable the finish event. (CSR = 2)
2) Wait for the finish event to occur.
3) Disable the finish event. (CSR = 0)
(set the address and size of the transfer)
4) Set transmission parameters. (bitbltbuf, trxpos, trxreg, trxdir)
(perform the actual transfer)
5) Set the BUSDIR register to local -> host mode. (BUSDIR = 1)
6) Read data from the host interface.
7) Set the BUSDIR register back to host -> local mode. (BUSDIR = 0)
And here's my code:
graph_wait_finish();
// Set the transmission parameters.
dma_packet_clear(&graph_packet);
dma_packet_append(&graph_packet, GIF_SET_TAG(4, 1, 0, 0, GIF_TAG_PACKED, 1));
dma_packet_append(&graph_packet, 0x0E);
dma_packet_append(&graph_packet, GIF_SET_BITBLTBUF(address >> 8, width >> 6, psm, 0, 0, 0));
dma_packet_append(&graph_packet, GIF_REG_BITBLTBUF);
dma_packet_append(&graph_packet, GIF_SET_TRXPOS(0, 0, 0, 0, 0));
dma_packet_append(&graph_packet, GIF_REG_TRXPOS);
dma_packet_append(&graph_packet, GIF_SET_TRXREG(width, height));
dma_packet_append(&graph_packet, GIF_REG_TRXREG);
dma_packet_append(&graph_packet, GIF_SET_TRXDIR(1));
dma_packet_append(&graph_packet, GIF_REG_TRXDIR);
dma_packet_send(&graph_packet, DMA_CHANNEL_GIF);
dma_channel_wait(DMA_CHANNEL_GIF, 100000);
// local -> host
*VIF1_REG_STAT = (1 << 23); // VIF1 -> MEMORY
GS_REG_BUSDIR = GS_SET_BUSDIR(1);
// Read in the data.
dma_channel_receive(DMA_CHANNEL_VIF1, data, data_size);
dma_channel_wait(DMA_CHANNEL_VIF1, 1000000);
FlushCache(0);
// host -> local
*VIF1_REG_STAT = 0; // MEMORY -> VIF1
GS_REG_BUSDIR = GS_SET_BUSDIR(0);
When this code is actually run, it messes up the draw environment or something because all I end up with is a static screen and a buffer full of zeros.
I've been looking at the screenshot code in the debug lib inside ps2sdk, but it has never seemed to want to work for me - it locks up somewhere inside. I figured following the gsuser guide would be a better approach.
It wasn't. :)
Help?
Posted: Thu Apr 14, 2005 6:44 pm
by blackdroid
Well you have the theory correct, but uhm the screenshot code that emoon comitted to cvs worked for me ( notice worked, but I dont think anyone has messed with that code since I tried it ).
Posted: Thu Apr 14, 2005 7:10 pm
by _case
although it is sps2 (ps2linux) specific , it provides a series of steps required for 'one' way of doing it....
http://www.hsfortuna.pwp.blueyonder.co. ... /sshot.htm
may give you some insight?
Posted: Thu Apr 14, 2005 7:27 pm
by blackdroid
There is only one way of doing it anyway, good tutorial as always by mr.fortuna.
Posted: Thu Apr 14, 2005 8:32 pm
by Guest
Neov got this working in gsKit supposedly with much help from Sparky. Check with either of them and/or gsKit code. :)
Posted: Fri Apr 15, 2005 3:48 am
by ooPo
From gsKit currently in cvs, on gsMisc.c:
More debugging, a partial and incomplete gsKit_vram_dump()
So that isn't much help at the moment. As for emoon's screenshot code, it has never worked for me. It will write out the tga header then just lock solid. It even takes down ps2link to the point where I have to power off the ps2 manually. That is far from working, in my world. :)
Still, its good to know the theory is right, and I'll take a closer look at that fortuna example tonight.
Posted: Sat Apr 16, 2005 3:53 am
by ooPo
Well, finally it was figured out with the help of emoon and herben. Ends up it was tied to my dma_channel_wait function not actually... waiting. Or something like that.
Anyway, its in cvs now. Not that most of you will care as you're using the already existing screenshot function or a separate graphics lib... but I care. :)
Posted: Sat Apr 16, 2005 7:27 am
by J.F.
Where in the cvs? GSKit?
Posted: Sat Apr 16, 2005 9:36 am
by ooPo
ps2sdk/ee/graph/src/graph.c
Posted: Sat Apr 16, 2005 12:22 pm
by _case
is there a reason why there is duplicates of header files?
eg. with the file graph.c it has the includes
Code: Select all
#include <dma.h>
#include <dma_registers.h>
#include <graph.h>
#include <graph_registers.h>
commonly the 'default' include paths of the ps2dev environment would be set to something like
amongst others.
but in the case of say the graph sample it requires the includes in the subdirectories dma & graph respectivley e.g.
Code: Select all
#include <../dma/include/dma.h>
#include <../dma/include/dma_registers.h>
#include <../graph/include/graph.h>
#include <../graph/include/graph_registers.h>
is there a reason why the specific dma & graph includes are different to those found in ps2sdk/ee/include? If not, should there be a syncing up of
or better yet, just one copy of each include in only one location?
if it is the case that seperate includes are desired, then is it just a matter of ensuring that the appropiate #include path is specified in the particular Makefile in leui of the duplicate found in
etc.
please do not take this as a criticism, I am just trying to get an understanding of the src code layout and some of the requirements assumed when building.
thanks in advance.
Posted: Sat Apr 16, 2005 1:17 pm
by ooPo
The reason I can't access the ps2sdk includes in their standard location in the code is... get ready for this, you'll love it...
This code IS ps2sdk.
How can you use a standard include for something that isn't installed yet? You put in a hardcoded path to it.
Simple, no?
When ps2sdk is all compiled and installed, includes work exactly how you'd expect.
Posted: Sat Apr 16, 2005 2:48 pm
by _case
actually the graph.c i mentioned in my previous post was referring to the one found in the sample folder, NOT the graph.c required to build ps2sdk. sorry for not making that clear. :)
on getting the latest of ps2sdk, which means it's installed so to speak, i have a collection of header files in
now in the case of dma.h, if my client application wants to include it, my include path would be set to
and naturally i would just
but there is also a copy of dma.h in
which is similiar but has additional function declartions and defines. why are they not the same? are the additional declarations & defines of
there as 'privates' only required for the building of ps2sdk but never needed by client applications? or is it expected of clients to have an include path that has both paths to the different dma.h files. I guess, probably mistankingly, I was thinking of the
sample graph.c as a client of ps2sdk and should only have to refer to the
i guess the crux of my mental block on this one, is the requirement of duplicate header files which are similiar in content.
sorry for the confusion.
[/code]
Posted: Sat Apr 16, 2005 4:57 pm
by ooPo
Actually, they aren't duplicates... they're the same file.
When compiling the graph library, it needs to know where to find the dma library includes. As ps2sdk isn't installed yet, it has to use a hardcoded path to reach it. Hence things like "../dma/include/dma.h"
When installing, ps2sdk moves the ee/dma/include/dma.h into $PS2SDK/ee/include/dma.h, meaning it has been moved to the standard include path.
I think you're mixing up the two states of ps2sdk. There's a directory layout for the source and a different directory layout for it once installed. The source layout is designed to keep each part separate, for ease of development. The installed layout is designed to keep everything in one place to make standard paths for includes and libs simple. You'll find that once installed, there is no ee/dma/include/dma.h file, just $PS2SDK/ee/include/dma.h.
Does this make sense, or have I confused you more? :)
[EDIT: Fixed the pathname, oops]
Posted: Sat Apr 16, 2005 6:14 pm
by _case
bah!
i was looking at an old '.../ps2sdk/include' created with a previous 'make install', did a cvs update on this tree, then i was looking at different versions of dma.h, the 'old' one in .../ps2sdk/include and the updated version in .../ps2sdk/ee/dma/include. i was then short-circuiting the process by trying to build the sample graph.c, which of course i had to manually point at the new dma.h in .../ps2sdk/ee/dma/include because my .../ps2sdk/include still contained the 'old' dma.h, which had not been copied over. this of course, could have all been avoided by just doing a make install off the bat.
thanks for your patience and explanation.
Posted: Sat Apr 16, 2005 11:52 pm
by dlanor
ooPo wrote:You'll find that once installed, there is no $PS2SDK/ee/include/dma.h file, just $PS2SDK/ee/include/dma.h.
Does this make sense, or have I confused you more? :)
I don't know about him, but I'm definitely confused, as the two paths you mention in the quote above are identical.
I was further confused by the fact that a search through the main PS2SDK folders I have, both the 'installed' one and the CVS checkout, shows that I have no file at all by he name "dma.h". The closest match I do have is "sifdma.h" in "$PS2SDK/common/include" and apparently this file is in matching subfolder both for the installed PS2SDK and the CVS source. This lack of a file named just "dma.h" could be my fault though, for not updating to the most recent version yet (if dma.h is a recent addition that is).
Btw: I'm using the Win32 package by 'Loser'.
Best regards: dlanor
Posted: Sun Apr 17, 2005 12:00 am
by blackdroid
Its quite recent yes, update your working repository.
revision 1.1
date: 2005/03/16 07:04:35; author: oopo;
Posted: Sun Apr 17, 2005 4:12 am
by dlanor
blackdroid wrote:Its quite recent yes, update your working repository.
revision 1.1
date: 2005/03/16 07:04:35; author: oopo;
This is weird... I just tried to update it, using the 'Update' command in WinCVS, but I never got that file. When inspecting my repository folder contents I find several other PS2SDK files that were updated (as shown by modify date), but still no "dma.h". I also tried the 'checkout' command, and that too failed to add this file. I must be missing something...
(Perhaps some additional setting of WinCVS ?)
Best regards: dlanor
Posted: Sun Apr 17, 2005 4:59 am
by pixel
Posted: Sun Apr 17, 2005 9:13 am
by blackdroid
dlanor wrote:blackdroid wrote:Its quite recent yes, update your working repository.
revision 1.1
date: 2005/03/16 07:04:35; author: oopo;
This is weird... I just tried to update it, using the 'Update' command in WinCVS, but I never got that file. When inspecting my repository folder contents I find several other PS2SDK files that were updated (as shown by modify date), but still no "dma.h". I also tried the 'checkout' command, and that too failed to add this file. I must be missing something...
(Perhaps some additional setting of WinCVS ?)
Best regards: dlanor
Make sure it updates new directories
with the cli version of the cvs command you have to add the -d switch to update.
checking out a new ps2sdk repository will dl the latest and greatest, but you dont do that in a working repository.
Posted: Sun Apr 17, 2005 9:21 am
by dlanor
Thanks for the link pixel. I've downloaded the file and put it in the 'installed' $PS2SDK/ee/include, so that file is no worry anymore.
However, since WinCVS failed to download that file when it claimed to be updating the PS2SDK module in my repository, I now have more serious worries. It means that I can't rely on the content of ANY module in my CVS repository, as any of them may be missing files in the same way...
I'd appreciate any hints as to what might be causing this. It's probably something silly, like some setting I've forgot and keep missing, but until I find it I have no way of using CVS reliably.
Best regards: dlanor
Posted: Sun Apr 17, 2005 9:36 am
by dlanor
blackdroid wrote:Make sure it updates new directories
with the cli version of the cvs command you have to add the -d switch to update.
That could very well be it, although I really think that ought to be the default in WinCVS (or any CVS for that matter). After all, what would be the point of making an update that did NOT include new stuff...?!?
In any case, I'll have to search the (very slim) docs I have for how to specify that option in the GUI.
checking out a new ps2sdk repository will dl the latest and greatest, but you dont do that in a working repository.
Yes, I realize that, but when 'Update' didn't work right I was no longer sure to what extent that module was still 'working', so I tried it anyway.
Anyway, thanks for the tip. I'll try it as soon as I figure out how to do it in the GUI.
Best regards: dlanor
Posted: Sun Apr 17, 2005 10:25 am
by blackdroid
-d is to pickup new directories only. not files.
since dma.h is in ee/dma and you dont get the files it seems you dont have the dma dir at all, update -d would have solved that.
Posted: Sun Apr 17, 2005 10:55 am
by dlanor
blackdroid wrote:-d is to pickup new directories only. not files.
I understood that. But as I see it new stuff is no less important just because it's been sorted into a new subfolder. So I still think that should be the default mode for the update command. But as long as that mode can be selected, the default isn't very important.
since dma.h is in ee/dma and you dont get the files it seems you dont have the dma dir at all, update -d would have solved that.
Yes, I didn't have that folder, and I've now found out how to do it in the gui.
I misunderstood part of the text in the settings dialog earlier, because they use the same term about my local repository and the remote one on the server. It seems to be working now, though it's very slow to complete, as tons of stuff is being downloaded now that I never saw before.
Thanks again for the help.
Best regards: dlanor