Jump to content
JonB

Adventure cartridge

Recommended Posts

On 9/14/2019 at 9:52 PM, arcadeshopper said:

note: Return to Pirate's isle on the TI-99/4a was the first "graphic adventure" sold (according to Scott Adams) 

I'm pretty sure that means Scott Adams' first Capital A graphic "Adventure."

 

It was pretty late to the game, as Sierra had pioneered graphic adventures with Mystery House in 1980, and Wizard and the Princess was known widely on the Apple II. 

Share this post


Link to post
Share on other sites

The FINDEX program recent posted in the Cassette Power! thread could arguably be expanded in this capacity, just with lots of user intervention.

 

It already puts a small index data block at the front of the cassette (it stores 10 records), but uses a fixed indexing schema.   If instead you put the tape load routine at the start of the tape (and you already know how large this routine is, so you can reliably skip it to get to the index right after it from a freshly rewound tape), you can get the indexer into memory reliably, then you can get the index into memory reliably, and from there, you can get to any file on the cassette reliably.

 

If I wasnt so horribad at programming, I would look into writing a more advanced DSR for the TI that can handle arbitrary files...

 

DSRs are out of my league, but I can probably improve his indexer to have arbitrary number of indexes, with proper (not fixed) location seeking.  You just need to have a routine that holds cassette motor control line low, and count a desired number of seconds, then raise it high. (then prompt user to press stop.)

 

The user would have to know how large a program is in memory. (There's an extended basic command that will return memory free, which can tell you the size of the loaded program, but sadly it does not live in stock ti basic.) This would complicate adding an index, but that's fine.  You could get many more programs per tape, and could seek reliably.  His program already seeks pretty damn reliably with its fixed indexes. Just, if you have a REALLY large program, I cannot guarantee it wont go past his fixed index position boundary.

 

 

(See the cassette power thread.  I gave better instructions on how to set up tapes to use that indexer, because the vintage documentation is rather incoherent, and rambling. It does not explain how to use the program acceptably, IMO.  However, once you set up the tape with the indexer in position 1, you have room for 9 more programs (or adventure modules) on that cassette, and the stock indexer already has a means of putting 3 comments on the tape, allowing you to indicate which, if any, programs at the fixed indexes are adventure scenarios.)

 

 

Edited by wierd_w

Share this post


Link to post
Share on other sites

Hi.  I have recently unearthed my old TI99/4A and challenged my grandchildren with Scott Adams Adventure games.  They were fascinated but soon lost interest because of the need to frequently reload the data bases from tape!  (Lack of instant gratification!!!) I have a PEB with working disk drive and would like to transfer the data tapes to disk to speed up the data load but cannot find a way to do it with standard TI kit.  The disk drive manual suggests a simple basic program to transfer data from cassette to disk... open a cassette file and a disk file, input a record from the tape, write ('print') record to disk file and loop until done.  Unfortunately it fails at the first line... 100 Open £1: "CS1" (read 'hash' for the £ sign) because Ext Basic requires file parameters before it accepts the command and I have no idea what the cassette file parameters are.. or whether the records are numerical or strings.  Even if I knew, I am not clear how this simple program can synchronise reading the records with the writing unless the whole tape is a single record.   The files are not 'PROGRAM' type because you cannot load them with OLD.

 

Anybody come across a solution to this? 

 

David

Share this post


Link to post
Share on other sites

Yeah, they are PROGRAM image files, I don't think there's a way to move them to disk with XB. (Maybe there's already a copy tool out there somewhere?)

 

Do you have a way to get disk images from the internet to your TI? The files are all available that way.

 

  • Like 1

Share this post


Link to post
Share on other sites

This is one of my first assembly language programs: Copy an adventure to disk. I call it "Avdenture" because of a typo I made when renaming the file.

 

**** ADVENTURE COPY ****
 
       DEF  COPY
       REF  VWTR,DSRLNK,VMBW,GPLLNK
 
PABDAT DATA >0500,>0AD0,>0000,>30C0,>6003
CS1    TEXT 'CS1'
PAB2   DATA >0600,>0AD0,>0000,>30C0,>000D
       TEXT 'DSK1.SAV-ISL2'
 
COPY   LI   R0,>834A
       LI   R1,CS1
       MOVB *R1+,*R0+
       MOVB *R1+,*R0+
       MOVB *R1,*R0
 
       LI   R0,>03A0
       LI   R1,PABDAT
       LI   R2,13
       BLWP @VMBW
 
       LI   R0,>03AD
       MOV  R0,@>8356
       LI   R0,3
       MOV  R0,@>8354
       CLR  @>83D0
       LI   R0,>0800
       MOVB R0,@>836D
       CLR  @>837C
 
       BLWP @GPLLNK
       DATA >003D
 
       CLR  @>837C
       LI   R0,>03A0
       LI   R1,PAB2
       LI   R2,22
       BLWP @VMBW
 
       LI   R0,>03A9
       MOV  R0,@>8356
 
       BLWP @DSRLNK
       DATA 8
 
       RT
       END

  • Like 4
  • Thanks 1

Share this post


Link to post
Share on other sites

Wow! Am I glad I joined this forum! Great stuff. Many thanks Tursi and Home Automation for your helpful responses.  Yes I do have Editor/Assembler cartridge and will gratefully type in your code, mizapf... thanks so much. 

I had every intention of mastering TI Assembly Language in the 80's but a young family and the appearance of IBM PC's, DOS and the great DEC microvax systems kind of put the kibosh on that aspiration... the manual remains on its shelf barely opened. Time to dust it off!

Share this post


Link to post
Share on other sites

I have some pretty ancient hardware, Tursi but none with 5.5in disk so my TI is isolated from the net unfortunately but thanks for the suggestion.

  • Like 1

Share this post


Link to post
Share on other sites
12 minutes ago, diydave said:

I have some pretty ancient hardware, Tursi but none with 5.5in disk so my TI is isolated from the net unfortunately but thanks for the suggestion.

Fyi there's a new device out that will resolve this issue easily.   if you are interested..  also allows your TI to natively telnet, "browse the internet" grab files from websites/ftp  etc.. 

https://www.arcadeshopper.com/wp/the-ti-raspberry-pi-connection/

 

also I'd be happy to copy my adventures disk and mail them to you if needed.. lmk

 

Greg 

  • Thanks 1

Share this post


Link to post
Share on other sites
2 minutes ago, arcadeshopper said:

Fyi there's a new device out that will resolve this issue easily.   if you are interested..  also allows your TI to natively telnet, "browse the internet" grab files from websites/ftp  etc.. 

https://www.arcadeshopper.com/wp/the-ti-raspberry-pi-connection/

 

also I'd be happy to copy my adventures disk and mail them to you if needed.. lmk

 

Greg 

Thanks Greg. I'll bear that in mind.

David

Share this post


Link to post
Share on other sites
14 minutes ago, diydave said:

Thanks Greg. I'll bear that in mind.

David

No problem. Keep us in the loop if you are able to convert them?


Greg

Share this post


Link to post
Share on other sites

Note that this is a really simple program; it does not even find out the correct length. It seems to be fixed to 30C0 (obviously for Savage Island 2); you may have to experiment a little by using smaller values until the cassette fails to load.

 

(I think I was about 15 years old when I wrote it ... now I'm almost 51)

  • Like 1

Share this post


Link to post
Share on other sites

Thanks mizapf.  Its going to take my 78 year old brain some time to catch up with your 15 year old one but I am enjoying the challenge!  I am trying your prog out on The Count, writing to 'dsk1.countdat' which has the same word length as your sav-isl2 file so do not expect that to be an issue.  Not at all clear yet about file length (is >30C0 a finishing address?).  I do have an immediate problem you may be able to help with however.  I have assembled your prog without errors and the object file loads back in correctly but when I try to run it, entering COPY, I get a 'program not found' error.  I note the COPY label at line 7 has an LI on the same line... should the program label be on a blank line to stop this?  (I haven't yet found how to get the editor to insert a blank line into the source code to test this; RETURN just acts like Funct DOWN and Funct INSERT seems to affect only individual letters/numbers!)

 

Other points demonstrating my ignorance... a)Lines 9 and 10 (MOVB *R1+,*R0+) are identical... correct?  I assume this section loads 'CS1' character by character into Workspace?) 

                                                                b)LI R0,>03AD, line 16 is intentionally not LI R0,>03A0 per lines 12 and 27?  (because the former refers to the Cassette DSR PAB and the latter 2 to the Disk DSR?)

                                                                c)What length is being defined by 'LI R2,22' in line 29?

Cheers

David

  • Like 1

Share this post


Link to post
Share on other sites

