Jump to content
senior_falcon

XB Game Developers Package

Recommended Posts

Good news and bad news:

The good news - Now that I am initializing the registers properly for bit mapped mode the graphics look the way they should.

The bad news - Disk access with The Missing Link works fine on a real TI99. (And by the way, I am really enjoying using the XB 2.8 G.E.M. cartridge on my TI)

Unfortunately, disk access does not work when using the compiled version of The Missing Link. (it does now work with Win994a, so I was hopeful that it would work with real iron.)

To make room for the graphics, I move the disk buffers to a new location. I will go through the code to see what is different and try to get this fixed. In my naïveté. I had assumed that if it worked in an emulator then it would work on a real TI99.

  • Like 4

Share this post


Link to post
Share on other sites
13 hours ago, Tursi said:

I don't see the description of the original problem, but yes, that seems likely! That is part of the compatibility code to allow 80 column mode without unlocking... it would be interesting to know if the problem also happens on F18A, but it's more likely Classic99 specific. That'll clean up a bit when I split the chips up.

 

If have a comment in my F18A code:

1.8 firmware: writes to registers > 7 are masked if 80 columns mode is not enabled

 

Share this post


Link to post
Share on other sites
On 4/15/2021 at 8:42 AM, Asmusr said:

If have a comment in my F18A code:

1.8 firmware: writes to registers > 7 are masked if 80 columns mode is not enabled

Yeah, I coded the 80 column mode long before I coded any other F18A registers (and hell, YOU coded some of them for me! ;) ), so F18A graphics in Classic99 are a bit of a hodge-podge. I don't really support the graphics side in Classic99.

 

  • Like 2

Share this post


Link to post
Share on other sites

I am still unable to run the compiled version of TMLDEMO  on the real TI99. It works fine but fails when it tries to do disk access. Not clear why this is happening. It runs fine in Classic99 (always did), in Win994a, and in JS99er.

I am beginning to wonder if the files might have been slightly corrupted when I sent them over via RS232. I will send a fresh copy tomorrow and we will see what develops. 

 

The good news is that I have my HRD4000 up and running again, and sending files back and forth is now pretty straightforward, so testing will be easier from now on.

  • Like 2

Share this post


Link to post
Share on other sites

Yep, that was it. I RS232'd  the package to the TI a second time and this time it works properly. Must have been a tiny error because everything else worked fine.

Here it is again, and this time it will work on a real TI99. Put in DSK1 and it autoloads from XB.

 

CTMLDEMO.zip

Edited by senior_falcon
  • Like 8

Share this post


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

Yep, that was it. I RS232'd  the package to the TI a second time and this time it works properly. Must have been a tiny error because everything else worked fine.

Here it is again, and this time it will work on a real TI99. Put in DSK1 and it autoloads from XB.

 

CTMLDEMO.zip 23.53 kB · 2 downloads

works great!

  • Like 1

Share this post


Link to post
Share on other sites

Now I am doing some work on error handling for assembly routines. For the compiled XB part of the program nothing will change - errors will not be reported. But The Missing Link reports 3 different errors if necessary: I/O ERROR, BAD VALUE, and BAD ARGUMENT. I should be able to report those if they occur, although the only place to go after reporting is an endless loop scanning for the quit key. So you will know what went wrong but will have to figure out where.

Of more use is ON ERROR LINE NUMBER. If you are prompted for a file name and provide the wrong one, the XB program can deal with that and re-prompt you for the name again.

  • Like 1

Share this post


Link to post
Share on other sites

Almost ready to release. I've been doing a few little tweaks.The most recent is this: When assembly is done, you press Enter and that takes you back to the main compiler menu via the LOAD program. This works fine in normal XB. When using the assembler with XB 2.8 G.E.M. and CPU overdrive, when you press Enter you have to get your finger off the key instantly or running the LOAD program will be suppressed. Now the assembler waits until your finger is off the Enter key before returning to XB.

  • Like 4

Share this post


Link to post
Share on other sites

Hi,

 

the game I am currently working on may need a little more memory than expected. So I started to experiment with the "Put Runtime in Low Memory" Option in ISABELLA 7 but can not make it work. I tried normal XB and GEM 2.8 with different programs using just XB or XB with XB256.

 

