StrangeCart

[+dhe]

A whole lot of steps forward.

 

1) The sparkfun cable is a perfect match. It goes in easy and has a positive click when inserted.

     I didn't notice the tiny slits in the connector, but the sparkfun cable has little half arrows that click perfectly in place.

 

2) Upon connect the cable, tera term immediately gave me options in a terminal window.

 

3) The firmware update procedures for windows worked perfectly.

 

4) I could play Parsec just fine.

 

5) I was able to run a basic program from the strange cart:

 

 

6) I ran diagnostics and here is what I am seeing:

 

During the time in diagnostics, 4 would always take me back - so never a lockup!

[SteveB]

On 5/4/2022 at 9:39 PM, speccery said:

I modded a standard cartridge case for the StrangeCart. A quick and dirty job for sure. I can't believe how dusty my computer looks like in this picture, please try to ignore that fact... Running firmware C, i.e. the 150MHz version, the version I released at GitHub doc project.

I've never seen a cartridge with an own OLED Display before ... Amazing!

[speccery]

2 hours ago, dhe said:

A whole lot of steps forward.

 

1) The sparkfun cable is a perfect match. It goes in easy and has a positive click when inserted.

     I didn't notice the tiny slits in the connector, but the sparkfun cable has little half arrows that click perfectly in place.

 

2) Upon connect the cable, tera term immediately gave me options in a terminal window.

 

3) The firmware update procedures for windows worked perfectly.

 

4) I could play Parsec just fine.

 

5) I was able to run a basic program from the strange cart:

Thanks a lot for your efforts! It seems you are now getting the experience you should have been getting from the beginning. I think the new firmware - which has a modified bus timing - works much better. Judging from the pictures it appears you're using an actual VDP. That's great, I haven't tested that, my two development TIs both have F18A installed. It appears you have full functionality.

 

I am glad the firmware update worked for you, since there will be many more coming  I do firmware updates all the time, in a matter of 10 seconds or something like that (with the command line script and manual button pushing).

 

The next steps would be to test CALL CARTS from TI Basic to get a listing and then for example CALL CARTS(1) to bring up one of the demos. I have not tested these with the real VDP.

 

The firmware version you now have supports SAVE and OLD operations from the SCD1 drive. So once you have a Basic program written or loaded, you should be able to do SAVE SCD1.NAME and then later use OLD SCD1.NAME to get it back. They go into a 2 megabyte filesystem. I'm not entirely sure if that file system needs initialisation, I think not with the current firmware. Anyway more can be done from TeraTerm now that you have the terminal connection. The filesystem support is still in its infancy and you for example cannot erase files or list them from Basic. From the command prompt over TeraTerm you can look at the files with the spiffs_dir command.

[+dhe]

I big thank you to @ti99iuc!!

 

 

 

 

 

[speccery]

I noticed the other thread here where there is benchmark with the Sieve of Eratosthenes.  Naturally wanted to benchmark this with StrangeCart Basic, so I wrote it in Basic.

I don't remember what is the size of the data area I have set aside, but I will increase it so that DIM A(8192) will succeed on the StrangeCart. It requires 4 bytes per entry or 32K for that array, as for me the floating point values are single precision numbers. I am also thinking of expanding the Basic with something like "DIM A(8192) AS BYTE" but this kind of extension of course would no longer work with regular TI Basic, so I need to resist for now.

 

Anyway, running the Sieve did not work since I uncovered a bug in the implementation of FOR-TO-STEP. In the inner loop, sometimes the loop variable is initialised to a value higher than the limit. In this case the whole loop is skipped. I am lacking currently that functionality, so I am in the process of adding it but I am running out of time now, will continue over the weekend.

 

Fixing this leads to interesting findings with some subtleties, for example this loop (screen capture running on the actual hardware with normal TI Basic ) :

So here we have two nested loops, but the outer loop at line 100 is from 11 to 10 with a positive step. So the whole loop is skipped, and we continue from 160. Still, naturally I gets declared and has the value of 11.

 

Note that the inner loop above is also using I as the loop variable, and yes I did have another bug which I already fixed: the inner loop initialisation was trying to reuse a slot in the for-next stack but due to bug it didn't. I had originally line 140 like this: "140 NEXT I" so I had two nested loops with the same variable, I was testing that behaviour and at that time I had the outer I going from 1 to 10. That should result in an error on line 150 since the loop with I has already ended. With TI Basic it does, but originally in my Basic it didn't because of the bug. Now the error is issued (for-next stack empty).

 

Anyway, note that in the listing above line 140 is on purpose NEXT K. So this is a mismatch, but TI Basic doesn't care since it seems to just be counting FOR-NEXT tokens when skipping. I was planning to make the same, but just wanted to double check how much checking the Basic does while skipping. And it does not do excess checking  

Thus I need to add code to handling of FOR, so that if the loop variable after initialisation is already above the limit (or below with negative STEP value) it will read through the code and continue after the NEXT statement belonging to the FOR being handled at present. Thus in this sense a FOR statement is capable of performing actually a fairly intricate GOTO. 

 