Update.  Found how to insert a line. Gave 'COPY' label its own line and reassembled. No joy but I now don't think the program name is the issue as the  Error Message is now 0D  "Unresolved references".  I note VWTR is referenced but not used in the program. Is that relevant?

Share this post


Link to post
Share on other sites

a) This section copies "CS1" to >83D4 in SCRATCHPAD. This is required by the cassette DSR.

 

b) The cassette DSR and the disk DSR use different conventions to locate the PAB.

 

c) This section copies the entire PAB(PABDAT) including the device's TEXT name "CS1" to VDP RAM.

 

I assembled and ran this successfully, although I didn't actually convert a game file.

 

LOAD.thumb.JPG.6a2370ebbf96164bd535796b701b133a.JPG

 

RUN.thumb.JPG.ff2f56c89daf80e5238ef6310fda8cb6.JPG

 

RUNNING.thumb.JPG.12f43a89913b652b007f09abd83a64b8.JPG

 

This was probably meant to run from BASIC or EXTENDED BASIC. The cassette prompts were not visible. Changing Byte 08...

 

PABDAT DATA >0500,>0AD0,>0000,>30C0,>6003
CS1    TEXT 'CS1'

 

to:

 

PABDAT DATA >0500,>0AD0,>0000,>30C0,>0003
CS1    TEXT 'CS1'

 

will allow prompts to display from E/A's RUN options.

 

Edited by HOME AUTOMATION
'
  • Like 2

Share this post


Link to post
Share on other sites

The VWTR is obviously not used, you can remove that ref. As I used the >60 offset, it seems as if this program was meant to be started from TI BASIC (not Extended Basic!) with plugged-in Editor/Assembler cartridge by CALL LOAD("DSK1.COPY") and subsequent CALL LINK("COPY"). If you run it by Editor/Assembler's LOAD AND RUN, you have to set the offset to 00.

 

You can choose any file name, it does not depend on the DEF.

 

I guess you mean "DSK1.COUNTDAT". People easily get spoilt by DOS/Windows' case insensitivity; the TI is case-sensitive ("dsk1" != "DSK1").

 

The COPY label should be in the LI line. If you put it before, it may reference an unaligned address if the previous TEXT has an odd number of characters. Insert an EVEN after the TEXT line to make sure.

  • Thanks 1

Share this post


Link to post
Share on other sites

Update 2.  First thanks to all for great help. I am beginning to get to grips with the concepts.

 The Unresolved References error was a typo on my part.  I now have two versions of the assembled program up and running, one from E/A and the other from TI Basic with E/A cartridge in place.  Both correctly load the file from CS1 ending with the usual prompt "Data OK, Press Cassette Stop and then press ENTER."   

On pressing 'ENTER':-

If running from TI Basic (cyan screen throughout) it then returns to a standard Basic prompt '>'.

If running from E/A 'load and run' (colors as in H Auto above) the screen reverts to blue with a 'Press any key to continue' prompt: doing so returns to the normal E/A options screen. (At no point does the disk run).

Subsequent attempts to 'save' to DISK anything that has been loaded at that point fail in either scenario.

 

Its almost as though the program has run on and finished while the cassette is loading.... is a 'PAUSE' until the cassette has finished loading required or is this a case of adjusting the 30C0 value referred to above?   I did try and COPY Savage Island to check but this behaved similarly when loading Sav Isl 1 and gave a quick 'Error in Data' if starting the tape at where a second file (Sav Isl 2?) appears to start shortly after Sav Isl 1 finishes. ( I never got as far as part 2 all those years back!!)

 

Apologies if I am overstaying my welcome but any guidance ideas would be most welcome.

 

Cheers

David

  • Like 2

Share this post


Link to post
Share on other sites

The cassette DSR, prompts the user to operate the cassette players/recorders buttons.
(personally, I find this behavior ...most annoying):x

 

The disk DSR runs seamlessly(no prompts)

 

Sooo...

 

You should have a preformatted disk, with enough free space, inserted in the disk drive, before pressing ENTER, after the cassette prompts "DATA OK".

  • Thanks 1

Share this post


Link to post
Share on other sites

Thanks H A.  Yes, I thought of that and had an appropriate disk in place before pressing ENTER.  But there was no disk drive action at all on doing so, just a return to TI Basic or E/A. (My subsequent attempts at a save after the program terminated were just experimental to see if anything that had been loaded from CS1 was independently saveable.)

 

