+Lee Stewart Posted October 3, 2018 Share Posted October 3, 2018 I do not know that it is the problem, but I think that your reliance on the persistence of GPLWS’s R9 is flawed. I think you should stash it in a safe PAD-RAM location (>83xx) and either copy it to R9 within DSKLNK prior to “BL *R9” or use “BL @>83xx” instead. [Edit: Crossed-out stuff will not work!] ...lee Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 3, 2018 Author Share Posted October 3, 2018 I do not know that it is the problem, but I think that your reliance on the persistence of GPLWS’s R9 is flawed. I think you should stash it in a safe PAD-RAM location (>83xx) and either copy it to R9 within DSKLNK prior to “BL *R9” or use “BL @>83xx” instead. [Edit: Crossed-out stuff will not work!] ...lee Ahhhh. Very cool. I just tried running with a disk image and some source code on the disk image, Disk1 = TYPE3. No problem. ! I will implement your idea after lunch. B Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 3, 2018 Author Share Posted October 3, 2018 I made 3 major changes changes: Everthing still works fine in Classic99 with a TYPE 3 DISK1 and disk image. Use a variable to transport the ROM code entry to GPL R9 Turned off the disk card after calling OPENDEV, which searches for the device in ROM and gets all the relevant numbers re-wrote ENABLE and DISABLE in ALC and they now disable and enable interrupts respectively. VARIABLE: ROM \ holds ROM entry address found by OPENDEV \ Create the VECTOR that we call with BLWP. \ workspace compile program address \ --------- ----------------------- CREATE: DSKLNK DSRWKSP T, [cc] THERE TCELL + T, [tc] 83E0 LWPI, \ change to GPL workspace 837C @@ CLR, \ clear GPL status ROM @@ R9 MOV, *R9 BL, \ GPL R9 already has the entry address NOP, \ in case the DSR returns here DSRWKSP LWPI, \ DSR returns here. RTWP, \ Return to Forth Workspace NEXT, \ Return to Forth interpreter : OPENDEV ( $addr len card -- ) \ turn card on, set DSR DUP >R ENABLE ?CARDID \ abort if card is not 'AA' 'DSRLIST DSRFIND ( -- link) DUP ?DEVERR \ abort if link=0 DUP 83D2 ! \ store link in O/S variable DUP 4 + ( -- link $) \ link+4=DSR$ ie: Name of the DSR in CARD ROM C@ 8355 C! ( -- link) \ length byte of DSRNAM -> 8355 2+ @ ROM ! \ link+2 contains DSR CODE entry ADDR -> ROM variable R> DISABLE ; CODE: Enable ( CRU -- ) 0 LIMI, TOS R12 CMP, NE IF, 0 SBZ, ENDIF, TOS R12 MOV, TOS 83D0 @@ MOV, 0 SBO, TOS POP, NEXT, END-CODE CODE: Disable ( CRU -- ) TOS R12 MOV, 0 SBZ, TOS POP, 2 LIMI, NEXT, END-CODE Did some interactive sleuthing at the Forth console and found that I could call OPENDEV with no problem. When I do an OPEN operation ( 0 FILEOP ) The DSKCARD comes on, : That's good The drive motor does not start : somehow the card is not getting the correct drive info? After a second the ok prompt comes back to Forth but the system is locked up. : The BLWP operation is working as expected The disk controller light does not go out fully but is dim, like it's being flashed very rapidly. : Some code is running that should not be? However when I run the word INCLUDED to try and load a file, the screen goes white. My next steps will be to get all my variables out scratch-pad. After that take all my code out of scratch-pad as well. I can't be sure what the ROM code is using in that memory area. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted October 4, 2018 Share Posted October 4, 2018 Just curious - what values are in GPLWS (83E0) registers 13 and 15 and address 0x8370? Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 4, 2018 Author Share Posted October 4, 2018 I will check it out in my next round. My patience ran out tonight. :-) B 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 4, 2018 Share Posted October 4, 2018 Please let me know when you find out what it is so I can add a check to the Classic99 DSR. I'm pretty surprised it's that far off when using the type 3 disk though -- are you sure the Classic99 debug log confirms that is doing the right thing? That runs the real TI DSR all the way down to the sector access itself. Maybe you have a misconfiguration? I've used it to actually step through the disk controller ROM before. Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 4, 2018 Author Share Posted October 4, 2018 Please let me know when you find out what it is so I can add a check to the Classic99 DSR. I'm pretty surprised it's that far off when using the type 3 disk though -- are you sure the Classic99 debug log confirms that is doing the right thing? That runs the real TI DSR all the way down to the sector access itself. Maybe you have a misconfiguration? I've used it to actually step through the disk controller ROM before. I did not see any errors fly by on the Classic99 debug window. But I will double check every thing as time permits. Thanks for your interest. I did notice when I single stepped that there was a never time that the code was running in the ROM range. The BLWP occurred and then suddenly it had returned to the expansion memory. I went on to other things, but I will review that again. I don't have the latest version of Classic99. Maybe that's a problem? Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 4, 2018 Share Posted October 4, 2018 I am probably picking at nits, but it does not seem that you zero >8354 when you store the DSR name-length in >8355. I do not know whether this could be a problem, but all of the DSRLNKs clear the word at >8354 before storing the DSR name-length byte at >8355. ...lee Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 4, 2018 Author Share Posted October 4, 2018 I am probably picking at nits, but it does not seem that you zero >8354 when you store the DSR name-length in >8355. I do not know whether this could be a problem, but all of the DSRLNKs clear the word at >8354 before storing the DSR name-length byte at >8355. ...lee At this point I will try anything you suggest. Thanks Lee. Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 4, 2018 Share Posted October 4, 2018 I did not see any errors fly by on the Classic99 debug window. But I will double check every thing as time permits. Thanks for your interest. I did notice when I single stepped that there was a never time that the code was running in the ROM range. The BLWP occurred and then suddenly it had returned to the expansion memory. I went on to other things, but I will review that again. I don't have the latest version of Classic99. Maybe that's a problem? I'm not talking about errors -- if it doesn't explicitly say that it is using the "TICC" to handle the call, then it's not using the TI Disk Controller ROM. If you change the config from the GUI, it will undo the manual change, since the GUI doesn't know about this (not so) secret hack. You also can only edit Classic99.ini while the emulator is closed. Your description says it's still using the Classic99 DSR (which doesn't have any 9900 code), so for one of those reasons it doesn't seem to have taken. Double check your config and the debug - it will save you some trouble debugging. Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 4, 2018 Author Share Posted October 4, 2018 (edited) I'm not talking about errors -- if it doesn't explicitly say that it is using the "TICC" to handle the call, then it's not using the TI Disk Controller ROM. If you change the config from the GUI, it will undo the manual change, since the GUI doesn't know about this (not so) secret hack. You also can only edit Classic99.ini while the emulator is closed. Your description says it's still using the Classic99 DSR (which doesn't have any 9900 code), so for one of those reasons it doesn't seem to have taken. Double check your config and the debug - it will save you some trouble debugging. Cool. Thanks for that. And indeed the TYPE was set to 2! Ok now I have a better debug platform than rs232 to floppy Edited October 4, 2018 by TheBF Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 5, 2018 Share Posted October 5, 2018 Is it possible to post a step by step that I can try to reproduce with here? Just as far as the open would (probably?) be enough... You'll have to include which files I need to get. Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 5, 2018 Author Share Posted October 5, 2018 (edited) I can give you something. Today however I am on the highway (in 10 mins) and up here in the great white north we have Thanksgiving early because when we used to do it on the USA date, years ago, everything here was a frozen wasteland. So that's this weekend. However if you go to github you can get the current flawed version by taking this folder: https://github.com/bfox9900/CAMEL99-V2/tree/master/DSK1 The only files you actually need are listed in the file called START. Just read it with TIDIR and you will see what is "included" on boot. ( I am not on my dev. machine at the moment so I can't read it myself at the moment) As mentioned, it works as a FIAD drive, but failed on my old 99. I have not tested this exact version on a disk image, but it is the one I send over to try on real metal. Gobble gobble. (And we don't pardon any turkeys. I guess we are not as polite as legends suggest) EDIT: And I of course discovered that you cannot use .F extensions on TI-99 files. Too many years away from the old beast to remember that. Edited October 5, 2018 by TheBF Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 7, 2018 Share Posted October 7, 2018 I'm Canadian, you don't have to explain Thanksgiving to me! I'll take a peek... Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 7, 2018 Share Posted October 7, 2018 I can't get very far... I downloaded the archive and mounted the DSK1 folder as DSK1 in Classic99, then I loaded Editor/Assembler and run CAMEL99. But, it just beeps and locks up, I don't see much happening. Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 8, 2018 Author Share Posted October 8, 2018 I assume you are using a disk image? That's the actual problem if so. With a type 1 drive it should load and then try to compile DSK1.START. With the disk image it should do what happened to you. In re-reading the DSR doc I see that the system assumes it has 36 bytes at 834E. I am using some of that so I re-built a version that keeps that area clear, however that did not seem to fix the problem at my end. If you want to try it under better control, I could give you a version of the kernel that doesn't try and load a file at boot time. If it's too much trouble then I will just continue searching for myself and report back to you. Happy Thanksgiving. (I did suspect there would be many Canadians on here) Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 8, 2018 Share Posted October 8, 2018 No, I'm using the files you instructed me to download, copied into a folder and mounted as a folder. I need to see it working before I try to troubleshoot the stuff that doesn't. Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 8, 2018 Author Share Posted October 8, 2018 No, I'm using the files you instructed me to download, copied into a folder and mounted as a folder. I need to see it working before I try to troubleshoot the stuff that doesn't. That's for sure. Ok let me find out what the heck is up there. I have always just pushed it up but never downloaded back to re-tested. Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 8, 2018 Author Share Posted October 8, 2018 No, I'm using the files you instructed me to download, copied into a folder and mounted as a folder. I need to see it working before I try to troubleshoot the stuff that doesn't. So I re-worked the kernel so that it now does NOT touch anything in the area of >834E. (Version is 2.1.i) (interim version) I changed the names in the folder DSK1 so they no longer have a .F extension. Most importantly. so I stop wasting your precious time, I mounted the DSK1 folder that is on GitHub onto Classic99 and booted the kernel which compiled DSK1.START file and the other files it includes. That part should now be solid for you to see now (apologies for the previous experience) The new START file is this so you need these files in the folder. ( or you can leave some out and see the file error 7 occur) \ V2.1 START file loads NEEDS/FROM and then loads ANS Forth extensions S" DSK1.NEEDFROM" INCLUDED NEEDS INCLUDE FROM DSK1.INCLUDE NEEDS CODE FROM DSK1.CODE NEEDS ALIAS FROM DSK1.CELLS NEEDS CHAR FROM DSK1.CHAR CR .( ok) HEX 17 7 VWTR I have incorporated one of LEE's changes which is clearing >8354 when I put the length byte into >8355. I have reverted back to passing the ROM entry address by directly writing it to GPL R9, and interrupts are running so that is back to the way I started. And I can confirm now that when I run this version as a disk image I get a bunch of this: Illegal opcode (0000) at address >98A0, Bank >0000, DSR >0001 Illegal opcode (0000) at address >98A4, Bank >0000, DSR >0001 Illegal opcode (0000) at address >98B8, Bank >0000, DSR >0001 Illegal opcode (0000) at address >98BC, Bank >0000, DSR >0001 Illegal opcode (0000) at address >98C0, Bank >0000, DSR >0001 Illegal opcode (0000) at address >98C4, Bank >0000, DSR >0001 Illegal opcode (0000) at address >98C8, Bank >0000, DSR >0001 Illegal opcode (0000) at address >98CC, Bank >0000, DSR >0001 Illegal opcode (0000) at address >98D0, Bank >0000, DSR >0001 Illegal opcode (0000) at address >98D4, Bank >0000, DSR >0001 Illegal opcode (0000) at address >98D8, Bank >0000, DSR >0001 Illegal opcode (0000) at address >98DC, Bank >0000, DSR >0001 Illegal opcode (0000) at address >98E0, Bank >0000, DSR >0001 Illegal opcode (0000) at address >98E4, Bank >0000, DSR >0001 Illegal opcode (0000) at address >98F8, Bank >0000, DSR >0001 Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 8, 2018 Share Posted October 8, 2018 > ( or you can leave some out and see the file error 7 occur) Do I want to see the file error 7 occur? I know it sounds petty, but what I'd really like is a step by step instruction from nothing to seeing the error I need to troubleshoot. >Illegal opcode (0000) at address >98A0, Bank >0000, DSR >0001 I can guarantee you shouldn't be executing code at that address, that's the Speech Synthesizer (IIRC). I'd put a breakpoint there and see how it jumped there. I can try to take a peek tonight after work. Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 9, 2018 Author Share Posted October 9, 2018 (edited) > ( or you can leave some out and see the file error 7 occur) Do I want to see the file error 7 occur? I know it sounds petty, but what I'd really like is a step by step instruction from nothing to seeing the error I need to troubleshoot. >Illegal opcode (0000) at address >98A0, Bank >0000, DSR >0001 I can guarantee you shouldn't be executing code at that address, that's the Speech Synthesizer (IIRC). I'd put a breakpoint there and see how it jumped there. I can try to take a peek tonight after work. Yes that is a glaring problem. Step by step, 1. put the files named in the START file listing in the folder with the CAMEL99 program 2. E/A5 option DSK1.CAMEL99 Works in a folder. Fails miserably in a disk image. I appreciate you even considering it. Thanks Edited October 9, 2018 by TheBF Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 9, 2018 Share Posted October 9, 2018 Still no luck -- maybe you are squeaking by on your older version of Classic99, or maybe I'm doing something wrong, but I can't even get it to start, it doesn't make it to the first disk access. Have a look here and tell me what to try differently: https://youtu.be/6osTkOynCEg Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 9, 2018 Author Share Posted October 9, 2018 I don't see anything wrong with what you are doing. The 2 variables that I can think of are: 1. I have an older Classic99 2. I have not done exactly what you just did. Ball is in my court. Thanks very much for being my Alpha tester. The cheque is in the mail (CDN $ only) :-) Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 9, 2018 Author Share Posted October 9, 2018 (edited) And the results are in: My code runs on Q1394 but NOT on Q1399.003 It was hours of fun while the illusion lasted! I will be looking much closer at working examples of DSRLNK to find the error of my evil Forth ways. Thanks again Tursi and Lee for weighing in. Edit: ...But this begs the question. I can convert programs from my cross compiler, from V9T9 to TIFILES, then send them over RS232 to my real TI-99 and run them. Different versions that I built of CAMEL99 Forth worked perfectly as long as I did not try to access files. Are there differences in Classic99 Q1399.003 and my old TI-99? Edited October 9, 2018 by TheBF Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 10, 2018 Share Posted October 10, 2018 The assumption is that the newer version is closer... but the fact it runs on your real hardware is interesting. Are the files on Github the same files as you are running? (ie: have you tried re-downloading them?) Classic99 is not even getting as far as the DSR call, which makes me wonder if it's crashing on something else. I can see it executing scratchpad code and jumping out, so it seems the interpreter started. It's also beeping, and something must have turned on the sound chip -- is it supposed to start with a beep? 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.