Classic99 Updates

[OX.]

 

And finally I have an Arcturus sidecart rom image (adapted by yourself) which is a single file of Arcturus.bin of size 24K, any idea what the setup would be to run this?

 

Dunno. Doesn't sound like something I'd have released. Is it a converted GROM version? (Do you see a 'cart conv by Tursi' when it starts?). How do you load it on MESS?

 

It has your name on the title screen along with JDG 09'

 

I got it working in MESS by creating an rpk with this xml header -

 

<?xml version="1.0" encoding="utf-8"?>

<romset version="1.0">

<resources>

<rom id="romimage1" file="arcturus.bin"/>

</resources>

<configuration>

<pcb type="paged379i">

<socket id="rom_socket" uses="romimage1"/>

</pcb>

</configuration>

</romset>

 

Which I'm not sure is right as some of the ships disappear now and again, but plays ok. Have no idea how I'd run that in Classic99.

arcturusc.zip

[Tursi]

It has your name on the title screen along with JDG 09'

 

Well, that's been altered, then. I did the work to make it run without the side car (it had an 8k bank of ROM located at >4000, which is DSR space, I moved that into RAM), but my version was was an E/A#5, 3 files, and the title page said "Jon Guidry & Tursi".

 

<pcb type="paged379i">

<socket id="rom_socket" uses="romimage1"/>

</pcb>

 

That's a 379 style cartridge -- see the type? In Classic99 the type for that is '3', or you can rename it to Arcturus3.BIN and it should be able to autoload using Cartridge->User->Open. If that works, let me know, and we can take care of the automatic INI version. Jon probably modified it with his loader code before releasing it.

 

Which I'm not sure is right as some of the ships disappear now and again, but plays ok. Have no idea how I'd run that in Classic99.

 

Not my game, I can't help you with bugs. Jon sent it to me as a challenge, I did the modification, and gave it back. So far as I know it worked but what happened after it left my hands was no concern of mine. They could just be disappearing "behind" walls? It's a little imperfect, that wall occlusion detection.

[OX.]

 

That's a 379 style cartridge -- see the type? In Classic99 the type for that is '3', or you can rename it to Arcturus3.BIN and it should be able to autoload using Cartridge->User->Open. If that works, let me know, and we can take care of the automatic INI version. Jon probably modified it with his loader code before releasing it.

 

Which I'm not sure is right as some of the ships disappear now and again, but plays ok. Have no idea how I'd run that in Classic99.

 

Not my game, I can't help you with bugs. Jon sent it to me as a challenge, I did the modification, and gave it back. So far as I know it worked but what happened after it left my hands was no concern of mine. They could just be disappearing "behind" walls? It's a little imperfect, that wall occlusion detection.

 

I've tried loading the cart image as type 3 - "3|6000|2000" but it didn't work, probably because I'm not sure what size and start address params to use with it though.

 

The disappearing sprites could well just be a quirk of the game as they seem to lose half of the image as they collide with other sprites.

 

I'm finding Classic99 is eminently more interfaceable with emulator front-ends now since the last release, thanks.

[RXB]

I have a real problem with Classic99. From XB it will not do the simple thing like this:

 

100 OPEN #1:"DSK3.LMYXB3",VARIABLE 80,INPUT,DISPLAY

110 OPEN #2:"DSK3.LRXB3",VARIABLE 80,OUTPUT,DISPLAY

120 INPUT #1:X$

130 PRINT #2:SEG$(X$,22,60)

140 GOTO 120

 

Classic99 refuses to write anything to a disk from this program. The file stays a 1 sector file and writes nothing to disk.

 

Seems pretty insane that I have to fire up my TI99/4A or PC99 to do what Classic99 should be able to do.

 

Why should this be a problem to do?

It sure looks like a major bug.

( By the way with a text editor this would take hours and hours to do)

[OX.]

I have a real problem with Classic99. From XB it will not do the simple thing like this:

 

100 OPEN #1:"DSK3.LMYXB3",VARIABLE 80,INPUT,DISPLAY

110 OPEN #2:"DSK3.LRXB3",VARIABLE 80,OUTPUT,DISPLAY

