home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.sys.tandy      Life is dandy cuz you're gettin a Tandy!      5,684 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 5,171 of 5,684   
   Joe Hagen to George Phillips   
   Re: Anyone Know Why This Is ....   
   04 Feb 10 05:22:41   
   
   70b8b9c3   
   From: jdhagen@chorus.net   
      
   On Wed, 03 Feb 2010 20:46:04 -0800, George Phillips wrote:   
      
   > On Feb 3, 8:09 pm, Ira  wrote:   
   >> YUP!   ... now about those REMS :)   
   >   
   > Heh, working on it.  The preliminary indicators are too good not to   
   > report.  I used my emulator's trace function to record every instruction   
   > the Z-80 CPU was executing.  I captured what it did from just before the   
   > first  to the READY prompt.  And did another capture after   
   > ' was typed until it when back to MEMORY SIZE?   
   >   
   > Clearly whatever it does in the crash case is wrong.  After looking at a   
   > few differences one big one jumped out.  The Z-80 ran from $FBFB all the   
   > way up to the end of RAM.  Which takes it back to 0 where it always   
   > starts on boot.  So that's how you get back.  But why did that happen?   
   >   
   > Normally the high memory wouldn't be initialized so anything could   
   > happen when the Z-80 jumps there.  But the path to the end was very   
   > regular.  In fact, it was a series of instructions with opcode $FB. Him   
   > again!  BTW, $FB is EI -- enable interrupts not expansion interface.   
   >   
   > This all comes as no coincidence when you fold in one more fact.  The   
   > apostrophe abbreviation for REM is tokenized internally to $3A $93 $FB.   
   >   
   > There's certainly enough evidence for a conviction.  When either   
   > tokenizing the input or processing the input BASIC got confused and   
   > decided to keep copying $FB into memory.  It didn't stop until it filled   
   > all of memory with $FB.  Or at least enough of memory until some   
   > critical vector was overwritten with $FBFB.  BASIC jumped to that vector   
   > and that was it.   
   >   
   > In short, BASIC crashed hard.  But exactly why it started trashing   
   > memory I don't know yet and that's the interesting part.  I can almost   
   > guess the bug at this point.   
   >   
   > I'll see if I can come up with a patch for the problem, but you might be   
   > better off getting an official bug fix.  You'll be able to find the   
   > programmers easily enough.  It'll either be Paul Allen or Bill Gates.   
      
   I tried this under the Keil, Vavasour, Reed, and TRS80GP emulators, and   
   they all reset.   
      
   Wait a minute, I think George did the TRS80GP emulator, so he's   
   likely to figure this out.   
      
   I even booted into Vernon Hester's Multidos and tried this in   
   Superbasic with the same result.  I'm not sure if Superbasic   
   calls into the normal BASIC ROM or is self-contained, but it   
   seems to take the same code path, so there must be some   
   common code.   
      
      
   Joe   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca