StrangeCart

[speccery]

7 hours ago, GDMike said:

Does the user have the ability to control speed of a program they wish to write, say, in assembly for example? Or will we still be running at around 4mhz if I were to run One of my programs. You may have covered this, I'm sorry if I'm outta the loop on this. 

The graphics demo presented on the video consists of two parts: TI-99/4A cartridge ROM for the TMS9900 and ARM code. When the demo TI cartridge is loaded, it is associated with ARM code (and this is compiled C using hardware floating point unit, not BASIC so I am cheating in my comparison a bit  ). When the TMS9900 writes to magic locations in the cartridge ROM area it causes the ARM processor to run code, and as a result the ARM will write new TMS9900 machine code into the cartridge area, which the TMS9900 will then run. The primary role of the TMS9900 is to update screen with data calculated by the ARM.

 

To answer your question, if you run your current programs they will still run at 3MHz using the TMS9900, whether they're BASIC or assembly. But I am working on two pieces of code which would make the performance of the StrangeCart accessible:

• Interpreters running on the ARM, and using the TI for input/output. I have some kind of a start of a BASIC interpreter for this, and it also would be nice to add Forth.
• SDK to make it possible to create "cartridges" which contain TMS9900 machine code and ARM machine code, the ARM code created by compiling C code using GCC.

[Tursi]

1 hour ago, speccery said:

• SDK to make it possible to create "cartridges" which contain TMS9900 machine code and ARM machine code, the ARM code created by compiling C code using GCC.

[speccery]

1 hour ago, Tursi said:

If there was supposed to picture in there, I can only see an empty rectangle...

[Tursi]

"I'm interested in this".

 

[+TheBF]

12 hours ago, speccery said:

• Interpreters running on the ARM, and using the TI for input/output. I have some kind of a start of a BASIC interpreter for this, and it also would be nice to add Forth.

Innocent question: Wouldn't it be simpler to run a TMS9900 emulator on ARM?  

 

Mecrisp Stellaris is a native code compiler ARM that is still fully interactive.

Mecrisp Stellaris Unofficial UserDoc — Mecrisp Stellaris Unofficial 1.0 documentation (sourceforge.io)

[+TheBF]

A bit more

• Mecrisp-Stellaris Forth fits into 19 KB of flash and runs with at least 1 kb of ram. Compare this to C which requires 20KB just to provide embedded printf!
• Mecrisp-Stellaris Forth is fully interactive in real time on your MCU, see register contents, change GPIO states etc.
• If you wish Mecrisp-Stellaris Forth ran on your favourite chip, just get in contact with Matthias, and maybe there will be another port soon.

[speccery]

22 hours ago, TheBF said:

Innocent question: Wouldn't it be simpler to run a TMS9900 emulator on ARM?  

 

Mecrisp Stellaris is a native code compiler ARM that is still fully interactive.

Mecrisp Stellaris Unofficial UserDoc — Mecrisp Stellaris Unofficial 1.0 documentation (sourceforge.io)

We could also run TMS9900 emulator on the ARM, I have considered that too. In that case we still need the same kind of I/O routing between the processors. But I haven't fully figured out the benefit of emulating the TMS9900 - so that we effectively could run the same software, but this time emulated and probably quite a bit faster, but with quite a bit of complexity in routing all I/O operations to the real TMS9900 to handle... But this is certainly a possibility.

 

And yes, I am aware of Mecrisp and support for that could probably be added as well, although my current firmware is designed in a way that it would handle all the interrupts and USB communication etc, so Mecrisp would need to be a passenger, not the driver  at least if I were to integrate it.

[+9640News]

On 7/12/2021 at 3:23 AM, speccery said:

The graphics demo presented on the video consists of two parts: TI-99/4A cartridge ROM for the TMS9900 and ARM code. When the demo TI cartridge is loaded, it is associated with ARM code (and this is compiled C using hardware floating point unit, not BASIC so I am cheating in my comparison a bit  ). When the TMS9900 writes to magic locations in the cartridge ROM area it causes the ARM processor to run code, and as a result the ARM will write new TMS9900 machine code into the cartridge area, which the TMS9900 will then run. The primary role of the TMS9900 is to update screen with data calculated by the ARM.

 

To answer your question, if you run your current programs they will still run at 3MHz using the TMS9900, whether they're BASIC or assembly. But I am working on two pieces of code which would make the performance of the StrangeCart accessible:

• Interpreters running on the ARM, and using the TI for input/output. I have some kind of a start of a BASIC interpreter for this, and it also would be nice to add Forth.
• SDK to make it possible to create "cartridges" which contain TMS9900 machine code and ARM machine code, the ARM code created by compiling C code using GCC.

