Jump to content

Photo

Adventure Cartridge and GPL

Adventure GPL F18A

60 replies to this topic

#51 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • Topic Starter
  • 2,164 posts

Posted Sun May 20, 2018 7:11 PM

Sounds like a plan, guys.  I will give it a whirl when my next opportunity comes available.


  • RXB likes this

#52 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,826 posts
  • Location:Denmark

Posted Sun May 20, 2018 11:40 PM

I added GPL code to set VR02 to >03.   One thing I have not considered is the F18A 80 column mode as that might require being cautious with the register order.  I forget whether or not the F18a must be unlocked to enable 80 column mode; if not, then VR8-15 order becomes more important.

 

You don't have to unlock the F18A to use the 80 columns mode.



#53 matthew180 OFFLINE  

matthew180

    River Patroller

  • 2,536 posts
  • Location:Castaic, California

Posted Tue May 22, 2018 6:43 PM

Writing to VR8..VR14 will not bother the F18A while it is locked, and when unlocked only VR10 and VR11 are used; and then only if Tile-Layer 2 is enabled.  Even VR15 might be ignored while the F18A is locked, but I need to check the HDL.  But writing 0 to VR15 is always a safe value.


  • RXB likes this

#54 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • Topic Starter
  • 2,164 posts

Posted Tue May 22, 2018 9:43 PM

Writing to VR8..VR14 will not bother the F18A while it is locked, and when unlocked only VR10 and VR11 are used; and then only if Tile-Layer 2 is enabled.  Even VR15 might be ignored while the F18A is locked, but I need to check the HDL.  But writing 0 to VR15 is always a safe value.

Thanks Matthew.  I took a quick look at TIMXT's routines today and came to the realization that my F18A/V9938 detection routine is flawed.  When used with a V9938 system, TIMXT sets VR#2 to the unlocked value, which results in a weird split screen effect similar to what Michael posted a few days ago in this thread.  Now it all makes sense (again). 

 

I learned how to set each VR value individually using GPL, so my next challenge is to figure out how to loop through the registers.  GPL is sort of like a cross between BASIC and Assembly; once you learn syntax its not all that bad either :)



#55 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,316 posts
  • Location:Germany

Posted Wed May 23, 2018 7:28 AM

One obviously safe detection method is to query status register 4, at least to tell apart TMS9918A and v9938. SR4 returns one of two values, 0xFE or 0xFF. Since the 9918A only has one status register, it will return its value, and it is highly unlikely that you get FE or FF from it, and impossible if you have less than 5 sprites on the screen. You need to check with the F18A, of course.

 

To read SR4, you have to set video register 15 to 4 and then read via the status register port. Remember to reset VR15 to 0 afterwards.



#56 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • Topic Starter
  • 2,164 posts

Posted Wed May 23, 2018 9:35 AM

One obviously safe detection method is to query status register 4, at least to tell apart TMS9918A and v9938. SR4 returns one of two values, 0xFE or 0xFF. Since the 9918A only has one status register, it will return its value, and it is highly unlikely that you get FE or FF from it, and impossible if you have less than 5 sprites on the screen. You need to check with the F18A, of course.

 

To read SR4, you have to set video register 15 to 4 and then read via the status register port. Remember to reset VR15 to 0 afterwards.

 

I don't recall ever seeing (or trying) this detection method.  Seems nice and simple.  Typically, I have used VR14 to flip between two different VRAM banks, writing values then comparing the two banks.   In TIMXT I am trying to detect the F18A, which used to work, so maybe I goofed up elsewhere.  More research required.  

 

fortunately, there is little need to detect the 80 column support type in the Adventure cartridge.  I had considered adding some color to the status area but unlike Infocom, the status window is dynamic.  And this is Adventure after all... :)  



#57 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,316 posts
  • Location:Germany

Posted Wed May 23, 2018 9:53 AM

I don't remember where I saw it; at least it required me to fix that status register in the MAME implementation.



#58 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • Topic Starter
  • 2,164 posts

Posted Sun Jun 3, 2018 1:07 AM

