Jump to content
IGNORED

in praise of the F18a


hloberg

Recommended Posts

@hloberg: Can you get some numbers for me. Put in either mini memory or editor assembler. Go to BASIC, then CALL FILES(3). Then CALL PEEKV(16376,A,B,C,D,E,F,G,H). PRINT A;B;C;D;E;F;G;H and report the results here. Thanks, I'm pretty sure we can figure this out.

 

The results for my nanoPEB v1 are

170  3  0  10  0  9  0  6

When I run fbForth v1.0, (which starts up with FILES = 3), and read >3FF8 – >3FFF, I get precisely the same thing, which in hex is

AA03 000A 0009 0006

Those 8 bytes remain the same regardless of changes to the number of files allowed simultaneously. I changed to FILES=1 and FILES=4 with no change in those bytes for both TI Basic and fbForth.

 

The high 3 words correspond to the DSK volumes that are mounted for each of DSK1 (>000A), DSK2 (>0009) and DSK3 (>0006). I do not know what the word (>AA03) at >3FF8 represents.

 

...lee

Link to comment
Share on other sites

This is a creative and undocumented use of the disk buffer space. When you do a CALL FILES(n) the TI allocates disk space working down from V3FFF and sets >8370 to point to the first available memory space below the 5 byte header. That pointer lets XB know where the stack should start and probably is what tells the disk system where the buffers can be found. I discovered that by moving that 5 byte buffer I could put it where I wanted instead of where TI thought it should be. The disk buffers are indexed to the pointer so they just go along for the ride. This way TML can reserve space for disk buffers AND buffers for all the bit mapped stuff. What happens when TML starts up is that it copies the TML routines from high memory to low memory, starts up an interrupt routine, does the call files, moves the aforementioned header, changes the pointer at >8370, erases the loader program and returns to XB. The TI then goes about business as usual with no clue that the pointers are "wrong". It can load and save programs and doesn't seem to care about the changes. Note that this applies to the TI and Corcomp disk controller. The Myarc controller is a different animal - it is not indexed to the header. It is indexed to >3FFF so the buffers don't move with the header. So TML has to be mapped diffferently for the Myarc controller. It may be that CF7 works like the Myarc controller or maybe completely differently from either one.

For a clue, look for my write-up in the forum regarding CF7 and FunnelWeb and CF7 devices. I had to modify FunnelWeb's startup sequence to avoid the eight bytes used by the CF7 as its disk indices.

Link to comment
Share on other sites

For a clue, look for my write-up in the forum regarding CF7 and FunnelWeb and CF7 devices. I had to modify FunnelWeb's startup sequence to avoid the eight bytes used by the CF7 as its disk indices.

 

That would be here.

 

...lee

 

{EDIT: Oops! I had the wrong post! Sorry...}

Edited by Lee Stewart
Link to comment
Share on other sites

I remembered right - TML clears out all the video memory up to >3FFF. Here's one more thing to try:

CALL INIT
OLD DSKn.TML
CALL LOAD(-7283,13)

CALL LOAD(-7237,14)
RUN
and then try loading and running TMLDEMO

This will avoid overwriting those 8 bytes at the top of VDP memory.

If it doesn't do the trick then I'll have to read up on the CF7.

Link to comment
Share on other sites

I remembered right - TML clears out all the video memory up to >3FFF. Here's one more thing to try:

CALL INIT

OLD DSKn.TML

CALL LOAD(-7283,13)

CALL LOAD(-7237,14)

RUN

and then try loading and running TMLDEMO

This will avoid overwriting those 8 bytes at the top of VDP memory.

If it doesn't do the trick then I'll have to read up on the CF7.

didn't work.

Link to comment
Share on other sites

I will write a simple program that remaps the VDP the way TML and XB256 expect. I will fully comment it so it can be understood and then post it here so that someone who actually has a CF7 can determine if this can be done. Also, does TML run when there is no disk access? The one line circle drawing program in post #6 should be enough to know.

Link to comment
Share on other sites

OK, I'm ready to throw this effing computer in the trash. I wrote the test program mentioned above. Standard assembly language, nothing unusual. It assembles fine, but cannot load in XB - I keep getting an "unrecognized character" error. I have looked closely at the program and can see nothing suspicious. When running under TI BASIC using the E/A cartridge it loads and runs fine with no complaints from the computer. WTF!!! I've attached the source code. Can someone explain to me why this keeps giving this error.