120 INPUT #1:X$

130 PRINT #2:SEG$(X$,22,60)

140 GOTO 120

 

Classic99 refuses to write anything to a disk from this program. The file stays a 1 sector file and writes nothing to disk.

 

Seems pretty insane that I have to fire up my TI99/4A or PC99 to do what Classic99 should be able to do.

 

Why should this be a problem to do?

It sure looks like a major bug.

( By the way with a text editor this would take hours and hours to do)

 

Because Disk access is only a recent inclusion and Tursi is still working on it -

 

5.3.2 Disk Images

Classic99 has experimental support for DSK images. Both sector dump images (V9T9/MESS style) and track

dump images (PC99) are supported, including support for the reverse sector numbering on side two of a DSSD

diskette (as V9T9 sometimes wrote).

Disk images are a dump or reproduction of actual TI diskettes, and as such are subject to all of their limitations.

Classic99 supports reading disk images using the conventions set up on TI‟s disk controller, but will work with

the larger disk formats of Corcomp and Myarc as well.

No disk images are configured by default, use the configuration menu to attach a disk image to a particular disk

number.

BUG: Image access is currently read only. PC99 disk images are auto-detected, but this auto-detection

cannot be disabled.

Edited May 29, 2011 by OX.

[Tursi]

I've tried loading the cart image as type 3 - "3|6000|2000" but it didn't work, probably because I'm not sure what size and start address params to use with it though.

 

Well, slow down a little. All the documentation is available to you and will serve you better than guessing!

 

First, the length is a length... if you stop to think about it, it is the length of the ROM file. You have a 24k ROM file, you already know this, so the length field should be at least 24k too. 24k in hexadecimal is 6000. (Windows Calculator can do the hexadecimal conversion if you change the 'view' mode, and 24k is 24*1024 = 24,576 -- or just right click the ROM file and select 'properties', and read the actual length from there).

 

Start address you do normally have to deduce, and you made a good guess since all cartridges start at >6000, but if you look at the reference for Classic99.ini in the manual you'll see that type 3 carts are special, and have their own memory space starting at 0000... so start this one at 0000.

 

"3|0000|6000"

 

That should bring it up. But I need to know the results of testing the automatic load before I add auto-detect to the INI file - try loading it with Cartridge->User->Open from the menu instead of from the INI. (Edit: make sure you rename it so the files ends with 3.BIN first!)

Edited May 29, 2011 by Tursi

[Tursi]

Seems pretty insane that I have to fire up my TI99/4A or PC99 to do what Classic99 should be able to do.

 

Please RTFM before you call my work insane, Rich. I am, but that's not the point!!

 

If you want to write files, use the FIAD mode, that is what Classic99 was designed to use. I consider disk images artificially limiting, given that the TI file system was designed to support any device, and I wish they had gone away a very long time ago. Write support to disk images isn't scheduled anytime soon. I only added them so you could get data off of them.

[OX.]

 

Start address you do normally have to deduce, and you made a good guess since all cartridges start at >6000, but if you look at the reference for Classic99.ini in the manual you'll see that type 3 carts are special, and have their own memory space starting at 0000... so start this one at 0000.

 

"3|0000|6000"

 

That should bring it up. But I need to know the results of testing the automatic load before I add auto-detect to the INI file - try loading it with Cartridge->User->Open from the menu instead of from the INI. (Edit: make sure you rename it so the files ends with 3.BIN first!)

 

I renamed it to Arcturus3.bin and I've tried both editing the .ini settings and setting the rom as "3|0000|6000" and loading it with Cartridge->User->Open from the menu - before I realised it's not a V9T9 cart so Classic99 will not load it. I wonder if there's a way to convert it to V9T9?

Edited May 29, 2011 by OX.

[lucien2]

I renamed it to Arcturus3.bin and I've tried both editing the .ini settings and setting the rom as "3|0000|6000" and loading it with Cartridge->User->Open from the menu - before I realised it's not a V9T9 cart so Classic99 will not load it. I wonder if there's a way to convert it to V9T9?

 

Auto-detect works by me, with Classic99 350 and 353.

 

