Stevie Development Thread

[+retroclouds]

Here's a rather long demo on some of the clipboard and TI Basic integration stuff I'm currently working on. 

Have some more debugging to do, but it's almost ready for release. Want to have a new release out before Xmas.

 

Edited November 25, 2021 by retroclouds
video was missing...

[+Vorticon]

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

[+retroclouds]

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.

 

[+retroclouds]

Multiple TI Basic sessions in Stevie 1.2M

 

[HOME AUTOMATION]

Smart! I likey.

[+retroclouds]

I'll be releasing Stevie 1.2Q in the next few days. This is the first release where there will be 2 separate cartridge ROM binaries:

• Stevie 1.2Q
  • Requires the F18a and runs in 30 rows 80 columns mode.
  • Uses sprites for cursor and ruler.
  • Runs on TI-99/4a with F18a VDP.
  • Runs on js99er emulator
     
• Stevie 1.2Q (24x80)
  • Requires the F18a and runs in 24 rows 80 columns mode.
  • No support for sprites. Cursor is character.
  • Runs on TI-99/4a with F18a VDP.
  • Runs on classic99 emulator

[+retroclouds]

I've released Stevie 1.2Q

 

 

[+retroclouds]

I've released Stevie 1.2S

 

Removed some delay loops and added a new feature. 

 

[+retroclouds]

Started working on Stevie 1.3

Focus is on platform integration and code refactoring.

I've got a couple of things I want to try out, like resume a Stevie session when the computer gets reset. 

[+retroclouds]

Here's an experiment I did, which will make the development experience on the TI-99/4a itself a bit easier.

This is in a very early stage and I basically reused the functionality I have in place for jumping into TI-Basic.

 

What I wanted to accomplish, is that when I for example jump from Stevie into TI Basic, I call an assemly language program and from there reset to the TI-99/4a Title screen by pressing FCTN-Q or using the reset button on the FinalGROM card.

In the TI selection screen I can then resume my previous Stevie session. That means the file I was editing is still there and I can continue working.

If you think about it, it's quite easy to do with SAMS, backdraw is that it only works with non-SAMS programs but for that it's really cool.

 

This is what I for example did on my real TI-99/4A machine:

 

1. Start Stevie

2. Load and edit a large file

3. Jump into TI-Basic while inside Stevie

4. In TI-Basic I do "call menu" which on my HRD4000B calls the menu program

5. In the menu program I run DM1000

6. Do some stuff in DM1000

7. Reset to the TI Title screen

8. On the cartridge selection screen I select "2 FOR RESUME SESSION"

9. I'm back in Stevie and my file (2) is still present in the editor and I can continue editing.

 

 

Well anyway, here's a recorded video that show a small demo in JS99er.

Obviously this will need a lot of polishing, but it is quite useful.

 

 

 

 

[Asmusr]

In 1.2S, with only 32K, I find that the first line you enter of a new file disappears. The same doesn't happen if you have SAMS enabled. Tested in https://js99er.net. where I added the latest version

 

Edited January 24, 2022 by Asmusr

[+retroclouds]

1 hour ago, Asmusr said:

In 1.2S, with only 32K, I find that the first line you enter of a new file disappears. The same doesn't happen if you have SAMS enabled. Tested in https://js99er.net. where I added the latest version

 

Thanks for the feedback. That reminds me I finally need to add a proper SAMS card detection routine.

https://github.com/MirrorPusher/Stevie/issues/51

 

Stevie requires a 1MB SAMS and the F18a GPU.

[+Lee Stewart]

7 hours ago, retroclouds said:

Thanks for the feedback. That reminds me I finally need to add a proper SAMS card detection routine.

https://github.com/MirrorPusher/Stevie/issues/51

 

Stevie requires a 1MB SAMS and the F18a GPU.

 

If you are looking for ways to detect a SAMS card and discover how much RAM is supported, you are welcome to use my fbForth startup code if it looks useful (CRU is R12). ?

Spoiler

