Jump to content
Tursi

Classic99 Updates

Recommended Posts

6 hours ago, Torrax said:

What program did you use to dump the CF7+ DSR.  As I would like to dump both of mine (CF7+ & NanoPEB) for use in Classic99.

A little mini-guide on this operation would be nice.

I didn't, I found it online somewhere. Sorry, I know that's not terribly helpful.

 

Share this post


Link to post
Share on other sites

Note you can create subfolders in the menu by using a different word than "UserCart", as long as it doesn't conflict with any of the reserved words. So for instance, "Games" is fine. 

[Spill0] 
; *** Yahtzee - works 
name="Yahtzee" 
rom0=C|6000|2000|G:\Nedlastninger\Software\Software installert\TI 99 4A\000 Classic99\classic99\MODS\Orginal\Yahtzeec.bin 
rom1=G|6000|A000|G:\Nedlastninger\Software\Software installert\TI 99 4A\000 Classic99\classic99\MODS\Orginal\Yahtzeeg.bin

 

[usercart|Spill0] 
; *** Yahtzee - works 
name="Yahtzee" 
rom0=C|6000|2000|G:\Nedlastninger\Software\Software installert\TI 99 4A\000 Classic99\classic99\MODS\Orginal\Yahtzeec.bin 
rom1=G|6000|A000|G:\Nedlastninger\Software\Software installert\TI 99 4A\000 Classic99\classic99\MODS\Orginal\Yahtzeeg.bin

 

[usercart0Spill0] 
; *** Yahtzee - works 
name="Yahtzee" 
rom0=C|6000|2000|G:\Nedlastninger\Software\Software installert\TI 99 4A\000 Classic99\classic99\MODS\Orginal\Yahtzeec.bin 
rom1=G|6000|A000|G:\Nedlastninger\Software\Software installert\TI 99 4A\000 Classic99\classic99\MODS\Orginal\Yahtzeeg.bin

 

[Games0] 
; *** Yahtzee - works 
name="Yahtzee" 
rom0=C|6000|2000|G:\Nedlastninger\Software\Software installert\TI 99 4A\000 Classic99\classic99\MODS\Orginal\Yahtzeec.bin 
rom1=G|6000|A000|G:\Nedlastninger\Software\Software installert\TI 99 4A\000 Classic99\classic99\MODS\Orginal\Yahtzeeg.bin

 

[Games1] 
; *** Yahtzee - works 
name="Yahtzee" 
rom0=C|6000|2000|G:\Nedlastninger\Software\Software installert\TI 99 4A\000 Classic99\classic99\MODS\Orginal\Yahtzeec.bin
rom1=G|6000|A000|G:\Nedlastninger\Software\Software installert\TI 99 4A\000 Classic99\classic99\MODS\Orginal\Yahtzeeg.bin

 

This one works: (I use a cart that I know works)
[usercart99] 
; *** Yahtzee - works 
name="Yahtzee" 
rom0=C|6000|2000|G:\Nedlastninger\Software\Software installert\TI 99 4A\000 Classic99\classic99\MODS\Orginal\Yahtzeec.bin 
rom1=G|6000|A000|G:\Nedlastninger\Software\Software installert\TI 99 4A\000 Classic99\classic99\MODS\Orginal\Yahtzeeg.bin

Share this post


Link to post
Share on other sites

I can confirm those aren't working.

 

I will write again after I know why. ;)

 

  • Like 2

Share this post


Link to post
Share on other sites

Haha, well, that was easy. It has been so long since I added a group that I never thought about how the emulator knows what groups you want. You need to add one more section to your INI, that lists out the groups you want it to search. "Usercart" is automatic, you do not list that one. So, mine looks like this:

[CartGroups]
Group0=Mikes
Group1=Test

So... yours would be something like this:

[CartGroups]
Group0=Spill
Group1=Games

You can have up to 100 groups, numbered 0-99. But, of course, I don't know what Windows will do if you exceed the screen real estate, so stay conservative. ;)

 

The "usercart|xxx" and "usercart0xxx" are not valid, but I totally understand why you tried them! :)

 

Sorry about that!

 

  • Like 1

Share this post


Link to post
Share on other sites

I wanted to make 7 After last test, I know now that I had to long names! Max 5 letters!

 

If you do:

[CartGroups]

Group0=Spill

Group1=Programmer - It dos not work!

 

[CartGroups]

Group0=Spill

Group1=Prog - Dos work