I saw your feedback on Facebook, as well as saw this note here.  For that graphics demo, is there someplace, even if for another computer, that has that program listing?  

 

My interest was just seeing what the Geneve might be able to do with some kind of interpretation of the code, whether it be in Geneve Advanced Basic, Geneve assembly, or possibly on the TI with Myarc Extended Basic.

 

 

[Tursi]

10 hours ago, speccery said:

We could also run TMS9900 emulator on the ARM, I have considered that too. In that case we still need the same kind of I/O routing between the processors. But I haven't fully figured out the benefit of emulating the TMS9900 - so that we effectively could run the same software, but this time emulated and probably quite a bit faster, but with quite a bit of complexity in routing all I/O operations to the real TMS9900 to handle... But this is certainly a possibility.

Yeah, but if people can load any ARM code they want, then a developer who wants that can load a TMS9900 emulator and be done. No need to invent every possible use in advance

 

[speccery]

12 hours ago, 9640News said:

I saw your feedback on Facebook, as well as saw this note here.  For that graphics demo, is there someplace, even if for another computer, that has that program listing?  

 

My interest was just seeing what the Geneve might be able to do with some kind of interpretation of the code, whether it be in Geneve Advanced Basic, Geneve assembly, or possibly on the TI with Myarc Extended Basic.

I had to dig up my notes to see where the original program came from. After digging for a while it was no surprise to notice it came from Stuart's pages. (I couldn't insert his AA handle here since there are quite a few Stuarts in here and right now I forget which was is his - but credits go to him).

You can find it here: http://www.stuartconner.me.uk/tms99110_breadboard/tms99110_breadboard.htm

There are also some interesting benchmark results there. Need to check how fast this would go in TI BASIC or TI Extended BASIC, running it without plotting should give a good idea.

 

The run time on the StrangeCart without data transfer to TMS9900 is currently 18ms (milliseconds). Almost all of the runtime is spent running C-library sinf() and sqrtf() functions (single precision sin and square root). There are ARM optimised versions of these but I haven't tested them yet, I expect them to be quite a bit faster. I am curious to check them out.

 

Here is the C-code:

Spoiler

Header:

typedef void (*plot_func)(int x, int y, unsigned color);

void set_plot_func(plot_func myfunc);
int draw_stuff(int width, int height, unsigned int color, float phase, float scale);

Implementation:

plot_func f = dummy_plot;

void set_plot_func(plot_func myfunc) {
	f = myfunc;
}

__attribute__( (long_call, section(".data.$RAM2")))
int draw_stuff(int width, int height, unsigned int color, float phase, float scale)
{
	int pxcount = 0;
  int xs = 2, ys = 2;
  float w = width;
  float h = height;
  float b = w*w;
  int x;
  float i;
  for(x=0; x<width; x+=xs) {
    float s = (float)x*(float)x;
    float p = sqrtf(b - s);
    int m,n;

    for(i=-p; i<p; i+=6*ys) {
      float r = sqrtf(s+i*i)/w; // sqrt(s+i*i)/w;
      float q = (r-1)*sinf(10.0f*r+phase);
      int y = (int)(i/3.0f+q*h);

      if (i == -p) {
        m = y;
        n = y;
      }
      if (y > m)
        m = y;
      if (y < n)
        n = y;
      if (m == y || n == y) {
        int x1 = scale*x/2;
        float y1 = height/2.0f - scale*y/2.0f;	// int
        int xp1 = width/2+x1;
        int xp2 = width/2-x1;

        (*f)(xp1, y1, color);
        (*f)(xp2, y1, color);
        pxcount += 2;

      }
    }
  }
  return pxcount;
}

Plot function used to draw into RAM of ARM - there are no boundary checks here. The frame buffer is for a 256*192 bitmap.

#define WIDTH dimx
#define HEIGHT dimy

__attribute__( (long_call, section(".data.$RAM2")))
void framebuf_plot(int x, int y, unsigned int color) {
	unsigned char *p = monofp[0] + WIDTH/8*y + (x>>3);
	*p |= 1 <<  (7-(x & 7));
}

 

 

[speccery]

2 hours ago, Tursi said:

Yeah, but if people can load any ARM code they want, then a developer who wants that can load a TMS9900 emulator and be done. No need to invent every possible use in advance

 

So true  

[+9640News]

2 hours ago, speccery said:

