senior_falcon Posted March 7, 2013 Author Share Posted March 7, 2013 Hi Jacques: Can you run XB256 and 256DEMO in Classic 99? To be sure everything worked properly, I downloaded the zipped folder at the top of this page. The zipped folder contains XB256 and 256DEMO which are TI Extended BASIC programs, a PDF of the docs, and a Win994a disk image. I started TELCO on the TI side and Hyperterminal on the PC side, both set to 1200 baud 8-N-1. I had no trouble sending XB256 and 256DEMO (once I went to 1200 baud - 2400 seemed to not work, though it used to in the past) I loaded and ran XB256 with no problems. (When you run XB256 nothing happens that you can see - maybe I should have changed the cursor shape or something like that.) Then I loaded and ran 256DEMO and it worked like it should. I don't know anything about PC99 or the TI994W emulator and can't offer any suggestions about them. XB256 does a CALL FILES(2) from assembly language. Possibly there is some incompatibility with your disk controller. The code used is from TML and was tested back in the day with a Myarc controller and it worked fine. You shouldn't need to convert anything to text and back to transfer these files. Let me know if this works. If it doesn't I have some ideas, but let's try plan A first. Harry Quote Link to comment Share on other sites More sharing options...
jacquesg Posted March 7, 2013 Share Posted March 7, 2013 Hi Jacques: Can you run XB256 and 256DEMO in Classic 99? To be sure everything worked properly, I downloaded the zipped folder at the top of this page. The zipped folder contains XB256 and 256DEMO which are TI Extended BASIC programs, a PDF of the docs, and a Win994a disk image. I started TELCO on the TI side and Hyperterminal on the PC side, both set to 1200 baud 8-N-1. I had no trouble sending XB256 and 256DEMO (once I went to 1200 baud - 2400 seemed to not work, though it used to in the past) I loaded and ran XB256 with no problems. (When you run XB256 nothing happens that you can see - maybe I should have changed the cursor shape or something like that.) Then I loaded and ran 256DEMO and it worked like it should. I don't know anything about PC99 or the TI994W emulator and can't offer any suggestions about them. XB256 does a CALL FILES(2) from assembly language. Possibly there is some incompatibility with your disk controller. The code used is from TML and was tested back in the day with a Myarc controller and it worked fine. You shouldn't need to convert anything to text and back to transfer these files. Let me know if this works. If it doesn't I have some ideas, but let's try plan A first. Harry I have never used Classic 99. PC99 has two utility files, RSECTOR and WSECTOR, that are used to transfer disks to and from a TI-99/4A by copying sectors over a serial connection. I found it strange that after I got XB256 and 256DEMO over to my TI-99/4A and they would not run but they ran after I copied the disk over to PC99. When I reversed the process and transferred the disk back to the TI the programs again would not run. It is obvious that XB256 ran but the problem was when I tried to run 256DEMO either by using line 10 or using RUN in command mode. The disk controller light comes on but it does not seem to find the file. It just hangs and I have to turn off the TI. I have no problem in running TML on the TI. Later today I will make a fresh start and transfer the two programs direct to my TI usung MagicFM. The only reason that I used a transfer of a text file was that I initally thought that 256DEMO program perhaps got corrupted and this was another way of moving the program. This will be my plan A. Jacques Quote Link to comment Share on other sites More sharing options...
lucien2 Posted March 8, 2013 Share Posted March 8, 2013 It is obvious that XB256 ran ... It just hangs and I have to turn off the TI. I reproduced this problem with MESS 0.136 and the floppy controllers "Texas Instruments SD" or "SNUG's BwG". With MESS 0.136 and the floppy controller "MyArc's HDFC", it runs fine. 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 9, 2013 Author Share Posted March 9, 2013 OK, here's something to try out. The attached zipped folder has the same files as the one at the beginning of this thread with one additional file: XB256NCF which skips the CALL FILES(2) from assembly. From the command line type: CALL FILES(2) OLD DSKn.XB256NCF RUN Then you should be able to RUN "DSKn.256DEMO" Let me know if this works. Harry XB256.zip Quote Link to comment Share on other sites More sharing options...
lucien2 Posted March 9, 2013 Share Posted March 9, 2013 Let me know if this works. Sorry, no improvement. I also tried it with PC99 and V9T9 with the TI disk controller: Same problem (freeze when loading 256DEMO). The CPU is lost in a loop at addresses >4690 .. >4B76. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 9, 2013 Author Share Posted March 9, 2013 I am confused about when this fails. First, LOAD and RUN XB256. Does the cursor come back? I had assumed it was failing at that point. If the cursor comes back then enter this simple program: 10 CALL LINK("SCRN2")::CALL LINK("DISPLY",1,1,"TEST") 20 GOTO 20 You should see TEST printed in the upper left of the screen. Fctn 4 should break the program. (Haven't tested this program - I'm on the wrong computer) If that works then try saving the program. Did it save and did the cursor come back? If it saved OK then type NEW and try loading the program you just saved. Does the cursor come back? Is the program there and does it run? If all that works then try the following: OLD DSKn.256DEMO Does the cursor come back? Is the program loaded? Try running the program. Does it run? With this information I can at least figure out where it is failing. Quote Link to comment Share on other sites More sharing options...
lucien2 Posted March 9, 2013 Share Posted March 9, 2013 Load of XB256: OK. Test program: OK. Save of the test program: Same crash as the loading of 256DEMO. (No cursor coming back) Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 9, 2013 Author Share Posted March 9, 2013 (edited) So there is something happening to prevent disk access. Let's try to isolate the problem a little more: From XB: CALL FILES(2) OLD DSKn.XB256NCF Remove the CALL LINK("XB256") from line 10 RUN Does the cursor come back? OLD DSK7.256DEMO Does the cursor come back? CALL LINK("XB256") Does the cursor come back? RUN Does the demo run? Edited March 9, 2013 by senior_falcon Quote Link to comment Share on other sites More sharing options...
lucien2 Posted March 9, 2013 Share Posted March 9, 2013 Yes, all steps are working. The demo runs! Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 9, 2013 Author Share Posted March 9, 2013 Now follow the steps in my previous post. Then break the program with Fctn 4. Now try to save or load something to disk. Does it crash? Quote Link to comment Share on other sites More sharing options...
lucien2 Posted March 9, 2013 Share Posted March 9, 2013 Yes, same crash, even after a NEW. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 9, 2013 Author Share Posted March 9, 2013 From XB: CALL INIT CALL FILES(2) CALL LOAD(-31888,43,255) Then try to save or load a program. Do you get the same crash? Quote Link to comment Share on other sites More sharing options...
lucien2 Posted March 9, 2013 Share Posted March 9, 2013 You found it! Same crash, with or without CALL FILES(2). CALL FILES(9) writes >2BB3 at >8370 and works. Writing >2BFF makes it crash, I don't understand that. I tried to reverse the order: First CALL LOAD(-31888,43,255), then CALL FILES(2). It crashes directly after CALL FILES. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 9, 2013 Author Share Posted March 9, 2013 OK, I might have an answer for this. Try this: CALL INIT CALL FILES(2) CALL LOAD(-31888,43,255) CALL LOAD(-31976,43,255,43,255) Then try to save or load a program. Does it crash? Quote Link to comment Share on other sites More sharing options...
lucien2 Posted March 10, 2013 Share Posted March 10, 2013 Yes, it still crashes. I stepped a bit in the DSR with the PC99 debugger. It reads the VDP pointed by the value at >8370. When CALL FILES(2) is executed, it writes >39DD at >8370 and it writes >00AA,>3FFF,>1102 at >39DD in VDP. So, after CALL LOAD(-31888,43,255) (@>8370 = >2BFF), I wrote >00AA,>3FFF,>1102 at >2BFF. It does not crash anymore. SAVE and OLD works. But if I do that after running XB256, I always have an I/O ERROR 04 or 64 (Out of table or buffer space on the device)... Those bytes are documented here: ftp://whtech.com/magazines/smartprogrammer/sp8405.pdf Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 10, 2013 Author Share Posted March 10, 2013 When a program starts to run in XB256 it will write >80 768 times to VDP memory starting at >2C00 which will clear screen2 and overwrite the header you just wrote You could try this which might work: Change the value at >8370 to >2BF7 Write those bytes (>00AA,>3FFF,>1102) to the VDP starting at >2BF7 Now the header is below >2C00 and won't be changed when the screen clears. One problem is that I have no idea where the disk buffers are kept in VDP with this controller. Right after XB256 starts up (assuming it does) but while still in screen1, try opening 2 files and then read and write to them. Then have the program CALL LINK("SCRN2") If the buffers are in the same place as the TI the screen should be blank. If not there will be garbage on the screen Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 10, 2013 Author Share Posted March 10, 2013 Will have a revised version soon (maybe tonight) that should work with all controllers. Quote Link to comment Share on other sites More sharing options...
lucien2 Posted March 10, 2013 Share Posted March 10, 2013 Change the value at >8370 to >2BF7 Write those bytes (>00AA,>3FFF,>1102) to the VDP starting at >2BF7 Here are the results of some tests. I'm not sure which disk controller is used by PC99 by default (TI?) Oops, I think I did all these tests with >2B7F instead of >2BF7... PC99 1. CALL FILES(2) 2. Write >2B7F at >8370 and (>00AA,>3FFF,>1102) at VDP >2B7F 3. OLD XB256NCF -> OK 4. RUN -> SYNTAX ERROR with CALL LINK("X") PC99 1. CALL FILES(2) 2. Write >2B7F at >8370 and (>00AA,>3FFF,>1102) at VDP >2B7F 3. OLD XB256 -> OK 4. RUN -> OK 5. Replace >2BFF from >8370 by >2B7F 6. OLD 256DEMO -> I/O ERROR 04 PC99 1. CALL FILES(2) 2. OLD XB256NCF -> OK 3. RUN -> SYNTAX ERROR with CALL LINK("X") MESS 1. CALL FILES(2) 2. OLD XB256NCF -> OK 3. RUN -> OK 4. OLD 256DEMO -> crash PC99 1. OLD XB256 -> OK 2. RUN -> OK 3. Write >2B7F at >8370 and (>00AA,>3FFF,>1102) at VDP >2B7F 4. RUN -> NO PROGRAM PRESENT PC99 1. OLD XB256 -> OK 2. RUN -> OK 3. Write >2B7F at >8370 and (>00AA,>3FFF,>1102) at VDP >2B7F 4. OLD 256DEMO -> I/O ERROR 04 PC99 1. CALL FILES(2) 2. OLD XB256 -> OK 3. RUN -> OK 4. Write >2B7F at >8370 and (>00AA,>3FFF,>1102) at VDP >2B7F 5. OLD 256DEMO -> OK 6. RUN -> OK !!! PC99 1. CALL FILES(2) 2. OLD XB256 -> OK 3. RUN -> OK 4. Write >2B7F at >8370 and (>00AA,>3FFF,>1102) at VDP >2B7F 5. OLD TEST1 -> OK 6. OLD TEST2 -> OK 7. 10 CALL LINK("SCRN2") 8. 20 GOTO 20 9. RUN -> screen blank PC99 1. CALL FILES(2) 2. OLD XB256 -> OK 3. RUN -> OK 4. Write >2B7F at >8370 and (>00AA,>3FFF,>1102) at VDP >2B7F 5. 10 OPEN #1:"DSK1.TEST1" 6. 20 PRINT #1:"TEST" 7. 30 OPEN #2:"DSK1.TEST2" 8. 40 PRINT #2:"TEST2" 9. 50 CALL LINK("SCRN2") 10. 60 GOTO 60 11. RUN -> I/O ERROR 04 IN 30 PC99 1. CALL FILES(2) 2. OLD XB256 -> OK 3. RUN -> OK 4. Write >2B7F at >8370 and (>00AA,>3FFF,>1102) at VDP >2B7F 5. 10 OPEN #1:"DSK1.TEST1" 6. 20 PRINT #1:"TEST" 7. 30 CALL LINK("SCRN2") 8. 40 GOTO 40 9. RUN -> garbage on screen Quote Link to comment Share on other sites More sharing options...
lucien2 Posted March 10, 2013 Share Posted March 10, 2013 Now the same test that worked with >2B7F, but with >2BF7 instead: PC99 1. CALL FILES(2) 2. OLD XB256 -> OK 3. RUN -> OK 4. Write >2BF7 at >8370 and (>00AA,>3FFF,>1102) at VDP >2BF7 5. OLD 256DEMO -> I/O ERROR 04 Quote Link to comment Share on other sites More sharing options...
jacquesg Posted March 10, 2013 Share Posted March 10, 2013 Here are the results of some tests. I'm not sure which disk controller is used by PC99 by default (TI?) I can run XB256 and 256DEMO from my PC99 setup as DSK4. My setup has a MYARC DC. this DC is useful because it allows a DSK5 as a RAM disk. I use it to contain the FW and other files files. I am not sure that PC99 has a default DC. Jacques Quote Link to comment Share on other sites More sharing options...
+Retrospect Posted February 1 Share Posted February 1 On 2/27/2013 at 11:46 PM, RXB said: My XB to GPL compiler is about half done before I gave up. The reason is the TI community is all about Assembly or C or Forth, so what is the point of a GPL compiler. Anyway what I did was use the SAMS as a buffer for Variables names and storage. This allowed me to tackle any size program and compile into GPL. I made videos on the process. Hope it gives you ideas: http://www.youtube.com/watch?v=TQzp25sSa1A&list=UUULwPKqrRFCtNv5_xMuOqQw&index=3 Good luck Rich Well, I know this is an old post I'm dragging back up here ... but I do have something to say about it. A GPL compiler could output a Cartridge image that works on a stock console, am I right? Well I think it would be fantastic. XB256 with it's compiler IS fast yes, and yes, GPL is slower, however, there is still a point. We can't just throw something away in the TI community just because there's something else, something faster, etc etc...... I'm gonna use this example: Rasmus is much better than me at programming great arcade games. But does it stop me doing it too? Hell no. I just keep going, and going, and going ... I will NEVER stop. So the point i'm making is this : you make an XB- GPL compiler and I will reward it with at least TEN games if not more, this will not be difficult for me to do. I'll be coding for XB256 and the GPL compiler at the same time. And that's just ONE programmer. Do it Rich. This is the last time I'll push for it I promise, specially as this is entirely the wrong thread for it (Harry you have my apologies for that!). @RXB 5 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.