XB Game Developers Package

[XB Game Developers Package]

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.

[Classic99 Updates]

1 hour ago, Tursi said:

It'd be interesting if those settings reported any errors in the debug log during assembly?

Hi Tursi,

yes there are errors after I select Assembler, the debugger  shows an Illegal opcode.

And this is the disasm LOG started before I select ASSEMBLER from the Isabella6 menu.

disasm.txt

 

And so it shows, when I use a fresh classic99.ini

disasm_working.txt

[XB Game Developers Package]

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

[XB Game Developers Package]

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>

 

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

 

3. I input "Q" to exit the program

 

 

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

 

 

 

[XB Game Developers Package]

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

[XB Game Developers Package]

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.

 

 

 

[XB Game Developers Package]

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.

 

[Classic99 Updates]

Hi Tursi,

 

I changed the classic99.ini file from the functional v030 to my non functional v037 and now the process is working!

 

So it seems that my classic99.ini has been corrupted since v032.

 

Thanks for looking at my issue!

Here is my defective ini file, but you don't need to take any further action here.

classic99-corrupt.ini

 

EDIT: I changed the ini file back and the issue is there, so it was the ini file!

[Classic99 Updates]

3 hours ago, Tursi said:

I need a step-by-step

Hi Tursi,

This is the .zip with the functional v399.030. I used.
 

_classic99_399-030.zip

 

The step by step is easy:

 

1. Run classic99 from the .zip. The cartridge is TI-Extended Basic and the DSK1=...\_classic99_399-030\ISABELLA6\

2. Select "2" for TI Extended Basic

    -> This will autoload the ISABELLA6 menu

3. Use Arrow down for Extended Basic + ENTER

4. >OLD DSK1.TEST + ENTER

5. >SAVE DSK1.TEST + ENTER   *** From now on you can only press ENTER when the program asks for an input!

6. >SAVE DSK1.TEST-M,MERGE press ENTER

7. >RUN "DSK1.LOAD" press ENTER
    -> the ISABELLA6 menu is on the screen

8. Select Compiler press ENTER
   -> The compiler asks for some files, you can always press ENTER (6 times) for the defaults.
   -> After the compiling the ISABELLA6 menu is in the screen again

9. Select Assembler press ENTER

   -> In classic99 later than v030 this step shows the destroyed screen and a terrible sound! 
   -> In classic99 v30 and earlier the assembler asks for some files, you can always press ENTER (5 times) for the defaults.
   -> The assembler is executing 

10.  Press ENTER if the assembly is finished and it shows 0000 ERRORS
   -> the ISABELLA6 menu is on the screen

11. Select LOADER press ENTER
   -> the loader asks for some file names, you can always press ENTER (4 times)

12. The compiles program is running and shows "HALLO"

 

I mapped the "ISABELLA6" folder in the actual classic99 v37 and got the described issue.

 

[Classic99 Updates]

Hi Tursi,

 

since classic99 399.032 I was'nt able to assemble a compiled XB program with the XBGDP internal assembler.

If I use the external Asm994a assembler all is working.

 

 

I used a simple "PRINT HELLO" program and in the version v399.030 all is fine:

TEST

 

 

Since classic99 v399.032/033... if I will assemble this I get the following screen:

 

 

 

 

Perhaps the cause lies in seniorfalcon's XBGDP program. However, this worked very well up to and including v30.

[XB Game Developers Package]

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

 

   

 

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.

 

 

[TIPI Usage and Support]

On 1/11/2021 at 6:01 PM, Vorticon said:

I wonder if it's worth trying to reflow the solder joints on the board...

Hi @Vorticon,

 

today I soldered the available solder joints on the back of the board and tried the card in the PEB. 

 

DU2K told me that the device on CRU >1000 is there again. So all should work.

 

Thank you for your recommendation!!!

 

 

@jedimatt42

 

CALL TIPI works again too. I was on tipi v2.16 and it shows me there was an update.

I did the update but the screen was freesing with the message "starting update..."

 

After about three minutes I tried to quit tipicfg but no reaction of a keypress, so I reseted the console and it seems the update was done.

 

 

I tried to run my Mega Menu program from the tipi and it works too, so all seems to be OK.

 

 

The last two day's I used my TI without the tipi card. 

 

I've started to set up my installation so that I can run some things from the ramdisk or from floppy.

Working with the TI without a tipi is many times slower. Especially when files have to be transferred from the PC to the floppy or ramdisk.

 

For me, the tipi card is the best extension currently available for the TI-99/4a!

 

Thanks a lot for this!

[TIPI Usage and Support]

2 minutes ago, Vorticon said:

I wonder if it's worth trying to reflow the solder joints on the board...

Yes, I can do it for the normal (not SMD) solder points. but there are SMD parts and this I can't solder. I would short anything!

 

I think the best is I send the card to arcadeshopper, to his address in USA or maybe to the address he has in the EU.

[TIPI Usage and Support]

3 minutes ago, Vorticon said:

I saw that, but was the failure pinpointed to a specific component on the board?

No nothing special, yesterday all went good and today I had to shotdown my PC and my two RPI's for a planned power outage in my office.

 

After Restarting the PC and my sidecar tippi work both as expected. My main tipi-peb system is working but doesn't access the usualy mapped tipi drive.
 

 

 

[TIPI Usage and Support]

Just now, Vorticon said:

So what exactly went wrong with your original TIPI-PEB? This would be the first time a failure has been reported as far as I know...

After the power down and restart a CALL TIPI results in "* SUBPROGRAM NOT FOUND"

 

I tried a lot of things, see post #1282, but without success.

[TIPI Usage and Support]