The file size is 32k, so the INI entry must be:

 

[userCart0]

name="Arcturus"

ROM0=3|0000|8000|MODS\ARCTURUS.BIN

Edited May 29, 2011 by lucien2

[Tursi]

I renamed it to Arcturus3.bin and I've tried both editing the .ini settings and setting the rom as "3|0000|6000" and loading it with Cartridge->User->Open from the menu - before I realised it's not a V9T9 cart so Classic99 will not load it. I wonder if there's a way to convert it to V9T9?

 

The filename /is/ V9T9 format. There's no format to a V9T9 cartridge, it's just a bare ROM dump with a special filename.

 

Classic99 doesn't care about the format of the ROM dump. That's why you give it all the information. Are you saying that none of the above worked?

[Tursi]

Auto-detect works by me, with Classic99 350 and 353.

 

The file size is 32k, so the INI entry must be:

 

[userCart0]

name="Arcturus"

ROM0=3|0000|8000|MODS\ARCTURUS.BIN

 

Nice that it works, though that's not auto-detect, you told it everything it needs to know in that INI line.

 

Autodetect only happens when you select Cartridge->User->Open and open the file, and it has to have the V9T9-style filename ending for that to work, as the ROM itself is not analyzed.

[lucien2]

I also tried to rename it to "acturus3.bin" and open it. It works too.

[OX.]

Yes, I can also confirm it works with both Cartridge->User->Open when the file is renamed Arcturus3.bin and when I changed the rom0 entry in the .ini file to 3|0000|8000.

 

It might have helped had I not been trying to use duff file from a completely different version

[RXB]

Because Disk access is only a recent inclusion and Tursi is still working on it -

 

5.3.2 Disk Images

Classic99 has experimental support for DSK images. Both sector dump images (V9T9/MESS style) and track

dump images (PC99) are supported, including support for the reverse sector numbering on side two of a DSSD

diskette (as V9T9 sometimes wrote).

Disk images are a dump or reproduction of actual TI diskettes, and as such are subject to all of their limitations.

Classic99 supports reading disk images using the conventions set up on TI‟s disk controller, but will work with

the larger disk formats of Corcomp and Myarc as well.

No disk images are configured by default, use the configuration menu to attach a disk image to a particular disk

number.

BUG: Image access is currently read only. PC99 disk images are auto-detected, but this auto-detection

cannot be disabled.

 

Ok explain to me why I can use the Assembler and make a DF80 file and the Assembler can make a DV80 file but XB is not allowed to?

 

Why would the Assembler be able to do this and yet the same exact process is not supported for XB?

Edited May 30, 2011 by RXB

[RXB]

Please RTFM before you call my work insane, Rich. I am, but that's not the point!!

 

If you want to write files, use the FIAD mode, that is what Classic99 was designed to use. I consider disk images artificially limiting, given that the TI file system was designed to support any device, and I wish they had gone away a very long time ago. Write support to disk images isn't scheduled anytime soon. I only added them so you could get data off of them.

 

I get fustrated wasting hours trying to get something to work, so when I posted I was pretty upset.

Looking at FIAD has no examples of how to make it work. The Documents for Classic99 say DSK1\ yet when you pull up the program option is shows .\DSK1\ so when I put this in the XB program it crashes.

.\DSK1\ or DSK1\ or .DSK1 or .DSK1\ or .DSK1\name or .\DSK1\folder\name.txt

You might as well say put gazzleflop in slotmode F. The docs just take for granted you already know excactly what to do to make it work, please explain how to make it work.

I change it so it says C:\Classic99\DSK3 for the FIAD but how the heck do you get XB to write to it?

OPEN #1:".\DSK\',OUTPUT

or

OPEN #1:"DSK1\",OUTPUT

or

OPEN #1:".DSK1\",OUTPUT

 

I just do not understand how Assembler or some programs can make a DV80 files yet XB can not. What is the problem with XB doing this, yet it is ok for Assembler.

If you do not like disk image I agree you are on a good track, I just want instuctions that are simple to use. I much prefer to just read the docs and get it done instead of having to go ask online.

By the way what is RTFM?

