Classic99 Updates

[Willsy]

I've been using Classic99 full-time for about 4 years. I developed TurboForth (a part-time, 2 year project) with it. File access is built right into the heart of TF. I've never ever had a problem with file access in classic99.

 

If you are using FIAD mode then remember it's not finished, and you get what you pay for

 

Mark

[matthew180]

Amazing that the PC sucks so much at editing a document by columns.

 

A "PC" (personal computer) is just a computer and has nothing to do with whether or not it can do a certain task. The right software for the job... And the Windows platform has more software than any other computer OS in history, so I would say there is probably a great tool for editing columns. Just because an esoteric tool is not available by default on a system does not mean such a task is hard to do on that system. I could just as easily say "amazing that the 99/4A sucks so much at 3D solid modeling."

 

As for the Docs of Classic99 they really need examples that are easy to follow and see how they work, unless you plan that the only 30 guys in the world will ever use it.

 

You are probably pretty close on that. The 99/4A community is very small world-wide, and I doubt it is going to grow. These are not the "golden years" of home computers and there are not thousands of users for anything. These days, you better be doing this kind of stuff because you love it. If you are in it for the money, or a large user base, you are going to be sorely disappointed.

 

I showed it to my daughter to use and she gave up after 2 hours.

She loves to play Classic TI stuff, but like she said "Who the hell wrote these instuctions?", "Do they expect the average person to understand this crap?" I think she has a point. Simple examples explain more then some explainations do.

I am personally trying to stay with Classic99 and not have to move back to PC99 or MESS, I just need better Docs then provided.

 

Is your daughter a programmer with 9900 assembly experience? If not, she is not the intended audience.

 

You are stating a contradiction. "Technical" and "average person to understand" do not go together. Neither does "options" and "simple". If I write documentation, I have to assume a certain level of knowledge about the reader. Do my docs have to teach someone English in case they don't already know it??? You have to pick a starting point, and your docs can't be everything to everyone.

 

Classic99 docs are written to a target user that is assumed to be more technical and knowledgeable of the system, and possibly even some programming under their belt. Could they be better? Probably. But shoving a technical manual in front of someone non-technical will probably solicit the same response as your daughter.

 

To answer her question: "Do they expect the average person to understand this crap?" No, *we* don't. We expect you to know the 99/4A from a technical standpoint, hex, and a little assembly language. If she is not in that category, then she is not qualified to comment on the documentation. "Average person" use of Classic99 stops beyond choosing cartridges from the menu and playing the provided cartridge-based games (which I assume she can do just fine.)

[matthew180]

What I am doing is pretty simple. I take a 1200 sector DV80 file and XB reads it and deletes the first 22 bytes. Then the next pass I included a XB line that looks for things like "Page ###" or "Pass #" or "New,alpha)" and eventually I have a clean file

converted from a List file to a Source file to use. Absolutely nothing in the PC side can do this, and if there is then that requires a whole bunch of new stuff to learn and load. I guess I will just have to do it in PC99 as that just gets the job done.

 

I can do that job on a Unix box, MAC, or Windows machine in any of 3 languages I use regularly. Having a "bunch of new stuff to learn" is totally based on your perspective and what you already know. Before you knew GPL it was a "bunch of new stuff to learn"... Again, knowing your system, how it works, and having tools to help you get the job done are key.

 

If you keep your knowledge stuck in the 80's, then you are going to be consistently frustrated with a modern PC (personal computer, whether that is a MAC, Windows, Linux, FreeBSD, or whatever.) Things change, and only you can decide if you want to fight the change or pick up a few new tools to make life easier. I would recommend you find a scripting language like PHP, Python, Ruby, or even Javascript, and get set up on your "PC" to use the language. Or, go with the .NET framework if you want to kick out programs in a hurry. Personally I like C and use either Visual C++ or MinGW on my "PC". Recently I've been learning Python, which everyone raves about but I'm finding it does not really suit my personality - but I'll give it a few more *weeks*.

 

