RXB Posted June 26, 2013 Share Posted June 26, 2013 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. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 27, 2013 Share Posted June 27, 2013 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 Quote Link to comment Share on other sites More sharing options...
RXB Posted June 27, 2013 Share Posted June 27, 2013 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. Quote Link to comment Share on other sites More sharing options...
Willsy Posted June 27, 2013 Author Share Posted June 27, 2013 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. Quote Link to comment Share on other sites More sharing options...
slinkeey Posted June 27, 2013 Share Posted June 27, 2013 (edited) 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 June 27, 2013 by slinkeey Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 27, 2013 Share Posted June 27, 2013 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. ... 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 1 Quote Link to comment Share on other sites More sharing options...
Willsy Posted June 27, 2013 Author Share Posted June 27, 2013 ...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. Quote Link to comment Share on other sites More sharing options...
matthew180 Posted June 27, 2013 Share Posted June 27, 2013 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. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted June 27, 2013 Share Posted June 27, 2013 Essentially, you can consider the GPL interpreter as an 8-bit virtual machine, and GPL is its machine language. Quote Link to comment Share on other sites More sharing options...
Tursi Posted June 27, 2013 Share Posted June 27, 2013 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. Quote Link to comment Share on other sites More sharing options...
RXB Posted June 27, 2013 Share Posted June 27, 2013 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. Quote Link to comment Share on other sites More sharing options...
RXB Posted June 27, 2013 Share Posted June 27, 2013 (edited) 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 June 27, 2013 by RXB Quote Link to comment Share on other sites More sharing options...
Tursi Posted June 27, 2013 Share Posted June 27, 2013 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. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted June 27, 2013 Share Posted June 27, 2013 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. Quote Link to comment Share on other sites More sharing options...
RXB Posted June 27, 2013 Share Posted June 27, 2013 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. Quote Link to comment Share on other sites More sharing options...
Tursi Posted June 27, 2013 Share Posted June 27, 2013 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! Quote Link to comment Share on other sites More sharing options...
RXB Posted June 28, 2013 Share Posted June 28, 2013 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? Quote Link to comment Share on other sites More sharing options...
marc.hull Posted June 28, 2013 Share Posted June 28, 2013 Can you actually communicate to the internal CPU in the F18 from the TI ? Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted June 28, 2013 Share Posted June 28, 2013 (edited) 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 June 28, 2013 by Kevan Quote Link to comment Share on other sites More sharing options...
Tursi Posted June 28, 2013 Share Posted June 28, 2013 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. Quote Link to comment Share on other sites More sharing options...
RXB Posted June 28, 2013 Share Posted June 28, 2013 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?" Quote Link to comment Share on other sites More sharing options...
Opry99er Posted June 28, 2013 Share Posted June 28, 2013 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? Quote Link to comment Share on other sites More sharing options...
+mizapf Posted June 28, 2013 Share Posted June 28, 2013 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. Quote Link to comment Share on other sites More sharing options...
RXB Posted June 28, 2013 Share Posted June 28, 2013 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?) Quote Link to comment Share on other sites More sharing options...
RXB Posted June 28, 2013 Share Posted June 28, 2013 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. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.