(Is this some kind of TEXTmessaging? )

Edited May 30, 2011 by RXB

[Tursi]

I get fustrated wasting hours trying to get something to work, so when I posted I was pretty upset.

Looking at FIAD has no examples of how to make it work. The Documents for Classic99 say DSK1\ yet when you pull up the program option is shows .\DSK1\ so when I put this in the XB program it crashes.

.\DSK1\ or DSK1\ or .DSK1 or .DSK1\ or .DSK1\name or .\DSK1\folder\name.txt

You might as well say put gazzleflop in slotmode F. The docs just take for granted you already know excactly what to do to make it work, please explain how to make it work.

I change it so it says C:\Classic99\DSK3 for the FIAD but how the heck do you get XB to write to it?

OPEN #1:".\DSK\',OUTPUT

or

OPEN #1:"DSK1\",OUTPUT

or

OPEN #1:".DSK1\",OUTPUT

 

I just do not understand how Assembler or some programs can make a DV80 files yet XB can not. What is the problem with XB doing this, yet it is ok for Assembler.

If you do not like disk image I agree you are on a good track, I just want instuctions that are simple to use. I much prefer to just read the docs and get it done instead of having to go ask online.

By the way what is RTFM?

(Is this some kind of TEXTmessaging? )

 

Did you TRY to put gazzleflop in DSK1? I don't think you really did!!

 

RTFM is a time-honored computer acronym that dates back to at least 1979, so it's unexpected that you have never come across it. (There is even some evidence it was a military term before this.) It stands for "Read The Freaking* Manual" (* - occasionally with stronger language), and I was using it here tongue-in-cheek. Reference: http://knowyourmeme.com/memes/rtfm

 

It's a little hard to try to address your points, Rich, so let me back things up a little.

 

You have to realize that in an emulator there are always two components to consider. On one side you have the original computer, which is generally used in the same way as it always has been. That means in this case, if you want to write to DSK1, you specify it as "DSK1", and nothing else. In Classic99 you can configure DSK0, DSK1, DSK2, DSK3, DSK4, DSK5, DSK6, DSK7, DSK8 and DSK9, where on the real TI you had DSK1, DSK2, DSK3 and maybe DSK4, as well as possibly hard drives. Classic99 doesn't support "hard drives", so we'll just stick to the DSK devices.

 

The other side is the host system that the emulator is running on, and the interface to that. In some emulators, this is minimalized as much as possible Emulators such as MESS and Win994A try to hide the host system from you (although both extend the keyboard and MESS includes clipboard support). Classic99 is not this kind of emulator. Classic99 is a development tool by goal, and so it embraces the host system as an extension rather than a simple shell.

 

Now.. your questions about the paths for FIAD suggest to me that you do not understand how the Windows file system works (or by extension, the older DOS file system). This is a problem. I can't teach you everything about modern computers through a forum, at least, not trivially! The path that you configure in Classic99 is the folder that you want the FIAD to point to. It is the WINDOWS path that Classic99 will redirect "DSK1." to. You don't put the Windows path in the TI side, Classic99 takes care of that.

 

"DSK1\" and ".\DSK1\" are equivalent paths in DOS and Windows. The first means "a subdirectory in the current working folder named 'DSK1'". In the second, the "." means "the current working folder", and "\DSK1\" means "a subdirectory called 'DSK1'". So you see that they say the same thing. What /actually/ appears in there is dependent on what is configured on your machine.

 

Now, when you changed it to say "C:\CLASSIC99\DSK3", you have specified that folder. I assume you put it under DSK3. So you would open it as OPEN #1:"DSK3.FILENAME",OUTPUT. Just like always -- DEVICE.FILENAME. In your examples you are providing Windows paths and no filename at all, of course it fails. Also, make sure you actually HAVE a C:\CLASSIC99\DSK3 on your hard drive - Classic99 isn't going to create it for you.

 

I think the problem is, is that you are seeing something you are not used to and expecting magic.. no magic. It's just another way to access the files. It's still a disk controller as far as the TI software is concerned... it's just being stored differently. And in fact this is completely normal for the way that the TI works. The files stored on an MFM hard drive are not stored the same way as on a TI Disk Controller, but you still load and save with the same syntax.

 