Also, get a *good* text editor like Textpad or Notepad++. Finally, learn enough about the filesystem of your "PC" to understand how files are stored and paths are written and referenced. It has nothing to do with DOS any more, and you don't need to learn DOS (you will never use a DOS command on a modern Windows machine or "PC"). As for DOS vs. CP/M... Who cares? Neither are main-stream any more and my limited experience with CP/M sucked (hate it, can't work with it, glad it died.) DOS sucks too, but that's what we had. The only thing on a Windows machine you need to know from DOS is that directory delimiters are a back-slash (vs. a forward-slash on other Unix-based systems) and drives are still "lettered", i.e. C:, D:, etc.

 

Am I ranting? This feels like a rant.

[OX.]

OK an example of disk to run with delay between keypresses - say I want to autoselect game 5 from the attached disk image after the menu has loaded.

 

I've got a bug to report in the last update (V3.54) since the autodetect cart routine was implemented - It seems to be experiencing variable speed issues (don't know if it's just audio playback), this is noticable in the previously attached arcturus side cart image game. It does'nt happen in V3.53 but was getting this effect with V3.53 when I was creating the .ini entries in the wrong order so perhaps it's just stuff in the .ini being created differently to that of V3.53?

 

Did not change anything for a long time that should affect speed, nor should the order of the INI file make any difference (I don't parse the INI myself, I just read entries from it using the Windows API.) Probably you are seeing a longer term issue caused by something else, so I'll need some way to reproduce it. Maybe zip up your test folder for me?

 

Likewise, for examples like your disk, can you please zip up your whole test including the INI to save me the time setting up a reproduction case? Otherwise I'm just guessing at what you're doing, and if I don't reproduce we have to go around an extra time. And I can quickly see if there's an error in the INI or something I didn't consider.

 

One thing I forgot to mention, if you don't delete the INI every time from your front end, you probably should write protect it, otherwise on exit Classic99 will fill in all the other settings.

 

Anyway... the standard paste mechanism works fine here. Starts Extended BASIC, loads the LOAD program, and selects item 5. What are you seeing in your test?

 

[Disk1]
Type=2
Path=Tigercub 1309 - Tigercub's Brain Games (19xx)(Tigercub Software)(PD).dsk

[roms]
cartgroup=2
cartidx=0

[usercart0]
name=Tigercub 1309 #5
rom0=O|0000|0004|Extended BASIC
rom1=K|0000|0000|x225\n

 

What are you seeing?

 

TigerCubTest.zip

 

The speed issue is a strange one as it doesn't reproduce when running the emulator standalone only from the Gamebase front end, so I'll need to take a better look at that.

 

Having now played around with several disk menu compilation disks I have unearthed what looks to be a bug :-

 

The attached disk contains a Backgammon game that is executed from option [A] in the disk menu.

However, when ran with Classic99 the menu misses the first file on the disk.

 

in MESS option [A] = Backgammon

in Classic99 option [A] = Bullfrog

 

Can you please shed any light on this?

PRGI3.zip

Edited June 1, 2011 by OX.

[Tursi]

Thanks Mark and Matthew! We'll get Rich onboard (they are right about Classic99's target though)

 

The attached disk contains a Backgammon game that is executed from option [A] in the disk menu.

However, when ran with Classic99 the menu misses the first file on the disk.

 

in MESS option [A] = Backgammon

in Classic99 option [A] = Bullfrog

 

Can you please shed any light on this?

 

Yep! You found a bug! I was wondering about this just tonight, too.. Classic99 is dropping the first file from imgdisk directories by skipping that entry in the directory map. (It starts counting at index 1 instead of 0). Duh.

 

I've updated it now. Go grab 355 and see if that helps!

[OX.]

Thanks Mark and Matthew! We'll get Rich onboard (they are right about Classic99's target though)

 

The attached disk contains a Backgammon game that is executed from option [A] in the disk menu.

However, when ran with Classic99 the menu misses the first file on the disk.

 

