XB Game Developers Package

[RXB]

I run Classic99 and TIDir99 from C:\Users\Rich\Documents

[Tursi]

I run Classic99 and TIDir99 from C:\Users\Rich\Documents

Well, it was a good theory while it lasted

[1980gamer]

Well, before you blame the emulator, you need to try the same steps on another emulator or (preferably) hardware, and see if it works there.

I don't think it is the emulator really. It was just a new element added to the equation.

 

I think I am smashing memory though. Because the bad value and lost drive things.

When I run my current program, I break out of it, when I type LIST or a line number, I get crazy characters. If I do enough on a line, it gives an error and I can type again.

 

This is not all the time, but frequent.

 

I am using a bunch of DIM's mostly 1 dimensional but 1 think 1 have two 2 dimensional arrays as well. Don't know if this is related at all.. Just an observation.

 

What do you think of the call overdrive On/Off?

 

Darn, I am really in the wrong thread for this.

 

But I have loved using Classic99 as well as XBGDP and XB256 for the past several years.. Thank you all for creating these wonderful tools.

 

I am certain most issues I ever encounter are config issues. Now even with Windows 10...

[Retrospect]

I do recall, XB-256 showing strange behaviour whilst Classic99 was using "CPU Overdrive" ... if that's the environment you are in, I would suggest turning overdrive off

[1980gamer]

Yes, running overdrive mode.

 

I use it because it is closer to how the software will run when compiled.

 

It is a godsend to have overdrive, especially on larger programs and anything with collision detection.

[senior_falcon]

@1980gamer:

 

I have an assignment for you. Included on the disk are three XB programs that I would like you to try to compile:

HELLO

8QUEENS

APERTURE

Be sure you are set up as described in Using XBGDP. Follow the steps described on page 4 to compile. Use CPU overdrive, but be sure to select Extended BASIC, not XB256.

Then post here whether you were successful.

 

If the problems you are having only happen while using XB256 and CPU overdrive then I think I know what is happening and how to fix it.

[LASooner]

I think he's saying turn it off when you are saving

[1980gamer]

@1980gamer:

 

I have an assignment for you. Included on the disk are three XB programs that I would like you to try to compile:

HELLO

8QUEENS

APERTURE

Be sure you are set up as described in Using XBGDP. Follow the steps described on page 4 to compile. Use CPU overdrive, but be sure to select Extended BASIC, not XB256.

Then post here whether you were successful.

 

If the problems you are having only happen while using XB256 and CPU overdrive then I think I know what is happening and how to fix it.

 

 

Okay, Hello and 8Queens worked perfectly.

Aperture, loads, but when I run, no overdrive, I get Bad Value in 180.

 

Closed Classic99, re-opened, same error.

 

i started Classic99 pressed 2 for XB and held it down... Loaded Aperture, bad value in 180

I never turned Overdrive on for Aperture.

 

Hope this helps.

[senior_falcon]

Aperture is written in TI BASIC and will not run in XB, hence the "bad value". Also, I made a few changes so it is compatible with the compiler's needs and these make it so it will not even run in BASIC. (Too big as I remember) But you can load it, save it and compile it as usual; you just can't test the original program in BASIC or XB.

 

When you say HELLO and 8QUEENS worked perfectly, do you mean you were able to compile them and run the compiled program?

I need to know everything: Can you load them into XB? Can you save them in both program and merge formats? Does the compiler load, run and compile them? Does the assembler load, run, read the compiled source code, and produce assembled object code? Does the loader produce programs that can be saved and run successfully?

 

And try to compile APERTURE. Use overdrive for everything until the final testing.

[1980gamer]

So, I thought it worked.

 

Both ran fine when I compiled. After loading the compiled versions, neither worked.

See screen shot. I will try to compile aperture tomorrow.

 

[senior_falcon]

When you want to run a compiled program in XB you cannot be in the autocomplete mode. What you have done above is press 2 for XB, then selected XB from the menu, then autoprompt suggests OLD DSK1 and you finished it up with HELLO-X or 8QUEENS-X. When you RUN it crashes.

The solution is simple: don't use autoprompt. Either press F3 to kill the autoprompt or hold down a key to bypass the menu and go straight to XB. Or you could press F4 to break the menu program before selecting XB. Then OLD DSK1.HELLO-X and RUN or RUN "DSK1.HELLO-X".

 

I guess there should be some indication that autoprompt is active by changing the cursor or the screen color. Also, I'm not quite sure why a compiled program would crash with autoprompt active. I will have to look into these issues.

 

