+hloberg Posted April 2, 2014 Share Posted April 2, 2014 (edited) Had to say this; just installed the F18a and WOW. it was so easy to install and the picture is great! The only hard part is cutting the hole for the plug. The only program I, so far, have problems with is 'The missing link'. keep getting, 'out of memory' and Stack memory goes to 0. Since I don't use it much, don't care. on the other hand It might be my imagination but the graphics seem faster. can't wait to delve into some of the extended features. Edited April 2, 2014 by hloberg 4 Quote Link to comment Share on other sites More sharing options...
matthew180 Posted April 2, 2014 Share Posted April 2, 2014 hloberg, I'm glad you like your F18A. Is "The Missing Link" a program that works with the original 9918A? There is a thread here in the forum that lists programs that require a 9938, yet work with the F18A. Keep in mind that the F18A is a 9918A replacement and does does not have the extended memory of the later VDPs (9938/58). The F18A does implement the 80-column mode of the 9938, so some programs will work (see the thread I mentioned) as long as they don't use or assume there is VDP memory over 16K. Quote Link to comment Share on other sites More sharing options...
TheMole Posted April 2, 2014 Share Posted April 2, 2014 If I understood it correctly, TML is set of subprograms that allow you to use bitmap mode from XB. I think senior_falcon wrote it back in the day. It is targeted at the 9918a though, so it'd be interesting to know what the problem is... Quote Link to comment Share on other sites More sharing options...
matthew180 Posted April 2, 2014 Share Posted April 2, 2014 You probably need the 32K RAM expansion (a PEB) or the CF7+/NanoPeb then. I have never messed with TML so I don't know the details, however if something works on the 9918A, then it should also work on the F18A. Were you able to run TML prior to installing your F18A? Quote Link to comment Share on other sites More sharing options...
+hloberg Posted April 2, 2014 Author Share Posted April 2, 2014 able to run it on the emulator fine. Senior Falcon re-released it a little while back and it's in the development resources. I remember testing TML with the CF7+ before I got the F18a and it worked fine. But I can't remember if I tested running a program, that's where it runs out of memory. The program runs in Ex BASIC. The program uses up most of the VDP memory as it starts up in the bit-map mode and stays in the bit map mode while you are in the editor. Even running normal it only has about 7k of stack space max. I'm sure it does a lot of weird alchemy in the VDP so I'm not surprised it has issue. It's not a big deal but I thought I might mention it, just so you would know. Might want to talk to Senior Falcon. He might released a new version that does work I haven't tried. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 2, 2014 Share Posted April 2, 2014 I'd need more information to know what's going on. Was this program written for The Missing LInk? Does it run on a TI without the F18A? Remember that there is a very limited amount of stack available, especially when running in the full color mode. You have almost 13K of the VDP used up for the pattern, color and screen tables, plus memory needed for disk buffers and sprites. which doesn't leave a lot of room for strings. Try a simple program like: 10 FOR I=10 TO 100 STEP 10::CALL LINK("CIRCLE",96,120,I)::NEXT I and see if that runs. (No manual in front of me so I'm not sure that program is right. If not you should be able to fix it). I'm not sure TML is compatible any more with a myarc controller which maps out the VDP differently. Quote Link to comment Share on other sites More sharing options...
matthew180 Posted April 2, 2014 Share Posted April 2, 2014 @hloberg, can you give me some step-by-step instructions to reproduce the error you are having? I would like to confirm if this problem is F18A specific, and if so I will do everything I can to fix it. Quote Link to comment Share on other sites More sharing options...
+hloberg Posted April 2, 2014 Author Share Posted April 2, 2014 I'm going to reload the TML with the latest tonight, to be sure. then re-test. I'll let you know. Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted April 3, 2014 Share Posted April 3, 2014 I've had some issues with the NanoPEB with the f18a.. turns out the sidecar looks for vdp a few milliseconds before the f18a is ready.. Jamie is working on a new model to fix this that delays the nano a few more to time it right.. Might be the issue if you have weird assembly issues. Greg Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 3, 2014 Share Posted April 3, 2014 I was wondering how you got a stack space of around 7K and did some tests to refresh my memory. Right after you load and run TML you will get a Texas shaped cursor and a green screen. If you then type size you see: 7895 BYTES OF STACK FREE and 15280 BYTES OF PROGRAM SPACE FREE. The program has erased itself after running, but the pointers are not updated. If you enter NEW or add any line then they get updated. After NEW, then SIZE you get the true numbers: 1460 bytes of stack and 24488 bytes of program space free. These are the default values for 1 disk file available and 16 colors. Hold any key down when loading to get a menu that lets you choose values other than these. BTW, I tested the one liner above and it works as expected. Quote Link to comment Share on other sites More sharing options...
+hloberg Posted April 3, 2014 Author Share Posted April 3, 2014 I'd need more information to know what's going on. Was this program written for The Missing LInk? Does it run on a TI without the F18A? Remember that there is a very limited amount of stack available, especially when running in the full color mode. You have almost 13K of the VDP used up for the pattern, color and screen tables, plus memory needed for disk buffers and sprites. which doesn't leave a lot of room for strings. Try a simple program like: 10 FOR I=10 TO 100 STEP 10::CALL LINK("CIRCLE",96,120,I)::NEXT I and see if that runs. (No manual in front of me so I'm not sure that program is right. If not you should be able to fix it). I'm not sure TML is compatible any more with a myarc controller which maps out the VDP differently. ran test program. got 'out of memory' in 10. showed 0 bits stack free. Your right, forgot to mention after type NEW get 1460 bytes. I will try running holding down the key to try other versions and let you know. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 3, 2014 Share Posted April 3, 2014 Post the program here or PM it to me and I'll take a look. Between Matthew and I we should be able to resolve this. Quote Link to comment Share on other sites More sharing options...
+hloberg Posted April 3, 2014 Author Share Posted April 3, 2014 (edited) OK. ran the test program, and after a few reboots, it ran OK in both the 16 and 2 color modes. but, can not save or load while in TML, always locks up the computer. outside TML, SAVE and LOAD fine. tried to load TMLDEMO, lock up. Tried both 2 color and 16 color modes, same thing. as arcadeshopper said it's probably something to do with using the f18a with the cf7+. Funnelweb had to be modified to work with the cf7+. I'm going to test the CF7+ without the voice syn. next. I have had issues ever since I attached it. same even without speech Edited April 3, 2014 by hloberg Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 3, 2014 Share Posted April 3, 2014 Can you (or someone else) try running TML and then the TMLDEMO without the cf7+ . i.e. with the F18A and a standard TI PEB. I seem to remember that the cf7 uses a couple extra bytes of VDP ram. Actually, you should be able to check this by typing NEW when in XB. Without the cf7 I get 11840 and 24488 bytes. If it is different using the cf7 then the missing link might need a minor adjustment. Quote Link to comment Share on other sites More sharing options...
+hloberg Posted April 3, 2014 Author Share Posted April 3, 2014 (edited) with cf7+ ext 24488 stack 11832. I don't have a machine with a real PEB currently. Edited April 3, 2014 by hloberg Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 3, 2014 Share Posted April 3, 2014 Here's something you can try: OLD DSK1.TML RUN NEW SIZE and you should get 1460 and 24488 then: CALL PEEK(-31888,A,B) PRINT A;B they should be 29 and 243 CALL LOAD(-31888,29,235) (or 8 less than the value returned in B) NEW SIZE and you should get 1452 and 24488 OLD DSK1.TMLDEMO RUN and hopefully it will run OK. Let me know. Quote Link to comment Share on other sites More sharing options...
+hloberg Posted April 3, 2014 Author Share Posted April 3, 2014 Here's something you can try: OLD DSK1.TML RUN NEW SIZE and you should get 1460 and 24488 >>>I get 1452 and 24488 then: CALL PEEK(-31888,A,B) PRINT A;B they should be 29 and 243 >>> I get 29,235 CALL LOAD(-31888,29,235) (or 8 less than the value returned in B) >>> I input 29,227 NEW SIZE and you should get 1452 and 24488 >>> i get 1444 and 24488 OLD DSK1.TMLDEMO >>> still locks up RUN and hopefully it will run OK. Let me know. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 3, 2014 Share Posted April 3, 2014 That's helpful info. TML does a CALL FILES(n) from assembly language. It then moves a 5 byte header to a different part of vdp and sets the pointer at >8370 to point to the relocated header. It looks like CF7 is adding an 8 byte header in front of the 5 byte header. Let's try moving 13 bytes instead of just 5. From XB: CALL INIT OLD DSKn.TML CALL PEEK(-7283,X)::PRINT X that should be a 5 - if so then: CALL LOAD(-7283,13) RUN and then try loading and running TMLDEMO Hopefully that will work. If not then try out the circle program above to see if TML works if there is no disk access. Quote Link to comment Share on other sites More sharing options...
matthew180 Posted April 3, 2014 Share Posted April 3, 2014 I have a CF7+ and have not had any problems myself, then again my use these days is generally limited to running F18A test programs from the E/A cart. However, it looks like this is panning out to be a slight PEB vs. CF7+/Nanapeb difference. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted April 3, 2014 Share Posted April 3, 2014 That's helpful info. TML does a CALL FILES(n) from assembly language. It then moves a 5 byte header to a different part of vdp and sets the pointer at >8370 to point to the relocated header. It looks like CF7 is adding an 8 byte header in front of the 5 byte header. Let's try moving 13 bytes instead of just 5. From XB: CALL INIT OLD DSKn.TML CALL PEEK(-7283,X)::PRINT X that should be a 5 - if so then: CALL LOAD(-7283,13) RUN and then try loading and running TMLDEMO Hopefully that will work. If not then try out the circle program above to see if TML works if there is no disk access. Unless I'm missing something, >8370 should not be changed by a program. It should always point to the highest available byte of VRAM, i.e., the first free byte below the disk sector buffering area in VRAM. It is changed by DSRs when they reserve buffer space at the top of VRAM. Indeed, the CF7/nanoPEB DSR reserves 8 extra bytes at the very top of VRAM before the "disk" sector buffers and filename area are reserved by the likes of CALL FILES(n). I don't know anything about TML, but if the user can do a CALL FILES(n) any other way than through TML, >8370 will be changed, thus destroying your pointer. Also, moving any part of the VRAM disk buffering area somewhere else I should think would destroy the integrity of the DSR's buffer space. ...lee Quote Link to comment Share on other sites More sharing options...
+hloberg Posted April 3, 2014 Author Share Posted April 3, 2014 That's helpful info. TML does a CALL FILES(n) from assembly language. It then moves a 5 byte header to a different part of vdp and sets the pointer at >8370 to point to the relocated header. It looks like CF7 is adding an 8 byte header in front of the 5 byte header. Let's try moving 13 bytes instead of just 5. From XB: CALL INIT OLD DSKn.TML CALL PEEK(-7283,X)::PRINT X that should be a 5 - if so then: CALL LOAD(-7283,13) RUN and then try loading and running TMLDEMO Hopefully that will work. If not then try out the circle program above to see if TML works if there is no disk access. value of X was 5 but no change. still will not save or load. after work will try more test. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 3, 2014 Share Posted April 3, 2014 Unless I'm missing something, >8370 should not be changed by a program. It should always point to the highest available byte of VRAM, i.e., the first free byte below the disk sector buffering area in VRAM. It is changed by DSRs when they reserve buffer space at the top of VRAM. Indeed, the CF7/nanoPEB DSR reserves 8 extra bytes at the very top of VRAM before the "disk" sector buffers and filename area are reserved by the likes of CALL FILES(n). I don't know anything about TML, but if the user can do a CALL FILES(n) any other way than through TML, >8370 will be changed, thus destroying your pointer. Also, moving any part of the VRAM disk buffering area somewhere else I should think would destroy the integrity of the DSR's buffer space. ...lee 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. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted April 3, 2014 Share Posted April 3, 2014 This is a creative and undocumented use of the disk buffer space. ... Nice! It may be that CF7 works like the Myarc controller or maybe completely differently from either one. I do know the top 6 bytes at >3FFA – >3FFF are expected by the CF7 to be in that spot. See this from Jaime's CFMGR.S source code: VDSK1 EQU >3FFA VDSK2 EQU >3FFC VDSK3 EQU >3FFE I don't know about the 2 bytes at >3FF8 – >3FF9; but, I would think they are fixed, as well. And, you may be right that the CF7 indexes from the top of VRAM. ...lee Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted April 3, 2014 Share Posted April 3, 2014 Good info! I think TML clears out the memory above the buffers to >3FFF. Will check that tonight and modify if needed. Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted April 3, 2014 Share Posted April 3, 2014 I have a CF7+ and have not had any problems myself, then again my use these days is generally limited to running F18A test programs from the E/A cart. However, it looks like this is panning out to be a slight PEB vs. CF7+/Nanapeb difference. The OLDER ones don't have any issues.. It's the newer models that I have seen the problem with. (com1, v2 etc) 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.