in MESS option [A] = Backgammon

in Classic99 option [A] = Bullfrog

 

Can you please shed any light on this?

 

Yep! You found a bug! I was wondering about this just tonight, too.. Classic99 is dropping the first file from imgdisk directories by skipping that entry in the directory map. (It starts counting at index 1 instead of 0). Duh.

 

I've updated it now. Go grab 355 and see if that helps!

 

Excellent, Thanks Tursi.

 

I hope you don't mind but I have what may be another disk handling bug - Infocom games crash out after loading the interpretor with "<Internal error> Disk read error" (Tested in V3.55 also in case the new update fixed it).

 

Any ideas?

zork1.zip

[Tursi]

I hope you don't mind but I have what may be another disk handling bug - Infocom games crash out after loading the interpretor with "<Internal error> Disk read error" (Tested in V3.55 also in case the new update fixed it).Any ideas?

 

Going to make you troubleshoot that, I don't provide support for applications I didn't write. Observe the Classic99 debug log and see if it reports anything interesting, and post the log here, and I'll take a peek.

 

There are certain means of accessing the disk that are not emulated for image disks.

[OX.]

I hope you don't mind but I have what may be another disk handling bug - Infocom games crash out after loading the interpretor with "<Internal error> Disk read error" (Tested in V3.55 also in case the new update fixed it).Any ideas?

 

Going to make you troubleshoot that, I don't provide support for applications I didn't write. Observe the Classic99 debug log and see if it reports anything interesting, and post the log here, and I'll take a peek.

 

There are certain means of accessing the disk that are not emulated for image disks.

 

Here's the Debug log :-

 

Initializing AMS mode 2, size 1024k

Loading file from resource: Type O, Bank 0, Address 0x0000, Length 0x0004

Loading file from resource: Type G, Bank 0, Address 0x6000, Length 0x8000

Loading file from resource: Type C, Bank 0, Address 0x6000, Length 0x2000

Loading file from resource: Type X, Bank 0, Address 0x6000, Length 0x2000

Loading file from resource: Type K, Bank 0, Address 0x0000, Length 0x0000

Loading file from resource: Type D, Bank 0, Address 0x1100, Length 0x01A0

Loading file from resource: Type S, Bank 0, Address 0x0000, Length 0x8000

Loading file from resource: Type P, Bank 0, Address 0x0000, Length 0xF800

Loading file from resource: Type G, Bank -1, Address 0x0000, Length 0x6000

Loading file from resource: Type C, Bank -1, Address 0x0000, Length 0x2000

Loading file from resource: Type O, Bank 0, Address 0x0000, Length 0x0004

Loading file from resource: Type G, Bank 0, Address 0x6000, Length 0x8000

Loading file from resource: Type C, Bank 0, Address 0x6000, Length 0x2000

Loading file from resource: Type X, Bank 0, Address 0x6000, Length 0x2000

Loading file from resource: Type K, Bank 0, Address 0x0000, Length 0x0000

Setting top of VRAM to >37D7 (3 files)

Loading to VDP >096F DSK1.LOAD on drive type Image

loading 0x71C bytes

Loading to VDP >1000 DSK1.ZORK-I on drive type Image

loading 0xE00 bytes

Loading to VDP >1000 DSK1.ZORK-J on drive type Image

loading 0x1700 bytes

Opening DSK1.ZRK11 on drive type Image

PAB requested file type is DF255

Allocating file buffer 0

c:\gbgame\0\zork1.dsk::ZRK11 read 90 records

Read 0xFF bytes drive 1 file ZRK11 (Fixed record 88) to >07D0

Read 0xFF bytes drive 1 file ZRK11 (Fixed record 89) to >08D0

Seek past end of file ZRK11

Failed reading max 255 bytes DSK1.ZRK11 on drive type Image

Setting file error 5 on file buffer 18

Releasing file buffer 18

 

OX.

 

My uneducated guess would be that some file is missing an EOF marker (which is ignored in MESS?)?