[CartGroups]
Group0=Spill - 5 letters is the limit!
Group1=Prog
Group3=Fav
Group4=Fav123 - Dos not work!

But if you put the CartGroups and then the Groups before all the [usercartx], then it dos NOT work!

Share this post


Link to post
Share on other sites

OK Working working... Some Edu files are in and working... Some other games and progs are OK and suddenly...

(I use the "TI99_MiSTer_FPGA_Core_SSS_Mega_Pack_V2.0.0\TI99_MiSTer_FPGA_Core\TI-99_4A" as a "Standard" to sort my Groups in... So I did )

 

[G20186] <--------------------(SSS_Games_HomeBrew_4K_Contest_2018) Two of the games I have problems with! "Fork" and "Markus" I have problems with all Type 8 file
; *** Markus of Marinus ????
name="Markus of Marinus" 
rom0=8|0000|4000|G:\Nedlastninger\Software\Software installert\TI 99 4A\000 Classic99\classic99\MODS\SSS_Games_HomeBrew_4K_Contest_2018\[HOMEBREW] Markus of Marinus (2018)(Owen Brand)[PAGED_378]_8.bin

 

[G20187] <--------------------This one is OK! No file for this one!
; *** Vortex OK
name="Vortex" 
rom0=C|6000|2000|G:\Nedlastninger\Software\Software installert\TI 99 4A\000 Classic99\classic99\MODS\SSS_Games_HomeBrew_4K_Contest_2018\[HOMEBREW] Vortex (2018)(Vorticon)_C.bin

 

 

[TIBa10] - This dos not work! As fare as I understand, I think I did the "8" stuff right or? Put in the 8 first TI Basic progs. and all did not work. Probably same issue!
*** 3D-Labyrinth
name="3D-Labyrinth" 
rom0=8|0000|4000|G:\Nedlastninger\Software\Software installert\TI 99 4A\000 Classic99\classic99\MODS\SSS_Games_TIBasic\[TI BASIC] 3D-Labyrinth (1983)(Marc Bruening & Wolfgang Bertsch)[Converted by TMOP]_8.bin


PS! HeroX - Cool game!

 

C99 002.png

[HOMEBREW] Markus of Marinus (2018)(Owen Brand)[PAGED_378]_8.bin [TI BASIC] 3D-Labyrinth (1983)(Marc Bruening & Wolfgang Bertsch)[Converted by TMOP]_8.bin

Edited by oddemann
bugs

Share this post


Link to post
Share on other sites
1 hour ago, oddemann said:

[CartGroups]
Group0=Spill - 5 letters is the limit!

 

 

Not so. These work just fine. Using your example (facetiously!):

[CartGroups]
Group0=Spill - 5 letters is the limit!
[Spill - 5 letters is the limit!0]
name=Whatever one
rom0=8|0000|8000|MODS\whatever_one_8.bin
[Spill - 5 letters is the limit!1]
name=Whatever two
rom0=9|0000|8000|MODS\whatever_two_9.bin

classi99_INI_test.thumb.png.9cd71b09598ae211679146c3d1166390.png

 

2 hours ago, oddemann said:

But if you put the CartGroups and then the Groups before all the [usercartx], then it dos NOT work!

 

This works just fine for me, as well. And, I have the same version of Classic99 as you.

 

...lee

  • Like 1

Share this post


Link to post
Share on other sites

Should this kind of file work?

This is my test and it is not working...

 

[Demo0]
; *** Commando Music OK
name="Commando Music" 
rom0=8|0000|8000|G:\Nedlastninger\Software\Software installert\TI 99 4A\Frittstående Ressurser\TI99_MiSTer_FPGA_Core_SSS_Mega_Pack_V2.0.0\TI99_MiSTer_FPGA_Core\TI-99_4A\SSS_Demos_Cart_Conversion\[DEMO] Commando Music (20xx)(Unknown)[PAGED_378]_8.bin

[Demo1]
; *** Gyruss Music Demo OK
name="Gyruss Music Demo" 
rom0=8|0000|8000|G:\Nedlastninger\Software\Software installert\TI 99 4A\Frittstående Ressurser\TI99_MiSTer_FPGA_Core_SSS_Mega_Pack_V2.0.0\TI99_MiSTer_FPGA_Core\TI-99_4A\SSS_Demos_Cart_Conversion\[DEMO] Gyruss Music Demo (20xx)(Sometimes)[PAGED_378]_8.bin

