Jump to content
senior_falcon

XB Game Developers Package

Recommended Posts

Hi senior_falcon,

 

thank you for your support! I do a lot of experiments right now to regain my XB skills. In both cases I need to convert the code from a inline-function RND to a separate subroutine call. I will play around with your IRND and my SUB RAND and see what suits best. In the eighties I only had the console, XB and a tape recorder, so this whole CALL LOAD, CALL LINK etc is still a little a little confusing to me... and it seems so natural for everybody else.

 

 

  • Like 1

Share this post


Link to post
Share on other sites

Hello Harry,

 

maybe you can help to solve a problem I have with the compiled command ACCEPT AT.

I have had an “EVPC2” 80 column card in my TI99 for a few weeks.
In my compiled Mega Menu program I use ACCEPT AT for some inputs.
If I press the SHIFT key for a input, I get a destroyed screen output.
It only seems to happen with the ACCEPT AT command.

 

Today I created a small test program to reproduce the behavior.
The XB program "AT" does some screen output and then asks for input.
 

AT.zip

 

image.png.8e1eb5269ee219782b4a4ae08edfe5a7.png  image.png.98c5b70109fa129cd176d5e0b93557f9.png 

 

This is the correct screen            and that happens after pressing the SHIFT key

 

In XB itself (not compiled) it works fine in C99 and on the real TI system.

In classic99 it works fine also in the compiled version. On the real system everything works as long as I don't press the SHIFT key.
As soon as the SHIFT key is pressed, the screen does not display all characters correctly and the TI hangs up!

 

I noticed on the real hardware and in classic99 that the ACCEPT AT command in the compiled version cannot be interrupted with FCTN + 4. This works in normal XB.

 

If there is no easy solution then I have to change my inputs to the CALL KEY command. With CALL KEY there are no problems with the SHIFT key.

 

 

Share this post


Link to post
Share on other sites

Hello again,

 

I tried to use a quick and dirty alternative routine for the ACCEPT AT, CALL INAT(row,col,val$,beep,ilength).

AT2.zip

This works in the small AT2 program in the compiled version on classic99 and on my real TI.

 

With the alternative routine I can input SHIFT characters like the "-" without a problem.

 

image.thumb.png.3607a00071376854614586d2bd1e3b81.png

Share this post


Link to post
Share on other sites
6 hours ago, wolhess said:

Hello Harry,

 

maybe you can help to solve a problem I have with the compiled command ACCEPT AT.

I have had an “EVPC2” 80 column card in my TI99 for a few weeks.
In my compiled Mega Menu program I use ACCEPT AT for some inputs.
If I press the SHIFT key for a input, I get a destroyed screen output.
It only seems to happen with the ACCEPT AT command.

This works fine in C99 and on the real TI system.

In classic99 it works fine also in the compiled version. On the real system everything works as long as I don't press the SHIFT key.
As soon as the SHIFT key is pressed, the screen does not display all characters correctly and the TI hangs up!

I noticed on the real hardware and in classic99 that the ACCEPT AT command in the compiled version cannot be interrupted with FCTN + 4. This works in normal XB.

If there is no easy solution then I have to change my inputs to the CALL KEY command. With CALL KEY there are no problems with the SHIFT key.

 

 

Hi Wolfgang:

Your AT-X program works fine in Classic99 and in Win994a

Have you tried running the compiled program AT-X on a real TI without using the EVPC2 80 column card?

Harry

 

Share this post


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

Hi Wolfgang:

Your AT-X program works fine in Classic99 and in Win994a

Have you tried running the compiled program AT-X on a real TI without using the EVPC2 80 column card?

Harry

 

Yes, without the EVPC2 card all is working fine. I use this program since about two years on my real hardware. My issue is only with the EVPC2 card.

 

I think the EVPC2 card switch the VDP memory and is using the EXTINT line to transport the VDP interrupt back from the PEB to the console. But I‘m no expert and I only have the manuals from snug for the card.

