Jump to content
IGNORED

BLWP @0


Asmusr
 Share

Recommended Posts

Any chance this is related to why we have to cold-reset the computer after playing some carts: because of banking? Or are you playing EA5 renditions?

 

Yes it's for carts. I'm working on a 512K cart with all my games and I would like to be able to soft reset from each one.

 

Edit: and I have headers in all banks.

Link to comment
Share on other sites

In some of my programs I found the need to reset scratchpad bytes, particularly the user interrupt vector and a handful of other bytes. GPLWS R13,R14,R15 are reset by the BLWP @0 vector but there isn't much else done prior to the first allowed LIMI 2/LIMI 0 sequence, IIRC.

 

Yep, it turned out to be the user interrupt vector.

Link to comment
Share on other sites

Is this why all the sprites go to warp speed on the way to the title screen?

 

Yeah, for as long as you are holding QUIT, it ends up in a tight loop just executing the interrupt routine and nothing else.

 

But the QUIT always gets executed and the system always goes to reset. However, nearly all the system initialization happens in GPL, which is slow enough that the interrupt routine always gets executed at least once (and likely several times) before the user interrupt gets cleared. I found this many years ago when I tried to write a 4k asteroids... I was using the user interrupt for timing, and to save memory, it jumped directly into my program. As a result, hitting quit just sped it up for a few frames, and then it continued merrily along when you released it. ;) I spent a little time to understand why.

Link to comment
Share on other sites

If the user ISR hook is actually the problem, then that means the system *relies* on RAM being zeroed-out at power on. That is a really *bad* assumption / design flaw. I have never seen a RAM datasheet specify that the memory is in a known state at power-on. Usually it would be the opposite, i.e. unknown until set. The console power-on routine should reset the user ISR as one of its first tasks, and certainly before executing LIMI 2!

Link to comment
Share on other sites

It actually is the problem and there are a couple of bad assumptions in the scratchpad RAM regarding startup. :) You can read through the startup in TI Intern till the ISR is cleared. The reset code runs only 11 instructions before the GPL Interpreter enables interrupts. GPL then executes 14 GPL instructions, with the 14th one being a MOVE that zeros scratchpad from >83C2 to >83CA (interrupt hook at >83C4). There are four other MOVE instructions before that, including loading all the VDP registers - it takes far more than 1/60th of a second.

 

So why doesn't it crash more often on startup? There's more than the VDP necessary for an interrupt to fire. The CRU needs to be setup as well -- at startup the CRU bit for relaying the VDP interrupt is not configured, so the CPU doesn't get the interrupt.

 

I suppose that means the closest way to hardware to fully reset is to clear CRU bit 2, disable interrupts, and BLWP @>0000. :)

Link to comment
Share on other sites

 

And clearing the word >83C4 before BLWP ?

 

Not necessary if you clear the CRU bit, and the hardware doesn't do that. Matt is right that you can't guarantee the contents of RAM at startup. If the CRU bit is cleared, then the interrupt can't fire so the user interrupt hook never gets used.

 

But I still think just clearing the >83C4 word is sufficient too. :)

  • Like 1
Link to comment
Share on other sites

The TI programmers of TI Forth filled low expansion RAM (2000h – 4000h) with “NO” before executing BLWP @0. For fbForth, I changed that to zeroing 83C4h before executing BLWP @0.*

 

...lee

 

____________

* ...after consulting with @Tursi some time ago. :)

Edited by Lee Stewart
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...