[Demo2]
; *** Lines MM Demo - NOT OK!!!
name="Lines MM Demo" 
rom0=8|0000|30000|G:\Nedlastninger\Software\Software installert\TI 99 4A\Frittstående Ressurser\TI99_MiSTer_FPGA_Core_SSS_Mega_Pack_V2.0.0\TI99_MiSTer_FPGA_Core\TI-99_4A\SSS_Demos_Cart_Conversion\[DEMO] Lines MM Demo (19xx)(Texas Instruments)[CART Conversion]_FULL-ROM.bin

[DEMO] Lines MM Demo (19xx)(Texas Instruments)[CART Conversion]_FULL-ROM.bin

Share this post


Link to post
Share on other sites
6 minutes ago, Lee Stewart said:

 

Not so. These work just fine. Using your example (facetiously!):

[CartGroups]
Group0=Spill - 5 letters is the limit!
[Spill - 5 letters is the limit!0]
name=Whatever one
rom0=8|0000|8000|MODS\whatever_one_8.bin
[Spill - 5 letters is the limit!1]
name=Whatever two
rom0=9|0000|8000|MODS\whatever_two_9.bin

classi99_INI_test.thumb.png.9cd71b09598ae211679146c3d1166390.png

 

 

This works just fine for me, as well. And, I have the same version of Classic99 as you.

 

...lee

Strange... YES! NOW your right!!!

I tried it before and then It would not accept more then 5 letters! Strange!!!

Edited by oddemann

Share this post


Link to post
Share on other sites
2 hours ago, oddemann said:

[DEMO] Lines MM Demo (19xx)(Texas Instruments)[CART Conversion]_FULL-ROM.bin

 

This file does not look like a cartridge ROM binary. The first 64 KiB are empty and there are only three addresses on 8 KiB boundaries that start with ‘AA’ and only one of those looks like a legitimate cartridge header with a single menu item called “LINES”. See spoiler below for a summary:

Spoiler
Address  Contents
-------  ---------------------------------------
00000    <64 KiB empty>
0FFFF

10000    AA02 0000 0000 0000 1310 1320 0000 0000 
         43DC 443C 49A9 4396 439E 4446 4449 444C 
         4052 51FE 4C82 4D59 4DB4 4E64 4EF9 4F01 
         4F5F 4F80 43CE 43D6 054D 1252 5E44 1705
         * * *

12000    AA02 0100 0000 214D 0000 4D1A 0000 0000 
         4417 4195 460B 466C 467E 4192 47F1 436D 
         46AB 8A80 B7A1 B2AE A9AE A79A 13A9 AEA3 
         AFB2 B2A5 A3B4 80B3 B4A1 B4A5 ADA5 AEB4
         * * *

14000    <no header information, but not empty>
         * * *

         <Below is only possible ROM cartridge header>
16000    AA01 0100 0000 600C 0000 0000 0000 6042 
         054C 494E 4553 2020 2020 2020 2020 2020 
         2020 2020 2020 3E3E 2D2D 2043 4152 5420 
         434F 4E56 2042 5920 5455 5253 4920 2D2D

18000    <no header information, but not empty>
         * * *

1A000    <64 KiB empty>
29FFF
 
2A000    <no header information, but not empty>
         * * *
      
2C000    <16 KiB empty>
2FFFF

 

 

...lee

Share this post


Link to post
Share on other sites
10 minutes ago, Lee Stewart said:

 

This file does not look like a cartridge ROM binary. The first 64 KiB are empty and there are only three addresses on 8 KiB boundaries that start with ‘AA’ and only one of those looks like a legitimate cartridge header with a single menu item called “LINES”. See spoiler below for a summary:

  Reveal hidden contents

Address  Contents
-------  ---------------------------------------
00000    <64 KiB empty>
0FFFF

10000    AA02 0000 0000 0000 1310 1320 0000 0000 
         43DC 443C 49A9 4396 439E 4446 4449 444C 
         4052 51FE 4C82 4D59 4DB4 4E64 4EF9 4F01 
         4F5F 4F80 43CE 43D6 054D 1252 5E44 1705
         * * *

12000    AA02 0100 0000 214D 0000 4D1A 0000 0000 
         4417 4195 460B 466C 467E 4192 47F1 436D 
         46AB 8A80 B7A1 B2AE A9AE A79A 13A9 AEA3 
         AFB2 B2A5 A3B4 80B3 B4A1 B4A5 ADA5 AEB4
         * * *