Storing files on the PC file system like this has tons of advantages. You can directly access the files, you can rename them, move them, copy them, delete them, all from the Windows side which is far more convenient than the TI side. Classic99 supports special advanced modes, too, like interacting with Windows text files, but we don't need to go into that right now.

 

As for why it works differently between assembly and XB -- it doesn't.

 

I can make a video if that will help?

Edited May 30, 2011 by Tursi

[Tursi]

I also tried to rename it to "acturus3.bin" and open it. It works too.

 

Yes, I can also confirm it works with both Cartridge->User->Open when the file is renamed Arcturus3.bin and when I changed the rom0 entry in the .ini file to 3|0000|8000.

 

It might have helped had I not been trying to use duff file from a completely different version

 

Thanks guys! With that, I give you Classic99 v354:

 

-added '*' as a Classic99.ini ROM type - means autodetect type by filename and size by file on disk

 

http://harmlesslion.com/software/classic99

 

Ox, you should now be able to write all your ROM lines as:

 

*|0000|0000|filename.bin

 

and Classic99 will figure out what they are and where to put them. You still need to list all the files, unlike the Cartridge->User->Open option.

 

The determination is not intelligent. The length is calculated by reading the length of the file on the disk. The load address is always >6000 for everything except 379 files, where it's always >0000, and the type is detected by the end of the filename:

 

xxxxxC.BIN means a cartridge ROM loading at >6000

xxxxxD.BIN means a second bank cartridge ROM, bank switched into >6000

xxxxxG.BIN means a GROM loading at >6000, and

xxxxx3.BIN means a 379 style bank-switched EPROM loading at >0000 in the 379 memory space

 

But at least it means you don't need anything but the filename in advance, even if the filename needs to be in proper "V9T9" format. Hope that helps you get your front end up and running, Ox!

Edited May 30, 2011 by Tursi

[RXB]

It's a little hard to try to address your points, Rich, so let me back things up a little.

 

Now.. your questions about the paths for FIAD suggest to me that you do not understand how the Windows file system works (or by extension, the older DOS file system). This is a problem. I can't teach you everything about modern computers through a forum, at least, not trivially! The path that you configure in Classic99 is the folder that you want the FIAD to point to. It is the WINDOWS path that Classic99 will redirect "DSK1." to. You don't put the Windows path in the TI side, Classic99 takes care of that.

 

Now, when you changed it to say "C:\CLASSIC99\DSK3", you have specified that folder. I assume you put it under DSK3. So you would open it as OPEN #1:"DSK3.FILENAME",OUTPUT. Just like always -- DEVICE.FILENAME. In your examples you are providing Windows paths and no filename at all, of course it fails. Also, make sure you actually HAVE a C:\CLASSIC99\DSK3 on your hard drive - Classic99 isn't going to create it for you.

 

I think the problem is, is that you are seeing something you are not used to and expecting magic.. no magic. It's just another way to access the files. It's still a disk controller as far as the TI software is concerned... it's just being stored differently. And in fact this is completely normal for the way that the TI works. The files stored on an MFM hard drive are not stored the same way as on a TI Disk Controller, but you still load and save with the same syntax.

 

Storing files on the PC file system like this has tons of advantages. You can directly access the files, you can rename them, move them, copy them, delete them, all from the Windows side which is far more convenient than the TI side. Classic99 supports special advanced modes, too, like interacting with Windows text files, but we don't need to go into that right now.

 

As for why it works differently between assembly and XB -- it doesn't.

 

I can make a video if that will help?

 

I am a old timer I worked on computers (K43 Teletype in 1976) writting programs for a Church and others and for the old Osborn and Compaq computers, but all my work was in Assembly or Machine language using CPM. So I never needed to learn DOS, and only very little of CP/M was needed to do what I was doing. Besides DOS (rip off of CP/M) did not come out till 1981. Or should I call it MS-DOS as that is actually what you are talking about. They were all refered to as DOS but had different names, anyway they all were a rip off of CP/M that came out in 1973, nothing Microsoft ever does is not a rip off or orignal.

