Need some XB help

[Sinphaltimus]

If the XB formatted program works then the EA5 should also work. Can you PM me the XB formatted program so I can take a look? Just copy it out of your Classic99 folder.

I PM'ed all my files early this morning.

 

Here's the latest XB version (not merged) that I have been working on since. Same issue. Compiles fine, crashes once loaded in to AE.

 

Nevermind on the latest version - here's the one from this morning - AllFiles.zip

Edited October 22, 2016 by Sinphaltimus

[Sinphaltimus]

Well, my code is dirty. lot's of rules form the copiler broken. I missed them the thousand times I went through it. So today I will step through every single line and make the necessary corrections.

Thank you Senior Falcon.

[Sinphaltimus]

Question. I have a couple more errors trying to assemble the Object file.
Something about Symbol Truncation and undefined Symbol, both -0926

How can I view the assembly to try and find where the error is so I can attempt to know what to look for in Extended Basic code?



I basically had a mishap with a text formatting macro that ran through my code briefly. I've been fixed formatting issues and typos for a while now due to this happening so I'm sure I know it's a tyuupo of some sort.
I just need to know where to look. This thing grew to 848 lines of code.

 

EDIT:

 

This is as far as I've gotten:

 

Here's the files. I tried using Disk Manager 1000 but couldn't find anyoptions for file except delete, rename and one other unrelated.

 

DSK2-ZOMB.zip

Edited October 23, 2016 by Sinphaltimus

[senior_falcon]

Heading out the door in 5 minutes, so this will be brief.

Use Classic99 to do your development.

The disk you will be using (DSK3, DSK4, or whatever) should be set so you can write all DV files as windows text

When compiling, instead of the source code being ZOMBI-S make it ZOMBI.TXT

When assembling I make the object code be ZOMBI.OBJ

(Remember that the object code file is ZOMBI.OBJ when using the loader)

Use a text editor that can show line numbers to view ZOMBI.TXT (such as notepad++)

You should be able to see what the XB line number is where the problem exists.

Find it and fix it! - Good luck.

[Sinphaltimus]

Getting on this immediately. Thanks! I'll be sure to follow up....

[Sinphaltimus]

Welp. I got stuck. Not sure what's going on but it gets a new error.

I gotta turn in for the night. Maybe I'm just too tired - I'll revisit tomorrow.

 

 

[senior_falcon]

I had no trouble compiling a source code file as Z239.TXT. When assembling, using an output file of Z239.OBJ I got an error message. This means there is something wrong with how I have set up the disk in Classic99. Not a big deal though, I just used Z239-O as the output file and it assembled normally. I got the same error as you did in line 926. Alright, let's take a look at the text file the assembler just produced.

Using Notepad++ I look at the file and find this at line 923:

923 L2750

924 DATA DELSPR

925 DATA SCREEN,NC2,CHAR,NC84,SC19,NC85,SC20,NC26,SC21

926 DATA NC86SC22 (labels can only be 6 characters long, so this accounts for the truncation error)

L2750 tells me that the error is in line 2750 of the XB program. Let's look at that:

2750 CALL DELSPRITE(ALL):: CALL SCREEN(10)CALL CHAR(89,"0044442810101010",79,"007C44444444447C",85,"0044444444444438",65"003844447C444444")

Aha! A missing double colon after CALL SCREEN(10) and a missing comma after the 65.

(XB would have found this for you if you had run the XB program)

Edited October 24, 2016 by senior_falcon

[Sinphaltimus]

As soon as I can, I need to figure out this text file thing and why I'm having these little issues. I'd love to be able to find these problems on my own.

 

I also need to be more careful with macros. I created a debugger script to capture variables for me. The text format was hard to interpret so I created a macro to sort the text. Then I bumped my mouse which caused the Windows focus to change to my source code and for a brief moment my code was getting altered. I didn't save firr a good 30 minutes dor I had to manually fix everything. Xb throwing out of memory errors at me. It was a nightmare for a brief time.

 

How many times can I say thank you? Each time is enough I suppose. I'm going to owe you a dinner soon.

 

Once I can compile this version I will focus on getting these text files output properly so I can at least begin getting my feet wet with assembly by observation.

 

Than you.

Edited October 24, 2016 by Sinphaltimus

[Sinphaltimus]

Holy cow! Because of this incident, I was unable to to compile and test. Now that it's working, I just confirmed that one of my biggest hurdles is resolved. I have reached a huge milestone in the ZOMBI project. Head on over there for the news....

http://atariage.com/forums/topic/255837-new-32k-xb-gamezombi-work-in-progress/page-5?do=findComment&comment=3617543

[senior_falcon]

As soon as I can, I need to figure out this text file thing

 

How many times can I say thank you? Each time is enough I suppose. I'm going to owe you a dinner soon.

 

 

You've already figured out the text file thing. The .OBJ file extension works with Cory Burr's Assm99 but doesn't seem to with Classic99. But there's really no need to save the object code in windows format. Just use the usual ZOMBI-O for the file name. What you sent me has source code you created with the compiler that is in windows format. You can open this with Notepad in windows, then Edit>Goto>926 will take you to the line in question. (I prefer Notepad++ but you can use any text editor you want)

 