14000    <no header information, but not empty>
         * * *

         <Below is only possible ROM cartridge header>
16000    AA01 0100 0000 600C 0000 0000 0000 6042 
         054C 494E 4553 2020 2020 2020 2020 2020 
         2020 2020 2020 3E3E 2D2D 2043 4152 5420 
         434F 4E56 2042 5920 5455 5253 4920 2D2D

18000    <no header information, but not empty>
         * * *

1A000    <64 KiB empty>
29FFF
 
2A000    <no header information, but not empty>
         * * *
      
2C000    <16 KiB empty>
2FFFF

 

 

...lee

This is something I found that is named... TI99_MiSTer_FPGA_Core_SSS_Mega_Pack_V2.0.0. It had a nice catalog structure and a lot of Carts.

I don't know if this is something for Raspberry Pi or some of the other cards you can now get for the TI

Share this post


Link to post
Share on other sites

One important detail - as there is way too much information up there for me to figure out what I need to answer next... ;)

 

The ONLY thing that decides whether an entry shows up in the menu is the existence of "Name=". If you don't see your entry, either you typoed the group name or you typoed (or omitted) the "name" line.

 

Don't get fancy with punctuation, you can never be sure how a filename/text parser will deal with it. Particularly since the square brackets are meaningful syntax in an INI file. When in doubt, simplify.

 

You shouldn't need quotation marks around the values.

 

I think I did the "8" stuff right or?

 

First thing you need to do when it doesn't work, is read the debug log and see if the emulator did what you expected it to do, and did not emit any warnings. :)

 

Share this post


Link to post
Share on other sites
2 hours ago, Lee Stewart said:

 

This file does not look like a cartridge ROM binary. The first 64 KiB are empty and there are only three addresses on 8 KiB boundaries that start with ‘AA’ and only one of those looks like a legitimate cartridge header with a single menu item called “LINES”. See spoiler below for a summary:

  Reveal hidden contents

Address  Contents
-------  ---------------------------------------
00000    <64 KiB empty>
0FFFF

10000    AA02 0000 0000 0000 1310 1320 0000 0000 
         43DC 443C 49A9 4396 439E 4446 4449 444C 
         4052 51FE 4C82 4D59 4DB4 4E64 4EF9 4F01 
         4F5F 4F80 43CE 43D6 054D 1252 5E44 1705
         * * *

12000    AA02 0100 0000 214D 0000 4D1A 0000 0000 
         4417 4195 460B 466C 467E 4192 47F1 436D 
         46AB 8A80 B7A1 B2AE A9AE A79A 13A9 AEA3 
         AFB2 B2A5 A3B4 80B3 B4A1 B4A5 ADA5 AEB4
         * * *

14000    <no header information, but not empty>
         * * *

         <Below is only possible ROM cartridge header>
16000    AA01 0100 0000 600C 0000 0000 0000 6042 
         054C 494E 4553 2020 2020 2020 2020 2020 
         2020 2020 2020 3E3E 2D2D 2043 4152 5420 
         434F 4E56 2042 5920 5455 5253 4920 2D2D

18000    <no header information, but not empty>
         * * *

1A000    <64 KiB empty>
29FFF
 
2A000    <no header information, but not empty>
         * * *
      
2C000    <16 KiB empty>
2FFFF

 

 

...lee

These files are from my pack for MiSTer FPG TI99 core. There is a readme.txt file in the archive that explains the meaning of the suffix:

"... These are converted files that contains GROMS, ROMS and the TI99 BIOS in the same file ("FULL-ROM.bin" suffix). Load with the "Load Full or C.bin *.BIN" option in MiSTEr menu."

 

Basically those with the "FULL-ROM.bin" are 196.608bytes files containing the full MiSTer memory map and are working only with MiSTer TI99 core. 

 

I suggest to download the pack I've prepared for MESS, that has the same files in the standard .C, .D and .G formats. You can download it on the ti99iuc site: http://www.ti99iuc.it/web/?pageid=articoli_tech&artid=196#.X01tku9xeUk at the end of the page.

 

 

  • Like 2

Share this post


Link to post
Share on other sites

For what it's worth, Classic99 already includes a LINES demo object for the MiniMemory in its DSK1 folder ;)

 

  • Like 4

Share this post


Link to post
Share on other sites

Ok I have to point out something crashing in Classic99.

QI399.31 has a bug.

