majestyx

Just so that I am understanding this correctly, does this mean if I define a named subprogram in the first program segment, for example, named RSF(FRN,LRN), then it cannot be used/called in subsequent program segments? Or can it only be defined in the first program segment, but can be called in a later one? I ask because I am using one like this in my current project. I don't currently need to chain programs together for this one, but for future reference, I'd just like to know so that I can plan ahead. The reason I ask is that it's the core subprogram that I use for displaying the text from a "story" file. In fact it's the only subprogram in the entire program at all. It also doubles as a "PRESS ANY KEY TO CONTINUE" subroutine when passing in 2,1, or passing in 1,0 to also include a single-line scroll first. So if in a future program where I may need to chain multiple program segments, if I can't use e.g. CALL RSF(1,91) in later segment, then I'll need to keep the program contained to a single program segment or figure out a different way to approach programming it. 8000 SUB RSF(FRN,LRN) 8010 ROW=1 8020 IF FRN>LRN THEN GOSUB 8065 :: GOTO 8100 8030 LINPUT #1,REC FRN:A$ :: FRN=FRN+1 8040 CALL LINK("PRINT",24,1,A$):: CALL LINK("SCROLL") 8050 IF ROW=23 THEN GOSUB 8070 :: IF (FRN-LRN)<1 THEN ROW=0 ELSE CALL LINK("PRINT",24,1,"",40):: CALL LINK("SCROLL"):: GOTO 8100 8060 ROW=ROW+1 :: GOTO 8020 8065 IF LRN=0 THEN CALL LINK("SCROLL") 8070 CALL LINK("PRINTI",24,8,"PRESS ANY KEY TO CONTINUE",25) 8080 CALL KEY(0,K,S):: IF S<1 THEN 8080 8090 RETURN 8100 SUBEND At first I thought you meant that if subprograms are to be used, they must all be defined in the first program segment, but could still be called in later ones. In other words, I took it to mean that if you are going to use subprograms, make certain they are all defined in the first program segment due to prescan being eliminated (my lack of memory management understanding is tripping me up) since they cannot be defined using SUB in later segments. But after re-reading the manual and now your post above, it sounds more like subprograms can be defined & called in the first program segment only, but can no longer be called in later program segments, most likely because line numbers in later program segments may overwrite the subprogram line numbers. If you could please verify which is the case, I'd greatly appreciate it.

I too am up and running with the expected cyan background and black text. Thanks for all the new features and fonts. This will be a lot of fun to play with!

I had already tried shift-838 (should have mentioned that) which does nothing, unless it needs to be entered somewhere specifically. Same for shift 383. Any key or joystick movement starts the game. Pressing 5 (or 5 with any modifier key) during play returns to the startup screen. Pretty amazed at how well done this version is, based on my memory of the C64 version. The bonus counts down far too quickly, but otherwise, this is a really impressive conversion for the TI!

So does anyone have the manual? Also, what is the cheat code?

I feel like we are chasing ghosts here, as there doesn't seem to be much consistency in the results. I did no CALL LOADs, just the CALL PEEK & PRINT. Two samples using my 256 MB card (did it 5 times): 102, 150, 152,0,117,4,17,16 (the first time) 102, 150, 152,4,117,68,17,80 (every other time) Two samples using my 4 GB card (did it 5 times): 95, 198, 58, 119, 119, 0, 86, 223 (all but one time) 244, 0, 131,224,0,36,87,246 (this happened once & after getting the preceding values) I'm guessing that the above values could change if I tried it enough times. These results are all from cold starts using XB 2.8

This just keeps getting stranger. On a whim, I tried a different CF card - the one that came with it which is 256 MB as opposed to the one I've been using which is 4 GB. I get different values now of 17 and 80. I have no idea what this means, but the numbers stay consistent at least. When I use the 256 MB card, the numbers are 17 & 80. When using the 4 GB card, the numbers are 86 and 223. Since I have another 4 GB CF card available, I tried it as well. This time the numbers are 87 and 214. I reformatted this card, then used ti99dir 7.2a (I recalled that this was formatted with an earlier version of ti99dir) to make it CF7A+ usable. Now when I do the PEEKs, I get the same values as the other 4 GB card - 86 and 223. I repeated this once more and got the same numbers - 86 and 223. I can confirm I get these values whether using the FG99 for XB 2.8 and TI XB, or a real TI XB cart. Not sure if this makes things clearer or even more confusing.

