Reading From Vram - How?

Discuss the development of software, tools, libraries and anything else that helps make ps2dev happen.

Moderators: cheriff, Herben

Post Reply
ooPo
Site Admin
Posts: 2023
Joined: Sat Jan 17, 2004 9:56 am
Location: Canada
Contact:

Reading From Vram - How?

Post 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?
blackdroid
Posts: 564
Joined: Sat Jan 17, 2004 10:22 am
Location: Sweden
Contact:

Post 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 ).
Kung VU
_case
Posts: 5
Joined: Wed Apr 13, 2005 9:40 pm

Post 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?
blackdroid
Posts: 564
Joined: Sat Jan 17, 2004 10:22 am
Location: Sweden
Contact:

Post by blackdroid »

There is only one way of doing it anyway, good tutorial as always by mr.fortuna.
Kung VU
Guest

Post by Guest »

Neov got this working in gsKit supposedly with much help from Sparky. Check with either of them and/or gsKit code. :)
ooPo
Site Admin
Posts: 2023
Joined: Sat Jan 17, 2004 9:56 am
Location: Canada
Contact:

Post 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.
ooPo
Site Admin
Posts: 2023
Joined: Sat Jan 17, 2004 9:56 am
Location: Canada
Contact:

Post 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. :)
J.F.
Posts: 2906
Joined: Sun Feb 22, 2004 11:41 am

Post by J.F. »

Where in the cvs? GSKit?
ooPo
Site Admin
Posts: 2023
Joined: Sat Jan 17, 2004 9:56 am
Location: Canada
Contact:

Post by ooPo »

ps2sdk/ee/graph/src/graph.c
_case
Posts: 5
Joined: Wed Apr 13, 2005 9:40 pm

Post 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

Code: Select all

 ps2sdk\ee\include
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

Code: Select all

 ps2sdk\ee\include 
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

Code: Select all

ps2sdk\ee\include 
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.
ooPo
Site Admin
Posts: 2023
Joined: Sat Jan 17, 2004 9:56 am
Location: Canada
Contact:

Post 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.
_case
Posts: 5
Joined: Wed Apr 13, 2005 9:40 pm

Post 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

Code: Select all

...\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: Select all

...\ps2sdk\ee\include 
and naturally i would just

Code: Select all

#include <dma.h>
but there is also a copy of dma.h in

Code: Select all

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: Select all

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: Select all

.../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]
ooPo
Site Admin
Posts: 2023
Joined: Sat Jan 17, 2004 9:56 am
Location: Canada
Contact:

Post 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]
Last edited by ooPo on Sun Apr 17, 2005 7:47 am, edited 1 time in total.
_case
Posts: 5
Joined: Wed Apr 13, 2005 9:40 pm

Post 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.
dlanor
Posts: 258
Joined: Thu Oct 28, 2004 6:28 pm
Location: Stockholm, Sweden

Post 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
blackdroid
Posts: 564
Joined: Sat Jan 17, 2004 10:22 am
Location: Sweden
Contact:

Post by blackdroid »

Its quite recent yes, update your working repository.

revision 1.1
date: 2005/03/16 07:04:35; author: oopo;
Kung VU
dlanor
Posts: 258
Joined: Thu Oct 28, 2004 6:28 pm
Location: Stockholm, Sweden

Post 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
pixel
Posts: 791
Joined: Fri Jan 30, 2004 11:43 pm

Post by pixel »

pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.
blackdroid
Posts: 564
Joined: Sat Jan 17, 2004 10:22 am
Location: Sweden
Contact:

Post 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.
Kung VU
dlanor
Posts: 258
Joined: Thu Oct 28, 2004 6:28 pm
Location: Stockholm, Sweden

Post 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
dlanor
Posts: 258
Joined: Thu Oct 28, 2004 6:28 pm
Location: Stockholm, Sweden

Post 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
blackdroid
Posts: 564
Joined: Sat Jan 17, 2004 10:22 am
Location: Sweden
Contact:

Post 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.
Kung VU
dlanor
Posts: 258
Joined: Thu Oct 28, 2004 6:28 pm
Location: Stockholm, Sweden

Post 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
Post Reply