Jump to content
Willsy

Random F18A questions

Recommended Posts

It's a GROM DSR.. TI BASIC, Editor/Assembler... anything written in GPL can usually pull DSRs from both ROM and GROM. Most assembly language programs only check ROM DSRs, though.

 

You can't use ROM DSRs on the cartridge port, unfortunately.

 

Yea this has been my complaint about Assembly access to DSR's as MIller Graphics has a DSR that finds the same ones as XB or BASIC or EA Cart, but Assembly people like Bruce Harrison never used the Miller Graphics one.

Utill I called him and explained several times why it was better then the normal one he used that would only work on >4000 space alone.

After that he started many programs examples on using GPLDSR LINKS.

Share this post


Link to post
Share on other sites

Yea this has been my complaint about Assembly access to DSR's as MIller Graphics has a DSR that finds the same ones as XB or BASIC or EA Cart, but Assembly people like Bruce Harrison never used the Miller Graphics one.

Utill I called him and explained several times why it was better then the normal one he used that would only work on >4000 space alone.

After that he started many programs examples on using GPLDSR LINKS.

 

The problem with the GPL DSRLNK is that the pointers are different and it returns to GPL. As to XB, EA Cart, TIForth and, now, fbForth, their DSRLNKs can all be patched or rewritten because they reside in low memory expansion. TurboForth's is in ROM, but changeable if @Willsy were so inclined and can get a little room in ROM space. The only one where I think we're basically screwed is TI Basic.

 

...lee

Share this post


Link to post
Share on other sites

The problem with the GPL DSRLNK is that the pointers are different and it returns to GPL. As to XB, EA Cart, TIForth and, now, fbForth, their DSRLNKs can all be patched or rewritten because they reside in low memory expansion. TurboForth's is in ROM, but changeable if @Willsy were so inclined and can get a little room in ROM space. The only one where I think we're basically screwed is TI Basic.

 

...lee

 

True but for Assembly you get a crippled version that ignores most of the DSR's the TI99/4A uses.

Miller Graphics showed how to do this without a problem, but again ignored.

Share this post


Link to post
Share on other sites

I think Rich is refferring to the July 1986 edition of The Smart Programmer, which does indeed publish a very neat DSRLNK that actually uses the DSRLNK in GROM 0. It's assembly language code, and presumably (I haven't studied it yet) consists of mostly trampoline code to cleanly get in/out of GPL.

 

Here it is below. I'm publishing it as screen shots, as the PDF is too large to upload to Atariage. Nice tip, Rich. :thumbsup:

 

post-24932-0-86730300-1372321813_thumb.png

post-24932-0-75603500-1372321828_thumb.png

post-24932-0-55768600-1372321840_thumb.png

post-24932-0-04029700-1372322120_thumb.png

Share this post


Link to post
Share on other sites

True but for Assembly you get a crippled version that ignores most of the DSR's the TI99/4A uses.

Miller Graphics showed how to do this without a problem, but again ignored.

 

Doesn't GPL eventually end up being Assembly? So anything done in GPL can be done in Assembly, right?

Edited by slinkeey

Share this post


Link to post
Share on other sites

I think Rich is referring to the July 1986 edition of The Smart Programmer, which does indeed publish a very neat DSRLNK that actually uses the DSRLNK in GROM 0. It's assembly language code, and presumably (I haven't studied it yet) consists of mostly trampoline code to cleanly get in/out of GPL.

 

Here it is below. I'm publishing it as screen shots, as the PDF is too large to upload to Atariage. Nice tip, Rich. :thumbsup:

 

...

 

I transcribed MG's GPLLNK and DSRLNK awhile back. It is attached. That could probably be patched to handle DSRs in other locations by branching to those DSRs directly; but, I don't think the GPL DSRLNK will handle DSRs anywhere else but 4000h space.and the additional console space for CS1 and CS2.

 

...lee

 

UniversalGPLLNK_DSRLNK.txt

  • Like 1

Share this post


Link to post
Share on other sites

...but, I don't think the GPL DSRLNK will handle DSRs anywhere else but 4000h space.and the additional console space for CS1 and CS2.

 

That's what I thought. I thought the regime was quite well defined. All DSRs are at >4000 and are paged in via CRU. The exception are the cassette DSRs which are implemented in GPL.

 

Therefore, the F18 can't have it's own DSRs, and furthermore, a cartridge cannot provide DSRs either. The only option is external (loaded from disk etc) libraries/drivers.

