| View previous topic :: View next topic |
| Author |
Message |
ooPo
Site Admin
Joined: 17 Jan 2004
Posts: 2032
Location: Canada
|
 Posted: Thu Apr 14, 2005 4:00 pm Post subject: Reading From Vram - How? |
 |
|
I'm trying to read from vram, but I'm having some trouble. Here's what gsuser_e.pdf says to do:
| Quote: | (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:
| Quote: | 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? |
|
| Back to top |
|
 |
blackdroid
Joined: 17 Jan 2004
Posts: 564
Location: Sweden
|
| Posted: Thu Apr 14, 2005 6:44 pm Post subject: |
|
|
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 ).
_________________
Kung VU |
|
| Back to top |
|
|
_case
Joined: 13 Apr 2005
Posts: 5
|
|
| Back to top |
|
|
blackdroid
Joined: 17 Jan 2004
Posts: 564
Location: Sweden
|
| Posted: Thu Apr 14, 2005 7:27 pm Post subject: |
|
|
There is only one way of doing it anyway, good tutorial as always by mr.fortuna.
_________________
Kung VU |
|
| Back to top |
|
|
Guest
|
| Posted: Thu Apr 14, 2005 8:32 pm Post subject: |
|
|
| Neov got this working in gsKit supposedly with much help from Sparky. Check with either of them and/or gsKit code. :) |
|
| Back to top |
|
|
ooPo
Site Admin
Joined: 17 Jan 2004
Posts: 2032
Location: Canada
|
| Posted: Fri Apr 15, 2005 3:48 am Post subject: |
|
|
From gsKit currently in cvs, on gsMisc.c:
| Quote: | | 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. |
|
| Back to top |
|
|
ooPo
Site Admin
Joined: 17 Jan 2004
Posts: 2032
Location: Canada
|
| Posted: Sat Apr 16, 2005 3:53 am Post subject: |
|
|
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. :) |
|
| Back to top |
|
|
J.F.
Joined: 22 Feb 2004
Posts: 2906
|
| Posted: Sat Apr 16, 2005 7:27 am Post subject: |
|
|
| Where in the cvs? GSKit? |
|
| Back to top |
|
|
ooPo
Site Admin
Joined: 17 Jan 2004
Posts: 2032
Location: Canada
|
| Posted: Sat Apr 16, 2005 9:36 am Post subject: |
|
|
| ps2sdk/ee/graph/src/graph.c |
|
| Back to top |
|
|
_case
Joined: 13 Apr 2005
Posts: 5
|
| Posted: Sat Apr 16, 2005 12:22 pm Post subject: |
|
|
is there a reason why there is duplicates of header files?
eg. with the file graph.c it has the includes
| Code: |
#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: |
#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. |
|
| Back to top |
|
|
ooPo
Site Admin
Joined: 17 Jan 2004
Posts: 2032
Location: Canada
|
| Posted: Sat Apr 16, 2005 1:17 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
_case
Joined: 13 Apr 2005
Posts: 5
|
| Posted: Sat Apr 16, 2005 2:48 pm Post subject: |
|
|
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
| Code: | | ...\ps2sdk\ee\include |
now in the case of dma.h, if my client application wants to include it, my include path would be set to
| Code: | | ...\ps2sdk\ee\include |
and naturally i would just
but there is also a copy of dma.h in
| Code: | | ps2sdk\ee\dma\include |
which is similiar but has additional function declartions and defines. why are they not the same? are the additional declarations & defines of
| Code: | | ps2sdk\ee\dma\include\dma.h |
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
| Code: | | .../ps2sdk/include directory |
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] |
|
| Back to top |
|
|
ooPo
Site Admin
Joined: 17 Jan 2004
Posts: 2032
Location: Canada
|
| Posted: Sat Apr 16, 2005 4:57 pm Post subject: |
|
|
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]
Last edited by ooPo on Sun Apr 17, 2005 7:47 am; edited 1 time in total |
|
| Back to top |
|
|
_case
Joined: 13 Apr 2005
Posts: 5
|
| Posted: Sat Apr 16, 2005 6:14 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
dlanor
Joined: 28 Oct 2004
Posts: 269
Location: Stockholm, Sweden
|
| Posted: Sat Apr 16, 2005 11:52 pm Post subject: |
|
|
| 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 |
|
| Back to top |
|
|
blackdroid
Joined: 17 Jan 2004
Posts: 564
Location: Sweden
|
| Posted: Sun Apr 17, 2005 12:00 am Post subject: |
|
|
Its quite recent yes, update your working repository.
revision 1.1
date: 2005/03/16 07:04:35; author: oopo;
_________________
Kung VU |
|
| Back to top |
|
|
dlanor
Joined: 28 Oct 2004
Posts: 269
Location: Stockholm, Sweden
|
| Posted: Sun Apr 17, 2005 4:12 am Post subject: |
|
|
| 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 |
|
| Back to top |
|
|
pixel
Joined: 30 Jan 2004
Posts: 791
|
|
| Back to top |
|
|
blackdroid
Joined: 17 Jan 2004
Posts: 564
Location: Sweden
|
| Posted: Sun Apr 17, 2005 9:13 am Post subject: |
|
|
| 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.
_________________
Kung VU |
|
| Back to top |
|
|
dlanor
Joined: 28 Oct 2004
Posts: 269
Location: Stockholm, Sweden
|
| Posted: Sun Apr 17, 2005 9:21 am Post subject: |
|
|
| pixel wrote: | | http://cvs.ps2dev.org/cgi-bin/viewcvs.cgi/ps2sdk/ee/dma/include/dma.h?rev=HEAD&content-type=text/vnd.viewcvs-markup |
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 |
|
| Back to top |
|
|
dlanor
Joined: 28 Oct 2004
Posts: 269
Location: Stockholm, Sweden
|
| Posted: Sun Apr 17, 2005 9:36 am Post subject: |
|
|
| 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.
| Quote: | | 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 |
|
| Back to top |
|
|
blackdroid
Joined: 17 Jan 2004
Posts: 564
Location: Sweden
|
| Posted: Sun Apr 17, 2005 10:25 am Post subject: |
|
|
-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.
_________________
Kung VU |
|
| Back to top |
|
|
dlanor
Joined: 28 Oct 2004
Posts: 269
Location: Stockholm, Sweden
|
| Posted: Sun Apr 17, 2005 10:55 am Post subject: |
|
|
| 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.
| Quote: | | 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 |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