http://en.wikipedia.org/wiki/CP/M

 

I see where you are comming from as the system shares file systems. But this is the problem I do not have with the TI99/4A.

That program I wrote and posted says DV80 and it comes like this:

crlf LIST EQU >8018 8014 Save a ProgramcrlfMERGE EQU >80QU >802A....

In a nutshell gobbly gook, a PC file that attempting read with a TI is just to much work.

Now I can take that PC DOS file and manualy make another DV80 file (cut and paste) then run the next loop of the XB program, but this step is totally unneeded on a real TI. As it is a different file system I have a extra step to get back to where I was already on the TI. Amazing that the PC sucks so much at editing a document by columns.

 

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. 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.

Edited May 30, 2011 by RXB

[OX.]

I also tried to rename it to "acturus3.bin" and open it. It works too.

 

Yes, I can also confirm it works with both Cartridge->User->Open when the file is renamed Arcturus3.bin and when I changed the rom0 entry in the .ini file to 3|0000|8000.

 

It might have helped had I not been trying to use duff file from a completely different version

 

Thanks guys! With that, I give you Classic99 v354:

 

-added '*' as a Classic99.ini ROM type - means autodetect type by filename and size by file on disk

 

http://harmlesslion.com/software/classic99

 

Ox, you should now be able to write all your ROM lines as:

 

*|0000|0000|filename.bin

 

and Classic99 will figure out what they are and where to put them. You still need to list all the files, unlike the Cartridge->User->Open option.

 

The determination is not intelligent. The length is calculated by reading the length of the file on the disk. The load address is always >6000 for everything except 379 files, where it's always >0000, and the type is detected by the end of the filename:

 

xxxxxC.BIN means a cartridge ROM loading at >6000

xxxxxD.BIN means a second bank cartridge ROM, bank switched into >6000

xxxxxG.BIN means a GROM loading at >6000, and

xxxxx3.BIN means a 379 style bank-switched EPROM loading at >0000 in the 379 memory space

 

But at least it means you don't need anything but the filename in advance, even if the filename needs to be in proper "V9T9" format. Hope that helps you get your front end up and running, Ox!

 

Nice one Tursi, I'm going to be a bit of a pain and grovel for another update I need - or maybe there is already a way to solve this one? :-

 

In the Keyboard input field I need a way to pause the input for a given amount of seconds, this is a problem when having to wait for disk-menu's to load and then select a corresponding number or letter to run the required program.

 

OX.

[Tursi]

In the Keyboard input field I need a way to pause the input for a given amount of seconds, this is a problem when having to wait for disk-menu's to load and then select a corresponding number or letter to run the required program.

 

Keyboard input is only entered when the keyboard is actually scanned, and the keyboard is not scanned when disk files are loaded. Take another look at my examples, especially the TI BASIC example which loads a file and then RUNs it.

 

In certain instances one or two characters can be dropped due to initialization scans, so all you need to do is insert a dummy keypress in those cases.

 

There should be no need for time-based delays, but if you can show me might be able to work out why it seems to. (Or you might have a case I never anticipated, hehe ).

[OX.]

In the Keyboard input field I need a way to pause the input for a given amount of seconds, this is a problem when having to wait for disk-menu's to load and then select a corresponding number or letter to run the required program.

 

Keyboard input is only entered when the keyboard is actually scanned, and the keyboard is not scanned when disk files are loaded. Take another look at my examples, especially the TI BASIC example which loads a file and then RUNs it.

 

In certain instances one or two characters can be dropped due to initialization scans, so all you need to do is insert a dummy keypress in those cases.

 

There should be no need for time-based delays, but if you can show me might be able to work out why it seems to. (Or you might have a case I never anticipated, hehe ).

 

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?

Tigercub 1309 - Tigercub\'s Brain Games (19xx)(Tigercub Software)(PD).zip

[Tursi]

