Asmusr Posted November 1, 2015 Share Posted November 1, 2015 I find that sometimes (after playing my games) BLWP @0 fails to reset the computer properly (you end up on a blank cyan screen). Is there a way to soft reset the computer that always work? Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted November 1, 2015 Share Posted November 1, 2015 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? Quote Link to comment Share on other sites More sharing options...
Willsy Posted November 1, 2015 Share Posted November 1, 2015 Try LIMI 0 BLWP @0 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted November 1, 2015 Author Share Posted November 1, 2015 Try LIMI 0 BLWP @0 Thanks but I have LIMI 0 all the time. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted November 1, 2015 Author Share Posted November 1, 2015 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. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted November 1, 2015 Author Share Posted November 1, 2015 Perhaps the problem is with the usr ISR at >83C4? If I have used that address for something else, will that be cleared with a soft reset? 1 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted November 1, 2015 Share Posted November 1, 2015 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. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted November 1, 2015 Author Share Posted November 1, 2015 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. Quote Link to comment Share on other sites More sharing options...
Tursi Posted November 2, 2015 Share Posted November 2, 2015 Yeah, it's usually the ISR (which is guaranteed to fire before the console ROM clears it). You could use an ISR to technically defeat even a hardware reset switch and keep running. Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted November 2, 2015 Share Posted November 2, 2015 Is this why all the sprites go to warp speed on the way to the title screen? Quote Link to comment Share on other sites More sharing options...
Willsy Posted November 2, 2015 Share Posted November 2, 2015 Perhaps the problem is with the usr ISR at >83C4? If I have used that address for something else, will that be cleared with a soft reset? Good catch. I'll have to make sure TurboForth zero's that out when executing BYE. Quote Link to comment Share on other sites More sharing options...
Tursi Posted November 2, 2015 Share Posted November 2, 2015 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. Quote Link to comment Share on other sites More sharing options...
matthew180 Posted November 2, 2015 Share Posted November 2, 2015 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! Quote Link to comment Share on other sites More sharing options...
Tursi Posted November 3, 2015 Share Posted November 3, 2015 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. Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted November 3, 2015 Share Posted November 3, 2015 I suppose that means the closest way to hardware to fully reset is to clear CRU bit 2, disable interrupts, and BLWP @>0000. And clearing the word >83C4 before BLWP ? Quote Link to comment Share on other sites More sharing options...
Tursi Posted November 3, 2015 Share Posted November 3, 2015 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. 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted November 3, 2015 Share Posted November 3, 2015 (edited) 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 November 3, 2015 by Lee Stewart Quote Link to comment Share on other sites More sharing options...
apersson850 Posted November 4, 2015 Share Posted November 4, 2015 Filling low expansion with NO implies that the p-code card will not start. Or rather that it will exit again almost immediately. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.