CORTEX BASIC

[apersson850]

5 hours ago, TheBF said:

If TI had understood where the future of desktop machines was going your architecture with a 99000 processor could have challenged the IBM PC.

I've not used the Commodore 64, but I think it's similar to how that worked.

Some computers with this kind of architecture use write through, so that writing to ROM will end up in RAM even if the RAM is not enabled. In such a case you can copy ROM to RAM by simply MOV *R1,*R1+, since that will imply reading the ROM pointed to by R1 and then storing it in RAM, pointed to by the same register.

If I want to copy a memory block, the most efficient way is to read it from ROM to an unused RAM segment, enable RAM where the ROM is and copy back.

It's not necessary, but otherwise I have to enable/disable the RAM between each word transferred.

 

But since the TI 99/4A has memory mapped IO in the 8000-9FFF block, I can't do write through, or writing to the VDP addresses would end up in RAM instead. If I enable RAM in the block 8000-9FFF, I can't reach VDP, sound and such stuff. Likewise, if I enable RAM in 4000-5FFF, no DSR calls will be possible.

My system also allows the standard memory expansion to exist in parallell, since I simply disable internal RAM at 2000-3FFF and then the standard 8-bit low memory expansion is available instead. So with the 32 K RAM expansion in the box, my console has access to 96 K CPU RAM and 16 K VDP RAM at the same time.

 

Even if the ambition wasn't to take on the IBM PC, it would still have been a very capable machine back in 1982. Just imagine how the assembly enthusiasts would have explored it.

Edited August 10, 2023 by apersson850

[senior_falcon]

Here is a package that will make a 4 bank rom cartridge containing both Cortex BASIC and a program of up to 8K written in Cortex Basic. If by some chance there is a flurry of activity using Cortex BASIC and people want to make carts with programs longer than 8K, then I will revisit this and try to pack a longer program into the cart. Everything you need is in the folder. including some sample programs. The cartridge maker runs from Extended BASIC and Classic99.

CORTEXCARTRIDGE.zip

 

[+TheBF]

On 8/7/2023 at 8:04 AM, senior_falcon said:

In theory most, maybe even all, of the interpreter could be kept in the cartridge ROM, which would free up more memory for the BASIC program. But that's not how Stuart did it, and making a change like that is way beyond my abilities or interest level.

Apparently your abilities are much higher than you admit to.  

This is amazing. 

What a super contribution to the group. 

[senior_falcon]

22 hours ago, TheBF said:

Apparently your abilities are much higher than you admit to. 

 

Of course, I know a few things about the TI. But there are large gaps in my knowledge, and much of what I do is to find creative workarounds for my ignorance.

 

For example, auto loading in Cortex. I know very little about Cortex, but I do know that if you type LOAD "DSK8.GP" it will load and run the program named GP.

Is there a way to fool Cortex into thinking those characters were typed? With the debugger, I found where the keyscan routine is and instead of doing the keyscan I branch to a few lines of code I added that will put those characters where they would go if I had actually typed them. (I forget the exact address but it is around >FBC8) I then put >0D at >8375 and set the status byte to indicate a new key was pressed. And of course the Cortex code must then be restored so it can then actually do a keyscan. Lo and behold, it autoloads GP from disk.

 

For loading from disk, I know where I put the BASIC program in the cartridge, and from using the debugger, I know where it goes in ram. But I can't just move the program because cortex will not know it has been loaded. How do I fool Cortex into thinking that it actually loaded it from disk? Using the debugger I was able to find DSRLNK. I modified that to go to another short assembly routine that replaces DSRLNK. There are 3 things that happen when Cortex reads a program. It opens the file, it reads the file, and it closes the file. For open, my routine reports no error, so Cortex thinks the file was opened properly. For read, my routine changes a length value to 1 so that cortex only moves 1 byte out of the buffer and then decides it is done loading the program. For close, I move the program to the proper place in ram, update the length in the workspace, fix dsrlnk so it will now work properly, and return. Cortex doesn't know that I played a trick on it. Because there are no errors, it assumes the program was loaded normally and goes on from there.

 

Edited August 12, 2023 by senior_falcon

[+FarmerPotato]

22 hours ago, Asmusr said:

I didn't even know that BLWP R8 was a valid instruction. 

Heh..

I still have trouble thinking it through. 

(Moving to Assembly Language Tricks)

 

See also:

Application Note "Stack Structures on the TMS9900"

Maybe included in:

TMS9900 Family Systems Data book,

Also

TI Software Development Manual (2nd Ed)

(Most on Bitsavers.org)

[Reciprocating Bill]