When I load RXB 2020 into GRAM and go back to REA 2015 GPL Assembler it will lock up or reports nothing but errors.

I do not load GRAM7 where REA 2015 is only GRAM 3, 4, 5, and 6 ONLY!

When every I do GPL Assembly it either locks up at Symbol Table forever or just reports error after error after error.....

Shut down Classic99 with fresh version runs same exact code from GPL Assembler and not a single issue.

It only happens when I have loaded GRAM and even though I have not touched GRAM 7 where the GPL Assembler is running from it crashes???

What I am forced to do now is anything I have to assemble GPL code I have to run another Classic99 with no modification to get no errors or crash.

I tested this with a much older version Classic99 QI399.22 and it did not crash as often. 

I would say QI399.31 does it 70% of time and QI399.22 does it 30% of time.

Just to prove the problem exists I do not have anything else running in Windows 10 but Classic99

Share this post


Link to post
Share on other sites

Unfortunately, you're going to need to dig deeper to help troubleshoot that. It sounds like uninitialized memory, but it could also be a state issue in Classic99.

 

I don't have the time right now to trace through GPL code to see what is locking up, so the first thing to do is to identify what is happening WHEN it locks up. A screenshot or two, and a copy/paste of the disassembler (AND DEBUG LOG) would help. (Please, not screenshots of the logs, use view->freeze and then you can copy/paste the text). If you understand the lock up, some description of what the code is doing would also help.

 

Basically.. I'm not debugging third party code anymore. I realize you didn't write the GPL Assembler, and we're stuck with what IS, but neither do I have any experience with it, and I will spend hours just getting up to speed. So help me help you, collect as much information as you can about what is happening under the hood, and then we can try to figure out WHY. ;)

 

  • Like 4

Share this post


Link to post
Share on other sites

Had to give up on Classic99 SAMS test for size as you can put >FFFF into SAMS Register >4004 (>2000) and >4006 (>3000) and test if the page change.

I have no idea what page is actually loaded at time as it is impossible to be page >FFFF as that would be a 256 Meg SAMS and I am told only a 32 Meg SAMS is in Classic99 QI399.031

Share this post


Link to post
Share on other sites
On 9/5/2020 at 5:02 PM, Tursi said:

Unfortunately, you're going to need to dig deeper to help troubleshoot that. It sounds like uninitialized memory, but it could also be a state issue in Classic99.

 

I don't have the time right now to trace through GPL code to see what is locking up, so the first thing to do is to identify what is happening WHEN it locks up. A screenshot or two, and a copy/paste of the disassembler (AND DEBUG LOG) would help. (Please, not screenshots of the logs, use view->freeze and then you can copy/paste the text). If you understand the lock up, some description of what the code is doing would also help.

 

Basically.. I'm not debugging third party code anymore. I realize you didn't write the GPL Assembler, and we're stuck with what IS, but neither do I have any experience with it, and I will spend hours just getting up to speed. So help me help you, collect as much information as you can about what is happening under the hood, and then we can try to figure out WHY. ;)

 

Seems the problem is once you LOAD GRAM it gets corrupted somehow. I have noticed I have to restart Classic99 even when just loaded it, but see corruptions.

I have no idea what is causing it, but seems to tied to Disk Access when loading. After the 3rd try it seems to work fine. No clue what is the cause.

Using a AMD 3900X chip and 32Gig of RAM on a Rocket 2Tb drive for main drive. All less then 5 months old, mother board and CPU are less then 2 weeks old.

Edited by RXB
missing text

Share this post


Link to post
Share on other sites

For a start we can assume it's not your computer. If you get a chance, spend some time on trying to come up with a 100% reproduction case. If you can do that and I can follow the steps, I can fix it! But right now I don't know where to start. 😕

 

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
4 hours ago, RXB said:

Had to give up on Classic99 SAMS test for size as you can put >FFFF into SAMS Register >4004 (>2000) and >4006 (>3000) and test if the page change.

I have no idea what page is actually loaded at time as it is impossible to be page >FFFF as that would be a 256 Meg SAMS and I am told only a 32 Meg SAMS is in Classic99 QI399.031

 

