40 column routine or early version of XB24 for XB

[HOME AUTOMATION]

that has always been my biggest complaint with TIXB. The TI was the only computer (that I'm aware of) that the majority of it's video capabilities were not accessible from it's advanced BASIC. which leads me to a question, if TI, when the memory expansion was attached, had moved all the tables to the main memory out of the VDP, would that have worked? that way all the VDP could been used for graphics. I know now that would cause a lot of compatibility issues but if it been done form the getgo would it worked?

as for the tables cutting into the main programming area, it wouldn't been any different than the other computers of the era.

The TABLES are mapped to the VDPs internal hardware. So really... only moving the program out to CPU RAM makes any sense.

A sort of desperate approach to use VRAM for an interpreted program in the first place.

[+hloberg]

It's late and so I will just post this and let you read the docs. Have fun.

Here is a demo for T80XB. The utilities are virtually the same, except for 40 columns instead of 80.

40 Column, inverse and scrolling; I can now translate most my Atari BASIC programs without to much of overhauling the format. Thanks!

[+hloberg]

found a minor bug. Seems to only be in classic99 as it doesn't seem to manifest itself in MESS. while using the T40XB, every now and then classic99 will lock up. I can't seem to find a pattern. may only do it a couple times in an hour or not at all.

It could be I started using:

CALL PR(A$)

CALL LINK("PRINT",1,25,A$)

ENDSUB

so I can use CALL PR("TEXT") instead of call link. I know this eats into the VDP ram area. But like I said it doesn't seem to happen in MESS. It's no big deal to me just thought I would let you know.

[senior_falcon]

With XB256 and The Missing Link, I found that sometimes there were problems on program startup, but usually once the program was running it was OK. I think classic99 tended to do this more than a real TI99. But I don't remember it locking up; it would just give an error on startup and running the program again would make it work. This has something to do with the liberties the interrupt routine takes with the VDP stack pointer. For XB256 I added some code to the loader that tries to change the stack pointer in the grom code of the XB cartridge. For this to work you must enable GRAM at >6000. That seems to cure the problem. T40XB uses the same procedure to adjust the stack pointer, so I suppose this might help here as well.

Edited April 18, 2019 by senior_falcon

[senior_falcon]

Give this a try. Now you can enable GRAM @>6000 and the loader will modify the XB cartridge and with any luck your problems will end. The docs are updated to describe this addition.

 

One of the things I have noticed is that the newest version of Classic99 tends to lock up on me. There is no pattern to this. Tursi wants to see the debug log, but the program is completely frozen so that is unavailable. It could be my system - an old Dell optiplex 780 rescued from the trash running linux mint, which runs virtualbox, which runs Windows XP, which runs Classic99. So there are lots of layers where it could be failing.

T40XB1.zip

Edited April 18, 2019 by senior_falcon

[+hloberg]

Ah, we got a pattern here. I'm also running Classic 99 on Virtualbox with XP, on a Win10 laptop. I can't get TIDIR to run on my Win10 so all the TI stuff go in the VB. Sounds like a Classic99 issue.

So I just tried Classic99 on my Win7 machine, which runs Classic99 directly (and TIDIR without issue) and, what little testing I did, there was no lock up.

I'll download your new version and see what happens.

Edited April 18, 2019 by hloberg

[Tursi]

I've actually seen one lockup myself... but it wasn't something I could troubleshoot.

 

The next update to Classic99 requires me to fix something I broke pretty badly in the timing system, so that may be related. It'll be a little while yet though, bear with me.

[+hloberg]

I've actually seen one lockup myself... but it wasn't something I could troubleshoot.

 

The next update to Classic99 requires me to fix something I broke pretty badly in the timing system, so that may be related. It'll be a little while yet though, bear with me.

No problem. for some reason it stopped locking up. In fact, I did several things and I can't tell you which one made it stop. Even I my VB WinXP it doesn't lock up anymore. I ran the program in a loop with T40XB and it won't lock up. Throttled it and it won't lock up (but it does slow way down at points).

[+hloberg]

translated a little BASIC game from the Atari to the TI99 using T40XB.

Here's the blog: http://atariage.com/forums/blog/528/entry-15778-ti-99-40-column-text-game-using-t40xb/

edit: added a short description of T40XB.

Edited April 20, 2019 by hloberg

[senior_falcon]

"when the program ends or you jump back to the 32 column mode using CALL LINK("G32") your T40 text will disappear."

 

Just to be clear on this: The T40 text is still there and if you CALL LINK("T40") you will be in the T40 screen again. Or if you use F4 to break the program when it is in the T40 mode, you can list variables and do some debugging. When you CON, the program resumes in the T40 mode. If you are in the G32 mode you can print instructions in the T40 mode, then go back where you were in the G32 mode.

[RedBaron]

If anyone is interested.  I created an Extended Basic 40 column program that shows how the 40 column characters are made.  I have been using the Classic 99 program to go into Extended Basic and wrote a small program then save it to DSK1.  I am not sure how I can share this with anyone that would like to have it.  If someone would like to see it I could use a little help with how to post the code here.  I will give it a try myself and hope that this program is posted correctly.  Thank You.

 

40COLDEF

[RXB]

On 4/17/2019 at 6:22 PM, senior_falcon said:

With XB256 and The Missing Link, I found that sometimes there were problems on program startup, but usually once the program was running it was OK. I think classic99 tended to do this more than a real TI99. But I don't remember it locking up; it would just give an error on startup and running the program again would make it work. This has something to do with the liberties the interrupt routine takes with the VDP stack pointer. For XB256 I added some code to the loader that tries to change the stack pointer in the grom code of the XB cartridge. For this to work you must enable GRAM at >6000. That seems to cure the problem. T40XB uses the same procedure to adjust the stack pointer, so I suppose this might help here as well.

RXB 2020 has fixed this as you have CALL VDPSTACK(address) this changes the VDP Stack location in ROM and GROM so you do not have this issue.

 

Just to be clear there is also command for CALL POKER(VDP-Register-Number,value) this loads the Register with they value for what you want it to be.

In a RXB demo is how to set up 40 Column or Multi-color mode, Bit Mapped mode is a real issue that can not be done without a complete rewrite of XB.

Edited September 1, 2021 by RXB

[senior_falcon]

Bit Mapped mode is a real issue that can not be done without a complete rewrite of XB.

 

I seem to remember there was a program that supposedly gave the XB programmer full access to bit mapped graphics from an XB program. Can't seem to remember the name. I must be missing something. Is there a link where I can find out more about this?

[RXB]

1 hour ago, senior_falcon said:

Bit Mapped mode is a real issue that can not be done without a complete rewrite of XB.

 

I seem to remember there was a program that supposedly gave the XB programmer full access to bit mapped graphics from an XB program. Can't seem to remember the name. I must be missing something. Is there a link where I can find out more about this?

Yea but you have to run it from Assembly as all buffers in XB reside at VDP >0820 for XB program lines you can not move these variables used by XB:

***********************************************************
*    VDP addresses
NLNADD EQU  >02E2             New LiNe ADDress
ENDSCR EQU  >02FE             END of SCReen address
LODFLG EQU  >0371             Auto-boot needed flag
START  EQU  >0372             Line to start execution at
SYMBOL EQU  >0376             Saved symbol table pointer
SPGMPT EQU  >0382             Saved PGMPTR for continue
SBUFLV EQU  >0384             Saved BUFLEV for contiue
SEXTRM EQU  >0386             Saved EXTRAM for continue
* SAVEVP EQU  >0388           Saved VSPRT for continue
* ERRLN  EQU  >038A           On-error line pointer
BUFSRT EQU  >038C             Edit recall start addr (VARW)
BUFEND EQU  >038E             Edit recall end addr (VARA)
TABSAV EQU  >0392             Saved main symbol table ponte
SLSUBP EQU  >0396             Saved LSUBP for continue
SFLAG  EQU  >0398             Saved on-warning/break bits
SSTEMP EQU  >039A             To save subprogram program ta
SSTMP2 EQU  >039C             Same as above. Used in SUBPRO
MRGPAB EQU  >039E             MERGEd temporary for pab ptr
*----------------------------------------------------------
* Added 6/8/81 for NOPSCAN feature
PSCFG  EQU  >03B7
*----------------------------------------------------------
*    Flag 0:  99/4  console, 5/29/81
*         1:  99/4A console
CONFLG EQU  >03BB
*----------------------------------------------------------
* Temporary
NOTONE EQU  >0374             NO-TONE for SIZE in ACCEPT us
*                              in FLMGRS (4 bytes used)
SAVEVP EQU  >0388
ERRLN  EQU  >038A
ACCVRW EQU  >03AC             Temoporary used in ERRZZ, als
*                              used in FLMGRS
VALIDP EQU  >03B0             Use as two values passing fro
VALIDL EQU  >03B2             VALIDATE code to READL1
OLDTOP EQU  >03BC             Temporary used in ERRZZ, also
CRNBUF EQU  >0820             CRuNch BUFfer address
CRNEND EQU  >08BE             CRuNch buffer END
RECBUF EQU  >08C0             Edit RECall BUFfer
VRAMVS EQU  >0958             Default base of value stack
CNSTMP EQU  >0390             Use as temporary stored place
***********************************************************

Now you can move the Screen Image table but that means you retain the old one using up a ton of VDP memory, that really cuts down number of String Variables 

and the amount of buffers used, not to mention you need a interrupt routine too.

[HOME AUTOMATION]

8 hours ago, senior_falcon said:

I seem to remember there was a program that supposedly gave the XB programmer full access to bit mapped graphics from an XB program. Can't seem to remember the name. I must be missing something. Is there a link where I can find out more about this?

I seem to remember something called, The Missing Link, an amazing development platform at the time. For the life-of-me, I can't recall the creator's name ...but it's included with Classic99!

[senior_falcon]

That was it, it was called The Missing Link.

 

Yea but you have to run it from Assembly as all buffers in XB reside at VDP >0820 for XB program lines you can not move these variables used by XB:

 

Sure sounds like bit mapped graphics can only be used in an assembly program. I wonder if the author knew about the memory areas identified in post #39. Probably not. It sounds like this program is just a bunch of extravagant claims that cannot possibly work.

Still, if I wanted to use bit mapped graphics with XB, I guess I would try out The Missing Link on the unlikely chance that it might work. Then I would compare it with the bit mapped graphics routines built into RXB and use the one that works best for me.

 

The more I think about it, I seem to remember that The Missing Link was built into XB 2.8 G.E.M.

[+Lee Stewart]

11 minutes ago, senior_falcon said:

That was it, it was called The Missing Link.

 

Yea but you have to run it from Assembly as all buffers in XB reside at VDP >0820 for XB program lines you can not move these variables used by XB:

 

Sure sounds like bit mapped graphics can only be used in an assembly program. I wonder if the author knew about the memory areas identified in post #39. Probably not. It sounds like this program is just a bunch of extravagant claims that cannot possibly work.

Still, if I wanted to use bit mapped graphics with XB, I guess I would try out The Missing Link on the unlikely chance that it might work. Then I would compare it with the bit mapped graphics routines built into RXB and use the one that works best for me.

 

The more I think about it, I seem to remember that The Missing Link was built into XB 2.8 G.E.M.

 

Get your tongue out of your cheek, Harry! 

 

...lee

[RXB]

1 hour ago, senior_falcon said:

That was it, it was called The Missing Link.

 

Yea but you have to run it from Assembly as all buffers in XB reside at VDP >0820 for XB program lines you can not move these variables used by XB:

 

Sure sounds like bit mapped graphics can only be used in an assembly program. I wonder if the author knew about the memory areas identified in post #39. Probably not. It sounds like this program is just a bunch of extravagant claims that cannot possibly work.

Still, if I wanted to use bit mapped graphics with XB, I guess I would try out The Missing Link on the unlikely chance that it might work. Then I would compare it with the bit mapped graphics routines built into RXB and use the one that works best for me.

 

The more I think about it, I seem to remember that The Missing Link was built into XB 2.8 G.E.M.

 

If you would work with me instead of against it would help, I just stated facts so you turned it into a contest.

What I can do you can not is modify the base you are using, you are a really good programmer but you never fix the base just attach stuff to it.

 

Funny story my Grandfather was out in garage working on installing swinging cup holders to his hand built 22 foot wooden boat for Grandma.

While installing them he muttered: "All the crap she buys I attach to my boat I am going to push it out and watch her sink in it!"

 

[Jeff White]

On 9/1/2021 at 5:14 PM, RedBaron said:

If anyone is interested.  I created an Extended Basic 40 column program that shows how the 40 column characters are made.  I have been using the Classic 99 program to go into Extended Basic and wrote a small program then save it to DSK1.  I am not sure how I can share this with anyone that would like to have it.  If someone would like to see it I could use a little help with how to post the code here.  I will give it a try myself and hope that this program is posted correctly.  Thank You.

 

40COLDEF 6.38 kB · 4 downloads

Is the pissing match over Rich and Harry?  I am afraid not.

 

Thanks for your contribution, RedBaron!

[RXB]

51 minutes ago, Jeff White said:

Is the pissing match over Rich and Harry?  I am afraid not.

 

Thanks for your contribution, RedBaron!

I have used your XB 40 column program before it is a great program and TML and others like STAR too.

 

And there was no pissing match I just pointed out facts as they are and got this back.

 

Did I say anything untrue? Did Harry?

 

My approach is to modify the base, everyone else adds CALL LINKs,

so like I said helping me would help everyone,

as I share my source openly, do you guys?

[+TheBF]

16 hours ago, RXB said:

I share my source openly, do you guys?

I do but nobody knows what the hell it means.   (with a few notable exceptions)

: AMAZING_ROUTINE    OVER + SWAP ; 

 

To give credit to the assemblage of people here, the number of innovations for our old computer is remarkable to me; RXB being one of many.

Everyone should be very proud of their contributions.

 

On a train.. leaving Toronto at 100Km/Hr (with a Montreal IPA)  

[+retroclouds]

On 9/3/2021 at 2:37 AM, RXB said:

 

so like I said helping me would help everyone,

as I share my source openly, do you guys?

 

Rich has a point there. Myself I find it very important to release the source code.

It’s the only way (except going the reverse engineering route) that you can fix bugs and make enhancements to software over a long time period. With that I mean over several decades, and that’s not so unrealistic considering we’re still dealing with the TI-99/4a.

 

On a sidenote, in my professional career I had to take care of the closed-source, commerical version of an open source software.

It’s a very complex software and for several reasons I can’t detail here, it did make sense to use the commercial version.

Major backdraw was we had no access to the source code. We just had the binaries to run.

As the years progressed we got a lot better at knowing the internals by comparing behaviour with the open source version.

Then it got redicilous because of complex license mgt software to install required to run the software.

Also bugfixes and small enhancements had to be paid, for stuff that would take only few code changes in the open source version.

 

Long story short, without access to the open source version, we would never have had the chance to get to know enough of the internals. So in the end we felt confident enough to switch to the open source version.

 

Edited September 4, 2021 by retroclouds