SuperCart Construction

[Stuart]

Actually, looking at the SuperCart construction notes, there's already a resistor between pins 27 and 28. If you've built the SuperCart using a TI game cartridge as per http://www.mainbyte.com/ti99/supercart/supercart_4bank.html, then you should be able to write protect the RAM simply by inserting a switch in the wire between the 3rd edge connector pin and pin 27 of the RAM. 

[GDMike]

I'm wondering if I have that resistor.

Edited November 17, 2019 by GDMike

[GDMike]

Is it one of these? I wonder..

[GDMike]

I'll try to explain what's going on with my e/a notes program, I hope you can follow along. 

Im using an 8k supercart. The code sets up the ea cart menu from the TI main menu as written following the supercart assembly instructions on whtech. It uses no REFs. But after loading that program from dsk as it aorgs in >6000 and works every time I load it from dsk but if I select the option for the cart from the main menu it never runs a second time or after a reboot. But always after loading from dsk the first time. And it doesn't matter from what I gather what the program is doing that follows the code that creates the header code I call it, the aorg section of the main program. In this case I'm just moving memory locations, no VSBW or anything requiring a util.

Edited December 11, 2019 by GDMike

[+FarmerPotato]

Do you mean that inside EA load and Run, you run it once by entering “START” but it never works from the title menu?

 

it might be that VDP is not set up the way you think it is, from your experience running it from EA. 

 

THAT IS, the screen image table and charset is not where you think it is. So maybe your program appears to do nothing? Good practice is for a cartridge to assume nothing. It should set up all VDP registers the way it wants, load a charset, clear the screen etc. we can help you with sample code. or you could look the source for the Hopper cartridge. 

[GDMike]

I'll include the 2 programs.

 

Edited December 11, 2019 by GDMike

[GDMike]

Oops, outta order. But this file is the cart loader. BTW >A038 is my address for start.

 

Edited December 11, 2019 by GDMike

[GDMike]

And this program I want to run from high ram but temp store it in the cart until you select the cart in at that time it moves the program to high ram and runs it. This seems to be ok. But the loader cart program seems to be having trouble.

Edited December 11, 2019 by GDMike

[GDMike]

So what this does is it moves the eanote program into high ram, then I move it into the cart. Then when you select the cart it pushes it back to high ram and runs it.

But something is Happening to the cart loader.

 

[GDMike]

39 minutes ago, FarmerPotato said:

Do you mean that inside EA load and Run, you run it once by entering “START” but it never works from the title menu?

 

it might be that VDP is not set up the way you think it is, from your experience running it from EA. 

 

THAT IS, the screen image table and charset is not where you think it is. So maybe your program appears to do nothing? Good practice is for a cartridge to assume nothing. It should set up all VDP registers the way it wants, load a charset, clear the screen etc. we can help you with sample code. or you could look the source for the Hopper cartridge. 

Nope, it always performs when everything is loaded. Until a reboot. But I never have to reload the program that gets pushed to high ram, only the cart setup program is what seems to fail.

Edited December 11, 2019 by GDMike

[GDMike]

I'm wondering if both programs have to be converted to PRG format vs dis fix 80.

[Tursi]

It's difficult to debug from a couple of screenshots. Have you tried a debugger on the code to see where it fails?

 

But after loading that program from dsk as it aorgs in >6000 and works every time I load it from dsk but if I select the option for the cart from the main menu it never runs a second time or after a reboot.

 

To me, this line says to look at your memory access patterns - something is being corrupted. Where do you store your runtime data? It's not in the supercart by any chance, maybe where the program sits?

 

[GDMike]

The program I've ruled out due to the fact that this happens regardless if a program is there or not. My header 'title' that is constructed remains intact, but afterwards the program seems to lock. But a simple reload gets it working. I'm talking about the actual cart definition routine that accompanied the cart construction example. I'm still trying to find another cart creation file..or docs on it..I think, if this is plausible, the ref def table gets lost. In this case there is no ref table. But basically after creating the cart it seems to work for me as long as I don't shutdown With or without my second program. I know this is hard to explain..but I put a video there as well.but if you take into account that the problem exists without the second program. Works once as described..

Thanks so much for chiming in...im really homing in on the def table..where does that get created and does it get blown away at shutdown? I read somewhere about that getting built at load time.??

Forgive me if you will, as I'm just irritated. I completely changed my program and method because I had this problem last month and so I figured that a table somewhere was getting corrupted and it's definitely in the cart creation side. I couldn't put my finger on it then so I figured, ok let's store my real program, the one that the cart is supposed to load, and let's pull it from high mem at load time into a safe area inside the cart and at cart menu selection well just push it back to high mem and run it from there.and it appears it works flawlessly, except one thing, the cart menu program seems to get lost because it's only when I dump ram, which if the cart was self sustainable, then it shouldn't matter if the computer went off, as my main program never has to be reloaded.. but always having to reload the cart def program...ooh..tsk tsk

I'm going for a walk...lol thank you all For letting me rant...oh, this isn't that section...

Edited December 11, 2019 by GDMike

[GDMike]

Ok, I've never seen John's source code for hopper. I'll try working through it with his code. I'm determined.

[Tursi]

REF/DEF table is stored in low 32k memory expansion, building down from >3FFF. But if you have no refs and no defs, then you shouldn't care about that table.

 

Where are the program's variables stored? Is the initialization code capable of running more than once, and (more importantly) does it make NO assumptions about starting state? When you EA#3 load any memory that you are initializing with "DATA", for instance, is loaded regardless of where it was, but if you are running as a cartridge then it's your job to manually initialize all that memory with code. These are the sorts of things I'd be looking at.

 

[GDMike]

I think I found my problem, yes it was in the way I set up the header..I found, get this, a doc by Jon Guidry, with special thanks to Tursi, Stuart, Conner and Bob Carmany.

Haha.. this is funny, talking bout around the world... this illustration is basically what I'm building, moving a Program from the cart to high ram.. similar to this but not quite the same thing here..

And it's funny..I had extra Data points iny header, but without knowing how the header works I'm completely lost. This doc explains every byte value. I usually do ok trying to figure how my code will run, but creating the header in a cart is new for me. Sorry to waste y'all's time...I found the SOURCE I needed. Omg thank you so much for making that. It's going in my library..

[Opry99er]

Please link to that document.   

[GDMike]

I printed it out .I'll try to go back online and see..

[GDMike]

 

http://www.stuartconner.me.uk/ti/ti.htm#bank_switching

Edited December 11, 2019 by GDMike

[GDMike]

Ahh..I thought it would work..i mean, it does work. But now it's my other program that works once then not again after a shutdown. Hey, but the cart header is doing well. 

what I have going on now is I'm wanting to move the compiled program that is sitting at >6500 and I want to push it to >A000 and then Blwp to it. And it works each and every time until I do a shutdown and select the cartridge again, except this time it's a blank screen.

Ahh..is this the part you were talking about, that I would need to load a chardef perhaps? I just thought it was odd it ran from the cart initially but after shutdown it doesn't. So I'll go ahead and throw in my chardef and try again..

[+Lee Stewart]

I am with @Tursi in that without a printout of the program in front of me, it is really difficult to follow what your program is doing. I am accustomed to running programs in the >6000 – >7FFF CPU space as ROM code that cannot be overwritten, so I would never use any address in that space as my workspace as you seem to be doing back in post #32. As long as this space is actually RAM, it should be OK, so I will proceed, expecting that space is always writable.

 

I am pretty sure your problem is with 

       BLWP @HR

The operand for BLWP must be the address of a vector consisting of two 16-bit values. The first must be the address of the new workspace and the second, the address of executable code to which to branch. The address you gave BLWP is not the required vector. Instead, it is an executable instruction, but BLWP does not know that, so it interprets the code for LWPI (>02E0) as the address (somewhere in console ROM) of the new workspace and WS as the branch address, which initially likely contains only zeros. I really do not know what branching to an address containing >0000 does, but it seems that it might just continue incrementing the PC (program counter) register until it hits a nonzero value, which is

START  LWPI WS

which dutifully changes the workspace to WS and proceeds as you intended. However, when you attempt to execute it from the cartridge the second time the WS block has nonzero values scattered through it and the CPU chokes.

 

You can do either of two things to correct the problem. (1) Change the START line to

START  DATA WS,$+2

$+2 points to the word following itself, which is 

       LIMI 0

No addresses change with the above modifications because the START line still contains 2 words (4 bytes).

 

Or (2) change the BLWP to a B. You really do not need a context switch with the explicit change you are making with LWPI. And, I do not see where you are restoring the context switch with RTWP, anyway:

       B    @HR
STOP   LIMI 2
  ...

Again, no addresses should change, so your EQUates should still work.

 

...lee

[GDMike]

Very enlightening. I did btw change the blwp to a B @ >A038. I had actually changed this per the new docs I found.

Can't wait to try again with my ws change. Thank you for chiming in

[GDMike]

I did change a couple things.

I did the 'start data,ws+2" which points to limit 0. AND I added a chardef to my notes program. I compiled,ran and again it works without shutdown, but after shutdown I get a blank screen, as I had been getting prior. Note; the chardef is not within this program, but in the eanote program.

The listing Below "ends" at the next line, thank you.

 

 

I'm

Edited December 12, 2019 by GDMike

[+Lee Stewart]

You cut off the labels. The program cannot be read without them.

 

Also, if in fact, START is the label for the DATA directive, you should not be branching to it because WS is an address, not an executable instruction. I think you are mixing up what B and BLWP actually do:

       B    @ADDR
       ...
ADDR   MOV  R1,R2
       ...

B branches directly to ADDR to execute the instruction there—MOV in this case.

 

       BLWP @ADDR
       A    R5,R7
       ...
ADDR   DATA >8300,ADDR2
       ...
ADDR2  MOV  R1,R2
       ...
       RTWP

BLWP performs an indirect branch through the vector, which is the word at ADDR+2. It first performs a context switch by changing to the workspace indicated by the word at ADDR (>8300 in scratchpad RAM in this case) and saving the old WP, PC and ST CPU register values into the new R13, R14 and R15, respectively, to allow a return context switch to the previous environment. Then BLWP branches to ADDR2 to execute the MOV instruction. When RTWP executes, the previous environment is restored and the instruction (A in this case) following the BLWP is executed.

 

DATA is not an instruction. It is an Assembler directive that stores the words (16-bit values) that follow it, where it appears in the code.

 

...lee

[GDMike]

Understood. Changed  "entry" from

B @start

to 

Entry EVEN

with the next command being

START data,$+2

And that didn't seem to Change the output, although it's more precise