The 9929 VDP controller in the console is replaced by an REPL99 card with some resistors and a quarz.

 

If I run TI Basic the screen is always wrong. I have to do a CALL BASIC to get the correct screen output in TI Basic. This is a command from the EVPC2 dsr. If I press a SHIFT key in TI Basic the Basic blocks the screen again and I have to do a CALL BASIC again to get the Basic prompt.

 

All Extended Basics are working fine, even I press the Shift keys.

 

Up to now all XB programs and all assembly programs I tried are working with the EVPC2 card.
 

 

Maybe this helps to determine my problem.

 

 

 

Share this post


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

Hi Wolfgang:

Your AT-X program works fine in Classic99 and in Win994a

Have you tried running the compiled program AT-X on a real TI without using the EVPC2 80 column card?

Harry

 

Hi Harry,

 

right now I tried my AT-X program with mame and the emulated EVPC (not EVPC2) card and it works too.
We don't have an EVPC2 card simulator, so I can't reproduce my issue on a PC.

I think I must use my solution with the CALL INAT replacement for the ACCEPT AT.

 

Wolfgang

Share this post


Link to post
Share on other sites
On 1/17/2021 at 12:08 PM, wolhess said:

As soon as the SHIFT key is pressed, the screen does not display all characters correctly and the TI hangs up!

On post #752 I wrote that the TI hangs up, but this isn't the case!

I can use the program with press ENTER and input some characters or I can press "Q" to exit the program.
But the screen is destoyed, the input characters are not displayed on the screen.
If I press "Q" the program stops as it should and I see the correct screen output and the XB prompt.

 

 

I modified the AT program to show the interrupt address values on >83C4:

ATB.zip

 

 

1. I input HELLO and <ENTER>

image.thumb.png.6410a4dc672ce84ac4a067aa9e0c9218.png

 

2. I pressd <SHIFT> + "-" + <ENTER>

image.thumb.png.3a4a6fcfd251e794c8815976e8792724.png

 

3. I input "Q" to exit the program

image.thumb.png.4f498be45797d02f0a84bd9a826fbf1d.png

 

 

I changed a setting in the EVPC2 card from MOVE VDP = ON to MOVE VDP = OFF. But the problem is the same!

 

IMG_3831.thumb.jpg.9fc02ece9ec100275b79fc27d86fc687.jpgIMG_3832.thumb.jpg.b73736be58401fda3f5c68f0947dfc49.jpg

 

 

Share this post


Link to post
Share on other sites
6 hours ago, wolhess said:

Yes, without the EVPC2 card all is working fine. I use this program since about two years on my real hardware. My issue is only with the EVPC2 card.

 

I think the EVPC2 card switch the VDP memory and is using the EXTINT line to transport the VDP interrupt back from the PEB to the console. But I‘m no expert and I only have the manuals from snug for the card.

The 9929 VDP controller in the console is replaced by an REPL99 card with some resistors and a quarz.

 

If I run TI Basic the screen is always wrong. I have to do a CALL BASIC to get the correct screen output in TI Basic. This is a command from the EVPC2 dsr. If I press a SHIFT key in TI Basic the Basic blocks the screen again and I have to do a CALL BASIC again to get the Basic prompt.

 

All Extended Basics are working fine, even I press the Shift keys.

 

Up to now all XB programs and all assembly programs I tried are working with the EVPC2 card.
 

 

Maybe this helps to determine my problem.

 

 

 

Compiled programs use the GPL input routine built into console rom. This routine is used by TI BASIC. For compiled programs the boundaries are modified to permit ACCEPT AT, SIZE, etc.

The inability to run normal TI BASIC programs without exhibiting the same behavior shows that somehow this is caused by the EVPC2 card. I have no idea whether this is caused by an interrupt routine,or if the card is changing the console ROMs or something else. I will look more closely at your posts.