I reviewed the TI Writer GPL source and found the lines that should perform a CALL FILES(1) using the GPL subroutine >16.  I understand the CALL and the moves in memory.  I don't quite understand how >8381 plays into the call.  I'm thinking that for my purposes, all I need to do is call the routine and let the chips fall where they may.  If there is an error, I don't care, and it wouldn't really make any difference. 

 

Anyone have insight into 8381?   The next question is how do I turn this into GPL code?   I also included what looks like an efficient way to set all the VDP registers.

 

6342   CALL  G@>6663              |call files routine
       BYTE  >01                  | (1 file)
       BS    G@>6686               error   (maybe for Adventure we don't care if this works or not)

6663   FETC  @>834C                # of files (from CALL)
;       ST    >01,@>834C (can use this instead of byte after CALL)
       DST   >0116,V@>077E "pab" for these two bytes
       DST   >077E,@>8356 pointer for subroutine call
       ST    >EE,@>8381  not sure why we set this? what is 8381?
       CALL  G@>10                |link sub [16]
       BYTE  >0A                  |

       BS    G@>6682               error
       ST    @>8350,@>8381
       CZ    @>8381
       BR    G@>6682               status error
       RTN
6682   CEQ   @>8300,@>8300         return with error
       RTNC

; VDP registers set all at once (versus one register at a time)

60EA   MOVE  >07,G@>68BB,#>01      set VDP regs 1-7
68BB   BYTE  >20,>00,>0E,>01       VDP registers 1-7
       BYTE  >01,>06,>00,>F5



#59 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

  • 3,704 posts
  • Location:Silver Run, Maryland

Posted Sun Jun 3, 2018 6:14 AM

I reviewed the TI Writer GPL source and found the lines that should perform a CALL FILES(1) using the GPL subroutine >16.  I understand the CALL and the moves in memory.  I don't quite understand how >8381 plays into the call.  I'm thinking that for my purposes, all I need to do is call the routine and let the chips fall where they may.  If there is an error, I don't care, and it wouldn't really make any difference. 

 

Anyone have insight into 8381?   The next question is how do I turn this into GPL code?   I also included what looks like an efficient way to set all the VDP registers.

 

>8381 is the second byte of the default subroutine stack space, >8380 – >839F, with LSB of stack pointer at >8373 (followed by the default data stack space, >83A0 – >83BF, with LSB of stack pointer at >8372).

 

Re >8381, it could be that TI Writer uses the first stack position as free space and views the bottom of the stack as >8382  It certainly looks as though the second use of >8381 is viewed as free space.  I cannot figure out the storage of >EE at >8381, either.

 

...lee



#60 RXB OFFLINE  

RXB

    River Patroller

  • 3,254 posts
  • Location:Vancouver, Washington, USA

Posted Sun Jun 3, 2018 12:53 PM

TI Intern page 80:

"GPL uses essentially the area of the CPU-RAM's >8372 through

>83FF. The work space for the GPL interpreter is located at 8370.
The pointer for the GPL data stack is located at >8370 and the
pointer subroutine stack is located at 8372. The complete address
for the stack consists of the pointer plus >8300. Usually the ROM
area >8380 through >83BF is used for the stacks."
 
>8380 is Register 0 of the GPL Stack space.and >8381 is the LSB of Register 0
The OS ROM will scan update R0 and mask the byte at >8381 and when it returns to GPL
CZ    @>8381 looks for zero and if not jumps to >6682     CEQ   @>8300,@>8300
this resets the GPL STATUS >837C
RTNC is GPL code to return with no change to >837C to the caller.
 
Now if >8381 is zero it just returns normally back to caller and >837C is reset.

Edited by RXB, Sun Jun 3, 2018 12:55 PM.


#61 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • Topic Starter
  • 2,164 posts

Posted Sun Jun 3, 2018 1:35 PM

Thanks Rich and Lee.  I think it is safe not to worry about the >EE stored in >8381.  My next challenge is how to get the code to assemble. The TI Writer GPL code syntax seems to be different than the disassembly of the Adventure cartridge.   Is there a GPL toolkit available?   I have some things RXB sent me but I'm still confused on how to turn this into a properly assembled image file.







Also tagged with one or more of these keywords: Adventure, GPL, F18A

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users