I had to dig up my notes to see where the original program came from. After digging for a while it was no surprise to notice it came from Stuart's pages. (I couldn't insert his AA handle here since there are quite a few Stuarts in here and right now I forget which was is his - but credits go to him).

You can find it here: http://www.stuartconner.me.uk/tms99110_breadboard/tms99110_breadboard.htm

There are also some interesting benchmark results there. Need to check how fast this would go in TI BASIC or TI Extended BASIC, running it without plotting should give a good idea.

 

The run time on the StrangeCart without data transfer to TMS9900 is currently 18ms (milliseconds). Almost all of the runtime is spent running C-library sinf() and sqrtf() functions (single precision sin and square root). There are ARM optimised versions of these but I haven't tested them yet, I expect them to be quite a bit faster. I am curious to check them out.

 

Here is the C-code:

  Reveal hidden contents

Header:

typedef void (*plot_func)(int x, int y, unsigned color);

void set_plot_func(plot_func myfunc);
int draw_stuff(int width, int height, unsigned int color, float phase, float scale);

Implementation:

plot_func f = dummy_plot;

void set_plot_func(plot_func myfunc) {
	f = myfunc;
}

__attribute__( (long_call, section(".data.$RAM2")))
int draw_stuff(int width, int height, unsigned int color, float phase, float scale)
{
	int pxcount = 0;
  int xs = 2, ys = 2;
  float w = width;
  float h = height;
  float b = w*w;
  int x;
  float i;
  for(x=0; x<width; x+=xs) {
    float s = (float)x*(float)x;
    float p = sqrtf(b - s);
    int m,n;

    for(i=-p; i<p; i+=6*ys) {
      float r = sqrtf(s+i*i)/w; // sqrt(s+i*i)/w;
      float q = (r-1)*sinf(10.0f*r+phase);
      int y = (int)(i/3.0f+q*h);

      if (i == -p) {
        m = y;
        n = y;
      }
      if (y > m)
        m = y;
      if (y < n)
        n = y;
      if (m == y || n == y) {
        int x1 = scale*x/2;
        float y1 = height/2.0f - scale*y/2.0f;	// int
        int xp1 = width/2+x1;
        int xp2 = width/2-x1;

        (*f)(xp1, y1, color);
        (*f)(xp2, y1, color);
        pxcount += 2;

      }
    }
  }
  return pxcount;
}

Plot function used to draw into RAM of ARM - there are no boundary checks here. The frame buffer is for a 256*192 bitmap.

#define WIDTH dimx
#define HEIGHT dimy

__attribute__( (long_call, section(".data.$RAM2")))
void framebuf_plot(int x, int y, unsigned int color) {
	unsigned char *p = monofp[0] + WIDTH/8*y + (x>>3);
	*p |= 1 <<  (7-(x & 7));
}

 

 

Thanks for the link.  I think I will play with that code and see what can be generated first under Geneve Advanced Basic.

Beery

[+Lee Stewart]

2 hours ago, speccery said:

I had to dig up my notes to see where the original program came from. After digging for a while it was no surprise to notice it came from Stuart's pages. (I couldn't insert his AA handle here since there are quite a few Stuarts in here and right now I forget which was is his - but credits go to him).

You can find it here: http://www.stuartconner.me.uk/tms99110_breadboard/tms99110_breadboard.htm

There are also some interesting benchmark results there. Need to check how fast this would go in TI BASIC or TI Extended BASIC, running it without plotting should give a good idea.

 

Stuart’s AA handle is @Stuart.

 

...lee

[+9640News]

2 hours ago, Lee Stewart said:

 

Stuart’s AA handle is @Stuart.

 

...lee

Here's the graphic generated under Advanced Basic on the Geneve under MAME emulation.

 

I'm including the program and a jpeg of the listing.  I was actually a bit surprised at the syntax to see Advanced Basic as versatile as it was.

 

 

STRANGE

[speccery]

5 minutes ago, 9640News said:

Here's the graphic generated under Advanced Basic on the Geneve under MAME emulation.

 

I'm including the program and a jpeg of the listing.  I was actually a bit surprised at the syntax to see Advanced Basic as versatile as it was.

Thanks @9640News! I don't think I've ever seen a BASIC listing for the Geneve, apparently the syntax is similar to TI Extended Basic with twin colons. What was the speed like? I suppose this Basic is not doubly interpreted and the TMS9995 is faster than TMS9900 at least when workspace is in internal RAM.

[+9640News]

It took something like 6 to 8 minutes on my work laptop which I do not think runs at 100% speed on MAME. I will test the program this evening on my Geneve and report a true speed for @Stuart should he want to include the information on his webpage.  I am assuming you must have added another variable to get the moving graphic implementation.

 