[Tursi]

c:\gbgame\0\zork1.dsk::ZRK11 read 90 records

Read 0xFF bytes drive 1 file ZRK11 (Fixed record 88) to >07D0

Read 0xFF bytes drive 1 file ZRK11 (Fixed record 89) to >08D0

Seek past end of file ZRK11

Failed reading max 255 bytes DSK1.ZRK11 on drive type Image

Setting file error 5 on file buffer 18

Releasing file buffer 18

 

My uneducated guess would be that some file is missing an EOF marker (which is ignored in MESS?)?

It's pretty normal for applications to read past EOF as their EOF detection (not saying it's correct in Classic99, mind you, but so far it seems to be).

 

The line that ends with "read 90 records" is actually the last thing that is done insofar as the disk image happens - at that point the file has been buffered and stored as records in memory. So when it starts reading, that code should be common.

 

Weird that it starts at the end of the file... not sure what to make of that. Well, your next step is to extract the files from the image with TI99Dir, drop them into a folder, and see if it works there. Remember that disk images are experimental, so we just want to make sure whether it's the disk image support or the application which is malfunctioning.

 

The only thing I see that's unusual is the 255 byte record size is unusual on the TI, maybe I have a bug in handling those.

[+adamantyr]

The only thing I see that's unusual is the 255 byte record size is unusual on the TI, maybe I have a bug in handling those.

 

Hm... I can't find the reference now, but I don't think it's actually possible to set a record length to 255. If you do, the TI Disk Controller goes to a length of 80 as a default.

 

Adamantyr

[Tursi]

The only thing I see that's unusual is the 255 byte record size is unusual on the TI, maybe I have a bug in handling those.

 

Hm... I can't find the reference now, but I don't think it's actually possible to set a record length to 255. If you do, the TI Disk Controller goes to a length of 80 as a default.

 

Adamantyr

 

No, I'm pretty sure it's fine.. a default record length is only set if you use a record length of 0.

 

I got curious and took a look anyway... it looks like there is an issue with Classic99's handling of "current record" (which I more or less guessed at anyway). It's possible to just let the system count off records for you, but I detect that with an input record number of 0. Zork reads the last two records (88 and 89), then changes the record number to zero to read again... my code is detecting that as 'read next' and trying to read record 90, which doesn't exist.

 

Time to dig through Thierry's DSR disassembly and see the right way to handle that...

[Tursi]

Posted version 356. Fixes seeking to record 0 in relative files. (So Zork works now).

 

Also some MPD tweaks since that's what I was working on today.

[+retroclouds]

Posted version 356. Fixes seeking to record 0 in relative files. (So Zork works now).

 

Also some MPD tweaks since that's what I was working on today.

 

ok, I might have been offline for a short while. But what are the MPD tweaks ?

[Tursi]

Posted version 356. Fixes seeking to record 0 in relative files. (So Zork works now).

 

Also some MPD tweaks since that's what I was working on today.

 

ok, I might have been offline for a short while. But what are the MPD tweaks ?

 

The MPD is my Multiple Personality Distorter - a replacement console GROM set. The intro video I posted (which doesn't have the new OS cause it's not coded yet) is here:

 

Classic99 needs support for it since I'm developing it there.

[matthew180]

That's bad ass! Did you explain somewhere (like in the forum somewhere) on how you put the E/A editor and assembler in the GROM? I'm very curious about how you hacked that up?

[OX.]

Posted version 356. Fixes seeking to record 0 in relative files. (So Zork works now).

 

Also some MPD tweaks since that's what I was working on today.

 

Thanks once again Tursi - it's coming along a treat.

[OX.]

Hi Tursi, A couple of questions :-

 

. Is 80 column mode possible with Classic99?

 

. Is there any chance of implementing a "turbo-load" feature, ie: CPU speed automatically set to max for all disk operations and then resumes normal speed when disk activity has stopped (toggle setting under Menu - Disk & remembered in the classic99.ini)?

 