Don't worry about going to a fancy restaurant - a Chinese Buffet would be fine!

[Sinphaltimus]

My wife is an amazing cook. I'd break bread with you at my table.

 

Ok. I also figured out I could save files with the V9T9 header I classic99 so I no longer need to rely in TI99Dir. One less step in the work flow.

 

Yeah, I prefer np++ as well.

 

If you're ever near/in North Eastern PA, give me heads up.

Edited October 24, 2016 by Sinphaltimus

[Tursi]

The .OBJ file extension works with Cory Burr's Assm99 but doesn't seem to with Classic99.

 

It should. Can you guys look at the debug screen and see what the actual error message was?

[Sinphaltimus]

 

It should. Can you guys look at the debug screen and see what the actual error message was?

Opening DSK2.Z39L-M on drive type FIAD                                                                                 
PAB requested file type is DV0                                                                                         
Allocating file buffer 1                                                                                               
Detected C:\Users\LRivera\Documents\TI994a\EMU\classic99\DSK2-ZOMB\Z39L-M as a PC (headerless) file - read as DF128.   
Incorrect file type: 0/DF128 (real) vs 128/DV0 (requested)                                                             
Releasing file buffer 28                                                                                               
Setting file error 2 on file buffer 51                 


Wow, my whole response got wiped out somehow.

Anyway, here's attempt 2 - 

After selecting both DV and DF to save as win text.

Allocating file buffer 0

Flushed C:\Users\LRivera\Documents\TI994a\EMU\classic99\Contributors\Harry_Wilhelm\Compiler256D\Z39L-S.TXT (0 records)

Restore set record number to 0

DSR opcode >3 on PAB >36E3, filename DSK1.Z39L-S.TXT

writing 0x12 bytes drive 1 file Z39L-S.TXT (Variable record 0) from >3681

writing 0x10 bytes drive 1 file Z39L-S.TXT (Variable record 1) from >3681

writing 0x6 bytes drive 1 file Z39L-S.TXT (Variable record 2) from >3681

DSR opcode >0 on PAB >367A, filename DSK1.Z39L-M

Opening DSK1.Z39L-M on drive type FIAD

PAB requested file type is DV0

Allocating file buffer 1

Can't open C:\Users\LRivera\Documents\TI994a\EMU\classic99\Contributors\Harry_Wilhelm\Compiler256D\Z39L-M for input, er

Releasing file buffer 19

Setting file error 7 on file buffer 51

 

Here's the file I was using mind you it has issues.l It's old.Z30L-M.zip

Edited October 24, 2016 by Sinphaltimus

[senior_falcon]

 

It should. Can you guys look at the debug screen and see what the actual error message was?

I tried several times this evening to get the assembler to save the object code as windows text using .OBJ and also .TXT as the extension. I had no luck and was all set to take some screen shots for you. Then it suddenly started working. I did a "cold reset" at some point-could that be the secret? Anyway, I configured the disk to:

Write TIFILES headers

Write DV80 as windows text

Write DF80 as windows text

and all works properly.

[Tursi]

Rather than screenshots, just copy and paste the message out of the debug window (since it needs to scroll horizontally, screenshots will cut off important information).

 

Detected C:\Users\LRivera\Documents\TI994a\EMU\classic99\DSK2-ZOMB\Z39L-M as a PC (headerless) file - read as DF128.

Incorrect file type: 0/DF128 (real) vs 128/DV0 (requested)

Releasing file buffer 28

Setting file error 2 on file buffer 51

Okay, so Classic99 did not find a TIFILES or V9T9 header on the file, so it needed to figure out what to do with it. It did not see a .TXT or .OBJ extension, so it didn't treat it as Windows text. The default per the TIFILES standard is to treat PC files as DF128. Now that the emulator knows what the file will be, it looks to see what was requested. "DV0" was requested which does not match "DF128", and so the open was denied. Saving with a .TXT or .OBJ extension would work... or (apparently) the config as described, I didn't expect that.

 

Opening DSK1.Z39L-M on drive type FIAD

PAB requested file type is DV0

Allocating file buffer 1

Can't open C:\Users\LRivera\Documents\TI994a\EMU\classic99\Contributors\Harry_Wilhelm\Compiler256D\Z39L-M for input, er

Releasing file buffer 19

Setting file error 7 on file buffer 51

The "error number" part is cut off here, but based on the rest of the messages, I would assume "error 2", which is file not found. The emulator can't do much about that, your troubleshooting would include checking if the file at that exact path actually exists. The number after "error" in that message refers to the DOS error code, which you can look up on the web by searching for "errno"

 

I tried several times this evening to get the assembler to save the object code as windows text using .OBJ and also .TXT as the extension.

This is never automatic... the filename on the TI side needs to include that extension. Since the compiler adds its own extensions, that does kind of rule out that particular shortcut. The configuration switches you propose are definitely the nicest workaround.