OK, Thank You. So I need a new tipi-peb card. I just placed the order.

 

Wolfgang

[TIPI Usage and Support]

Hi,

 

today I shutdown my TIPI/RPI the first time since last summer. After the restart I had no connection to the tipi. A CALL TIPI results in a "* SUBPROGRAM NOT FOUND".

 

The RPI is running and I have access to the shared SD-CARD, so the PC side / RPI side seems to be OK.

 

The config program of the Horizon 4000B doesn't list the TIPI card.

 

I had shutdown the RPI again and controlled the cabeling between the RPI and the TIPI-PEB card. --> cabeling are all OK!

I used another slot in the PEB with same result (no CALL TIPI)

Then I changed the TI-Console, put the Speech Synthesizer away and used a standard TI-XB cardridge. All with the same result.

 

I checked the DSR EPROM of the TIPI card, first time it shows an ERROR, reading a second time all was OK.

So I programmed a new EPROM but only with the same effect (no CALL TIPI)

 

It seems to me the TIPI DSR is not loaded, because the HRD config and the DU2K doesn't show the device on address >1000.

 

Could it help to use another RPI? Should the TIPI card load the DSR even the RPI has a problem to connect?

 

Otherwise I think I need a new TIPI-PEB card?!

 

If anyone still has an idea, I would appreciate it.

 

Wolfgang

 

[RXB - Rich Extended Basic]

9 hours ago, Ksarul said:

I have not yet written down (or tested) all of the necessary changes to the revision 4A boards. I know it will require several trace cuts, some of which would require removal and replacement of existing chip sockets to get access to the cut points. It would also require two pairs of chips to be stacked (and a lot of flying wires) to add the necessary bits to the selection circuitry.

Ok, I think I don't want to do that. Nevertheless, thank you very much for the answer

[RXB - Rich Extended Basic]

17 hours ago, Ksarul said:

Though it is "technically" possible to upgrade the older 1M boards, it requires some significant board surgery and isn't generally advisable for those with limited soldering skills.

Hi @Ksarul

 

is there a description for changing my SAMS card from 1MB to 4MB capability?
It is a revision 4A Board, see post #1147.

 

Wolfgang

[Force Command ver 1.17 : kinda like command.com from 1985]

11 hours ago, jedimatt42 said:

Version 1.14 fixes the SAMS mapping before launching a cartridge. Mega Menu works for me with XB GEM 2.8 via the XB TIPI.MM.MM command.

Yes it works. I can run first FC and run Mega Menu from the script and from the Mega Menu I can run Force Command.

And I can run first Mega Menu and run Force Command from Mega Menu. I can cycle this back and forth without a problem.

Thank you for doing the changes so fast!

 

Same I can do on my non tipi system with the 80 column card. Here too I can cycle between Force Command and Mega Menu.

There is also an improvement. I don't need to reset the FG99/TI after the first power on. It works from the first run.

 

 

 

 

 

[RXB - Rich Extended Basic]

7 hours ago, RXB said:

OMG that is a problem that might be just a DSR issue as this never cropped up before now.

All AMSINIT ever did was turn of each page and see if it worked then put back what if found.

That would be insane for a 32Meg SAMS!!!!

I baught the SAMS card in March 2019 from @KSARUL. I think it is the last design for a 1M version and I see no DSR there.
Maybe it is able to upgrade to a 4MB card?

 

 

 

[Force Command ver 1.17 : kinda like command.com from 1985]

2 minutes ago, jedimatt42 said:

regarding the flashing cursor from READKEY, I took the cursor away on purpose.

@jedimatt42,

 

Too bad, for me that was a sign that FC is ready to press a button. If a key is pressed before the script is processed, it is not recognized or not always recognized.
But anyway, I can live without the cursor.

[RXB - Rich Extended Basic]

46 minutes ago, RXB said:

I could be wrong but if you are right then why did RXB 2001 to RXB 2015 work fine on my 1 MEG SAMS card?

Hi Rich,

in my real system I need to make a CALL AMSINIT to see my SAMS memory in the size command.

Without the AMSINIT call I see only the normal 32K size info and nothing about AMS.

 

But the programs like the amstest program are working.

[RXB - Rich Extended Basic]

28 minutes ago, RXB said:

IN THE DARK error 1280 is the new command CALL BLOAD, that replaced old command CALL PLOAD afraid you need the new IN THE DARK on the RXB 2020 zip file.

I‘m using the new In the dark game from the rxb 2020 package. And it works in classic99 from the same shared folder as it doesn‘t work on my real system.

 

And yes, it can has to do with the word and byte stuff for the mapper. I had a problem in an earlier Samscard tester from TheBF. He changed something from words to bytes and the new version works fine.

[RXB - Rich Extended Basic]

On 12/28/2020 at 12:52 AM, RXB said:

Re-Release this time with bugs fixed, (I hope!):

RXB 2020 A 

@RXB Hi Rich,

 

today I tried the new RXB 2020 a second time but I always have problems on my real hardware with the SAMS enablement.
In classic99 it works!

 

After a complete restart of the PEB and the TI, I see no SAMS in the SIZE command:

 

If I run XB 2015 and make a AMSINIT, I get the following screen:

 

Then I reset only the FG99 and run XB 2020

Today I tried to run the game In the Dark and after the title screen I get an ERROR in line 1280.

Could you please make a very simple example to enable the SAMS card and just use the SIZE command to see the default mapping.

 

I tried/used a lot of other SAMS programs and all were working fine, also three different AMS test programs tells me my AMS card is OK.

 

What am I doing wrong?

Mybe I didn't understand the AMS concept.

 

Wolfgang