Share this post


Link to post
Share on other sites

Doesn't GPL eventually end up being Assembly? So anything done in GPL can be done in Assembly, right?

 

I think Rich was referring to some routines that were written in assembly, and it is the way the routines are written that are limited. When you use assembly on the 99/4A you have complete access to all hardware. Yes, the GPL interpreter is written in assembly. The 99/4A can only execute 9900 machine code. Anything else is an abstraction layer.

Share this post


Link to post
Share on other sites

Essentially, you can consider the GPL interpreter as an 8-bit virtual machine, and GPL is its machine language.

Share this post


Link to post
Share on other sites
That's what I thought. I thought the regime was quite well defined. All DSRs are at >4000 and are paged in via CRU. The exception are the cassette DSRs which are implemented in GPL.

 

Therefore, the F18 can't have it's own DSRs, and furthermore, a cartridge cannot provide DSRs either. The only option is external (loaded from disk etc) libraries/drivers.

 

Cartridges can provide GPL DSRs, and the cassette DSRs are written in GPL. The GPL DSRLNK can find both types. But the only other GPL DSR I know of is the MiniMem's.

 

I think most people just decided that since with an Editor/Assembler or XB cartridge plugged in, the only available GPL DSR was cassette, and so it wasn't worth the extra code.

 

The conclusion is the same though. You need an external memory of some form to provide any kind of DSR for the F18A.

 

Share this post


Link to post
Share on other sites

Doesn't GPL eventually end up being Assembly? So anything done in GPL can be done in Assembly, right?

 

Yea but if you are using the Console OS ROM >0000 and GROM >0000it does not take 1 byte of code and would cut your DSR LINK size down and at the same time allow access to anything unlike the normal method.

Like CS1 or GROM DSRs are impossible to use. If you use the Miller Graphics GPLDSR you can access all the RXB DSR's too.

Like form any device prompt type EA and it goes to the RXB EA cart or type XB and it goes to XB or BASIC will go to TI BASIC.

Share this post


Link to post
Share on other sites

I think Rich was referring to some routines that were written in assembly, and it is the way the routines are written that are limited. When you use assembly on the 99/4A you have complete access to all hardware. Yes, the GPL interpreter is written in assembly. The 99/4A can only execute 9900 machine code. Anything else is an abstraction layer.

 

Sorry no, I am referring to the DSR LINK used normally by Assembly programmers that will not access anything but >4000 DSRs and ignores any others.

The Miller Graphics GPLDSR Link can access anything a Cart can access but from YOUR programs, just use the best DSR the Miller Graphics one.

 

By the way in a Micropendium is a version of the Miller Graphics DSR (GPLLINK) that is smaller and faster. Do not remember what issue.

Edited by RXB

Share this post


Link to post
Share on other sites
Sorry no, I am referring to the DSR LINK used normally by Assembly programmers that will not access anything but >4000 DSRs and ignores any others.

 

That's really TI's fault too, anyway, since the DSRLNK they released with Editor/Assembler behaves that way, and essentially set the standard.

Share this post


Link to post
Share on other sites

Sorry no, I am referring to the DSR LINK used normally by Assembly programmers that will not access anything but >4000 DSRs and ignores any others.

The Miller Graphics GPLDSR Link can access anything a Cart can access but from YOUR programs, just use the best DSR the Miller Graphics one.

 

By the way in a Micropendium is a version of the Miller Graphics DSR (GPLLINK) that is smaller and faster. Do not remember what issue.

Ahhh. A version of the Millers Graphics DSRLNK and GPLLNK might just be what I encountered in the Dinosaur disk loader. What is interesting is the secondary loader contains what seems to be the EA defacto DSRLNK code. Why Ken used two different routines is beyond me, since the standard DSRLNK will work within the XB environment with the proper setup. I may just finish my quick disassembly to look for anything 'suspicious'.

 

In general, TI's EA DSRLNK also provides the best compatibility with the Geneve. Unless a specific program requires GPL or accesses devices outside the x4000 peripheral card range, I would not recommend the GPL DSRLNK over the EA DSRLNK.

Share this post


Link to post
Share on other sites

That's really TI's fault too, anyway, since the DSRLNK they released with Editor/Assembler behaves that way, and essentially set the standard.

 

 

Well by that logic we should not be using the SAMS or PGRAM or Hard drives either. Nor the F18, I think you see my point.

