Jump to content
IGNORED

Adventure Cartridge 80 column development and GPL


Recommended Posts

 

Now that's the style of disassembly output I am more used to! Do you recall if the source will re-assemble into the cartridge or what programs I would use to attempt it? If so, I might take my comments and 'merge' them into your files.

 

Go ahead and use them. It looks like I used TI99/Sim DUMPGROM for the disassembly and was editing it for Theirry's GPL Assembler.

 

Here's all my GPL related files. Two of the included cart images in the Dev zip are usefull for the ADV Editor program.

GPL-EA_Dev.zip

GPL_Classic99.zip

GPL_SRC_GDUMP_TI99Sim.zip

  • Like 2
Link to comment
Share on other sites

The next few weeks may not allow me much if any hobby time. So here's the current version for those interested in trying it out.

 

1. The game file title text (not the title screen) is scrolled one extra line, resulting in some missing text on row 22/23. This is a temporary side effect of the 80 column scroll routine.

2. The save/load options do NOT work properly. I have not had a chance to fix the last few memory locations, in part because I need to address number 3...

3. The largest games, i..e, IRONHEART, are just a few bytes to large for this 80 column version. This will be fixed if and when I can implement the CALL FILES(1) code.

 

 

Anyway, the cart image works with Classic99. If someone else can convert for use with real hardware, feel free to do so. With luck the the video register settings are right for the F18A and v9938.

adventure804-pabplay9a80G.bin

Edited by InsaneMultitasker
Link to comment
Share on other sites

 

Aah, it's a GROM cart with an E/A#5 header.

What is the best way to fix that? I am not sure how the original bin was created, I just used what I could find.

 

 

I built a RPK from it, but I found a problem with the screen output. This is running on the emulated TI with EVPC card (9938).

 

Hmm. Probably a bit or two set wrong in VR0/1. Can you check the value in the debugger? I'll put this on my list.

Link to comment
Share on other sites

Could that be a wrong VRAM type setting? Not only is the text doubled, but the cursor is blinking at those two locations and adding keystrokes.

 

Ah. Here are the video register settings copied from Classic99's debugger. The Adventure cartridge is only changing VR0,1, 7. Seems the TI powerup incorrectly sets some high order bits in the VRs? I'll need to add a routine to set all registers to a compatible state, and probably should clear VR8-15 to be safe.

 

VDP0 04 mode

VDP1 F0 mode

VDP2 F0 screen image

VDP3 0E color-don't care

VDP4 F9 patterns

VDP5 86 sprite-don't care

VDP6 F8 sprite-don't care

VDP7 13 color

Link to comment
Share on other sites

...and probably should clear VR8-15 to be safe.

 

Ehm, no, I would not bet on that. VR8 has the VRAM setting, for instance. I can look up some safe values. Keep in mind that the Text2 mode need not respect any compatibility constraints.

  • Like 1
Link to comment
Share on other sites

Ehm, no, I would not bet on that. VR8 has the VRAM setting, for instance. I can look up some safe values. Keep in mind that the Text2 mode need not respect any compatibility constraints.

Good point. Now that you mention this, I recall a conversation between me and Gazoo regarding a few of these registers. For many of the TI-only (9918 typically) style programs he (and I) often reset the VRs to disable blinking and other sporadic problems when used with the V9938/9958 systems. I think I first noticed trouble in the GPL program, where I added a few register changes to stop naughty programs from creating random sprites and blinking. And it may have been an improper VR8 bit that "broke" vdp banking via R14 in programs like Funnelweb.

 

I will refresh my memory by looking at the V9938 manual and if you have a few safe values, by all means please share. :)

Edited by InsaneMultitasker
Link to comment
Share on other sites

Tim, I believe you were the source (via TurboForth) for the values I use in fbForth 2.0 for the VDP registers in Text80 mode:

VR00: >04
VR01: >F0
VR02: >03
VR03: >E8
VR04: >01
VR05: >06
VR06: >01
VR07: >4F
VR08: >88
VR09: >00
VR10: >00
VR11: >00
VR12: >4F
VR13: >10
VR14: >00 

...lee

  • Like 1
Link to comment
Share on other sites

Tim, I believe you were the source (via TurboForth) for the values I use in fbForth 2.0 for the VDP registers in Text80 mode:

VR00: >04
VR01: >F0
VR02: >03
VR03: >E8
VR04: >01
VR05: >06
VR06: >01
VR07: >4F
VR08: >88
VR09: >00
VR10: >00
VR11: >00
VR12: >4F
VR13: >10
VR14: >00 

...lee

 

I compared your post with my updates to the GPL interpreter (for the Geneve) and it sets VR8 just as you show above. The color registers are set to disable blinking regardless of the fore/background color, and all the high address bit Vregisters are cleared. Didn't we have a thread once upon a time where it was recommended to first set V8-V14 then VR0-7, to minimize F18A compatibility issues? Little fuzzy on this stuff right now.

 