I am a old timer I worked on computers (K43 Teletype in 1976) writting programs for a Church and others and for the old Osborn and Compaq computers, but all my work was in Assembly or Machine language using CPM. So I never needed to learn DOS, and only very little of CP/M was needed to do what I was doing. Besides DOS (rip off of CP/M) did not come out till 1981. Or should I call it MS-DOS as that is actually what you are talking about. They were all refered to as DOS but had different names, anyway they all were a rip off of CP/M that came out in 1973, nothing Microsoft ever does is not a rip off or orignal.

 

You're free to use many non-Microsoft alternatives today, but my point of view with almost as long in the industry as you is that is a very outdated attitude, and the Microsoft of today is not the Micro Soft of 1985. At any rate, the history of the system has absolutely nothing to do with whether you understand it and how much we can help fix that!

 

I /think/ I still have my CP/M disks somewhere... I was keeping them for the Infocom games back in the day. I had a Wang, a Nabu, and an all-in-one unit whose brand escapes me (I loved that luggable, wish I kept it).

 

I see where you are comming from as the system shares file systems. But this is the problem I do not have with the TI99/4A.

 

Well, you would if you plugged in a peripheral that communicated to the Windows file system. But most likely you are using a floppy drive there. There's no significant difference between the emulator and the real thing, just think of it as having plugged in a card that requires external configuration.

 

In a nutshell gobbly gook, a PC file that attempting read with a TI is just to much work.

 

You've lost me now. Just ignore the PC side of things if it's confusing you.

 

Now I can take that PC DOS file and manualy make another DV80 file (cut and paste) then run the next loop of the XB program, but this step is totally unneeded on a real TI. As it is a different file system I have a extra step to get back to where I was already on the TI. Amazing that the PC sucks so much at editing a document by columns.

 

I don't follow anymore. Every piece of TI software I have released in the last ten+ years has been made using this file system - I assure you it works. You just need to streamline your thinking a little bit.

 

Why don't you post the full program that you are trying to get to work, and we'll walk you through it? Because right now I do not understand the issue you are having or what you are trying to accomplish. You can get a listing out of Classic99 if it's large by typing LIST "CLIP", then just Edit->Paste in your browser right into the message. Make sure to wrap it with \[code\] tags so that the forum doesn't corrupt it.

 

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. 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.

 

Well, I wrote these documents, but I am not a doc writer by trade. Mind you, the output of most doc writers isn't looked upon too highly either, so I guess I did okay! If either of you would like to volunteer to rewrite them for free, I'll be happy to consider your contributions. Otherwise, here's your money back, and thanks for trying Classic99. Please don't harrass the free support!

 

Most PC users understand the PC file system. Most programmers using Windows -- the target audience of Classic99 -- likewise understand the PC file system. We've been able to get many others to understand it, we should be able to get you too. If you really want professional, hands on support, you're welcome to pay for it - my rate is $70/hr. Otherwise, please try to stay civil. Whether your daughter is civil is clearly up to you, but you chose to repeat it.

 

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.

 

So, you're saying they need to be about 20% cooler?

[RXB]

Well, I wrote these documents, but I am not a doc writer by trade. Mind you, the output of most doc writers isn't looked upon too highly either, so I guess I did okay! If either of you would like to volunteer to rewrite them for free, I'll be happy to consider your contributions. Otherwise, here's your money back, and thanks for trying Classic99. Please don't harrass the free support!

Most PC users understand the PC file system. Most programmers using Windows -- the target audience of Classic99 -- likewise understand the PC file system. We've been able to get many others to understand it, we should be able to get you too. If you really want professional, hands on support, you're welcome to pay for it - my rate is $70/hr. Otherwise, please try to stay civil. Whether your daughter is civil is clearly up to you, but you chose to repeat it.

So, you're saying they need to be about 20% cooler?

 

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.

 

Well I am very good a writing documents as I include many examples so the user can see the way to use it or from the examples and make similar projects. When I fully understand Classic99 I can work on making some docs with examples.

Also the nomenclature of the Documents should be in simple to understand even for a novice in that any term must be explained or the user just gets lost. Nomenclature is the bane for understanding any subject. If a person already knows the

nomenclature then this is not a problem at all. Hence PC users that already know the PC file system have little value for the documents as it is pointing out the obvious. For the novice the gradient is way to steep to learn the subject so the documents