I note that the total length of PAB2 + DSK1.SAV-ISL2  would appear to be 23 bytes if the 'period' in the file name counts as a byte. But line 29 indicates 22 bytes. Could this be an issue?

 

Could I check for some disk action by taking out the PABDAT and CS1 related lines from the program, leaving just the DISK DSR related lines and running those?

 

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

The 22 is wrong, should be 23. This means it will take the byte that happens to be at that video location; could be an invalid character.

My apologies for this very crude solution of mine; as I said, this is a very early work of my assembly language career, lots of checks missing. I can work over it once more this evening.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Don't apologise mizapf... I'm learning fast!  You were clearly a prodigy!

BINGO! Changing the 22 to 23 in line 29 (thanks H A for explaining the purpose of that section) did the trick and The Count datafile loaded back in when requested by the Adventure Cartridge.  Nothing fundamentally wrong with your early work miz!  Just shows how precise Assembly Language has to be.

 

For my own education, if you have the time, 

a) What does changing byte 9 in the PABDAT data (the 'offset') from 60 to 00 actually do to get the prog to run under the different scenarios (TI Basic or E/A)?

b) Can you elaborate on the '>30C0' issue?   What is that entity actually controlling and what would be the effect of varying it and by how much?

 

Cheers

David 

Edited by diydave
  • Like 2

Share this post


Link to post
Share on other sites

I just tried it, and as I see, you already got it running. I can confirm that the length byte was wrong. One thing annoys me; there seems to be no way to find out how many cassette bytes have been read.

 

(Actually, I thought that disk DSRs return the actual number of read bytes, but a quickly written test program proved me wrong. Maybe someone here remembers how to get the number of read bytes.)

 

As for your questions:

 

a) In TI BASIC, the character table is shifted in VDP RAM to save space. Hence, the codes of the characters on the screen are shifted as well. A space character in TI BASIC does not have the ASCII code 0x20 but 0x80 instead. All character codes are offset by 0x60.

 

TI BASIC's CALL GCHAR actually considers this and subtracts the 0x60, while any print operation on the screen adds 0x60 to each character before it gets on the screen.

 

The only problem occurs when a machine language program is executed from TI BASIC (using CALL LINK). Now the BASIC interpreter cannot correct the values because you directly work with the video processor. All this would not really pose a problem for device access if there were not the cassette DSR with screen text. So the TI engineers added a "bias value" into the PAB which corrects the output by adding 0x60 to the screen texts.

 

This means that if you start the program directly from Editor/Assembler, the bias value must be 0x00, but when you start the program from TI BASIC, it must be 0x60.

 

b) The 0x30C0 is the maximum number of bytes to be loaded. If this value is smaller than the size of the file, you get a load error immediately. I used 0x30C0 so that the buffer for the loaded bytes goes from 0AD0 to 0AD0+30BF = 3B8F.

 

Aha ... and now I know why I ran it from TI BASIC. It all makes sense at the end. I had to use TI BASIC's command CALL FILES(1) to push up the highest usable video RAM location. When you start Editor/Assembler, this highest address is 37D7 (corresponds to CALL FILES(3)), which is lower.

 

As I said above, I did not find a way to determine the true length of the cassette file, so I may have experimented with different values until they matched.

  • Like 3

Share this post


Link to post
Share on other sites

Thanks miz.  Very helpful, though I don't, yet, quite grasp all the implications. Suffice it to say your prog works from E/A as is (notwithstanding the lower max video ram address) so at the  moment its a case of "if it works, don't fix it".

I shall continue to play with the TI Basic version by way of appreciating these variables and will keep an eye on this forum to see if anybody comes up with a way of measuring those file bytes.  At the moment I am just relieved to find that the Cassette DSR has to complete its operation before the rest of the program continues!

Cheers.

Share this post


Link to post
Share on other sites

Into every life a little luck must fall... it seems I was very fortunate in getting the program to work with The Count' via E/A (and via TI Basic) because it failed with Savage Island.  Fortunately, however, Mizapf's memory came to the rescue with his timely recollection that a CALL FILES(1) was needed (only possible via Basic) to handle what must be  larger Savage Island files.  The Count file must have just neatly fitted below the 37D7 limit.

Nothing like errors to improve understanding!

  • Like 1

Share this post


Link to post
Share on other sites

There is another, even better way: Michael Weiand's Adventure Editor. It can load and save all Scott Adams Adventures, and it also fixes some issues in the original files.

Share this post


Link to post
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.

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...