Try again and be sure you can load and run the program from XB and also from EA5.

Edited July 24, 2018 by senior_falcon

[+retroclouds]

ok, have to ask this; what does autocomplete mode do?

[senior_falcon]

ok, have to ask this; what does autocomplete mode do?

There is a video in post #87 on page 4 that shows autocomplete. Essentially it makes some assumptions about what you are doing and automatically fills in data for you.

For example, let's say you are working on an XB program called XBTEST. When you start up XB from the main menu program you are prompted "OLD DSK1." You have to fill in the XBTEST. You make some changes to the program and want to save it. Type SAVE and it will fill in SAVE DSK1.XBTEST and you just press ENTER to save it. Then It assumes you will be compiling so the next prompt is SAVE "DSK1.XBTEST-M,MERGE" and you can just press enter to save as merge format. Next it assumes you will want to compile or something else, so the next prompt is RUN "DSK1.LOAD" and you just press enter to run the menu program.

The compiler, the assembler and the loader will also autocomplete for you.

[RXB]

Well, it was a good theory while it lasted

The reason I do this is Documents is 100% without FILE WRITE PROTECTION.

I made sure RICH is owner and Administrator of Documents and I have multiple backups time stamped on a secondary drive.

 

Currently I have every change made on a daily basis going back 3 months.

 

Also i keep my taxes, bills, and other stuff in same folder.

[1980gamer]

okay,

Yes, turning off auto complete did allow me load and run 8queems and hello compiled versions.

 

However, I need to re-download the package. My Aperture file is zero bytes, after the save that seemed to work did not...

 

[1980gamer]

i have given up on Aperture. I cannot get it to save without an error or making the file 0 KB.

 

At least for now... I will revisit it when I am in a better mind set.

[senior_falcon]

It is tough knowing what to do to help you. If problems only arise when running XB256 with cpu overdrive but everything else works perfectly then I have ideas that might fix that. But since you cannot even save an XB program normally, that tells me that the problem is not with my software. I am not very motivated to invest time in fixing something until I am sure it is broken.

 

Try this:

Download a fresh copy of Classic99 from Harmless lion. There will be a folder called classic99. Put that folder on your desktop. You will probably have to unzip it first. In the folder, find the classic99.exe file. Right click on that and make a shortcut, then move the shortcut to your desktop. Click on the shortcut to start up Classic99. Insert the Extended BASIC cartridge. Select XB. I don't remember if there is a LOAD program on disk 1. If there is then hold down F4 and the program will load but not start.

At this point you have a pristine new copy of classic99 running XB. Try writing a simple program with 3-4 lines. See if you can save it. See if you can save it in MERGE format. If the save was successful see if you can load it. Type NEW, then see if you can MERGE it. Write 3 or 4 simple programs so you can be satisfied that either:

1 - You are able to save and load XB programs as desired in both program format and in merge format.

2 - You cannot save and load XB programs. In this case you need to consult with Tursi or someone else with insights in what might be wrong.

 

Assuming you actually can save to and load from disk, then you should download a fresh copy of "Encruzado". Unzip it and put the ENCRUZADO folder into the classic99 folder alongside DSK1, DSK2, etc. Configure DSK1 to use the ENCRUZADO folder exactly as described in the docs. Now let's try compiling APERTURE

Press 2 to select XB

When the menu appears go down one line and select Extended BASIC

When OLD DSK1 appears fill it out to be OLD DSK1.APERTURE and press enter. APERTURE should load. It won't run so don't even try.

Select cpu overdrive.

Type SAVE and you will be prompted to SAVE DSK1.APERTURE, then SAVE "DSK1.APERTURE-M,MERGE", then RUN "DSK1.LOAD"

Repeatedly press ENTER until aperture is compiled, assembled, loaded, saved in both EA5 and XB formats.

Then you will see RUN followed by a flashing cursor. Turn off cpu overdrive, then press enter and the compiled version of aperture should run.

 

Repeat as desired with other XB (not XB256) programs such as HELLO and 8QUEENS until you are satisfied that the compiler works and that disk access functions when running cpu overdrive in XB.

 

Report your findings.

[Tursi]

The one thing I'd add - as always, when you see strange behaviour regarding the Classic99 disk emulation, please post the log! The log can report far more detailed status about the Windows file system than the TI DSR can. A 0 byte file usually means the file was never closed on the TI side (which causes the data to be flushed). Make sure you aren't doing something like resetting from the emulator menu when you need to be using BYE or anything like that.

[1980gamer]