Edited May 12, 2022 by speccery
trying to make it more readable, still opportunity to mix variable I and the word I :)

[+dhe]

Are the area's you want tested?  (Float/Trig/Char/etc)?

[speccery]

21 hours ago, dhe said:

Are the area's you want tested?  (Float/Trig/Char/etc)?

Thanks, I suppose all kinds of testing of the Basic would be useful. I have tested it with around 10 games only, and not sure if they work ok, although it seems that way.

I fixed the FOR loop issue described above, but haven’t tested it yet on the StrangeCart, just in my standalone test version of the same code.

[+dhe]

Is your goal in basic to emulate the radix-100 math native to the TI grom/rom?

[speccery]

7 hours ago, dhe said:

Is your goal in basic to emulate the radix-100 math native to the TI grom/rom?

No, not at the moment. Unless that is felt important. I'm still at the phase where I'd like to get the whole feature set implemented first, before possibly doing more work on data types. For now all numeric data is stored in standard single precision floating point format (ANSI/IEEE Std 754-2008), 4 bytes per value. 

This is a great question though, my thought process was that probably most TI Basic programs are gaming related, and in that domain single precision floating point will provide more than enough accuracy.

[speccery]

I got the sieve of Eratosthenes working on the StrangeCart, like I wrote in the thread. Sadly the interpreted Basic program speed (8.6 seconds) is still behind the assembly speed (6.4 seconds). This is very far from an apples to apples comparison, but obviously I will need to optimise the interpreter a little so that we get past the assembly code version.

[PeteE]

I have a huge interest in optimizing interpreters, I would be willing to take a peek if the basic interpreter can be run under Linux.  Is the code on github?

[speccery]

On 5/14/2022 at 9:17 PM, PeteE said:

I have a huge interest in optimizing interpreters, I would be willing to take a peek if the basic interpreter can be run under Linux.  Is the code on github?

Thanks @PeteE .

Good to hear about your interest  the code is currently not on Github. It can be run under Linux, I develop on macOS but with Xcode it makes no difference here.

 

FYI - I have setup things so that I have a command line version of the interpreter, which then can be cross compiled to be part of the firmware. The command line version of the code loads a binary file from disk and runs it, I have done pretty all of the development that way. When working on the code it's important to remember that it needs to run on an embedded system with little memory.

 

Thus as design principles I've designed it in a way that it doesn't use big libraries of frameworks, or 3rd party software in general other than some normal gcc runtime libraries. The heap sizes can be configured in a header file, and can be set very small, like 2k each. I currently use separate heaps for symbols and strings. The symbol heap includes everything else except contents of strings, so all arrays, variables etc are there. The code doesn't do any dynamic memory allocation outside of those heaps, and does not use malloc or new, at run time everything is allocated either statically or in the stack to keep memory usage small and under control. There's also no garbage collection, except for the string heap.

 

If you're interested I can publish the interpreter code on Github, it's very much work in progress.

Edited May 16, 2022 by speccery

[apersson850]

On 5/27/2020 at 4:21 PM, speccery said:

Yes, it could run the P-system. I was not familiar with p-code, but after a very quick read about the P-code architecture that should not be a problem. Of course it would require writing a P-code interpreter in C. I am sure those must already exist, so it would be a porting job.

The p-code card contains 8 GROM chips, mapped into DSR space, and 12 K ROM, also mapped in DSR space. Last 4 K bank switched by a CRU bit.

The PME is running partially from the p-code card, partially from expansion RAM and partially from scratch pad RAM (8300H).

[speccery]

33 minutes ago, apersson850 said:

The p-code card contains 8 GROM chips, mapped into DSR space, and 12 K ROM, also mapped in DSR space. Last 4 K bank switched by a CRU bit.

The PME is running partially from the p-code card, partially from expansion RAM and partially from scratch pad RAM (8300H).

Thank you for the details. The DSR space cannot be server by a cartridge, there is no chip select line for other than the 6000..7FFF address range. So direct emulation would not work, but similar functionality could be built. I haven't studied the P-code stuff since the last exchange two years ago...

[+Ksarul]

I know that at least one enterprising programmer from Vienna hoisted the entire p-System into a cartridge. Alexander Hulpke was one of his beta testers and demonstrated it at the TI-Treff in Berlin (1991). It worked on both the TI-99/4A and the Geneve (he tested it on my Geneve at the Treff to see if it would work).

[+mizapf]

31 minutes ago, Ksarul said:

I know that at least one enterprising programmer from Vienna hoisted the entire p-System into a cartridge.

Maybe after substituting addresses.

[apersson850]

That can of course be done. Since the cartridge space is unused by the p-system, there's no conflict in moving things there.

The GROM access addresses have to be modfied, where they now are referred to in the program. When running code from GROM it's loaded into a register used by the PME.

There's an assembly code repository located in GROM. It's transferred to RAM on startup. It must of course also be modified, where it addresses things in ROM.