;[*++ Check for presence of SAMS card.
***++ SAMS flag will be set to highest available bank#.

* Testing will start with 32 MiB SAMS and will proceed by halving the range
* until 128 KiB is reached. 128 KiB is assumed to be the lowest viable SAMS.
* The actual bank tested will be >000E higher than the lowest bank in the
* upper half of the range.
*
* To test, Map >000E + lowest bank in upper half of SAMS range to >E000. For
* 32 MiB, this is >1000 + >000E. We initially store >0010 (LSB,MSB) in
* R3 to allow a circular shift each round before MOVing to R0 to then add
* >0E00 (LSB,MSB) for the next test. If the test fails at >001E, the last
* viable SAMS (128 KiB), R3 will go to >0800, at which point the loop
* exits, setting R3 to 0, effectively reporting "no SAMS".
*
* Set up SAMS check.
*
       LI   R2,>994A      `check-value
       MOV  R2,@>E000      check-value to check-location
       ; Classic99 emulator can do 32 MiB
       LI   R3,>0010       lowest bank in upper half of SAMS to R3 (LSB,MSB)
       LI   CRU,>1E00      CRU address of SAMS
*
*
SAMS_CHECK: 
       MOV  R3,R0          lowest bank in upper half of SAMS range
       AI   R0,>0E00       get >000E banks higher
       SBO  0              enable SAMS registers
       MOV  R0,@>401C      poke SAMS register for >E000
       SBZ  0              disable SAMS registers
       C    @>E000,R2      compare possible copy with test value
       JNE  SAMS_EXIT      exit if SAMS mapped, viz., no match
       SRC  R3,1           shift right circularly by ^2 to next lower SAMS
       CI   R3,>0800       too far?
       JNE  SAMS_CHECK     try half as much if not >0008 (LSB,MSB)
       CLR  R3             no-SAMS..set flag to 0
       JMP  SAMS_EXIT0     we're outta here
SAMS_EXIT:
       SWPB R3             restore bank#
       SLA  R3,1           double value (highest bank# + 1)
       DEC  R3             decrement to highest bank#
SAMS_EXIT0:
       MOV  R3,@ARG        save SAMS flag to ARG (hoping it survives!)
       JEQ  FRTHCP         go to copying Forth inner interpreter if no SAMS
*                          ...no need to restore anything if no SAMS
*
* Remap default bank >0E to >E000.
* CRU should still have correct value.
*
       LI   R0,>0E00       load SAMS bank >000E
       SBO  0              enable SAMS registers
       MOV  R0,@>401C      poke SAMS register for >E000
       SBZ  0              disable SAMS registers
;]*

 

 

...lee

[+retroclouds]

7 hours ago, Lee Stewart said:

 

If you are looking for ways to detect a SAMS card and discover how much RAM is supported, you are welcome to use my fbForth startup code if it looks useful (CRU is R12). ?

  Hide contents

;[*++ Check for presence of SAMS card.
***++ SAMS flag will be set to highest available bank#.

* Testing will start with 32 MiB SAMS and will proceed by halving the range
* until 128 KiB is reached. 128 KiB is assumed to be the lowest viable SAMS.
* The actual bank tested will be >000E higher than the lowest bank in the
* upper half of the range.
*
* To test, Map >000E + lowest bank in upper half of SAMS range to >E000. For
* 32 MiB, this is >1000 + >000E. We initially store >0010 (LSB,MSB) in
* R3 to allow a circular shift each round before MOVing to R0 to then add
* >0E00 (LSB,MSB) for the next test. If the test fails at >001E, the last
* viable SAMS (128 KiB), R3 will go to >0800, at which point the loop
* exits, setting R3 to 0, effectively reporting "no SAMS".
*
* Set up SAMS check.
*
       LI   R2,>994A      `check-value
       MOV  R2,@>E000      check-value to check-location
       ; Classic99 emulator can do 32 MiB
       LI   R3,>0010       lowest bank in upper half of SAMS to R3 (LSB,MSB)
       LI   CRU,>1E00      CRU address of SAMS
*
*
SAMS_CHECK: 
       MOV  R3,R0          lowest bank in upper half of SAMS range
       AI   R0,>0E00       get >000E banks higher
       SBO  0              enable SAMS registers
       MOV  R0,@>401C      poke SAMS register for >E000
       SBZ  0              disable SAMS registers
       C    @>E000,R2      compare possible copy with test value
       JNE  SAMS_EXIT      exit if SAMS mapped, viz., no match
       SRC  R3,1           shift right circularly by ^2 to next lower SAMS
       CI   R3,>0800       too far?
       JNE  SAMS_CHECK     try half as much if not >0008 (LSB,MSB)
       CLR  R3             no-SAMS..set flag to 0
       JMP  SAMS_EXIT0     we're outta here
SAMS_EXIT:
       SWPB R3             restore bank#
       SLA  R3,1           double value (highest bank# + 1)
       DEC  R3             decrement to highest bank#
SAMS_EXIT0:
       MOV  R3,@ARG        save SAMS flag to ARG (hoping it survives!)
       JEQ  FRTHCP         go to copying Forth inner interpreter if no SAMS
*                          ...no need to restore anything if no SAMS
*
* Remap default bank >0E to >E000.
* CRU should still have correct value.
*
       LI   R0,>0E00       load SAMS bank >000E
       SBO  0              enable SAMS registers
       MOV  R0,@>401C      poke SAMS register for >E000
       SBZ  0              disable SAMS registers
;]*

 

 

...lee

 

Thanks Lee, that’s a clever routine you have there and I’m more than happy to use that. No need to reinvent the wheel.

[+retroclouds]

Here's a screenshot of Stevie v1.3B in classic99.

 

That was a little thing I wanted to try, show the currently active TI-Basic sessions.

An active TI-Basic session is a session I jumped into, did some actions and jumped back to Stevie.

Normally you would have a program still loaded.

 

 

[+jedimatt42]

@retroclouds, somewhere you asked if the updated kscan you use works well with my usb keyboard adapter. I can report that it does indeed work well. 

 

It used to have trouble with the F keys... while holding ALT(FCTN) and pressing a number would work.  The F keys are mapped to the same action, but of course the holding of alt is as brief as a keypress.  Anyway.. it works great now! 

[+retroclouds]

7 hours ago, jedimatt42 said:

@retroclouds, somewhere you asked if the updated kscan you use works well with my usb keyboard adapter. I can report that it does indeed work well. 

 

It used to have trouble with the F keys... while holding ALT(FCTN) and pressing a number would work.  The F keys are mapped to the same action, but of course the holding of alt is as brief as a keypress.  Anyway.. it works great now! 

Thanks for testing. Great to hear it works more reliably. Now I only need to build an usb keyboard adapter myself. ?

 

[+retroclouds]

Just a short update on what I'm currently working on:

 

As you probably know, the Stevie editor already has the possibility to jump in/out of multiple TI Basic sessions. The way it works is that upon TI Basic session exit, all of VDP memory and scratchpad is copied into SAMS.

When jumping back into the TI Basic session, stuff gets copied back to scratchpad and VDP and the TI Basic interpreter resumes the session. Nothing new so far.

 

What is new though, is that when returning to the Stevie editor the VDP Dump in SAMS gets examined with the purpose to "uncrunch" the program listing into the editor.

This still is very much a work in progress. However I'm able to traverse the line number table and unpack the line numbers for adding as lines in the editor buffer.

Next up is the "uncrunching" of the tokens themselves.

 

Purpose of all of this is, that if you for example jump from Stevie into TI Basic, OLD a program, do some editing and then exit back to Stevie, that you will have the TI Basic program source code immediately synced in Stevie for further editing.

Obviously the other way around "crunching" from Stevie into TI-Basic will also be required and that is far more of a challenge (but that's something for a later time).

Edited February 7, 2022 by retroclouds

[+retroclouds]

Here's a demo of the latest work I'm doing on TI Basic integration in Stevie.

 

In the demo I jump into TI Basic and then load a large TI Basic program.

After listing a small part of the program I then return to Stevie and press a shortcut key to "uncrunch" the TI basic program (=expand the tokenized source code) to the editor. This is still a work in progress and some bugs to iron out, but am pleased with the uncrunch speed.

 

In the last part of the demo I then jump back into TI Basic and then enter "bye" to return to the TI title screen.

From there I then select the cartridge again and notice how the environment is restored and I can keep working.

 

 

Edited February 26, 2022 by retroclouds
Replaced with youtube video

[+retroclouds]

Have been a bit quiet about Stevie development, so it’s time for an update.

 

I’ve got uncrunch working, meaning that if you jump into TI Basic and then create or load a TI Basic program you can automatically get the TI Basic listing uncrunch into Stevie’s 80 columns full-screen editor. I’m pleased with the uncrunch processing speed.

 

Now before starting to work on the crunch part (tokenizing the TI Basic source code), I started working on a new feature that I need to have in place. The thing is that TI Basic source code can obviously be longer than 80 columns. (The same also applies to other stuff that I for example load from the “CLIP.” device in classic99). Obviously in the editor I could just wrap this single long line into multiple 80 columns rows.  

 

However as far as TI Basic source code is concerned, doing so will make the crunch part more complicated because I have to reliably detect what rows make up a single TI Basic statement (that’ll also apply to XB as well). Instead of wasting time on that, I prefer to implement a general solution where the long lines don’t wrap, but instead you have a horizontally scroll window. Similar solution as used in TI writer/editor assembler editor.

 

I’m working on a first prototype and it looks promising so far. The idea is to edit lines up to 255 chars in length. Does require some refactoring again, meaning new bugs to iron out. Besides that I’ve introduced some other bugs I need to solve. Save file functionality stopped working, that’s a bummer but should be easy to fix I hope.

 

Long story short, it will take some more time before I release the new version (that will not yet include crunch, that’s for the version after that). Also have a lot of other stuff I’m digging into for work so hobby time is rather limited. 

 

 

 

 

 

 

 

 

 

 

 

[+Vorticon]

Happy to see work continuing on this great program.

I am rather ambivalent about scrolling windows for long lines, as it can make editing clunky. While I do understand that detecting multi-line statements will add overhead and hobble the editor's response time, I think it will be worth the effort to have all the code visible in one window. 

I would be interested in hearing what others have to say about this.

[+retroclouds]

1 hour ago, Vorticon said:

Happy to see work continuing on this great program.

I am rather ambivalent about scrolling windows for long lines, as it can make editing clunky. While I do understand that detecting multi-line statements will add overhead and hobble the editor's response time, I think it will be worth the effort to have all the code visible in one window. 

I would be interested in hearing what others have to say about this.

 

Yes, I'm interested hearing about that as well.

 

Having the scroll functionality in place, would offer one future possibility I haven't invested much time in so far: a 40-columns version of Stevie for the 9918A.

 

Not sure if it is something really to follow up upon, but might be worthwile to consider depending on the still missing general availability of the F18a MK2.

Granted you still need SAMS but with the planned availability of SD99 and the TIPI sams sidecar (is that still available? I have one at thome).

[+retroclouds]

I've released Stevie 1.3Q

 

Usability:

• Reworked menu system for easier navigation on real-iron and emulators.
  • Support 2 level navigation.
  • Added 'Shortcuts' menu for easy access to editor features.
  • Can now close menu by pressing 'SPACE' key.
     
• Added possibility to load finalgrom99 cartridge via 'Cartridge' submenu.
  For this to work the cartridge image files must be present on FG99 SD card in same directory as Stevie.
  • Currently supported:
    • Extended Basic G.E.M (XB29GEMG)
    • Rich Extended Basic   (RXBG)
    • Force Command         (FCMDG)
    • fbForth                      (FBFORTHC)
       
• Reworked build-system. Details: https://github.com/FilipVanVooren/stevie/issues/62   
• Stevie now licensed under GPLv3

      
TI Basic integration

• Possibility to unpack ("decrunch") TI Basic program to BASIC source code in Stevie editor.
• Filename detection if TI Basic program is saved from inside TI Basic session.
• AutoUnpack option exists (default is off). 
• Possibility to resume Stevie session after quiting TI Basic to title screen (or calling external program).
• Added option 'RESET STEVIE MEMORY' to TI selection screen. Used for resetting stevie if resume fails because of memory corruption.

         
Editor

• Goto line functionality added
• Added Possibility to turn on/off AutoInsert functionality. Is off by default.
• Added possibility to back-tab cursor
• Changed some editor keys for easy access on real-iron as well as emulators (tested with classic99 and js99er).
• Switch to latest TI Basic session via FCTN-0 key.
• Filename scan in editor text. Move cursor to a filename in the editor and file open dialog will pre-select the detected file.

    

Bug-fixes

• See https://github.com/FilipVanVooren/stevie/issues?q=is%3Aissue+is%3Aclosed

 

Please be aware that the TI Basic integration is still a work in progress and there are bugs lurking there, always save your editor files often.

In case of a lock-up after returning from TI Basic, you might need to select the 'RESET STEVIE MEMORY' option for Stevie to proceed working.
 

Have fun! 

 

 

[+Vorticon]

I know this is a fancy ask, but how about mouse support when a TIPI is present? Imagine being able to pick an insertion point anywhere on the screen with the mouse, or select a block of text by clicking and dragging. One can dream...😁

[+retroclouds]

1 hour ago, Vorticon said:

I know this is a fancy ask, but how about mouse support when a TIPI is present? Imagine being able to pick an insertion point anywhere on the screen with the mouse, or select a block of text by clicking and dragging. One can dream...😁

I thought about that actually. In fact I think the menu system would lend itself pretty well to mouse point & click and would be fun to implement. We'll see😀

Also with js99er TIPI mouse support we could even use it in the emulator.

I've opened up a GitHub issue for it
https://github.com/FilipVanVooren/stevie/issues/69

 

Edited January 6 by retroclouds