Share this post


Link to post
Share on other sites

The EVPC does have its own 80-column GROM0. It was authored by Winfred Winkler and has proven to have various "eccentricities". So much so, that Tony Knerr wrote a version of his own that has much better performance. I have been using a customized version that Tony wrote for me many years ago. It works quite well with 80-column devices (EVPC, AVPC, etc).

Edited by atrax27407

Share this post


Link to post
Share on other sites

The line editor is in grom 1 and and in a quick once over I didn't see any calls to grom 0. Maybe grom 1 was changed too?

Anyhow, the bottom line is: Is Gazoo's version compatible with TI BASIC? If so then it will probably work with a compiled program as well.

You could try out AT-X in post #752 above to see what happens.

Share this post


Link to post
Share on other sites
2 hours ago, atrax27407 said:

The EVPC does have its own 80-column GROM0. It was authored by Winfred Winkler and has proven to have various "eccentricities". So much so, that Tony Knerr wrote a version of his own that has much better performance. I have been using a customized version that Tony wrote for me many years ago. It works quite well with 80-column devices (EVPC, AVPC, etc).

Hi @atrax27407,

 

I'm using the snug EVPC2 80 column card without the extra wire from the console to the PEB.
The card has a dsr, but I think it uses the standard GROM 0-3 in the console. Maybe I'm wrong.

 

Usualy the EVPC2 is working without a console but with a HSGPL and a SGCPU card. In the HSGPL I assume the console GROMs are modified to work with the EVPC2 card.

 

So I think I have no chance to use a modified GROM in my system.


Wolfgang

Share this post


Link to post
Share on other sites

If it can be used with a basic console, GROM0 must be part of the DSR. That being the case, I'm sure that there must be a way to chnage GROM0 in the DSR. Contact Michael Zapf for further information.

Share this post


Link to post
Share on other sites

According to the documentation of the EVPC2 you don't need a modified GROM0. There seems to be special DIP switch settings:

 

(translated by me)

Dip switch 2:
In the operating system in GROM 0 in the console, some video registers are set with wrong values on startup so that the power-up routine in the DSR of the EVPC2 must fix these errors by copying the video memory areas.

When the EVPC2 is used with a SGCPU and HSGPL, these wrong register values in GROM 0 may be fixed, which removes the need to copy the memory areas. If the EVPC2 is used in such an environment, activating DIP switch 2 speeds up the power-up process.

Off = normal power-up

On = fast power-up

 

Dip switch 6:

TI put an error in the original GROMs which causes the character set in TI Basic to be loaded at a wrong place, which in turn leads to a display of weird characters instead of text. The DSR may be configured to reset the VDP registers every 20ms to sane values so that the display is correct.

Off = Leave video registers as is

On = Reset video registers repeatedly

 

All features described above are only meaningful for use with a console. When using a SGCPU and HSGPL, all glitches in the operating system are fixed so that neither a modified interrupt service nor other tricks to reset video registers need to be applied.

Edited by mizapf
  • Like 3

Share this post


Link to post
Share on other sites

Hi,

my EVPC2 card, DIP switch 6 was OFF. (This was recommended by Michael Becker, he told me only DIP switch 7 and 8 should be set to ON)