OX.

Edited June 3, 2011 by OX.

[Tursi]

. Is 80 column mode possible with Classic99?

 

Not today. It's on the books, but it's another non-standard add-on so it's not a priority of any sort. Possibly when I rewrite the VDP.

 

. Is there any chance of implementing a "turbo-load" feature, ie: CPU speed automatically set to max for all disk operations and then resumes normal speed when disk activity has stopped (toggle setting under Menu - Disk & remembered in the classic99.ini)?

 

Disk access is not emulated - it's simulated. So it already runs as fast as it possibly can (it becomes a memcpy in the emulator!). All delays you see related to loading of BASIC and XB is what's called the "prescan" - BASIC on the TI examines the program before starting it and builds tables before starting to execute. There's no straight-forward way to accelerate the prescan on a system where the GROMs are allowed to change, sadly.

[Tursi]

That's bad ass! Did you explain somewhere (like in the forum somewhere) on how you put the E/A editor and assembler in the GROM? I'm very curious about how you hacked that up?

 

I thought I did have a thread somewhere... but that's just the E/A Complete that I showed at the Chicago TI Faire last year. All it does is replace the code that loads EDIT1 and ASSM1 and ASSM2 with GPL MOVE instructions. In the case of the MPD, there's a little bit of bank switching going on too, since everything has to fit in the 3 console GROMs. The good news about this project is I've taken pains to document every little hack I did so when I do release it, everything is written down.

 

The harder part was relocating the Editor/Assembler to run at GROM >2000 instead of >6000 without source.

[OX.]

. Is 80 column mode possible with Classic99?

 

Not today. It's on the books, but it's another non-standard add-on so it's not a priority of any sort. Possibly when I rewrite the VDP.

 

. Is there any chance of implementing a "turbo-load" feature, ie: CPU speed automatically set to max for all disk operations and then resumes normal speed when disk activity has stopped (toggle setting under Menu - Disk & remembered in the classic99.ini)?

 

Disk access is not emulated - it's simulated. So it already runs as fast as it possibly can (it becomes a memcpy in the emulator!). All delays you see related to loading of BASIC and XB is what's called the "prescan" - BASIC on the TI examines the program before starting it and builds tables before starting to execute. There's no straight-forward way to accelerate the prescan on a system where the GROMs are allowed to change, sadly.

 

Running the Emulator on a game like Carfax Abbey - the difference between running at max cpu speed and normal means the loading time is about 5X faster I get what you are saying about prescan but if there is such a huge difference between loading times at max cpu and normal then would it not be possible to engage max speed at startup and switch to normal speed upon execution or is there no way of discerning execution?

 

OX.

Carfax.zip

Edited June 4, 2011 by OX.

[Tursi]

Running the Emulator on a game like Carfax Abbey - the difference between running at max cpu speed and normal means the loading time is about 5X faster I get what you are saying about prescan but if there is such a huge difference between loading times at max cpu and normal then would it not be possible to engage max speed at startup and switch to normal speed upon execution or is there no way of discerning execution?

 

It's difficult. You would have to verify that the GROM being executed is TI BASIC or Extended BASIC (could be done using configuration), then see if the GPL code being interpreted was part of the prescan code (documented for TI BASIC, not documented for Extended BASIC), then use that to toggle it on and off.

 

I won't be doing it anytime in the near future. The prescan is part of the BASIC experience on the TI. If you want to bypass that, you can use the Classic99 cartridge maker if it's TI BASIC (sort of a save state concept but makes carts that could actually run on a real machine). If it's Extended BASIC, there's no simple solution.

[matthew180]

That's bad ass! Did you explain somewhere (like in the forum somewhere) on how you put the E/A editor and assembler in the GROM? I'm very curious about how you hacked that up?

 

I thought I did have a thread somewhere... but that's just the E/A Complete that I showed at the Chicago TI Faire last year.

 

I know, but I only had like 5 minutes to talk to you at the Faire...

 

