StrangeCart

[speccery]

I've been very busy in the last month or so with work, no progress with any of my TI related projects. But now I have a long weekend, with some time to work on the strangecart and I also plan to work on the grommy2 firmware.

 

I've refactored the strangecart firmware somewhat, this has been a background project, I started it already a couple of months ago. It's been slow going progress due to lack of time. I've reached a point where the code is somewhat easier to work with.

 

Anyway, I've now been able to get some progress done with the Basic interpreter. These are not only visible internally to the code but also providing additional functionality. One of the open points in the strangecart Basic was the lack of proper handling of INPUT statements. That's now in much better shape, supporting proper handling of input prompts and input to multiple variables. I still need to improve the line editing functionality, it's now super simple and does not support any editing   but I will change that. The strangecart firmware already has a line editor which is used when communicating with it using the serial port (over USB). That line editor also supports command history features. As part of the refactoring I ported that code from my previous C-language version to C++. I will need to see if I use that as the basis for the input line editor, or if I create another version. 

 

Having a line editor will also be necessary to add in the future tokeniser (i.e. conversion of input text to Basic lines). I want to do that since I want the strangecart be able to also offer interactive Basic mode. Once I have that, I want to add support for 40 column text mode and also support 80 column mode with F18A. My intention still is to resist going wild with extensions - tempting as those are, but rather make the Basic programming and debugging experience friendlier.

 

The bottom line is that there is progress, and hopefully quite soon a new version of the firmware. There aren't many strangecarts out yet, but if you have feature requests please let me know!

Edited April 7 by speccery

[+TheBF]

Did you ever find a use for Mecrisp or was that a side project?

[speccery]

1 hour ago, TheBF said:

Did you ever find a use for Mecrisp or was that a side project?

I did test it a little. I tested it on the grommy2 board but I didn’t try to get the actual GROM functionality running it. I think it is interesting and very useful for brining boards up, but I am so much more productive with C++ that at least for now I am keeping it on the side. I am still considering making it available on the StrangeCart, but if I do it it would rely on the existing code for communication with the TI, so I would need to integrate it.

[speccery]

I released new firmware for the StrangeCart, please see description at the Github wiki page.

The new firmware is available here.

The updates are relatively minor on the outside, but internally more significant. The big one is a more comprehensive INPUT handler with a line editor with command history memory. One thing I forgot to mention in the Wiki is that the line editor currently works a little differently from the one we're used to with the TI: FCTN+1 works like backspace (delete to the left) rather than delete. Insert mode is on all the time.

[speccery]

I have continued to work on the StrangeCart BASIC over the past several weeks. I haven't recently had the time work on the hobby for extended amounts of time in one go, with these constraints working on software seems to be somewhat easier than hardware (I have several things to do there such as new picocart PCB layout). 

 

Anyway I realised that what I was missing was the thing BASIC is known for - immediacy i.e. command mode. Up til now what you could have been doing with the StrangeCart is to load an existing TI BASIC program and save it to the memory of the StrangeCart, and use its CALL RUN to have run the BASIC program very fast. In other words, BASIC program editing would be done with regular TI BASIC; access to StrangeCart has been a bit indirect, as save to the flash memory of the board has the side effect of making the program available for the StrangeCart BASIC interpreter.

 

Earlier, the firmware has thus treated the BASIC program as a ROM: even though my interpreter can run the BASIC program, it could not modify it. I am now in the process of adding a tokeniser and building blocks for editing the loaded program. The revised BASIC has already now a command interpreter, which can be entered and it runs entirely on the StrangeCart. Within the interpreter there are bunch of standard BASIC features already working:

• RUN command enables running the program (nothing new)
• LIST command enables listing the program (supports now ranges of lines)
• OLD enables loading a BASIC program from the SCD1 drive
• BYE exits the command interpreter

Those commands were already there in various forms, but now:

• Entering NEW clears the BASIC program and variables (yes, progress comes in small steps)
• Entering a line number alone deletes the line from memory
• Entering a line number and code after it tokenises the code and inserts the code line into the right place of the program.

These sound trivial additions, but the size of the BASIC and other parts of the firmware expanded by almost 1000 lines of C++ to support these features.

 

Tokenising TI BASIC lines takes a bunch of code, and the memory management of altering BASIC programs in memory is also a bit tedious: I am maintaining in the StrangeCart's memory the BASIC program in normal TI BASIC save format: there is a 8 byte header, followed by the line number table (backwards as in the VDP memory) followed by the program code (also backwards, highest numbered line of code in the lowest memory address). The only change I implemented is that while in VDP memory the BASIC program size is restricted to 16K (in practice less) and is loaded near the top of the 16K space, now after loading a I modify the 16-bit line pointers so that they are zero based relative to the memory address where the BASIC program is stored. This is reversible - it simply means subtracting a fixed memory offset from every line number table address entry. That can be added back, and if subsequently saved the program can be loaded back to normal TI BASIC (I haven't tested it yet but I am sure I can make it work since the format is the same). But the plus side is that the tokenised program size can extend up to 64K. The compatibility at the moment with the use of 16-bit line offsets means that 64K is the limit for tokenised code - data areas are on top of that.

 