Is yours working fine without having to enter the CALL LOAD lines? I'm wondering if it's an issue with either my system or my FinalGROM, based on Casey's post. I'm also using a nanoPEB so not sure if that has something to do with it. EDIT: I may have stumbled upon the answer. I disconnected my nanoPEB & tried running XB 2.8 from The FinalGROM. Works fine - cyan screen with black standard text. Of course, my nanoPEB also has the 32K in it so I am unable to run the other versions like T40XB. Casey (or anyone else) - could you verify your set up (PEB, nanoPEB, CF7+) and whether you are getting the same symptoms as I am? I'd greatly appreciate it and I'm sure Harry would too, as I don't want him going on a wild goose chase for something that may only be happening for me.

Can you please point me to this topic (or topics)? I've done a search to include finalgrom and supercart and get nothing that discusses in detail.

This relates to Insane Multitasker's topic on the Infocom interpreter. Is there an easy way to get The FinalGROM to act like a Supercart? I tried hex editing the E/A cart by placing placing R in the 4th byte for the first try (enable RAM), then X for the second try (enable both RAM and GRAM). Same result - the E/A cart loads, choose option 5, enter DSK1.SAMPLER1A . It starts to load, then dumps me back to the FG99 DEV menu, but the menu is not functional. In fact, if I press any keys on the keyboard, it beeps and eventually gives a long BEEEEEEEEP until I turn the system off due to it being locked up. So if there is a way to either create a Supercart image or get the E/A cart image to act like one, please let us know. Thanks~!

I still get the orange screen and the different font when using it in the FG99. Is this something that will be fixed in a future release, or is this just an oddity of using it with the FG99, since it doesn't happen in Classic99?

That works!

Now it loads but is really strange - I get an ugly orange screen with somewhat distorted text characters. First is just XB 2.8, second is T40XB which is a bit blurry.

Okay, but I don't read every topic and I don't see it listed as a subject. I thought since the usefulness of the Supercart is being debated, I would ask about it here because it seemed appropriate to the discussion of the cart. It appeared from the discussion in THIS topic that the Supercart MUST be used for those games. Now I know, so thanks for the confirmation. This is what made it so confusing: I'm like, wait, how can you use both the Supercart (which I've never had or used) AND the E/A cart? As I've mentioned in some of my other posts, still not THAT familiar with all the TI stuff that's happened between 1985 and around the time I joined AA. I appreciate the patience!

I have the latest firmware on my FinalGROM & it's not working. Also, if the ROMs were inverted, I think we wouldn't see any menu entries at all, but I'm no TI tech wizard. I just know the symptoms of when I tried (unknowingly) using inverted ROMs. All that would show up on the menu was TI BASIC. I don't know if I've ever seen a C file as large as this one, so perhaps that's the issue? Maybe Ralph B can shed some light on it.

I know this is getting away from the original topic, that being a poll, but does Classic99 emulate a Supercart in order to play the Infocom titles that need it (Leather Goddesses was mentioned, and I know that the Infocom Sampler states it needs it), or is that overcome by it being able to emulate SAMS, or perhaps some other method?

Just tried this myself and while the menu entries do show up, I cannot get any of the choices to load, including DM1000. They all lead to a blank cyan screen which locks up the computer so that FCTN-QUIT doesn't even work. Pressing reset on the FG99 brings me back to the TI title screen. Pressing any key shows the XB 2.8 menu choices, but once again, all choices lead to the blank cyan screen.

So far, I've only had luck with SanDisk CF cards. I have a Transcend that gets corrupted every time I try to use it with the nanoPEB, and the SD-to-CF card adapter I'm using also has had no success with the 2GB PNY SD cards I have, as well as an ancient Lexar 128MB card I used many years ago in an HP camera. Too bad it wasn't designed to use SD cards, although there may be a technical reason for that. The manual itself states this: Due to TI-99/4a’s bus timing, hard disks and some Compact Flash cards will not work. Generally, SanDisk and Kingston cards are reliable. I'm sure Greg tests his cards before shipping, so if you're having a problem sourcing one that works, sounds like he can help you out.