All it does is replace the code that loads EDIT1 and ASSM1 and ASSM2 with GPL MOVE instructions.

 

That's *all*?? Seems pretty complicated to someone who knows nothing about GPL or how to get the GPL executed. Any time you want to publish those details, I'd be interested in hearing the (in depth) story about how you went about doing that hack!

[Tursi]

All it does is replace the code that loads EDIT1 and ASSM1 and ASSM2 with GPL MOVE instructions.

That's *all*?? Seems pretty complicated to someone who knows nothing about GPL or how to get the GPL executed. Any time you want to publish those details, I'd be interested in hearing the (in depth) story about how you went about doing that hack!

 

Thanks.. that one was easy though. Originally, I was writing a GPL DSR to load the files (I had it working for EDIT1).. the idea was then I just hacked the E/A GROM to load from my hidden DSR name instead of DSK1, and it was a port of the CS1 DSR from the console using TI Intern. Then I found that Thierry had fully commented a disassembly of the E/A GROM. At that point, it was just find the part that loaded the file from disk, replace it with a MOVE command (or two for the assembler), and jump over the rest. Just like patching assembly.

 

The MPD required a lot more work, since I had to reverse engineer code (TI Intern was massively useful, but didn't cover the 99/4 which I had to partially disassemble), as well as write a lot. Everything in that MPD video is running in GPL. The configuration tool was written in Extended BASIC then converted with a tool I wrote (it's on my website, but it's quite limited. I actually hoped that people would find it interesting and let me know what needed to be added, but everyone decided to learn real GPL about the same time I published it ). Everything else was hacked together by hand, including all the 99/8 hacks and its Set Speed program. The only thing I didn't do by hand completely was the CALL DIR command... I actually did 99% of this by hand, but I was running out of room in the GROM and it jumped around a lot to fill the empty spaces, so I needed to consolidate and rearrange it. For that I finally used a GPL assembler, but since my syntax (learned from TI Intern) isn't the same as the assemblers take, I also wrote a tool to convert it.

 

Now I just need to sit down and write my replacement OS, which is the MPD's main purpose in life. I think I have the feature set mostly locked in, though I do need to add one more feature to the AVR. I also need to replace Disk Manager 1000 with something more modern. It's more floppy centric than I thought it was - I need something that works with pretty much everything possible. Is Fred's Disk Manager any good?

[OX.]

Hi Tursi, is this a bug with V9T9 disk images handling - the attached game addresses the disk files by it's disk-name "DSK.DRAGON.FILENAME" it seems that Classic99 uses only the logical disk DSK1, DSK2 etc.

 

Is their a possible fix?

 

Also there's an intermittent problem where I get a frozen black screen (of death) or freezing with a long beep just every now and then - when starting a game from disk image, initialisation problem? This one has only been happening since very recent, possibly the last update as it never happened in V3.54 and below.

 

OX.

DRAGON1.zip

Edited June 4, 2011 by OX.

[Tursi]

Hi Tursi, is this a bug with V9T9 disk images handling - the attached game addresses the disk files by it's disk-name "DSK.DRAGON.FILENAME" it seems that Classic99 uses only the logical disk DSK1, DSK2 etc.

 

Is their a possible fix?

 

Also there's an intermittent problem where I get a frozen black screen (of death) or freezing with a long beep just every now and then - when starting a game from disk image, initialisation problem? This one has only been happening since very recent, possibly the last update as it never happened in V3.54 and below.

 

Classic99 doesn't support the DSK.DISKNAME.FILENAME syntax in its DSR. That's a syntax that instructs the disk controller to search for the disk. It's not a fix situation, it's new code.

 

Also there's an intermittent problem where I get a frozen black screen (of death) or freezing with a long beep just every now and then - when starting a game from disk image, initialisation problem? This one has only been happening since very recent, possibly the last update as it never happened in V3.54 and below

 

Unlikely that it's a new problem, my changes have been pretty small. But without seeing at least the debug log after a hang you give me nothing to go on.