My assembly version of "Lines" (16-bit console, based on senior-falcon's Cortex BASIC version):  

 

 

Edited August 23, 2023 by Reciprocating Bill

[+TheBF]

11 hours ago, Reciprocating Bill said:

My assembly version of "Lines" (16-bit console, based on senior-falcon's Cortex BASIC version):  

 

 

Lines Assembly.mov 11.51 MB · 2 downloads

 

That is a thing of beauty, and a thing of beauty is a joy forever as a workmate of mine used to say. 

 

I would love to see how that code does what it does if that's possible. 

Edited August 23, 2023 by TheBF
typo

[Reciprocating Bill]

10 hours ago, TheBF said:

I would love to see how that code does what it does if that's possible.

E/A source ("LINES4") and option3 executable ("LINES4O") attached. Program name "START."  Hold option Quit to exit.

 

I found an optimization, so this is a bit faster than posted above. 

LINES4 LINES4O

[+TheBF]

1 hour ago, Reciprocating Bill said:

I found an optimization, so this is a bit faster than posted above. 

Why am I not surprised. 🙂 

 

Thanks Bill.  It's good for me to see Assembler from a veteran.

 

I have this weird Assembler that's like Forth:

• 2 stacks built in
• colon/semi-colon for nestable sub-routines
• constants variables allot 
• Nestable down-counting FOR/NEXT loop 

The difference is you have to explicitly name the registers and variables in your code even stuff that's on the stack.

But it assembles native code. It's kind of fun to play with.

 

I translated your sieve benchmark to it and it runs in the same time frame.

If you are curious it's here: ASMFORTH/demo/ASMFORTH-SIEVE.8.FTH at main · bfox9900/ASMFORTH (github.com)

 

I will take a spin a translating your lines code to that language for my amusement. 

[Reciprocating Bill]

42 minutes ago, TheBF said:

It's good for me to see Assembler from a veteran.

 

More a jewel thief than a veteran. I borrowed from hither and yon. The Bresenham routine is a translation from the pseudocode in the Wikipedia article, combined with the E/A calculation for byte and bit offsets. I picked up the bit mask operation here somewhere. The RAND routine is purloined from TI's book, "16-Bit Microprocessor Systems" with, IIRC, a dash of Tursi wisdom, (the last few instructions, which constrain the output to the limit set in RNDLMT.) And, of course, the core routine is from senior_falcon's code in Cortex BASIC. 

[senior_falcon]

Your console has the 32K memory on the 16 bit bus. Since 2/3 of Cortex basic is in the 32K memory, it would be interesting to see how lines runs in that environment. (I don't know where the plot routine is. Would be easy to find out with the debugger, but I am at work.)

 

Oops - sorry. I see you posted that back on August 3rd.

Edited August 24, 2023 by senior_falcon

[Reciprocating Bill]

Here's another datapoint - Lines in Cortex BASIC running out of FinalGrom on a 16-bit console - so some of Cortex is running from cartridge space. Significantly slower than running purely out of 16-bit RAM, looking to me like the line drawing routine runs out of 8-bit cartridge space in this setup. 

[senior_falcon]

Here's another datapoint - Lines in Cortex BASIC running out of FinalGrom on a 16-bit console - so some of Cortex is running from cartridge space. Significantly slower than running purely out of 16-bit RAM, looking to me like the line drawing routine runs out of 8-bit cartridge space in this setup. 

 

Actually, the debugger shows the line drawing routine running from the 32K memory. There are things done in the cartridge rom, which probably involve processing the X and Y points

[Reciprocating Bill]

13 hours ago, senior_falcon said:

Actually, the debugger shows the line drawing routine running from the 32K memory. There are things done in the cartridge rom, which probably involve processing the X and Y points

Interesting. To my eye it appears that the lines themselves are drawing more slowly. But overall there is less than a 10% difference between Cortex running from all 16-bit RAM and running partially out of cartridge ROM, with this particular program.

 

Has anyone ever disassembled the TI/Minimem Lines program, or otherwise seen the source?

[senior_falcon]

1 hour ago, Reciprocating Bill said:

Has anyone ever disassembled the TI/Minimem Lines program, or otherwise seen the source?

Yes, but I am pretty sure I would not be able to find it. As I remember, I adapted the line plotting routine from Lines for The Missing Link. I can extract that and see how it compares. There are some things that make it a little slower in The Missing Link than it would be when running from assembly.

 

[Reciprocating Bill]

Ti's original LINES running out of MiniMemory, My LINES running out of 8-bit SuperCart memory, and My LINES running in 16-bit RAM

 

[senior_falcon]

It's pretty clear that your line drawing routine is quite a bit better than the TI one!!!

Guess I picked the wrong one to copy.