My constructive comments / questions on the documentation: Page 4 states More information on using RUN, RUNL1 and SAVEIV can be found in the section starting on page 26 entitled AUTOLOADING AND CHAINING PROGRAMS. Since the manual is only 12 pages, this actually starts on page 11. Regarding the new CALL RUN / RUNL1, it states that these are used to run XB256 programs. Is it safe to say this will also work to T40XB/T80XB/XB 2.8 programs too? Based on the discussion on pages 11 & 12, that would appear to be the case, but as Benny Hill once said - NEVER ASSUME! I am guessing that the XB256 naming may be left over from earlier versions of the documentation. On page 8, to be consistent with the documentation changes to CALL VPEEK & CALL VPOKE, this line: CALL GPEEK is now PEEKG would be clearer if it was CALL GPEEK is now CALL PEEKG On page 11, this is confusing: CALL SAVEIV(”DSKn.PROGNAME”) XB 2.8 G.E.M. has a subprogram that will to force XB to save a program of any length in IV254 format. In the immediate mode, with your program loaded, simply type:CALL LINK(“SAVEIV”,”DSKn.PROGNAME”) I'm guessing that it is indeed CALL SAVEIV, unless the CALL LINK also works. Also on page 11, just a typo where line 10 should be A$ instead of D$: 10 D$=”DSK1.PROGRAM” 20 CALL RUN(A$) THANK YOU SO MUCH for designing these incredible tools that make programming the TI so much easier and fun!

I was about to come here to mention the mismatch of the filenames of these two files. I also noticed that the XB27GEM_8.BIN file has an older date & time stamp (by 18 hours & 20 minutes) than the G file does. Can senior_falcon verify that this is the correct one to be using, or was it an earlier version that was still being used with 2.7?

For the Dumping feature that I see on the FG99 homepage, I am confused about how this is done, or maybe I'm expecting it to do something that it does not do. I read the description of this feature, but am just not getting how this works. Is there some way to take a snapshot of the game state of existing cartridges which is then overwritten to the .bin files on the SD card? Since the description mentions "To save the progress or high scores of games..." I take that to mean that one can "save" the progress of a game such as Parsec, where you may be having a great run & want to save the game state to come back to later. Or is this feature for future ROM images created specifically to use this feature? I don't understand how to trigger the dump while playing a game, if that is indeed what is being referenced.

Is there a cartridge image of this available for download? I'd like to finally mess around with it on my real TI with FinalGROM99. If you could provide a link to it here, I'd greatly appreciate it!

I don't want to assume anything so I just have to ask this: Will the compiler work with T40XB?

I still think it's relevant that the current Atari VCS still has no known developers for it, yet Atari is insisting it will be shipping in October to backers and before Christmas to retailers. As has been mentioned ad nauseam in this thread, there has been no real demonstration of what exactly this thing is going to do. Sure, they mention streaming (my Roku TV does this in 4K and cost me $10 more in August of 2019 than they are asking for the VCS now), playing classic Atari 2600 games (what platform can't these days? not to mention at least 10 different Flashbacks which look more similar to the original than what the new VCS does), &... umm... did we mention it kinda looks like the Atari VCS from the 70s, with an option for a woodgrain finish? Add to the failures that were the Atari Speakerhat and the Gameband - gee, what could possibly go wrong? I'm sure we would all LOVE for a developer to show us a demo of a game they are making, running on the actual hardware (I mean it has to exist in order to develop for it, right?) so we can at least verify that someone has even a prototype unit. But so far, nothing even close to this has happened, at least that I'm aware of.

Received an email about an hour ago from the "Atari VCS Team" with links to a Q&A (which has many of the same answers - a variant on "The Atari VCS is powered by an AMD Ryzen R1606G processor with Radeon “Vega” Graphics technology, which is a modern X86 PC processor.") https://medium.com/@atarivcs/atari-vcs-july-2020-q-a-with-coo-381f121f664c ...and a Developer Page: https://shop.atarivcs.com/developer Does anyone know who is actually developing anything for it? You'd think they'd be mentioning this & showing WIP of the exciting things you will be able to play this Christmas when your $400 finally pays off.

I check this particular forum almost exclusively to see if the new version is available yet, as well as to see if Rich's RXB 2020 is available. I'm anxiously waiting for the release of both, as they are the two development tools I am using on my latest two projects. Thanks for keeping us updated~!