Transferring Data from Petit Computer to PC
It's no secret that you can save the graphic screen to your SD card. What is the problem is that the data isn't stored flat. It actually is saved in character format, with block-sized groupings at that.
Discostew (of PTC MegaMan 2) wrote an article on the subject and Randomous reposted it here:
http://petitcomputer.wikia.com/wiki/GRP_File_Format_(External)
Well, that's fine and dandy if you want to use a separate program on the PC. What if you don't want to use a separate program on PC? Can you do the conversion right on Petit Computer? Of course. The question is: how difficult is it?
This is just an extremely simple problem. All I have to do is reverse the process, and I'd be done. Except, for some reason, I couldn't get it right. After four tries, and a whole day has gone, this is what I came up with:
- ACLS
- FN$="G0":'GRAPHIC FILENAME
- LOAD "GRP1:"+FN$,FALSE
- PNLTYPE "OFF"
- WAIT 180
- CX=0:CY=0
- FOR J=0 TO 2:FOR I=0 TO 3
- FOR Y=0 TO 7:FOR X=0 TO 7
- FOR YY=0 TO 7:FOR XX=0 TO 7
- GPAGE 0,2,2
- GPSET (I*64+X*8+XX),(J*64+Y*8+YY),CX
- GPAGE 1,3,3
- GPSET (I*64+X*8+XX),(J*64+Y*8+YY),CY
- CX=(CX+1)%256
- IF CX==0 THEN CY=CY+1
- NEXT:NEXT
- NEXT:NEXT
- NEXT:NEXT
- WAIT 60
- FOR J=0 TO 191:FOR I=0 TO 255
- GPAGE 1,2,1
- X=GSPOIT(I,J)
- GPAGE 1,3,1
- Y=GSPOIT(I,J)
- GPAGE 1,1,1
- C=GSPOIT(I,J)
- GPAGE 0,0,0
- GPSET X,Y,C
- GPAGE 1,1,1
- 'GPSET X,Y,0
- NEXT:NEXT
- WAIT 600
That's a two-step process. First, I load the graphic on the bottom screen, and encode the coordinates on GRP2 for x-coordinates, and GRP3 for y-coordinates. Then I use such coordinates to re-arrange the points on the top screen. You see such convoluted GPAGE commands because I'm switching back and forth among the different pages.
It works, but hardly elegant. The problem is that for some reason, my brain just can't wrap around the problem. Intellectually, I know the problem is a simple referencing problem. A pointer problem, for those of you doing in C programming language. And yet, the answer eludes me.
It's not until I'm at McDonald, getting my StreetPasses, warm and fed, that my brain functions again. Of course, after so many tries to the problem, my brain did start to warm up to the problem.
It was so trivial. I sketched the solution on the back of the receipt, and five minutes later, I was done! Here is what I came up with:
- LOAD "GRP1:FILENAME",FALSE
- PNLTYPE "OFF"
- GOSUB @SCAN
- 'SAVE GRP0 here...
- END
- @SCAN
- CX=0:CY=0
- FOR J=0 TO 2:FOR I=0 TO 3
- FOR Y=0 TO 7:FOR X=0 TO 7
- FOR YY=0 TO 7:FOR XX=0 TO 7
- GPAGE 1
- C=GSPOIT(CX,CY)
- GPSET CX,CY,0
- GPAGE 0
- GPSET (I*64+X*8+XX),(J*64+Y*8+YY),C
- CX=(CX+1)%256
- IF CX==0 THEN CY=CY+1
- NEXT:NEXT
- NEXT:NEXT
- NEXT:NEXT
- RETURN
Quite a big difference, wouldn't you say? I had all the pieces all along, and when I compared the solution on the receipt with my code, I realized that the code had it backwards. All I have to do then is to just switched the direction the coordinates was transfered! That's it.
Well, except it doesn't work, and Discostew pointed out that my latest code did double encoding, and the original "erroneous" code was right to begin with! Oh, well. So read in linear, and output blocks!
That's a reference, or pointer, problem. And guess what? As a programmer, you have to understand the concept of "reference". Like finger pointing to the moon. You look at the moon, instead of the finger. Simple, isn't it? Yet, so many people are confused.
So much so, that people are leaving C programming language for something easier to program. By that, they mean a programming language that does not use pointer. Guess what? The concept of reference is so universal in programming, it exists even in a pointer-less language such as BASIC.
Therefore, I say, you must learn the concept of pointers. If you don't, you just limit yourself to the problems you can solve.
Oh, and about this? I don't know why I was having such troubles. But I did solve it, and that's the important thing. The next time such a problem come up again, I'll be ready.