become even more of a impedance then a help.

 

As for the PC file system, DOS is not really a normal thing that is being continued, matter of fact the DOS support in Windows 8 will be Emulation only. Microsoft would love to dump DOS and has stated such many times, but lucky for us we will have

a virtual DOS we can access many years down the line. I have some ol buddies that work at Microsoft, DOS is considered a problem to support so Virtual support is the only answer.

 

As for my daughter this was only to show perspective, can not see the forest for all the trees. A novice can explain better how they are doing with documents or a product then the guy using if for years. It was not a insult, just a statement on facts.

Sorry I was not trying to be abrasive. I too have received many letters or phone calls about RXB so I know the feeling, which is where I learned that the documents are just a important as the product itself. Most software fails for this reason.

 

I would like to see many more new users of Classic99 and expand our numbers. You have a excellent product here and I would be happy to help.

[Tursi]

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

[Tursi]

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.

 

This should work fine. Can we see the source? Can probably fix it for you faster than this whole discussion has taken.

 

If you've already completed the work then it doesn't matter anymore.

 

For the novice the gradient is way to steep to learn the subject so the documents become even more of a impedance then a help.

 

It's very difficult to support a novice, and someone will always find something they can't figure out. In fairness, as a community we took Owen from never using a TI to writing assembly software, in Classic99, in a year or so. And that was with no documentation! The thing that throws me supporting you is that you clearly already know how to program, so we tend to assume you understand more than you do. You are not a novice, Rich! So sometimes we overstep, thinking that you must already understand something. You should not be getting upset with people for this, just make it clear where the confusion lies.

 

As for my daughter this was only to show perspective, can not see the forest for all the trees.

 

Bad manners are bad manners, Rich. I never once claimed my documentation was perfect, I just asked you to read it, because you made many statements about things that ARE explained. (And I was goaded into writing them by the community, else you'd still have a text file, so I tell /everyone/ to read them first. At least you have pictures now! ). That you had trouble with parts of it could be addressed constructively, without trolling. To take some blame myself, perhaps you took offense to RTFM, I was starting to get a little annoyed at that point.

 

Sorry I was not trying to be abrasive. I too have received many letters or phone calls about RXB so I know the feeling, which is where I learned that the documents are just a important as the product itself. Most software fails for this reason.

 

You are forgiven, but let me make the following points:

 

-Classic99 is a hobby project, that I create for my benefit. I share it with you in the hopes that it might be useful, but by no means am I obligated to make it so.

 

-Classic99 is in Beta (yes, I know it has said this for a long time, but it is NOT something I consider complete). Therefore nothing in there is guaranteed to even work, let alone make sense.

 

-I do not have time to provide full time support for it, nor interest. I do my best when I can to help people truly interested in it. Anyone who doesn't appreciate that, I do bite my tongue as best I can, but I'm inclined to direct them back to MESS, PC99, or any of the other emulators that people love to tell me are better.

 

-Therefore Classic99 by definition can neither "succeed" nor "fail", since it really exists only to provide myself with a development tool. I choose to share the tool and anyone interested in it, I am happy to do my best to help. I don't have a lot of time for this, sadly, though sometimes I devote a lot more time than I should. But it has been on the internet and in near-daily use since 1996. It's the only TI emulator with that longetivity still seeing active support. It has introduced a number of little firsts, some of which have been adopted by other emulators, and so if it has helped other people produce software or relive memories to any extent whatsoever, then it has already surpassed my expectations.

 

Yeah, it could be better. Yeah, it could be perfect. It could have proper timing, better controls, tighter debug integration, proper keyboard support, more peripherals, a complete hands-on training course, and many other features. But these take time to build, and I've little time and less inclination for many of these features. I tend to code what's needed most. I've already even done a feature just for you, such as the ability to replace GROM with GRAM. If I hadn't, you probably would not have been ranting at me today because you wouldn't be using it.

 

I would like to see many more new users of Classic99 and expand our numbers. You have a excellent product here and I would be happy to help.

 

Thanks. I'd like to see it stay small, honestly. Maybe when I get it finished and out of beta, then we can talk marketing.