CF7TEST-S.zip

Link to comment
Share on other sites

Come now, I'm not exactly a newbie at this. I wish it were that simple. I tried assembling both compressed and uncompressed, and the files are clearly different from each other. I transferred everything over to Win994a and the results are exactly the same. Maybe it's my equipment telling me I need to get another hobby. Why don't you try assembling and loading and see if you get the same results.

Link to comment
Share on other sites

If it does the same thing in WIN994A, it isn't an equipment problem. It is probably something really subtle in the code that will have you smack your head in disbelief once you do find it. I don't know enough Assembly to help more than this, I'm afraid, but I'm sure that one of the programming gurus will find it in short order.

 

It sounds like it is about time for a relaxing brew! :)

Link to comment
Share on other sites

Thank you, that is the answer-I forgot that you had to supply the addresses for VSBW etc. Boy do I feel dumb! What I have been writing lately generally contains its own utilities and I just plain forgot about that feature.That sound you hear is me smacking my head in disbelief!

Edited by senior_falcon
Link to comment
Share on other sites

Now that I've gotten over spending several hours on a rookie mistake, I have one more thing to ask before posting my program: Can someone with a CF7 use EA or minimemory and do the following:

CALL PEEKV(14296,A,B,C,D,E,F,G,H,I,J,K,L,M)

PRINT A;B;C;D;E;F;G;H;I;J;K;L;M

Thanks!

 

My nanoPEB (should be the same) gives all zeroes.

 

...lee

Link to comment
Share on other sites

  • 3 weeks later...

Here is a test program that allocates memory the way that TML does. (XB256 is similar and if it will work with TML then it can be made to work with XB256) The source code is included "CF7TEST-S.TXT" and it has way more comments than normal for me. The object code is: "CF7TEST-O". Rather than rewrite a bunch of stuff I have pasted instructions from the comments. This program describes what TML does with the disk buffer spaces. Someone who actually has a CF7 and some knowledge of assembly may be able to figure out if it is possible to modify this code so that disk access will work with the CF7 while reserving the memory spaces in VDP needed by TML.

*******************************************
*These subroutines mimic what happens to the VDP ram when TML or XB256 run
*First, we change the pointer to top of memory to reserve space for our routines to use
*in this case we reserve the addresses used by TML, but XB256 works similarly
*Then we write >E5 to all the VDP memory used by TML
*try various disk operations, then check the VDP to see if there are any changes to it.
*They are used this way:
*CALL INIT
*CALL LOAD("DSKn.CF7TEST-O")
*CALL LINK("MOVHDR")
*NEW
*SIZE
*CALL LINK("WRITE5")
*Try disk access - load program, save program, open DV80 and write or read
*file, close file, etc.
*Assuming the disk access works then:
*CALL LINK("CHKVDP") to see whether using the disk system modified
*the VDP memory needed by TML
*
*When you run MOVHDR from XB it starts with CALL FILES(3) set by default in XB
*The subroutine will move the header in the disk buffering area to a new
*location in VDP RAM. When using a TI disk controller,>8370 contains >37D7
*with call files(3). This points one byte below the 5 byte header.
*With the TI controller the header contains:
*>37D8 validation code for the disk controller dsr (>aa)
*>37D9 points to top of vdp memory (>3fff)
*>37DB CRU base identification (11 for CRU 1100)
*>37DC maximum number of opened files (3 by default)
*The CF7 puts 8 more bytes in front of the header and adjusts the pointer
*at >8370 accordingly. (I have no idea what those bytes contain)
*MOVHDR moves the 13 byte header (8+5 bytes) to a new location in VDP RAM
*This lets an XB program run with less stack space and with the VDP RAM
*from >2000 to >3DEE reserved so it is not be used by XB or when
*performing disk operations. The VDP memory above the header is set to zero
*except for the area from >2000 to >3DEE (TML uses this) which is set to >E5 for testing
*purposes. CHKVDP copies VDP ram to >B000 where it can be examined
*from XB using CALL PEEK if necessary. It then checks VDP from >2000 to
*>3DEE to see if the memory there has been changed when using disk.
*It prints "PASS" or "FAIL"
******************************************************

CF7TEST.zip

Edited by senior_falcon
  • 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...