Edited October 25, 2016 by Tursi

[Sinphaltimus]

Ok. I get it now. The fine extension txt, obj and the ?W all work together with the save dv files as Windows text. In order for this to work ?W (or the config to save dv as Windows text) along with obj or txt is what I need to do.

 

I thought the txt and obj were optional for some reason.

Edited October 26, 2016 by Sinphaltimus

[Tursi]

It depends on the exact operation.

 

Classic99, when READING a Windows file with a TXT or OBJ extension, will allow the TI to open it as Display/Variable and read it as if it were a TI native text file. No switches needed in that case.

 

When WRITING, the "extension" is not considered because it's not a TI concept (I may have confused that point above). So only the ?W part or configuration switches help you there.

[Sinphaltimus]

Wow. Thanks auto correct. Previous comment fixed

[Sinphaltimus]

I have to point out something that must be obvious for many of you.

The performance gain for compiling extended basic to AE5 is incredible.

Personal experience. There was a ton of bloated code in ZOMBi because I was really struggling with the performance for many of the things I needed to do. So I had to write more code to reduce the amount of sprites I had to check for a coinc.
Now with all this performance boost, I'm able to reduce the size of the program a bit here and there to make room for the title and instructions screens. Not there yet, but I will be.

So if you're coding in XB, I recommend doing it for compiling. It can be a pain but once you get the routine down, it goes pretty quickly.

I go from TidBit to XB to the 256 compiler, assembler, loader then finally E/A to test. This when running in XB is too slow to be able to test anything meaningful. The best test for me is the please don't crash test. XB is good for that one.

EDIT: it no longer compiles in to 3 files (A,B,C) - it's now just A&B

Edited October 27, 2016 by Sinphaltimus

[Sinphaltimus]

Is there a way (and could you share please?) to check if there is a DSKx drive and then check to see if there is a writable floppy in the drive?

I want to add a highscore table that saves to my ZOMBi game. I don't know how this can be done without saving out to file.

 

I'd like to have a subprogram that will ask the player if they have a DSK drive to which they would like to save the high scores.
If the player says yes they enter the DSK# and the save highscore implementation works. If they say no then the entire process is skipped.
I'd like to be able to catch errors without is crashing the game since I'm going to bin as a final format.

NOT CRITICAL! Just thinking about options. The game will save highscores (eventually) for each pay session but will be lost at power off otherwise.

[senior_falcon]

As far as I know the only way to check for a disk in the drive is to try writing to it or reading from it. The compiler now supports disk access; the main limitation is that it is only DV files. There is some error handling to get you out of trouble and keep the program from crashing. RTM for more information. You'd probably want to start the game by reading the high scores from the disk - otherwise how would you know if the current score is the high score.

[Omega-TI]

Is there a way (and could you share please?) to check if there is a DSKx drive and then check to see if there is a writable floppy in the drive?

 

I want to add a highscore table that saves to my ZOMBi game. I don't know how this can be done without saving out to file.

 

I'd like to have a subprogram that will ask the player if they have a DSK drive to which they would like to save the high scores.

If the player says yes they enter the DSK# and the save highscore implementation works. If they say no then the entire process is skipped.

I'd like to be able to catch errors without is crashing the game since I'm going to bin as a final format.

 

NOT CRITICAL! Just thinking about options. The game will save highscores (eventually) for each pay session but will be lost at power off otherwise.

 

I don't know if this would translate if you ever decided to compile it into an E/A 5, but I've always used the

ON ERROR n statement. In this case you pretty much know what error will pop up, so you could program in a line or two on the screen that says something like:

 

Media not found.

Ensure storage media is properly inserted,

then press SPACE to continue.

 

At this point you would have the program go back to the origin point for the do-over.

 

Sure, it's not the best programming technique, but in BASIC it works.

[Sinphaltimus]

OK, tonight after work, I'll play.

Thanks much both of ya. I'll follow up on this particular topic when I have some results to share.

[Sinphaltimus]

How do external subprograms work?

This is what I mean.

Without the title and instructions screen I have plenty of "program space" free.

As soon as I add the code for the title and program screens I'm left with 195 bytes free.

When it comes to external subprograms, do I need enough ram to hold all of the main program and the subprograms?

Or is there a way to clear out that ram (subprogram) once I'm done with it.

So theoretically my zombi game would start with a program that opens up the title and instructions screens and then runs another program to actually play the game. Once the game starts, those screens are no longer needed so any and all resources dedicated to displaying them should be free'd from the system.

Is there a way I can accomplish this using extended basic?
If yes, is it compiler friendly?

[Sinphaltimus]

I may have worked around the previous issue of ram. I'll find out tomorrow, going to turn in now.

I finally got around to doing this...a sprite sheet or in this case a character sheet with all codes assigned properly for all graphics in the game that are needed.

Now I just have to code it all in. Going to load all the graphics in first, before any other code, then the rest is just vchar calls already generated by Magellan.

I can't wait to see how much program memory I have remaining. Hope it's enough.