As for the Geneve it uses a different Processor and is 8 bit so that is a whole other can of worms of a problem.

Share this post


Link to post
Share on other sites
Well by that logic we should not be using the SAMS or PGRAM or Hard drives either. Nor the F18, I think you see my point.

 

I see your point, but I disagree by technicality -- there was no SAMS, PGRAM, or hard drive when the Editor/Assembler package was released, but there /was/ GPL DSRs. My point is that TI chose to down-value them, your point is that TI didn't write code for hardware that didn't exist yet. ;) And that's where I'll leave that!

Share this post


Link to post
Share on other sites

I see your point, but I disagree by technicality -- there was no SAMS, PGRAM, or hard drive when the Editor/Assembler package was released, but there /was/ GPL DSRs. My point is that TI chose to down-value them, your point is that TI didn't write code for hardware that didn't exist yet. ;) And that's where I'll leave that!

 

Well not really, the Assembly Language guys just never talked to the GPL guys. You can see that is most of the Carts, they just sat in cubicles and did not talk much back and forth.

 

XB source is a perfect example of goofy code to do a MVUP or MVDN in VDP or RAM yet the GPL MOVE command does that at the same speed.

 

Superfluous coding from lack of communications.

(Example is the ROMs source code I had and you can see it in the GPL code of the XB module.)

 

I have tested it and the ROMs in XB have other code problems that show this as a fact. It took 1 hour to show a 40 second improvement.

 

That does not mean all standards are good one, it means just what became popular. Or should we all be driving the People car today?

Share this post


Link to post
Share on other sites

The conclusion is the same though. You need an external memory of some form to provide any kind of DSR for the F18A.

So, you are basically saying that, any Tom, Dick or Harry with a Super Cart, and a program that does not exist, could give us access to all the goodies locked up inside the F18A?

Sounds like a decent programmer could make some money with such a program.

Edited by Kevan

Share this post


Link to post
Share on other sites
So, you are basically saying that, any Tom, Dick or Harry with a Super Cart, and a program that does not exist, could give us access to all the goodies locked up inside the F18A?

 

Except for the "program that does not exist" part, no. A Super Cart (meaning an Editor/Assembler cartridge with RAM, in the traditional sense) can not load DSRs at all. The new cart that is being built (whatever it will be called) could in theory support a GROM DSR, but that's got fairly limited compatibility with assembly language software. So it's not a good choice either.

 

A ROM chip and a CRU select is the best option. Or it could be built into something that already has a programmable DSR, like the Horizon RAMDisk or the HDX.

Share this post


Link to post
Share on other sites

Sounds like Assembly is short sighted and limited for access of use. Which is what I have been saying all along.

 

I have DSR's in RXB that work fine if anyone would upgrade the 30 year old standard.

 

LOL reminds me of the Monk that asked the natives why they threw children into the volcano, his reply "We always have?"

Share this post


Link to post
Share on other sites

Would it not be fair to say that, since GPL is written in assembly, that it cannot exist without assembly? I mean, anything GPL can do, assembly must, by definition, be able to do those things.

 

GPL is a higher level language than assembly, that's all. It's certainly easier to clear the screen in BASIC than in assembly, but that doesn't make assembly "short sighted".... Am I wrong here?

Share this post


Link to post
Share on other sites

As for the Geneve it uses a different Processor and is 8 bit so that is a whole other can of worms of a problem.

 

It is not more 8 bit than the TI-99/4A itself, just the databus multiplexer is built into the CPU. TI did a lot of things the right way here.

Share this post


Link to post
Share on other sites

Would it not be fair to say that, since GPL is written in assembly, that it cannot exist without assembly? I mean, anything GPL can do, assembly must, by definition, be able to do those things.

 

GPL is a higher level language than assembly, that's all. It's certainly easier to clear the screen in BASIC than in assembly, but that doesn't make assembly "short sighted".... Am I wrong here?

 

I was talking about setting a standard like Assembly only access to devices.

If Assembly can not do it and yet everything is written using Assembly then how is it not short sighted to not have access to a device?

 

That is strange that the same computer language that is the base computer language can not access devices written with that computer language?

(Come on does that not even sound kinda stupid?)

Share this post


Link to post
Share on other sites

It is not more 8 bit than the TI-99/4A itself, just the databus multiplexer is built into the CPU. TI did a lot of things the right way here.

 

Yea it was a great idea, but to late for TI to survive.

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