What am I doing wrong? Sometimes I get IO or Syntax Errors, but when I get until here

 

Lowmem1.thumb.jpg.14ca05e7ea27f278303fdce20e26a2c3.jpg 

 

then this happens next ...

 

Lowmem2.thumb.jpg.59f27c06e0b48b5baee98953490bc030.jpg

 

What am I missing? Any hint would be appreciated.

 

Thank you

Steve

 

Share this post


Link to post
Share on other sites

Very puzzling. I had modified ISABELLA7 to be able to load to low memory using XB 2.8 G.E.M. I know I tested this, so I will have to take a look to see what is not working. At least you get a colorful screen. My test program just crashes, giving the cyan screen of death.

  • Sad 2

Share this post


Link to post
Share on other sites

I tried this with both APERTURE and 256DEMO and both work fine. Be sure you are using ISABELLA7 which can be downloaded on page 31, post 770.

As it turns out, I made a change to RUNTIME1 which broke the loader in JUWEL (all fixed now), but in ISABELLA7 it seems to work fine.

Make sure you download the entire package. You can't always mix and match the files.

 

(Edit) I see your file name is DSK1.XB256. This makes me wonder why that file name? If you use that name then you are likely to overwrite XB256 on the ISABELLA disk. Try saving the XB program with something like DSK1.TESTPROG or DSK1.MYGAME.

Edited by senior_falcon
  • Like 1

Share this post


Link to post
Share on other sites

I checked, it is ISABELLA7 I am using. RUNTIME1 is dated January 18th. My XB256 is on disk 4, your ISABELLA is on disk 1.  My exact setup is:

 

Classic99 dated April 14th, Standard Extended Basic 110

Disk 1: ISABELLA7, set to write TIFILES-Header

Disk 4: Set not to write TIFILES-Header for DV and DF files (for use of ASM994a)

 

Test-Program: DSK1.TEST resp. DSK1.TEST-M

100 INPUT VV
110 Y=INT(RND*VV)
120 PRINT Y
130 GOTO 100

 

Lowmem3.thumb.jpg.756c3eb8d3e716fd09d1e2e80fc8e4ac.jpg

 

Lowmem4.thumb.jpg.a5109e0d897c015ca5b16105ee460b02.jpg

 

Next thing is the colorful screen like above. No problem when I select N for Runtime in low memory, except that the program produces strange results when you enter 0 in the compiled version. INT(RND*0) gives a large numbers when compiled, 0 as expected in XB.

 

I repeated the steps with XB 2.8 from XB 2.8 GEM. Then I get;

Lowmem5.thumb.jpg.1746de869ad47c561390fe54b440d822.jpg

 

Strangely, when I use the slow internal assembler and SB 1.1 it does work correctly also in low memory! Perhaps that gives a hint? 

 

Thanks, Steve

 

 

Share this post


Link to post
Share on other sites

Here's what I know so far. I made a folder called STEVEB and set it up as disk 4. It is set up just like disk 1, the ISABELLA7 disk.

If the program is called TEST, put all the various TESTs (TEST, TEST-M, TEST.TXT, TEST.OBJ, etc.) on the same disk. (I tried having TEST-M on disk1 and TEST.TXT on disk 4 as you did and that had problems. It may have been that the disk was not set up properly. I will find out.)

If you are using disk 4, be sure the 8 runtime files are on that disk if using Win994a.

This works fine using the TI assembler, whether you are putting the runtime routines in low memory or high memory. With Asm994a, it works fine when the runtime routines are in high memory. When they are in low memory, I get the colorful screen.

Now to find out why...

  • Like 1

Share this post


Link to post
Share on other sites

This error crept in when I modified the loader to be able to use compressed object code. I see what needs to be done and the fix should be simple.

 

The random number bug when using a limit of 0 can be fixed with 4 bytes. Is this really a problem? Is there really an application that would expect a random number from 0 to 0?

  • Like 2

Share this post


Link to post
Share on other sites
3 hours ago, senior_falcon said:

Is there really an application that would expect a random number from 0 to 0?

You know how that goes.

Share this post


Link to post
Share on other sites
5 hours ago, senior_falcon said:

This error crept in when I modified the loader to be able to use compressed object code. I see what needs to be done and the fix should be simple.

 