It is tough knowing what to do to help you. If problems only arise when running XB256 with cpu overdrive but everything else works perfectly then I have ideas that might fix that. But since you cannot even save an XB program normally, that tells me that the problem is not with my software. I am not very motivated to invest time in fixing something until I am sure it is broken.

 

Try this:

Download a fresh copy of Classic99 from Harmless lion. There will be a folder called classic99. Put that folder on your desktop. You will probably have to unzip it first. In the folder, find the classic99.exe file. Right click on that and make a shortcut, then move the shortcut to your desktop. Click on the shortcut to start up Classic99. Insert the Extended BASIC cartridge. Select XB. I don't remember if there is a LOAD program on disk 1. If there is then hold down F4 and the program will load but not start.

At this point you have a pristine new copy of classic99 running XB. Try writing a simple program with 3-4 lines. See if you can save it. See if you can save it in MERGE format. If the save was successful see if you can load it. Type NEW, then see if you can MERGE it. Write 3 or 4 simple programs so you can be satisfied that either:

1 - You are able to save and load XB programs as desired in both program format and in merge format.

2 - You cannot save and load XB programs. In this case you need to consult with Tursi or someone else with insights in what might be wrong.

 

Assuming you actually can save to and load from disk, then you should download a fresh copy of "Encruzado". Unzip it and put the ENCRUZADO folder into the classic99 folder alongside DSK1, DSK2, etc. Configure DSK1 to use the ENCRUZADO folder exactly as described in the docs. Now let's try compiling APERTURE

Press 2 to select XB

When the menu appears go down one line and select Extended BASIC

When OLD DSK1 appears fill it out to be OLD DSK1.APERTURE and press enter. APERTURE should load. It won't run so don't even try.

Select cpu overdrive.

Type SAVE and you will be prompted to SAVE DSK1.APERTURE, then SAVE "DSK1.APERTURE-M,MERGE", then RUN "DSK1.LOAD"

Repeatedly press ENTER until aperture is compiled, assembled, loaded, saved in both EA5 and XB formats.

Then you will see RUN followed by a flashing cursor. Turn off cpu overdrive, then press enter and the compiled version of aperture should run.

 

Repeat as desired with other XB (not XB256) programs such as HELLO and 8QUEENS until you are satisfied that the compiler works and that disk access functions when running cpu overdrive in XB.

 

Report your findings.

 

I didn't have any TI time yesterday. I'll try what you suggest.

However, just to be clear, Only Aperture is failing when saving consistently.

 

I cannot ever be certain saving is working for even small programs. Because it works....until it doesn't.

That is, I can work on something and save it 10-20 times no problem. Then I/0 Error 07 pops up out of the blue.

Sometimes, I can switch drives and save, sometimes I cannot. However, I can list "clip" and save the text file.

 

So, if memory is corrupted, it is not doing anything to the program listing. I still do get random BAD VALUE messages that are not real.

When I type SIZE, I still have plenty of memory available.

 

Let me test as you suggest.

 

Assuming C:\Desktop Can you send me a Config file.

Then you will know exactly how thing are set up. Then I can give you the results and you will have no USER variables. (me not following directions correctly)

[1980gamer]

The one thing I'd add - as always, when you see strange behaviour regarding the Classic99 disk emulation, please post the log! The log can report far more detailed status about the Windows file system than the TI DSR can. A 0 byte file usually means the file was never closed on the TI side (which causes the data to be flushed). Make sure you aren't doing something like resetting from the emulator menu when you need to be using BYE or anything like that.

I'll look at sending the log. I haven't played with this part of classic99.

 

I guess I don't understand what you are saying about exiting properly?

 

I am not leaving Classic99 when I have saving issues. I am working, do a save and continue to work.

I look in the folder and see the file size is 0KB or I get an I/O error. I wish I always got the error. I lost some work early on, not knowing my saves were failing.

 

I am failing this is a windows 10 thing. I am close to putting an XP hyperV together.... I must have an XP disc around here!

[senior_falcon]

 

I cannot ever be certain saving is working for even small programs. Because it works....until it doesn't.

That is, I can work on something and save it 10-20 times no problem. Then I/0 Error 07 pops up out of the blue.

Sometimes, I can switch drives and save, sometimes I cannot. However, I can list "clip" and save the text file.

 

So, if memory is corrupted, it is not doing anything to the program listing. I still do get random BAD VALUE messages that are not real.

When I type SIZE, I still have plenty of memory available.

 

Let me test as you suggest.

 

Assuming C:\Desktop Can you send me a Config file.

