Jump to content


+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

  • Days Won


retroclouds last won the day on November 16 2015

retroclouds had the most liked content!

Community Reputation

1,332 Excellent

1 Follower

About retroclouds

  • Rank
    River Patroller
  • Birthday 01/05/1973

Contact / Social Media

Profile Information

  • Gender
  • Location

Recent Profile Visitors

21,233 profile views
  1. Yes I can confirm its faster with SAMS. I guess roundabout 0.3 seconds
  2. Here’s an idea that grabbed my mind and just doesn’t let go, so I need to write about it. I’m playing with the idea of creating a session manager for TI Basic (and possible Extended Basic) It’s a spin-off of the TI Basic integration work I’m doing with Stevie and thought it’s better to discuss in a separate thread. So what is this about? In Stevie I’m now able to jump into TI Basic with a single keypress, do program stuff and return to Stevie with FCTN-9. I can then repeat jumping back and forth, all while the TI Basic program, screen layout and colors is all still there. That is nothing so special, but I’m happy to get it working nonetheless. It’s inspired by the work done by @Tursi with his TI Basic cartridge creator and classic99 functionality. With the difference being that this time it’s all handled on the TI-99/4a itself. The way it works is by setting up a ISR routine before jumping into TI Basic. The ISR then calls the necessary functions to copy VDP memory and scratchpad to SAMS ram. Now here is the nice thing, with SAMS you have lots of memory. This is where I got the idea of a session manager for basic. Some of the functionality I can think of: Have multiple TI Basic/Extended Basic sessions Switch between sessions by using keyboard combination Dump and restore sessions on a fast storage device (e.g. TIPI, HDR), aka “snapshots” Periodically switch between sessions, even while the TI basic program is running (so you get a “faked” multitasking) Exchange data between sessions (not sure how that would work, need to give it some more thoughts) Give basic some kind of API to query and manipulate session state, e.g. set session title, periodically take snapshots by having a corresponding TI basic command => 100 CALL SNAPSHOT(“TIPI.SNAP….” ) Possibility to use the load interrupt to restore a session if it got stuck (not sure about this one, need to give more thoughts). Is anything of the above useful in any form? Probably not. But I think it’s a kinda cool idea I’m going to further explore. Will see what comes out of it. Wish me luck 😀
  3. Quick question on that. Do we have sample code showing how to use the scanline handler. I guess you basically load a short program on the F18A GPU and then set the start address in one of the VDP registers?
  4. That is a great idea I want to take a further look at. Thanks for pointing that out.
  5. Briefly thought about that. Also thought about using the F18a’s 2nd nametable to overlay on top of lines 25-30. Not sure if that would be even possible.
  6. I am. The way to distribute my software is via the FinalGrom. The fact that I have a GRAM kracker and with that the possibility to override the GROMs doesn’t help me. There are sufficient FinalGROMs out there and they are still available. Something not to be said about the GRAM kracker for example. Having said that, with the strangecart on the horizon it may become a future option again. But it’s not there (yet).
  7. To be honest, I don’t eather. But I see the ISR as a vehicle to manipulate VDP and scratchpad at the right moment so that the basic interpreter does stuff in a slightly different way. Not sure if this is even going to work, but that’s part of the fun.
  8. Thanks for pointing that out. I actually have a copy of TI INTERN at home. Didn’t think about that.
  9. As far as I know you cannot override ROM0,GROM1,GROM2 with the final grom cartridge. So I guess that would be out of the question and only leaves the ISR route. Only other possibility I can think of is introducing a new call in TI Basic that does the necessary setup. Guess that won’t fly because setup of VDP memory would be a one time thing.
  10. What I have in mind is the F18a 30 rows mode of 32 characters. TI Basic works great that way and screen output is as one might expect. The only issue is that by using 30 rows, the crunch buffer becomes visible on screen. So putting anything in that screen area gets overwritten. Probably could get away with the lines 28-30, depending on how long the line is that’s being crunched. From a technical perspective what I like about TI Basic is that everything is in VDP. Yes, it’s slow but cool nonetheless. So when thinking more about it, VDP space for the SIT should not be an issue. 24x40 = 960 30x32 = 960
  11. ** This question is about the crunch buffer in TI Basic, not the crunch buffer in Extended Basic ** ok, so I have been doing some experiments with TI Basic lately. For one of the tests I'm doing I am using the F18a with 30 rows mode. What I would like to do is add some information on the rows 25-30. The thing is that the VDP memory for that area is "blocked" by the TI Basic crunch buffer that starts at VDP >320 So here are my questions: Is it possible to move the TI Basic crunch buffer to another location in VDP memory? I presume it's hardcoded in the TI Basic interpreter in GPL. Was thinking about using a ISR routine in assembly routine that "kicks-in" and changes addresses (GPL registers, addresses) in a transparent way. Considering that TI Basic is so slow I might actually get away with it Any ideas on this one? Is the TI Basic disassembly available somewhere? I'm aware of TI XB disassembly, but not TI Basic itself. Actually I start liking TI Basic much. Yes it's slow, but I'd like to learn a lot more about its internals before addressing TI Extended Basic.
  12. Stuff on ebay is going crazy. I’ve seen a single, used TI-99/4a console in good state being offered for 800 EUR. That is just plain nuts. There was nothing in there that made the offer special. Well except for the price maybe.
  13. RMC are planning on doing a MISTER console run in the near future. I might consider getting one.
  14. yes, my spectra2 library only uses a stack. It was originally implemented for doing arcade games with scratchpad memory only. It was at the core of the ROM version of Pitfall. Since then I kept the habit of using a stack, also in my Stevie editor (also has spectra2 at its core). That’s why I think it would be a good match for the TMS99105. Having said that, would like to change my design for using multiple stacks. A return stack and a value stack. As it is now, they are combined in a single stack. Think that the advantage of having an additional return stack is that it would be more stable if you mess up, and it’s easier to keep track of your call chain. Well at least that’s what I noticed with my trampoline function (that one has a separate stack for keeping track of jumps between banks). Have been holding back on that redesign, because I have thousands of lines of code to deal with and it’s already stable as it stands now.
  15. So I have been playing with TI Basic integration in Stevie. Really think that TI Basic needs some love, and it's fun to mess with. Not sure where this is heading to, but I'd like to make a good TI Basic integration. That means that I can jump from Stevie to TI Basic while retaining both the Stevie editor buffer as well as the TI Basic environment. Part 1 (keeping the Stevie editor buffer) is in a working state now. Let's see how far I get with part 2. Anyway, here's a short video: js99er-20210920201435.webm
  • Create New...