Oh, you and Michael may have helped track down a related TIMXT problem that Atrax reported. :)

Link to comment
Share on other sites

This is what is written by your Adventure cartridge to the video registers:

 

 

* Console startup with EVPC
 
[:ioport:peb:slot2:evpc:vdp] Write 20 to R#1
[:ioport:peb:slot2:evpc:vdp] Write 70 to R#2
[:ioport:peb:slot2:evpc:vdp] Write 0e to R#3
[:ioport:peb:slot2:evpc:vdp] Write 39 to R#4
[:ioport:peb:slot2:evpc:vdp] Write 86 to R#5
[:ioport:peb:slot2:evpc:vdp] Write 38 to R#6
[:ioport:peb:slot2:evpc:vdp] Write f7 to R#7
[:ioport:peb:slot2:evpc:vdp] Write 00 to R#1
[:ioport:peb:slot2:evpc:vdp] Write 02 to R#14
[:ioport:peb:slot2:evpc:vdp] Write 20 to R#1
[:ioport:peb:slot2:evpc:vdp] Write 00 to R#2
[:ioport:peb:slot2:evpc:vdp] Write 01 to R#4
[:ioport:peb:slot2:evpc:vdp] Write 06 to R#5
[:ioport:peb:slot2:evpc:vdp] Write 00 to R#6
[:ioport:peb:slot2:evpc:vdp] Write 08 to R#8
[:ioport:peb:slot2:evpc:vdp] Write 02 to R#9
[:ioport:peb:slot2:evpc:vdp] Write f7 to R#12
[:ioport:peb:slot2:evpc:vdp] Write 00 to R#14
[:ioport:peb:slot2:evpc:vdp] Write 00 to R#9
[:ioport:peb:slot2:evpc:vdp] Write 60 to R#1
[:ioport:peb:slot2:evpc:vdp] Write 00 to R#1
[:ioport:peb:slot2:evpc:vdp] Write 60 to R#1
 
* After selecting 2 FOR ADVENTURE 80
 
[:ioport:peb:slot2:evpc:vdp] Write 70 to R#1
[:ioport:peb:slot2:evpc:vdp] Write 4b to R#7
 
* After pressing a key, before showing "Where is the data base:"
 
[:ioport:peb:slot2:evpc:vdp] Write 13 to R#7
[:ioport:peb:slot2:evpc:vdp] Write 20 to R#1
 
* After entering the file name:
 
[:ioport:peb:slot2:evpc:vdp] Write 70 to R#1
 
* After loading, before showing "Want to restore ..."
[:ioport:peb:slot2:evpc:vdp] Write 04 to R#0
Link to comment
Share on other sites

The screen contents mirror exactly at >0400.

 

Here is what MDOS writes when booting has completed:

 

 

[:vdp] Write 88 to R#8
[:vdp] Write 20 to R#1
[:vdp] Write 00 to R#0
[:vdp] Write 04 to R#0
[:vdp] Write 30 to R#1
[:vdp] Write 03 to R#2
[:vdp] Write 2f to R#3
[:vdp] Write 02 to R#4
[:vdp] Write 00 to R#14
[:vdp] Write 70 to R#1
[:vdp] Write f4 to R#7
Link to comment
Share on other sites

  • 2 weeks later...

Ehm, no, I would not bet on that. VR8 has the VRAM setting, for instance. I can look up some safe values. Keep in mind that the Text2 mode need not respect any compatibility constraints.

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.

 

I am about out of 'hack' space within this particular GROM cartridge. I probably need to add a second GROM to the cartridge if I have any hope of finishing the changes. My attempts to set CALL FILES(1) via GPL have so far failed. I'll have to play around with this another day...

Link to comment
Share on other sites

My evil thought of the day: rewrite the Z-interprter from Infocom in GPL and make a universal Infocom loader like the universal Adventure loader we have today. It was one of those somewhat unique things the TI had BITD--and other systems didn't use an external loader, they built a loader into each adventure game. . .

Link to comment
Share on other sites

Is that lack of hack space in a 6K or an 8K image? Even so, if it needs two GROMs instead of one, that would double your work space and allow you to do almost anything you like. . .

The image was dumped as 8k but I am not exceeding the 6k boundary. If going beyond 6k doesn't really matter "any more" then it would make my life a lot easier, as I could just append my poorly contrived GPL code in that 2k segment. I really should try to use the source Torrax provided to make a cleaner version but that will have to wait...

Link to comment
Share on other sites

I think the 6K barrier does not bother anyone anymore. If we burnt GROMs, yes. But anything we are doing now is what I call "gromemu" in MAME, that is, a simulation of GROM. The GROM interpreter obviously does not care that we use 1800-1fff.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...