Now that I have the basic code, I may just see what I can do with straight assembly under MDOS taking the basic interpreter out of the equation.

 

I think what it does show, as we already knew from your demo, the strangecart is very fast!!!  If you get to the point of commercially offering them, I would be one of your buyers.  Not sure at the present what I could implement on it, but I would be at least to see what I might be able to accomplish.

 

[+mizapf]

Time on my MAME emulation: 7 min 43 sec (using ABASIC4)

[+9640News]

3 hours ago, mizapf said:

Time on my MAME emulation: 7 min 43 sec (using ABASIC4)

Time on my Geneve, 8 min 47 sec MEM command reports 0 fast memory free pages

Time on my Geneve, 8 min   1 sec MEM command reports 5 fast memory free pages (after a & statement at MDOS prompt to clear some memory)

Time on my Geneve, 8 min   1 sec MEM command reports 7 fast memory free pages (nothing in AUTOEXEC)

 

 

 

 

[speccery]

14 hours ago, 9640News said:

It took something like 6 to 8 minutes on my work laptop which I do not think runs at 100% speed on MAME. I will test the program this evening on my Geneve and report a true speed for @Stuart should he want to include the information on his webpage.  I am assuming you must have added another variable to get the moving graphic implementation.

 

Now that I have the basic code, I may just see what I can do with straight assembly under MDOS taking the basic interpreter out of the equation.

 

I think what it does show, as we already knew from your demo, the strangecart is very fast!!!  If you get to the point of commercially offering them, I would be one of your buyers.  Not sure at the present what I could implement on it, but I would be at least to see what I might be able to accomplish.

 

Yes, I did another variable. If you look at the C-code in the spoiler, you can find two new variables: phase and scale. In the video only the phase parameter is used to vary the phase of the curves. After taking the video I also added the scale parameter, which allows changing the scale, but if "zooming in" it currently does not look too great as there are some breaks in the curves - the loops should be adjust a little accordingly.

 

I will add you to the list of people who are interested in the boards. I am trying to get to a point where I could start to offer the boards, I have acquired now components and PCBs for about 20 boards, which would be the prototype/first batch. Hand assembling the boards is certainly a chore, but with the present shortage of chips I figured its best to be a bit self sufficient. I just wish the present heatwave we are "enjoying" here in Finland would ease a bit so that I could me productive.

[Stuart]

16 hours ago, 9640News said:

Time on my Geneve, 8 min 47 sec MEM command reports 0 fast memory free pages

Time on my Geneve, 8 min   1 sec MEM command reports 5 fast memory free pages (after a & statement at MDOS prompt to clear some memory)

Time on my Geneve, 8 min   1 sec MEM command reports 7 fast memory free pages (nothing in AUTOEXEC)

That is *way* slower than I was expecting. A 9900 running with no wait states can do it in a little over 5 minutes.

[+9640News]

37 minutes ago, Stuart said:

That is *way* slower than I was expecting. A 9900 running with no wait states can do it in a little over 5 minutes.

I assume that is a program written entirely in assembly?  The data above was running under Advanced Basic, using the video XOP's for the video writes and math routines instead of direct video writes and no embedded assembly for the math routines.

 

Beery

[Stuart]

1 hour ago, 9640News said:

I assume that is a program written entirely in assembly?  The data above was running under Advanced Basic, using the video XOP's for the video writes and math routines instead of direct video writes and no embedded assembly for the math routines.

 

Beery

Nope, all done in Cortex BASIC.

[+mizapf]

19 hours ago, 9640News said:

Time on my Geneve, 8 min 47 sec MEM command reports 0 fast memory free pages

Time on my Geneve, 8 min   1 sec MEM command reports 5 fast memory free pages (after a & statement at MDOS prompt to clear some memory)

Time on my Geneve, 8 min   1 sec MEM command reports 7 fast memory free pages (nothing in AUTOEXEC)

 

Hmm, 3.75% too fast on the emulation ... should be better ... I'll check with my own real Geneve. Maybe this comes from the video wait states that I was not yet able to emulate precisely by the cycle.

[Reciprocating Bill]

Time on my 16-bit 99/4a running Cortex Basic (the version running strictly out of RAM) is 5 min, 58 seconds. 

 

(Is that Walter White under the hat?)

[Reciprocating Bill]

Running Cortex Basic out of the FinalGrom (rather than all in 16-bit RAM), Walter is complete in 6 minutes, 31 seconds (same console).