Uh oh! I think I know what is going on here. If you write a page number to a SAMS register that is higher than it is wired to read, the bits that are connected are what will set the page. If you write >FFFF to >4004 and only 13 bits (32 MiB) are connected, the high three bits are ignored and you get page >1FFF. Unfortunately, there is no easy way to discover what page actually got loaded without going down range, writing something and coming back to see whether the first write was overwritten. Without being able to read all bits connected to a SAMS register (see post #242 of SAMS usage in Assembly), we are flying blind on the high end. This means that I will need to change how fbForth 2.0 is deciding how much SAMS memory there is attached. Right now, I am starting high after writing a couple of bytes, checking whether they disappeared. If they did, I conclude that I hit the highest page and exit. If not, I keep halving the page. My method is flawed because, if any SAMS is present, my method will determine there is 32 MiB. Assuming 128 KiB SAMS (highest page = >001F) is the lowest likely to be found and that is what I am actually testing, page >001F will be written to every time! Back to the drawing board.

 

...lee

Edited by Lee Stewart
corrections
  • Like 1

Share this post


Link to post
Share on other sites
15 hours ago, Lee Stewart said:

 

Uh oh! I think I know what is going on here. If you write a page number to a SAMS register that is higher than it is wired to read, the bits that are connected are what will set the page. If you write >FFFF to >4004 and only 13 bits (32 MiB) are connected, the high three bits are ignored and you get page >1FFF. Unfortunately, there is no easy way to discover what page actually got loaded without going down range, writing something and coming back to see whether the first write was overwritten. Without being able to read all bits connected to a SAMS register (see post #242 of SAMS usage in Assembly), we are flying blind on the high end. This means that I will need to change how fbForth 2.0 is deciding how much SAMS memory there is attached. Right now, I am starting high after writing a couple of bytes, checking whether they disappeared. If they did, I conclude that I hit the highest page and exit. If not, I keep halving the page. My method is flawed because, if any SAMS is present, my method will determine there is 32 MiB. Assuming 128 KiB SAMS (highest page = >001F) is the lowest likely to be found and that is what I am actually testing, page >001F will be written to every time! Back to the drawing board.

 

...lee

Yea we have hit the same snag. I just removed the test of SAMS size from SIZE and CALL SIZE routines due to this issue.

It will just always pick the default top limit even if that is not true.

Also as I am using GPL it was taking almost 3 seconds to get an answer, but that was my fault as I was starting from 1 Meg and going up to 256 Meg.

 

I do report the page numbers it finds and show every memory area now of used and unused memory.

Edited by RXB

Share this post


Link to post
Share on other sites

The simplest way I know to size memory is to map page 0 and the page under test (to different addresses, of course). Write to the page under test and see if it appears on page 0. If so, you just wrapped around - the previous page was the last one. That's probably the fastest way if it works.

 

In either case, you only need to write once to each page. The goal is not a memory test, just to see how much there is. 32MB would only be 8192 pages... but yeah, I guess even that is getting up there for our little CPU. The GPL version could drop a tiny assembly test into scratchpad though, that would be quick enough.

 

 

 

  • Like 2

Share this post


Link to post
Share on other sites

I think, when I did this manually with EASYBUG, I just wrote and incremented a number to the first page of every 16M segment until I got a repeated value back, than I checked the page before. So when I got to >2000 and got a rollover I went back to >1FFF. Easy, but that doesn't account for 128k or 512k boards.

  • Like 2

Share this post


Link to post
Share on other sites
On 9/11/2020 at 2:29 PM, Tursi said:

For a start we can assume it's not your computer. If you get a chance, spend some time on trying to come up with a 100% reproduction case. If you can do that and I can follow the steps, I can fix it! But right now I don't know where to start. 😕

 

Tursi you were right it was not my computer, it was DSK2 that was corrupted by TIDIR as once I deleted DSK2 and replaced it with a new folder it works fine.

Over the last 2 years I had noticed if I have Classic99 and TIDIR both open and running it would do this pretty often, but not if I closed TIDIR from access folders while Classic99 is running.

TIDIR does something to Folders randomly so I think it may be a memory leak or file permissions or something.

TIDIR works great as long as you use it and close it before you use files, if you leave it running goofy things start happening.

  • Like 2

Share this post


Link to post
Share on other sites

Hmmm... that's probable. TIDIR will cache information from a disk image, so if Classic99 changes it underneath (due to a write), TIDIR will not know about the change and will perform its next operation based on the cached data. (Classic99 doesn't cache anything on purpose, to minimize that risk -- but that doesn't mean the TI software you are running doesn't!)

 

This tends to be less of an issue with files than disk images, but I think in the end your advice is fair - be careful if multiple programs are accessing the same files.

 

  • Like 3

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...