Vorticon

Yes, I already do this to some extent (I have a main game master file, 3 subroutine files (and counting) and a data file). What I still don't understand from you is what do you do when a certain file refers to a subroutine in another file? How do you get it to compile independently in this situation? Another issue I have is when I need to hunt and fix bugs that span more than one file, which is a frequent occurrence with large programs, as this usually means opening a file, editing it, saving it, closing it, opening another file and repeat... And I'm not even mentioning the awkwardness of copying code from one file to another and the risk of running out of space in the target file... I guess this part of the charm (?) of retrocomputing, but sometimes a little less charm and a little more efficiency is helpful

I've had my SAMS card for a few years now, and I have yet to use it once, which is a shame. I'm pretty sure that my next game will make use of it in some form or another though, especially now that it's fully supported by Classic 99. As Marc mentioned earlier, you really need a nice application to jump start its use by the community.

Yes, I already do this to some extent (I have a main game master file, 3 subroutine files (and counting) and a data file). What I still don't understand from you is what do you do when a certain file refers to a subroutine in another file? How do you get it to compile independently in this situation?

What is the actual address @CLOCK is pointing to? It's a memory variable, nothing more. I use it for a variety of purposes in my CRPG for timing. Adamantyr I see. I guess I'll use the VDP interrupt timer then. Thanks Oh and one more thing: is there a more efficient way to restrict the numbers generated to a certain range of values other than doing straight comparisons?

What is the actual address @CLOCK is pointing to?

It looks like I may have to write my own AMS based text editor eventually... This GPL thing is really fascinating! Thanks for the demo's.

Thanks While I really don't understand the math behind your RND routine (I have to research this a bit), I do understand its structure. One question though: what address is @CLOCK referencing? Is it the screen time-out counter >83D6? Also, the EA manual mentions address >8378 in the CPU RAM PAD area as being the random number generator. What is this used for? Here's your routine for reference: LI R4,23729 MPY @>83C0,R4 AI R5,31871 MOV @CLOCK,R0 ANDI R0,>000F SRC R5,0 MOV R5,@>83C0

Hi. I need to generate random numbers between 1 and 6 for Ultimate Planet, and it struck me that I don't know how to do that with assembly! Could someone here be kind enough to point me in the right direction?

Thanks! This is very helpful.

I was eying the real game on Ebay a couple of days ago! And I distinctly remember thinking that it would be a good game to emulate With your permission, I wouldn't mind posting it on the Gameshelf site

That's the idea. One obvious application would be the ability to store large amounts of graphics data such as whole bitmap screens that will allow relatively smooth scrolling over large areas. I definitely would like my next wargame to have that kind of capability Another one is multimedia with possibly animation and music data (think SID card ) stored in the SAMS. Afterall, the bulk of current megabyte games is multimedia content...

Talk about a dilemma here! To be perfectly honest, it seems to me that GPL would be easier to master for someone who already knows AL than TF. However, the involved development cycle you mentioned is certainly a pain, possibly enough to offset the TF learning curve. Sooo, here's what I'm going to do: Get familiar with GPL while waiting for your TF book to come out, and THEN dive into TF

Point taken. Now the dreaded question: how does one mix GPL and assembly into a single program since GPL is interpreted and assembly is compiled? GPL is compiled and interpeted. When I compiled RXB or REA or any other cart it is a compiled program, but when I run it the OS interpetes the complied code and from there GPL can load Assembly and run it. Examples are CALL LOAD, CALL LINK and many other RXB routines. GRAMPACKER was a program that puts Assembly into GROMs and runs them. None of this stuff is hard to do or that complicated. When you do a CALL INIT from XB or BASIC using a EA cart you are loading Assembly from GPL. About 1/5th of all routines you run in XB are actually run from the GPL calling Assembly in the ROMs. Actually the main reason XB is so slow is the total lack of VDP memory and the insane number of times the Garbage collection is needed to clean up the mess. When you see XB pause for a second while using it, that is the Garbage collection trying to get more VDP memory that is used for Strings, numbers, Files, Variables, and copies of stuff. 16K is dinky really. OK I get it now. This certainly holds a lot of promise, at least for me. Thanks for the explanations

I must say I am intrigued. I think the GPL manual is going to be my bedtime reading for the next few days Given that it's so similar to AL, I should not have too much difficulty going through it quickly.

Point taken. Now the dreaded question: how does one mix GPL and assembly into a single program since GPL is interpreted and assembly is compiled?

1.4K??? That can't be right. Can you clarify this for me?

So what you are saying is that GPL on real hardware is the slowest of the available languages (I assume XB is even slower), yet the learning curve is likely as steep as assembly, and the main advantage would be potential use of additional memory in external modules. While this might be advantageous for a few very specialized applications, I'm not sure it's worth the effort for most programmers when they can get faster execution speed with assembly... Unix in a cart might be a great idea, although I wonder if it would run too slowly if written in GPL. Besides, Tursi has demonstrated a great little hack with Linux in a cart at last year's Faire

Actually there are many. FunnelWeb, FirstDraft and the failed Asgard app PRESS. Before my SCSI drive died I had a EA module one that used the AMS someone wrote and sent it to me. It may have been Richard Bell. There was also a TI Writer version too. Also never released but I was told a TI Artist version was being worked on using AMS. Pretty pointless now adays. Funnelweb? How do I configure it to recognize and use the SAMS card? My copy only sees 32K...

That link gives me an error when I click it. Worked for me. I just downloaded and printed the entire manual (>200 pages!) and I have been quickly scanning through it. It sounds to me that GPL is simply another form of assembly language, which then begs the question: what would the benefit be in using GPL versus standard AL? What am I missing here?

Please forgive my ignorance, as I may have missed a previous thread on this: Is this package essentially an enhanced assembler or is it for GPL programming only?

Hi. Is there a text editor out there that has support for the SAMS card? The EA editor or the PReditor both are severely limited in the length of source code you can have within a single file, and it would make my life a lot easier if I was allowed larger files...

Chapeau bas mon vieux! This is an outstanding achievement that will open new programming opportunities for our TI and will likely relegate XB and c99 to the dustbin of memory... I will be contacting Bob ASAP and put an order for a cart.

I'll email you a DSK version for use with MESS. Otherwise, you can easily convert it to V9T9 format (which is similar to MESS) using Fred Kaal's TIDir utility program.

One can only hope

I really hope you can do without the 8K RAM, because otherwise it's going to limit its playability on real hardware given that many of us do not have that cart... Any chance of a release by Faire time this year?