Jump to content


+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by retroclouds

  1. 20 hours ago, Lee Stewart said:


    The E/A cartridge adds function CALLs, INIT, LOAD, LINK, PEEK, PEEKV, POKEV, CHARPAT and the ability to write your own routines. 


    The TE2 cartridge adds speech enhancements. I don’t know if it adds more.




    Can you give some details on “… and the ability to write your own routines” 


    Do you mean the def keyword? sub and subend are extended basic only if I’m not mistaking

  2. 44 minutes ago, Retrospect said:

    I've had a dabble with TI Basic and I found it okay for making games with so long as they are games your nan can play whilst listening to Classic-FM.


     The only technical benefit that I can think of is if you're using a stock console with 16K, you actually get a little bit more memory with TI Basic than you would with extended basic ... but at the end of the day when you're faffing around trying to write a routine that does DISPLAY AT using HCHAR and SEG$ it wouldn't make much difference then.


    Oh and the randomizers and mathematical stuff all work faster in TI Basic than they do in standard XB .  But as soon as you start printing the results , again, the execution of that is slower in TI Basic.


    Thanks, that all makes a lot of sense. DISPLAY AT and ACCEPT AT would be really great to have.

    Oddly, there is the DISPLAY function but I think it’s just an alias for PRINT. Would need to check if even the same token is used.

    Never tried to compare DISPLAY with PRINT. The manual does state that DISPLAY is only for screen output, so theoretically it could be a bit faster as file output stuff is not needed.


    Wasn’t there a command module that had some TI basic extensions as well?

    Can’t recall if it’s one of those funky educational cartridges or some kind of business/accounting cartridge.

  3. Give TI Basic some love…


    While working on integrating Stevie with TI Basic, I started appreciating TI Basic a lot.

    Back in the days I had Extended Basic so didn’t care about TI Basic much.

    Although the very first baby steps I did was in TI Basic, because I only got the TI Extended Basic module a few months later.


    Anyway, we all know how much powerfull TI Extended Basic is and that it has a lot of advantages over TI Basic.


    However, in this topic I ask you:


    1) What are the (technical) benefits of using TI Basic compared to Extended Basic?

    2) What are the most critical features missing in TI Basic?


    Reason for asking is because I’m working on improving the TI Basic experience in combination with Stevie (full-screen editor)


    As far as (2) is concerned, I’ll kick it off with: peek, poke (load), peekv, pokev, load, hex

  4. 3 hours ago, Vorticon said:

    Awesome work! Can you paste a Basic listing from Stevie into TI Basic?

    Thanks. Not at this time. Have been thinking if there is a way to accomplish that.

    One way would be to have the ISR inject the TI Basic statements. Not sure if that would be a good solution. 

    Can imagine it might be too slow. 


    Another approach could be a tokenizer that converts the TI Basic text statements into tokens and saves that to disk.

    That would require you to OLD from disk quite often when jumping back and forth between the editor and TI Basic.

    A third option could be some assembly language thatpokes the tokens into VDP memory before jumping into TI Basic.


    • Like 1

  5. Thanks for the update.


    One more question, with the possibility to override the GROMS 0-2, would it be possible to use the strange cart to drive a usb keyboard instead of the built-in TI-99/4a keyboard?
    I suppose it is not possible to override the system ROMS where KSCAN resides, but if the GPL interpreter is patched to not use the KSCAN.


    Would be kinda cool to have the strangecart as a "plug-and-play" solution for running a USB keyboard. Not sure if it would work with all software as that would really require KSCAN to be modified.

  6. 1 hour ago, Asmusr said:

    @retroclouds It's a brilliant demo, but what's the reason you didn't use bitmap mode? I believe it would have been a lot simpler to draw the shots if you weren't limited to 256 characters, and maybe you could have drawn more of the player ship as characters?




    The simple reason is that back then I didn’t know enough about bitmap mode to seriously consider implementing Time Pilot using it. Best approach would probably have been to do more proof-of-concept things before starting the actual implementation, but yeah I was kinda pleased how far I got before I lost interest.


    I’m sure that with the 9918VDP a real good conversion of the Time Pilot arcade game is possible on the TI-99/4a.

    Heck, with your skills and the experience you gained with your previous Ti-99/4a games I can see an almost arcade perfect Time Pilot.

    • Like 1

  7. 9 hours ago, whoami999ster said:

    Hello Retroclouds 

    guess whos back :)


    sorry for disturbing you again , I'm trying to evolve your demo in XB256 ... I'm fine with the movement of the fighter but I'm struggling with fire ... how did you implement it? I know that probably you forge everything but even some hits are welcome

    Just to explain my issue :

    1. how did you managed the 3 bullet barrage vs. single bullet 

    2. how did you managed the bullet sprite deletion

    3. how did you manage more than 4 sprite on the same row !!!!!!!! I getting crazy


    consider I'm developing in EXT BASIC and not in assembler  so just the theory on how did you implement such effect would help


    Thank a lot in advance for your help 





    oh yes, that was a long time ago, I think about 10 years or more.

    Even if you are not into assembly language I suggest you take a look at the code. 

    Tried my best to document the code on to what I was doing. 


    Anyway, the “secret” is that the bullets are not sprites. They are just plain characters that get redefined on the fly.

    Basically there is a region in RAM where I draw the bullets and this gets copied to VDP memory. 

    Repeat this process multiple times per second putting the pixels on a different Y,X coordinate and you get the illusion the bullets are moving.





    • Like 1

  8. 4 hours ago, Vorticon said:

    Sounds awesome. The only issue I foresee with using the disk as a clipboard is cluttering of the directory, unless the clipboard file is automatically deleted upon exit from Stevie. The main advantage however is that clipboard size is limited by the size of the disk, which could be quite large if a TIPI or hard disk folder is used, and you preserve the precious SAMS space for the text being edited. I assume some configuration of the target clipboard disk will be available?

    Yes, there will be a configuration option for setting the device/filename of the clipboard(s).

    • Like 2

  9. Watched the strangecart videos again. Really cool. 

    Do you have plans to do a run of assembled strangecart boards in the future? And if yes, when?


    Also very much like the TI Basic acceleration. How complete is it? Do you also have file IO support from a TI Basic program?

  10. On 11/8/2021 at 2:23 PM, TheBF said:

    That's the approach I took and SAMS made that quite simple.


    On 11/8/2021 at 1:06 PM, Vorticon said:

    What about just a clipboard space that survives between files and probably resident in SAMS? One could just block select the appropriate sections from a file, close it, open another file and drop the selection there.


    I’m going to do some tests in the next days. First thing I want to try is to re-use the functionality that is already in place and bind it to some shortcuts. This is what I have in mind; a clipboard file.


    You’r editing a file, mark a block and press a shortcut. The block is automatically saved to a file DSKx.CLIP

    Load the next file and press a shortcut, the DSKx.CLIP file is automatically inserted at the current line position.


    The cool thing about the clipboard file is TI basic integration.

    You could jump into TI-Basic, run a program that opens the DV80 clipboard file, does its magic and return to Stevie.

    Press the clipboard insert shortcut, and there you have it. Content is in the editor.

    I have a small disk catalog program in TI Basic I want to modify so that it writes to the clipboard file.


    The clip device/file should be configurable in some way (wasn’t there a clipboard device in classic99? have to check. Stevie does not fully run in classic99 yet, working on that too).




    • Like 4

  11. I’m considering getting a DREM 3 and connecting it to my TI-99/4a PEB.

    Main reason is I want to use it to emulate a HDD. I have a shift 838 IDE card that I want to use it with.


    Is that supported? I’m currently using the IDE with an old seagate drive. But the drive is starting to fail and is not reliable (and it’s also very loud). 

    Can I use a DREM with a Geneve as well? And if yes what controller is required for this to work.


  12. 5 hours ago, InfiniteTape said:

    Well, that's a test, I suppose. :)



    Looks great. What virtualization software are you using on the M1? Parallels Desktop?

    Also did you have to buy the Windows 11 ARM edition or is it possible to test without license key?

    have a M1 macbook myself and very much like the idea running classic99 on it.

  13. 6 hours ago, Vorticon said:

    What about just a clipboard space that survives between files and probably resident in SAMS? One could just block select the appropriate sections from a file, close it, open another file and drop the selection there.

    I’ll consider and do some tests.

    • Thanks 1

  14. 12 hours ago, Vorticon said:

    My vision is to be able to move portions of a file into another file. TI Writer/program editor incidentally has a facility to do that, something I used extensively in the past while working on a massive project (SkyChart).

    How is this useful? I can keep a large file with different assembly routines for various things like setting up the bitmap screen, redefining fonts, drawing lines, etc..., and then be able to pick one or more routine, copy them into the clipboard, open another file and insert the routines there.

    Being able to insert an entire file is great but it forces you to have each routine in a separate file which can be conducive to clutter.

    Again, this is just a one person feature wish :)


    I see 2 possible ways to handle this.


    1. Implement multi-file editing capability. I originally planned to have up to 10 editor buffers (accessible via shortcuts ctrl-0 to ctrl-9). In addition to that some kind of clipboard is needed to allow copying/moving file snippets accross editor buffers.


    2. Keep Stevie a single-file editor but implement a proper file picker with preview functionality. That way snippets can be inserted without too much hassle.


    hmm… knowing myself I probably will end up with a combination of 1 and 2 🙂


  15. 3 minutes ago, jedimatt42 said:

    That page also exceeds my 1meg SAMS... so a quick out of memory check stops it from overrunning... so, with that I've successfully loaded over 10000 lines from one page. You'll get bored before that happens... it is substantially faster now, but not 10000 lines fast.. 


    I think it's about time we get bigger SAMS cards.😆

    I've been approaching the 1MB sams limit myself (while testing with big files in Stevie) 

    • Like 1
    • Haha 1

  16. On 10/4/2021 at 5:05 PM, Vorticon said:

    One request if at all feasible:

    When a block is selected, could it be stored in a "clipboard" area in SAMS then copied back into a different file? This would be tremendously helpful if one keeps commonly used routines in a separate file.

    @Vorticon could you give some details on how your workflow looks like?

    In Stevie 1.2C (not released yet) I have the possibility to insert a file at the current line. Would that fit your needs?

    Note that the possibility to save a marked block to file is already present in the 1.1X version. 


    I have some more stuff to work on before I release Stevie 1.2, but this is what is now in place:


    1. Possibility to insert file at current line in file.

    2. Introduced keyboard shortcuts to move cursor to top of screen and bottom of screen. For this to work, I had to rearrange keyboard shortcuts again. This is the combination that works on both the TI-99/4a and in Google Chrome (js99er). (Getting keys to be accepted in a browser is not that trivial, as some keys can’t be passed to js99er. They are intercepted by the browser itself to do actions like open a new browser window, new tab, etc.).


    These are the shortcuts in place now:

    • ctrl-a Mark a block (shortcut moved from ctrl-v)
    • ctrl-v Move to top of file
    • ctrl-b Move to bottom of file
    • fctn-v Move to top of screen
    • fctn-b Move to bottom of screen

    3. Redesigned help screen for better overview. This will be further enhanced in a future version


    I’ll do some more bugfixing before I release 1.2* to the public.


    As always you can track on what I’m working on by looking at the issue tracker in GitHub.



    • Like 4
  • Create New...