Then you will know exactly how thing are set up. Then I can give you the results and you will have no USER variables. (me not following directions correctly)

What I am trying to determine is whether this problem only occurs when running XB256. There is an interrupt routine there that adjusts the stack pointer. That happens 60 times a second. This works fine when running at normal speeds. It may be that your computer is so fast when in cpu overdrive that it gets ahead of the interrupt routine and causes problems. I know how to fix this (I hope!) but because any fix leads to unwanted side effects I don't want to get into that until I know for sure that XB256 is the problem. The only way to know this is to eliminate XB256 from the testing.

 

So the statement "That is, I can work on something and save it 10-20 times no problem. Then I/0 Error 07 pops up out of the blue." is not helpful. I need to know whether this happens when you are not running XB256.

 

I don't know what a Config file is. There is a picture in the docs showing what should be checked when configuring the disk. Try what I suggested. If the program still misbehaves I can send a folder with Classic99 and the compiler all set up, but that should not be necessary.

[1980gamer]

What I am trying to determine is whether this problem only occurs when running XB256. There is an interrupt routine there that adjusts the stack pointer. That happens 60 times a second. This works fine when running at normal speeds. It may be that your computer is so fast when in cpu overdrive that it gets ahead of the interrupt routine and causes problems. I know how to fix this (I hope!) but because any fix leads to unwanted side effects I don't want to get into that until I know for sure that XB256 is the problem. The only way to know this is to eliminate XB256 from the testing.

 

So the statement "That is, I can work on something and save it 10-20 times no problem. Then I/0 Error 07 pops up out of the blue." is not helpful. I need to know whether this happens when you are not running XB256.

 

I don't know what a Config file is. There is a picture in the docs showing what should be checked when configuring the disk. Try what I suggested. If the program still misbehaves I can send a folder with Classic99 and the compiler all set up, but that should not be necessary.

 

First, the errors happen without specifically using xb256.

Second, I do have a fast i7 cpu. The overdrive may be an issue. It is compiling much faster on this computer than my Older I7.

 

Comfig file, I was saying the Classic99.ini file. This stores the settings for the dsk's, cart inserted etc.

 

I am about to do what you suggested yesterday or the day before. I'll let you know.

[Tursi]

I'll look at sending the log. I haven't played with this part of classic99.

Understandable - when all goes well you shouldn't need to. Just go to Edit->Debugger, and the log of the last 32 or so lines appears there, and you can copy and paste it out. File operations in particular usually generate a lot of debug, specifically so we can try to understand cases like this.

 

I guess I don't understand what you are saying about exiting properly?

If you close Classic99, or use File->Reset, and the software running in the TI side hasn't yet issued a 'close' operation on an open file, that file may never be written to the PC disk. It was just one possibility I mentioned...

 

I am failing this is a windows 10 thing. I am close to putting an XP hyperV together.... I must have an XP disc around here!

While it may be related to Windows 10's new permissions system, it's not a Windows 10 incompatibility. I've run and developed Classic99 on Windows 10 for over a year now.

 

Unfortunately I haven't had time to play with XB256, so best I can offer are debug suggestions.

[senior_falcon]

@1980gamer:

Anything to report?

[Tursi]

I went back to take a look since I made a few minutes to help test today.

Okay,
I am more stumped than ever!
If I save the Merge file first it works. See image. The is without the developer package.

I just took a closer look at this -- your example screenshot shows four lines:

SAVE DSK2.TEST-M.MERGE
SAVE DSK2.TEST
SAVE DSK2.TEST-M,MERGE
* I/O ERROR 07

What I missed the first time I looked at this is that your first command there is NOT a merge format save -- you typed a period rather than a comma. This means that the emulator saved a file named "TEST-M.MERGE" in normal XB format.

So, as far as I can see, in your examples MERGE format /always/ fails, but regular files are okay.

I am successfully able to save MERGE format on both FIAD and DSK images here using Classic99 v399a. So we really need to see your debug log to see what triggered the I/O Error (Classic99 generates the error, so it always knows!) This would also give us valuable information like your disk type configuration. ERROR 7 is a generic catch-all so we really need that extra information.

MERGE format is a DISPLAY/VARIABLE 163 type, which has different write semantics to the PROGRAM image file that a small XB program gets... so it may be related to that...

Is your PC disk full or close to full? That might explain zero byte files and occasional successes, as well as occasional program issues. In particular it would explain "it used to work but now it doesn't".

I've done a video of Senior Falcon's step-by-step to see if I reproduce anything... but everything appeared to work here.

https://youtu.be/1B8H1OM4wNU