I set it to ON, but my screen is still broken when I press the SHIFT key in the AT-X program. 
If I break the compiled XB program, the display is fine again (as described in post # 757).
I tested the program with both settings VDP MOVE=ON and VDP MOVE=OFF with the same results.

 

Even TI BASIC shows the same results (After running TI-BASIC I have to make a CALL BASIC to see the correct screen).
If I press one of the SHIFT keys the TI clears the screen, shows the TI BASIC READY prompt and I don't see any further input.
So I have to make a CALL BASIC and NEW. Then TI BASIC is working again.

 

It seems that the DIP switch 6 doesn't work in this case.

Share this post


Link to post
Share on other sites
23 hours ago, atrax27407 said:

It is compatible with TI BASIC

@Atrax: Can you download the AT-X program and see if it works with your card?

Thanks.

Share this post


Link to post
Share on other sites
18 hours ago, atrax27407 said:

I don't have a real iron system with an 80-column card (out for repairs). However, I can try it in MAME if that will work.

I tried the AT-X program in mame and it works there. I can input shift characters without a screen problem.
But mame emulates only the EVPC card and not the EVPC2 card.
AT-X1.thumb.JPG.1faf6036196811b4e8c841411aaabb7a.JPG  AT-X2.thumb.JPG.855cfcca33b592ca72e4e37c9ce9ff42.JPG

 

Share this post


Link to post
Share on other sites

Here is Isabella7. There are two main differences:

The low memory loader is now compatible with XB 2.8 G.E.M.

The loader program is much smarter. It reads the first line of the object code produced by the assembler to know whether the file exists and whether the runtime routines are in high memory or low memory. This all happens automatically and it is much easier to use now.

The option to use minimemory for faster loading has been removed. XB 2.8 G.E.M. is included which greatly speeds up loading when the runtime routines in low memory.

ISABELLA7.zip

 

(Edit) - forgot to mention that the folder with the TI specific files has not been changed yet. The windows format .TXT files and a few minor defaults  need to be changed. I will get to that at some point.

Edited by senior_falcon
  • Like 8

Share this post


Link to post
Share on other sites

I have made some progress in adding assembly support to compiled code. So far a compiled program can CALL LINK to an assembly support routine and return to the compiled code. The two test A/L subs are simple; PRINTA fills the screen with "A" and PRINTB fills the middle of the screen with "B"

As yet no variables can be passed in either direction with NUMREF, NUMASG, STRREF, STRASG. I have hopes these can be modified so this possible.

  • Like 5

Share this post


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

I have made some progress in adding assembly support to compiled code. So far a compiled program can CALL LINK to an assembly support routine and return to the compiled code. The two test A/L subs are simple; PRINTA fills the screen with "A" and PRINTB fills the middle of the screen with "B"

As yet no variables can be passed in either direction with NUMREF, NUMASG, STRREF, STRASG. I have hopes these can be modified so this possible.

That can really take your system to another level.  

Excellent work by you.

Share this post


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

I have made some progress in adding assembly support to compiled code. So far a compiled program can CALL LINK to an assembly support routine and return to the compiled code. The two test A/L subs are simple; PRINTA fills the screen with "A" and PRINTB fills the middle of the screen with "B"

As yet no variables can be passed in either direction with NUMREF, NUMASG, STRREF, STRASG. I have hopes these can be modified so this possible.

This sounds great! 

 

My upcoming version of TiCodEd will include a check for illegal user SUB routines and issues a warning. You have not updated page 12 in the manual so I assume those changes do not introduce new illegal names?  

 

I updated my installation to Isabella7 and everything worked immediately. Now waiting for version 8 ... 

 

Steve

Share this post


Link to post
Share on other sites
21 minutes ago, SteveB said:

This sounds great! 

 

My upcoming version of TiCodEd will include a check for illegal user SUB routines and issues a warning. You have not updated page 12 in the manual so I assume those changes do not introduce new illegal names?  

 

I updated my installation to Isabella7 and everything worked immediately. Now waiting for version 8 ... 

 

Steve

No, there are not any new illegal names.

There will not be a version 8. This will add enough new functionality (assuming it actually works) that it will merit a new name. "Juwel"

  • Like 4

Share this post


Link to post
Share on other sites

If people need a DSK image - like MAME users - here is one I quickly created. I imported all the TIFILES from the ISABELLA99 subdirectory and some more from the root of the ZIP file. I don't know if there are particular reasons why it should not run on MAME, but at first sight, everything seems OK.

isabella7.dsk

  • Like 3

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.

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