StrangeCart

[MWCool]

12 hours ago, speccery said:

After a while I am again working a bit on the strangecart firmware. Mostly on the Basic interpreter development. I am trying to get the new game Wormhole of @MWCool on the strangecart. I haven't gotten very far at all yet, since I merged my several different development branches together and in the process fixed some bugs. It appears I need to add a few but not many extended basic features to be able to support this game. I've already updated the tokeniser and detokeniser to support DISPLAY AT, AND, OR, NOT and XOR which perhaps are the only extended basic features used by the game. These keywords do not yet really do anything, but the basic now recognises them and is able to tell them apart for random strings.

 

In the process of the branch merging I've also updated the command interpreter. Yes, the strangecart basic does have it's own command interpreter (command mode) where one can enter commands like run, list, old, continue, trace, untrace and so on. I added debugging commands there while I was fixing the bugs I have introduced at some point, so now the BREAK and UNBREAK commands are supported from the command mode. Alas, the command mode is not available currently yet from the TI screen, only over USB serial link and some other development needs. I need to write some frontend code to be able to launch from the TI menu screen directly to strangecart basic, without using TI Basic as a launchpad; or alternatively add a command to TI Basic to move to strangecart basic and back. Probably both.

 

One thing I want to be able to do with the strangecart basic is to write an application launcher in Basic. It would enable easily browsing and choosing either a ROM cartridge or strangecart basic program and being able to run it directly from a menu, instead of the current multistep approach of listing and selecting a ROM cartridge from TI Basic or loading a TI Basic program first and saving it to the strange cart's basic workspace and calling run. For this to work I just need to expose some of the existing functionality of the strangecart to its Basic, so that a basic program can be used to create the menu.

Sounds like some amazing work you are doing with your  Strangecart!  I'm also so glad to hear my "almost BASIC" game is helping with your development

[speccery]

20 hours ago, RickyDean said:

Yes sir, I want a Strangecart + case and two grommy 2's to play with.

Drop me a PM if you want to discuss more  

[speccery]

I've been having some very interesting exchanges with @retroclouds. He is using his strangecart to run the Stevie editor on the real iron. Further, he has developed a development setup where he is uploading new Stevie images onto the strangecart automatically using build scripts. Or rather this was his goal, but there were some issue in the strangecart firmware. After a few iterations this was fixed pretty quickly, and I modified the firmware and fixed some bugs. The end result is that it is now pretty easy to upload cartridge images rapidly during development cycles.

 

I fixed the "rom" command (explanation below) and renamed and extended the dl_rom8 / dl_grom8 commands:

• "rom" command now does all the necessary setup *
• "dl_rom8" command has been available to receive 8k ROM images. This command has now been renamed to "dl_rom" and it determines the amount of data to receive from the cartridge configuration. So if you have a cartridge which has 32k of ROM, the command will receive 32K of ROM data. I say receive, since the actual transfer is done using the XMODEM protocol over the serial line over USB.
• ditto for "dl_grom8" command, it's now called "dl_grom" and receives GROM data.
• New command "romk a b" where a is the size of ROM and b the size of GROM for the cartridge. Both are indicated in kilobytes, and they are hexadecimal values. So to receive the image for the Stevie editor this needs to be "romk 40 0" where ROM space is configured for 64 kilobytes (hex 40) and GROM space is set to zero.

*) when I say the rom command has been fixed it is true, but there is one more caveat: the currently active cartridge image (before issuing the rom or romk command) must not be a cartridge image which has ARM side service routines active. The first three images are like this (strangecart basic, demo1, demo2). So the command "load" can be used to load any other cartridge first, followed by the rom command, which then is followed by dl_rom and/or dl_grom command to load the data.

 

As an example, to setup things for a 32K ROM cartridge after boot, for example the following commands could be used:

load 7
romk 20 0
dl_rom

 

This would be followed by the xmodem transmission of the ROM data. After that the cartridge image just uploaded is ready to go.

 

I attach the new development version of the strangecart firmware. There are also many other updates in it, I don't recall all of them as I have been lately working more on the grommy2 firmware.

 

The underlying problem was that the strangecart command line interface (available over the USB serial port connection) has some command which are supposed to set cartridge configuration parameters. I say "are supposed to" since during the debugging I discovered that the "rom" command had broken. This happened when I added experimental support to what I call streaming cartridges: basically multilink cartridges which are much bigger than what can fit into the onboard RAM of the strangecart. If a cartridge image has been configured to work in the streaming mode, the internal cartridge RAM (currently limited to 128K) is transformed into a sort of cache, and the strangecart will use some heuristics to preload the cache from the onboard 16MB flash chip. Preloading is necessary (as I have explained in some earlier message in this thread) since the cartridge ROM image data must be in the RAM to be available fast enough to serve cartridge port bus cycles. The cartridge port has no facility to force wait states to memory cycles, the side port has that support. Now making the streaming mode work meant that there is internal table which indicates the addresses of each 8K ROM bank in the memory of the strangecart; this same table needs to setup properly also for non-streaming mode cartridges. The "rom" command didn't do the setup, and the result was that only cartridges which came from the cartridge image file were handled properly.

firmware.bin

[speccery]

Some progress with the strangecart software development. I needed to do a bit of refactoring to clean up some experimental code. I have been working on the code but not yet tested on the strangecart. In my simulation environment (which is far from ideal) I have now added support for AND, OR, XOR and NOT logic operations as well as the DISPLAY AT statement. I also started to work on something which I've been wanting to do a long time: the ability to declare datatypes for BASIC arrays. In the past an array could be a string array or floating point array. That's all good, but many of things I want to do would require support for byte arrays, since using floats as the only numeric format wastes precious memory. So I've now added the ability to declare arrays with floating point values, bytes or 16-bit integers. The memory allocation for these work, but I still need to work more to get them properly support throughout the BASIC interpreter. This is not particularly hard but I'm still looking for the most robust way to do it; the change only has an impact on a limited areas of the code. I also want to add some strangecart specific routines which could be accessed with CALL. These would fall into a couple of categories, some to use provide access to strangecart specific features (like getting names of cartridges in basic), and then some lower level stuff to peek and poke memory and transfer data back and forth between strangecart Basic RAM and VDP RAM. I also want to add the ability to define VDP memory regions in a flexible way to support multiple display modes. The strangecart doesn't really need TI Basic to be running simultaneously, even if at the moment the interface is done so that it is accessed with TI basic command extensions like CALL RUN.