Airshack Posted January 4, 2021 Share Posted January 4, 2021 14 hours ago, Tursi said: Not sure if it will mean much to programmers I don't know what the hell you're talking about yet I greatly appreciate your efforts in maintaining my favorite emulator. Thank You! 4 Quote Link to comment Share on other sites More sharing options...
1980gamer Posted January 4, 2021 Share Posted January 4, 2021 It's TursiDOS Wow, I am so impressed by MANY TI enthusiasts. Thank you for your effort and support. I need to buy you a coffee. Everyone here should know what I am talking about! if not.... http://www.harmlesslion.com/cgi-bin/showprog.cgi?search=classic99/ 2 Quote Link to comment Share on other sites More sharing options...
+dhe Posted January 4, 2021 Share Posted January 4, 2021 Is this related to the level II/Level III Disk Routines that caused some many problems in the early days of MDOS? Quote Link to comment Share on other sites More sharing options...
Tursi Posted January 5, 2021 Author Share Posted January 5, 2021 10 hours ago, dhe said: Is this related to the level II/Level III Disk Routines that caused some many problems in the early days of MDOS? I can't tell you anything about MDOS. 2 Quote Link to comment Share on other sites More sharing options...
Tursi Posted January 11, 2021 Author Share Posted January 11, 2021 Classic99 399.037 This took substantially longer than I intended, but I reviewed and re-commented every single opcode to make sure I wasn't missing anything, in order to get memory accesses correct. I also updated every memory read function in order to gain tighter control of cycle counting with respect to the read-before-write cycles. To that end, 9 opcodes were updated (4 were mostly rewritten), although one of those was probably not wrong before I changed the memory system. This even included jumping into the data book to verify a couple of memory accesses I had documented but hadn't coded, as they were unclear. So hopefully, this will be it. The overall effect, though, is generally going to be pretty small. From the user's standpoint, you won't see much difference - indeed the error was within the margin of error of the CPU clock. But for programmers, cycle counting should be more correct, particularly on the byte instructions which was where most of the work went. STCR was outright missing a dummy read I knew about, and XOP, B and BL were missing dummy reads I didn't know about but had documented anyway! Since I changed a fair bit, I ran a number of regression tests as well as reviewing the changes multiple times, so I think it's okay! Anyway... usual places... http://harmlesslion.com/software/classic99 18 3 Quote Link to comment Share on other sites More sharing options...
wolhess Posted January 17, 2021 Share Posted January 17, 2021 Hi Tursi, since classic99 399.032 I was'nt able to assemble a compiled XB program with the XBGDP internal assembler. If I use the external Asm994a assembler all is working. I used a simple "PRINT HELLO" program and in the version v399.030 all is fine: TEST Since classic99 v399.032/033... if I will assemble this I get the following screen: Perhaps the cause lies in seniorfalcon's XBGDP program. However, this worked very well up to and including v30. Quote Link to comment Share on other sites More sharing options...
Tursi Posted January 17, 2021 Author Share Posted January 17, 2021 I need a step-by-step to reproduce the issue, a screenshot isn't enough. Even then, I don't know the compiler, but at least it's a start. However, here's the diff between 30 and 32: https://github.com/tursilion/classic99/compare/9d40c8ab6f8ac5628ddd58c83c751079751de95c..c6f1e02e0deab7cf01b55f947c7a1d6a3800a4f4 I don't see anything obvious in there, but you are saying if you go back to v30, you can run this correctly? Quote Link to comment Share on other sites More sharing options...
wolhess Posted January 17, 2021 Share Posted January 17, 2021 3 hours ago, Tursi said: I need a step-by-step Hi Tursi, This is the .zip with the functional v399.030. I used. _classic99_399-030.zip The step by step is easy: 1. Run classic99 from the .zip. The cartridge is TI-Extended Basic and the DSK1=...\_classic99_399-030\ISABELLA6\ 2. Select "2" for TI Extended Basic -> This will autoload the ISABELLA6 menu 3. Use Arrow down for Extended Basic + ENTER 4. >OLD DSK1.TEST + ENTER 5. >SAVE DSK1.TEST + ENTER *** From now on you can only press ENTER when the program asks for an input! 6. >SAVE DSK1.TEST-M,MERGE press ENTER 7. >RUN "DSK1.LOAD" press ENTER -> the ISABELLA6 menu is on the screen 8. Select Compiler press ENTER -> The compiler asks for some files, you can always press ENTER (6 times) for the defaults. -> After the compiling the ISABELLA6 menu is in the screen again 9. Select Assembler press ENTER -> In classic99 later than v030 this step shows the destroyed screen and a terrible sound! -> In classic99 v30 and earlier the assembler asks for some files, you can always press ENTER (5 times) for the defaults. -> The assembler is executing 10. Press ENTER if the assembly is finished and it shows 0000 ERRORS -> the ISABELLA6 menu is on the screen 11. Select LOADER press ENTER -> the loader asks for some file names, you can always press ENTER (4 times) 12. The compiles program is running and shows "HALLO" I mapped the "ISABELLA6" folder in the actual classic99 v37 and got the described issue. Quote Link to comment Share on other sites More sharing options...
wolhess Posted January 17, 2021 Share Posted January 17, 2021 (edited) Hi Tursi, I changed the classic99.ini file from the functional v030 to my non functional v037 and now the process is working! So it seems that my classic99.ini has been corrupted since v032. Thanks for looking at my issue! Here is my defective ini file, but you don't need to take any further action here. classic99-corrupt.ini EDIT: I changed the ini file back and the issue is there, so it was the ini file! Edited January 17, 2021 by wolhess Additional Info 2 Quote Link to comment Share on other sites More sharing options...
+Schmitzi Posted January 17, 2021 Share Posted January 17, 2021 42 minutes ago, wolhess said: Hi Tursi, I changed the classic99.ini file from the functional v030 to my non functional v037 and now the process is working! So it seems that my classic99.ini has been corrupted since v032. Thanks for looking at my issue! Here is my defective ini file, but you don't need to take any further action here. classic99-corrupt.ini 8.46 kB · 1 download EDIT: I changed the ini file back and the issue is there, so it was the ini file! As I can see, there are some small differences in the INI files. Just a thought, maybe you set them back, one by one ? (Not sure if I saw all the changes, but I think so) FIAD_AllowNoHeaderAsDF128=1 (BEFORE IT WAS: 0) FIAD_EnableLongFilenames=1 (0) cputhrottle=0 (1) systemthrottle=1 (0) EnableF18A=0 (1) ScreenScale=-1 (1) Good luck Quote Link to comment Share on other sites More sharing options...
+dhe Posted January 18, 2021 Share Posted January 18, 2021 Thanks Wolfgang, I need to give that a try, the directions for using Isabella got me somewhat overwhelmed I can follow this and give it a try... Thanks!! Quote Link to comment Share on other sites More sharing options...
Tursi Posted January 19, 2021 Author Share Posted January 19, 2021 On 1/17/2021 at 9:56 AM, wolhess said: Hi Tursi, I changed the classic99.ini file from the functional v030 to my non functional v037 and now the process is working! So it seems that my classic99.ini has been corrupted since v032. Thanks for looking at my issue! Here is my defective ini file, but you don't need to take any further action here. classic99-corrupt.ini 8.46 kB · 6 downloads EDIT: I changed the ini file back and the issue is there, so it was the ini file! Ah, that's great to know, but thank you for the detailed steps anyway! Bug reports like that make life easier. I will see if I can figure out why the INI caused such an issue, but in looking at the diff, as Schmitzi did... FIAD_AllowNoHeaderAsDF128=0 - will prevent you from opening general Windows files - probably not an impact but having it on simulates having files you downloaded from a PC BBS. I have this as 0 myself. FIAD_EnableLongFilenames=0 - will prevent long filenames from working in directory listings (will still allow you to OPEN long filenames). This is the safer option, as some software assumes a 10 character maximum, and may crash if longer filenames are returned. I keep this as 0 as well. cputhrottle/systemthrottle should only be set by the emulator, not manually. They don't mean what they originally did. But I don't think that's an issue... F18A and 80column were enabled in the working one. And DSK4-DSK9 were disabled in the working one. It'd be interesting if those settings reported any errors in the debug log during assembly? Maybe a disk error occurred that wasn't trapped, or the long filenames overflowed a directory buffer? Is that possible, @senior_falcon? Quote Link to comment Share on other sites More sharing options...
wolhess Posted January 19, 2021 Share Posted January 19, 2021 1 hour ago, Tursi said: It'd be interesting if those settings reported any errors in the debug log during assembly? Hi Tursi, yes there are errors after I select Assembler, the debugger shows an Illegal opcode. And this is the disasm LOG started before I select ASSEMBLER from the Isabella6 menu. disasm.txt And so it shows, when I use a fresh classic99.ini disasm_working.txt 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted January 19, 2021 Author Share Posted January 19, 2021 9 hours ago, wolhess said: Hi Tursi, yes there are errors after I select Assembler, the debugger shows an Illegal opcode. And this is the disasm LOG started before I select ASSEMBLER from the Isabella6 menu. disasm.txt 35.3 MB · 3 downloads And so it shows, when I use a fresh classic99.ini disasm_working.txt 15.39 MB · 3 downloads Unfortunately the illegal opcodes scrolled off any previous messages of interest -- you can trap that with the debugger option "Break on Illegal Opcode" - will automatically breakpoint at the first one. You can also use any Windows debug viewer to log /all/ the Classic99 messages, instead of just the last 20 or so. (DbgView is a good one - https://docs.microsoft.com/en-us/sysinternals/downloads/debugview ) In the second screenshot, my interest would be whether a directory happened, but again the file accesses scrolled anything interesting away. Is it odd that it's trying to access DSK6, though? Anyway, not asking you to dig deeper at the moment, just recording my thoughts. I can take a peek in a couple days - just getting into a new job here. 1 Quote Link to comment Share on other sites More sharing options...
wolhess Posted January 20, 2021 Share Posted January 20, 2021 15 hours ago, Tursi said: Unfortunately the illegal opcodes scrolled off any previous messages of interest -- you can trap that with the debugger option "Break on Illegal Opcode" - will automatically breakpoint at the first one. You can also use any Windows debug viewer to log /all/ the Classic99 messages, instead of just the last 20 or so. (DbgView is a good one - https://docs.microsoft.com/en-us/sysinternals/downloads/debugview ) In the second screenshot, my interest would be whether a directory happened, but again the file accesses scrolled anything interesting away. Is it odd that it's trying to access DSK6, though? Anyway, not asking you to dig deeper at the moment, just recording my thoughts. I can take a peek in a couple days - just getting into a new job here. Hi Tursi, Thank you for providing the debug tool. I'ts very easy to understand. You are right, the Isabella6 menu tries to load a file DSK6.QF after selecting "assembler" and in the wrong classic99.ini file I have a mapped drive to DSK6 on my tipi-SD card to Z:\C99FW\. In this folder I have the funnelweb system configured for c99 and there is a file QF. But this file doesn't have anything to do with the compiling process. With the fresh classic99.ini file there is no folder mapped to DSK6. so this failed to load and the compiling process can go on to assemble the program. I think the Isabella6 menu is using some type of auto boot tracking but I don't see anything to deal with the file DSK6.QF!? Maybe senior_falcon can check if he is searching a QF file on DSK6. It seems that classic99 is working correct! I changed DSK6 in the wrong classic99.ini file to Z:\MM\ (In this folder isn't a file called QF and the compiling process is working fine. In this case the Isabella6 menu can't open DSK6.QF and proceeds with assembling like the process with a fresh ini file. This are three log files of the complete process: - C99_AT_OK.log The compiling process with a fresh classic99.ini (working) - C99_AT_wrong.log The process with my corrupted classic99.ini (not working) - C99_AT_wrong_corrected.log The process with the corrected classic99.ini (working) - LOAD The Isabella6 menu file classic99_LOG.zip 2 Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 18, 2021 Author Share Posted February 18, 2021 (edited) Sorry, Wolhess, I forgot about that, but I'm really too frustrated to do any more work on this emulator. Go use MAME instead. The compiler system is exceptionally complex and it's difficult to trace through it - particularly since I have to reverse engineer the software as I go. Does Senior Falcon have no insight to offer?? (Edit: Ah, in re-reading I see that for the most part, we solved it, except that we have no idea WHY it's trying to load QF, or why it's trying from DSK6. I don't think that's a Classic99 problem.) Edited February 18, 2021 by Tursi 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 18, 2021 Author Share Posted February 18, 2021 Classic99 399.038 - fixes Control-F1 paste option to not insert a keypress as well - added autodetection of ROM cartridge boot bank - add better guesses on C.BIN versus 8.BIN versus nothing I'm not at all pleased with this release, but it'll work for the rest of you. http://harmlesslion.com/software/classic99 7 5 Quote Link to comment Share on other sites More sharing options...
wolhess Posted February 18, 2021 Share Posted February 18, 2021 14 hours ago, Tursi said: (Edit: Ah, in re-reading I see that for the most part, we solved it, except that we have no idea WHY it's trying to load QF, or why it's trying from DSK6. I don't think that's a Classic99 problem.) @Tursi, yes my problem is solved. So from my site classic99 is working with the compiler. Please don‘t be frustated. Classic99 is super! 2 Quote Link to comment Share on other sites More sharing options...
oddemann Posted February 19, 2021 Share Posted February 19, 2021 Well... for me... there is the real TI 99/4A and then there is Classic99! I have my first TI and I have last year gotten my hands on 2 "new" ones. But... lol 99,99% av the time I use Classic99! I think that Classic99 is today the "modern" TI, that is easy to play and use. So, you're a huge part of the legacy of the TI with Classic99! In my mind there is nothing that comes near your Classic99. Tried others, but they do not have the TI feel. The others strong point is that they made it easy to use software with the emulator. I am pretty sure that what ever you make for Classic99, will work 99,999% of the time on the real thing. Look at it this way... ALL the classic games on the TI have its revival and legacy in today's world, because of the Classic99! I can still play my games, because of Classic99! No need to put all the cables and real stuff together. It is more a "true love story" the real iron. But Classic99 keeps it near and STILL usable for me! I believe, @Tursi that you will be a huge part of the continued story of the TI! For me, you are, you have made it possible to keep my "love story" going! 5 Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 19, 2021 Author Share Posted February 19, 2021 (edited) Thanks, doesn't really stop the frustration when the work I do to reduce the amount of work I have to do is undone because "eh, whatever". Anyway, looks like the patch that I assumed was harmless broke the built-in Extended BASIC and RXB, so probably don't download .038 till I have time to reverse engineer yet another piece of software I didn't write. (Frankly, I'm kind of confused why they broke...) Edited February 19, 2021 by Tursi 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted February 19, 2021 Share Posted February 19, 2021 2 minutes ago, Tursi said: Thanks, doesn't really stop the frustration when the work I do to reduce the amount of work I have to do is undone because "eh, whatever". This sounds like the history of software since 1954. Your efforts however are Herculean and the results outstanding. I have no way to thank you except to use Classic99 everyday. 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 19, 2021 Author Share Posted February 19, 2021 It's true. I hate computers. The typo is fixed, and worse, it was a typo against my own standards that I had let slip due to peer pressure. Serves me right. .038a is up at all the usual spots. I didn't bother updating the header at harmlesslion though you can see the version in the title bar. http://harmlesslion.com/software/classic99 8 Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted February 19, 2021 Share Posted February 19, 2021 thanks for all you do Mike! 1 Quote Link to comment Share on other sites More sharing options...
jrhodes Posted February 19, 2021 Share Posted February 19, 2021 1 hour ago, Tursi said: It's true. I hate computers. The typo is fixed, and worse, it was a typo against my own standards that I had let slip due to peer pressure. Serves me right. .038a is up at all the usual spots. I didn't bother updating the header at harmlesslion though you can see the version in the title bar. http://harmlesslion.com/software/classic99 Want to learn good coding etiquette and practices? Study python. Nothing like your program not working as expected due to improper indentation to make you pay more careful attention next time around. 2 3 Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 19, 2021 Author Share Posted February 19, 2021 1 hour ago, jrhodes said: Want to learn good coding etiquette and practices? Study python. Nothing like your program not working as expected due to improper indentation to make you pay more careful attention next time around. ... Most of what I want to say to that is mean, and I know you were joking. 2 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.