+hloberg Posted April 3, 2014 Author Share Posted April 3, 2014 I have a newer CF7+. just bought it. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 3, 2014 Share Posted April 3, 2014 @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. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted April 4, 2014 Share Posted April 4, 2014 @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 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted April 4, 2014 Share Posted April 4, 2014 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. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted April 4, 2014 Share Posted April 4, 2014 (edited) 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 April 4, 2014 by Lee Stewart Quote Link to comment Share on other sites More sharing options...
+hloberg Posted April 4, 2014 Author Share Posted April 4, 2014 I haven't got a Assembler/Editor cartridge or Min mem just yet so I used a BASIC link subroutine for peekv. don't know if this helps since I wasn't able to set files but the values I got was: 170,3,0,104,0,4,0,3 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted April 4, 2014 Share Posted April 4, 2014 That would be here. ...lee {EDIT: Oops! I had the wrong post! Sorry...} Thanks for digging that up. I just returned home from Dallas, trying to beat all the storms around here. I forgot you could link a forum topic! Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 4, 2014 Share Posted April 4, 2014 I remembered right - TML clears out all the video memory up to >3FFF. Here's one more thing to try: CALL INITOLD DSKn.TMLCALL LOAD(-7283,13) CALL LOAD(-7237,14)RUNand 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. Quote Link to comment Share on other sites More sharing options...
+hloberg Posted April 4, 2014 Author Share Posted April 4, 2014 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. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 4, 2014 Share Posted April 4, 2014 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. Quote Link to comment Share on other sites More sharing options...
+hloberg Posted April 4, 2014 Author Share Posted April 4, 2014 problem never been running a program. I can run a program fine. your circles program runs fine. problem been loading and saving. it always locks up trying to do that. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 5, 2014 Share Posted April 5, 2014 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 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted April 5, 2014 Share Posted April 5, 2014 Unlike the E/A loader, the Extended Basic loader cannot load compressed object code. You must assemble the code without C option. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 5, 2014 Share Posted April 5, 2014 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. Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted April 5, 2014 Share Posted April 5, 2014 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! Quote Link to comment Share on other sites More sharing options...
+mizapf Posted April 5, 2014 Share Posted April 5, 2014 Come now, I'm not exactly a newbie at this. OK, I'll try once more, as you seem to be experienced. You know that the Extended Basic loader is not a linking loader? It does not know REF. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 5, 2014 Share Posted April 5, 2014 (edited) 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 April 5, 2014 by senior_falcon Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 7, 2014 Share Posted April 7, 2014 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! Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted April 7, 2014 Share Posted April 7, 2014 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 Quote Link to comment Share on other sites More sharing options...
+hloberg Posted April 29, 2014 Author Share Posted April 29, 2014 Did Senior Falcon ever get X256 or TML working with the CF7 ? Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 29, 2014 Share Posted April 29, 2014 No, not yet. I will post a program that may help diagnose the problem. It's written, just not posted yet. Quote Link to comment Share on other sites More sharing options...
+hloberg Posted April 29, 2014 Author Share Posted April 29, 2014 No, not yet. I will post a program that may help diagnose the problem. It's written, just not posted yet. thanks. finally got my E/A cartridge and a stable CF7 so whenever you need some help just let me know. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted May 4, 2014 Share Posted May 4, 2014 (edited) 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 May 4, 2014 by senior_falcon 1 Quote Link to comment Share on other sites More sharing options...
+hloberg Posted May 5, 2014 Author Share Posted May 5, 2014 Out of town. If no one get's to it before I get back Tuesday, I'll run the test. Anguish to see what the results are. Quote Link to comment Share on other sites More sharing options...
+hloberg Posted May 6, 2014 Author Share Posted May 6, 2014 Here is the results. Nothing will load after CALL LINK("MOVHDR") I get ERROR 2 if I try to load anything. but, memory size is: 24488 & 4168 result of CHKVDP is PASS Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.