The random number bug when using a limit of 0 can be fixed with 4 bytes. Is this really a problem? Is there really an application that would expect a random number from 0 to 0?

Well, certainly not when 0 is a constant. In my case it is a variable and my code relied upon the obvious. And the program went nuts when compiled. Sprites should have moved horizontally for X=0, but RND*X gave the funniest results and very fast sprites vertically. The vertical speed component is meant to be a spread-parameter, somehow like RND*X-X/2 while having a constant horizontal speed. Depending on X the sprites spread more or less in the game. Beware of the zero 🙂 (@OLD CS1 I only thought I knew and was quite surprised...). For now I use (X<>0)*(RND*X-X/2) as the first term is -1 on true and 0 on false, zilching the weirdness.

 

Thank you for taking care! I am still amazed what can be done with XB256 and the compiler now.

Steve

  • Like 3

Share this post


Link to post
Share on other sites

Here is ISABELLA8. This should fix all of SteveB's problems. The only files that were changed were LOAD, RUNTIME2 and ASSEMBLER, but you may as well unzip the entire ISABELLA8 folder.

The random number bug with a limit of 0 is now fixed as well.

 

ISABELLA8.zip

  • Like 7
  • Thanks 1

Share this post


Link to post
Share on other sites

I just installed and tested it everything runs fine now.

 

A big thank you!

  • Like 2

Share this post


Link to post
Share on other sites

image.thumb.png.5d6f53c9e0371cd2dc519a53aa2dbeab.png

 

This has been driving me crazy!  As it turns out, I simply saved the file as N128 and it all works fine.

I thought the file length was 8.3 

I was convinced I was smashing memory or something.  I re-wrote this darn program a few times to save space etc.

When I should have just tried the easiest thing first!

 

Now, I have to find an original version of this app before I introduced bugs shrinking it down...  LOL Or I guess I could debug it...  TO LATE to think straight.

 

  • Like 1

Share this post


Link to post
Share on other sites
On 4/30/2021 at 3:53 AM, 1980gamer said:

This has been driving me crazy!  As it turns out, I simply saved the file as N128 and it all works fine.

I thought the file length was 8.3 

It is not clear to me what the problem was and what you did to fix it. Can you elaborate?

Thanks!

Share this post


Link to post
Share on other sites

Very simple:  If my filename is NEC1208 the process fails with unrecognized character.

If I save the same file as N128 I can compile, the whole process works and I get my N128-X file.  and new to me... N128-Y, -G,-H,-E, and -F as well.

 

 

 

 

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

I don't understand why this was a problem for you. I renamed 256DEMO to both NEC12zero8 and NEC12oh8. It worked fine for me, so I don't think the problem is the file name. Can you PM me the XB version of NEC1208 that fails. I will test it out to see if it behaves the same way for me.

 

N128-E, N128-F, N128-G, N128-H are the EA5 files for your program. The EA5 loader loads 8K blocks of code until it has all been loaded, so for a program greater than 24K you need 4 blocks.

N128-X and N128-Y are the XB version of your program. When N128-X runs it transfers code to lowmemory, then loads and runs N128-Y, the compiled program.

Edited by senior_falcon
  • Like 2

Share this post


Link to post
Share on other sites

At last I have completed XBGDP "Juwel." You can now use assembly routines to support compiled code. Page 17 of XB Compiler.pdf has the details.

The files TMLC, T40XBC, T80XBC, XXBC are TML, T40XB, T80XB, XXB modified to work with the compiler. You can use your own custom routines if desired.

 

JUWELbeta.zip

  • Like 3
  • Thanks 1

Share this post


Link to post
Share on other sites

Maybe a silly question, but I do not understand... So I have to ask... (not sure if it is done here, seen some vid's where someone did an "elaborate" way to make a "playable" file.)

WHY... do you have to compile some files in one way, then make a new file of the original and then some more and after back and forth, you have the "real" compiled file - OK... But WHY can't this all, be done in ONE operation?

Share this post


Link to post
Share on other sites

I thought I was squared away...

Now I always get this error...   First it skips the Assembler Step.  So, I arrow up to run it.

image.thumb.png.c1f3978341524ce165be8076db53bcca.png

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

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

×   Your previous content has been restored.   Clear editor

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

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...