The p-code jump table for instruction interpretation points to ROM, but it's in RAM, so it's pretty easy to handle.

Bank switching is via CRU bit. That will not be directly supported by a cartridge, unless it's specifically built to implement the p-code card.

Parts of the system is in RAM just to be able to run even when other cards are used, like the disk controller or RS232. That implies turning off the p-code card, but if the p-code was hosted in cartridge space, that wouldn't be necessary. But it's perhaps not worth it, since that would only free memory from the 8 K RAM part, and that's not easily useful by any other part of the system. The code pools are in VDP RAM and the 24 K RAM parts anyway.

[+acadiel]

1 hour ago, apersson850 said:

That can of course be done. Since the cartridge space is unused by the p-system, there's no conflict in moving things there.

The GROM access addresses have to be modfied, where they now are referred to in the program. When running code from GROM it's loaded into a register used by the PME.

There's an assembly code repository located in GROM. It's transferred to RAM on startup. It must of course also be modified, where it addresses things in ROM.

The p-code jump table for instruction interpretation points to ROM, but it's in RAM, so it's pretty easy to handle.

Bank switching is via CRU bit. That will not be directly supported by a cartridge, unless it's specifically built to implement the p-code card.

Parts of the system is in RAM just to be able to run even when other cards are used, like the disk controller or RS232. That implies turning off the p-code card, but if the p-code was hosted in cartridge space, that wouldn't be necessary. But it's perhaps not worth it, since that would only free memory from the 8 K RAM part, and that's not easily useful by any other part of the system. The code pools are in VDP RAM and the 24 K RAM parts anyway.

I remember something about a "dummy cart" for copyright protection for one of the P-Code programs (word processor?)  Any thoughts as to what that was?

 

I think Bryan Roppolo wound up getting the one example I saw (from Joy Electronics).

 

Edit:  https://www.unige.ch/medecine/nouspikel/ti99/pcode.htm has the nitty gritty details on what you described above.  It was quite an interesting idea on how they could implement it!  (Also, an article that you wrote, here:  https://www.unige.ch/medecine/nouspikel/ti99/pcode.txt)

[apersson850]

I've disassembled most of the memory running the system, and figured out what some parts of it is doing. Mainly to support my ideas of pre-emptive multitasking and implementing graphics mode for turtle graphics.

[+Ksarul]

9 hours ago, acadiel said:

I remember something about a "dummy cart" for copyright protection for one of the P-Code programs (word processor?)  Any thoughts as to what that was?

 

I think Bryan Roppolo wound up getting the one example I saw (from Joy Electronics).

 

Edit:  https://www.unige.ch/medecine/nouspikel/ti99/pcode.htm has the nitty gritty details on what you described above.  It was quite an interesting idea on how they could implement it!  (Also, an article that you wrote, here:  https://www.unige.ch/medecine/nouspikel/ti99/pcode.txt)

The cartridges had a couple of weird purposes, including setting the machine up for a couple of specific printers. The cartridge was used with the p-Code word processor and the Aardvark spreadsheet program. I have one for each of those programs (and IIRC, there are a few subtle differences between them).

[speccery]

New firmware released, comments below from the wiki at https://github.com/Speccery/StrangeCart-Doc/wiki and also the new firmware can be downloaded from there. Now this version of the firmware can run Sieve of Eratosthenes I listed in the byte benchmark thread. It has some generic refactoring as well. It also is minimally feature complete for the built in SCD1 drive in that from TI Basic programs can be saved, loaded, deleted and with the new CALL DIR command also the filenames can be listed.

The current recommended file is firmware-2022-05-18.bin

• Runs at 150MHz
• TI Basic extension, i.e. go to TI Basic with menu option 1 and type commands there
  • Adds ability to list files stored in onboard storage, only works for SCD1: CALL DIR
  • Adds ability to delete files in onboard storage: DELETE "SCD1.FILENAME"
  • Fixed a bug with StrangeCart Basic handling of the FOR statement, now skips the loop if initial value beyond limit.

[+acadiel]

Curious how the SCD1 device works from the cart port.  I thought devices were only scanned at the DSR space of >4000, which the cart port doesn’t decode.  How are you injecting the device in the cart space?

[speccery]

23 minutes ago, acadiel said:

Curious how the SCD1 device works from the cart port.  I thought devices were only scanned at the DSR space of >4000, which the cart port doesn’t decode.  How are you injecting the device in the cart space?

Same way as with the mini memory cartridge: with GPL. TI Basic searches drivers also through GROM headers.

 

Another option would have been to modify system GROMs as the StrangeCart can override those too, but I am not doing this to support SCD1.

[speccery]

I just published a new video about the StrangeCart, discussing some aspects how to use it: https://youtu.be/VgxHLPK5p5A

 

Also added the GRAM support as discussed a little in the thread of @senior_falcon for speeding up TI Basic.

[+dhe]

With the newest firmware, can we do the input command?