When fully completed and the onboard command mode is finalised, these changes mean that I can support different video modes with ease. My intention is to do this so that when one enters the StrangeCart BASIC command interpreter, the 16k VDP memory contents are copied to the StrangeCart's memory for backup, and then I will be free to mess around with VDP memory to support any video mode - including F18A 80 column mode - for TI BASIC programs. When returning from the StrangeCart BASIC back to TI BASIC I intend to restore the state of the VDP.

 

Even with these limited features I have had a lot of fun playing with the command interpreter while working on the code. The command mode makes it self contained. In fact I am testing the interpreter without even plugging the board into the TI, since the command interpreter also supports operation over serial line.

 

Edited Friday at 07:53 PM by speccery

[+retroclouds]

Unfortunately I have like zero time to work on TI projects lately. In my Stevie editor I have TI-Basic integration working, so getting something like that combined with the pico cart would be real fun. My dream is to have a full-screen basic editor, where I can jump between multiple “sessions”. 

I have it working for the most part, if you look around in the forum you can find my Stevie development thread with some videos. 

Jump into TI Basic, load or type a program, jump back to Stevie and the TI basic program gets detokinzed and shown in the editor, including file name it was loaded from. Hooked into the ISR to keep track of what is happening while in TI Basic.

 

Didn’t have time to work on the tokenizing yet, but that will come.

 

Having the possibility to run TI-Basic at hyperspeed would be magic.

I really think that TI Basic is underestimated, because of XB and its enhancements there.

For me jumping into TI Basic and back out, without losing the program in VDP, quitting to the TI title screen, back into the editor, and “resuming’ the TI Basic session by restoring VDP contents what an eye opener. This is all done with SAMS, so it was just a question of switching pages.

 

Anyway, looking forward how your picocart further develops. 

[+Ksarul]

Note that TI also had the option of saving TI BASIC programs into the GROM3-7 space and executing it. A lot of early programs from TI used this trick, as did most of the Scott Foresman cartridges. Decoding the method and using that option would let you save programs of up to 40K into that space and actually run them as a cartridge on a standard, unexpanded console. IIRC, the method is somewhat described in some of the technical specifications.

[speccery]

59 minutes ago, Ksarul said:

Note that TI also had the option of saving TI BASIC programs into the GROM3-7 space and executing it. A lot of early programs from TI used this trick, as did most of the Scott Foresman cartridges. Decoding the method and using that option would let you save programs of up to 40K into that space and actually run them as a cartridge on a standard, unexpanded console. IIRC, the method is somewhat described in some of the technical specifications.

Thanks @Ksarul I remember this being mentioned by someone (you?) in some call or at least in the forums. Is there an example cartridge somewhere I could take a look at? I would be interested in taking a look. Would be a great match for this project - and a nice way to compare performance as the StrangeCart can both emulate GROMs allowing in cartridge mode and-  if I can extract the BASIC program - I could run it using it's BASIC interpreter.

[HOME AUTOMATION]

@Ksarul ...Good idea!

 

Helping-out a little, tonight.😁

 

Texas Instruments TI-99 4A [TOSEC]/Command Modules/Personal Record Keeping (1979)(Texas Instruments)[PHM 3013].zip

[speccery]

4 hours ago, HOME AUTOMATION said:

@Ksarul ...Good idea!

 

Helping-out a little, tonight.😁

 

Texas Instruments TI-99 4A [TOSEC]/Command Modules/Personal Record Keeping (1979)(Texas Instruments)[PHM 3013].zip

Thanks @HOME AUTOMATION that's great. Looking forward to studying this with a bit more time, but I checked this quickly by loading it in js99er.net, launching it and looking up a few things in TI Intern book. When launched, the line number table pointers at @>8330 and @>8332 are set to C03C and D24B respectively. Looking briefly at those addresses in the file (hexdump -C file | less) and noting the >6000 offset as this GROM stuff is loaded at address >6000 in GROM space, there are valid looking line number table entries in there. The highest numbered lines there are 26140, 26040, 26030, with respective line pointers to >8830, >c038, >8163. These address clearly are not in VDP space but would be valid GROM pointers. I looked at the tokens on those lines as well, last line was a RETURN which makes sense, the 2nd to last an assignment which also makes sense.

[HOME AUTOMATION]

Perhaps a bit OT, but I had considered the idea ...that by utilizing GRAM, and a program running from ROM pages, a CALL, could be added to BASIC, that could somehow crunch the BASIC program into GRAM/allow for longer BASIC programs.

[+FALCOR4]

9 hours ago, Ksarul said:

Note that TI also had the option of saving TI BASIC programs into the GROM3-7 space and executing it. A lot of early programs from TI used this trick, as did most of the Scott Foresman cartridges. Decoding the method and using that option would let you save programs of up to 40K into that space and actually run them as a cartridge on a standard, unexpanded console. IIRC, the method is somewhat described in some of the technical specifications.

@Ksarul, if memory serves, I believe that Craig Miller had a utility on the 2nd GramKracker utility disk that would move a basic program into those GRAM spaces?

[+FALCOR4]

15 minutes ago, FALCOR4 said:

@Ksarul, if memory serves, I believe that Craig Miller had a utility on the 2nd GramKracker utility disk that would move a basic program into those GRAM spaces?

MSAVE and MSAVE6. On one of the utility disks.