6502.org Forum Projects Code Documents Tools Forum
It is currently Sun Nov 24, 2024 4:41 am

View unanswered posts | View active topics


Board index » 6502.org Users Forum » Hardware

All times are UTC




Post new topic Reply to topic  Page 1 of 1
  [ 3 posts ] 
  Previous topic | Next topic 
Author Message
BigDumbDinosaur
PostPosted: Tue Aug 27, 2024 4:53 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
I’ve been monkeying with POC V1.4, which had been collecting dust ever since it got built and subjected to some testing late in 2022.  Unlike its predecessors in the POC V1.x series, V1.4’s glue logic is in a 22V10 GAL.  I was suspecting that the GAL wasn’t behaving as expected, so I constructed a GAL test rig to confirm or debunk my suspicions (they were debunked).

Anyhow, I hooked up V1.4 to the logic analyzer to observe general circuit behavior and captured what the 65C816 was doing during reset:

Attachment:
File comment: Annotated Reset Sequence, 20ns Resolution
reset_v1.4_annotated.gif
reset_v1.4_annotated.gif [ 131.53 KiB | Viewed 319 times ]

I set the logic analyzer to a fairly low resolution of 20 nanoseconds, since my interest was in capturing all activity up to the fetch of the first instruction (an SEI) of the reset handler, which commences at $00D000.  Due to the relatively-coarse resolution, things may look to be a little out of proportion, especially the Ø2 clock signal.

The capture begins shortly before reset clears.  As with the 65C02, the 65C816 goes through an initialization sequence that consumes six full clock cycles following the rise of reset.  During this initialization, a seemingly-random location in ROM is accessed with both VDA and VPA asserted, which means the 816 is in an opcode-fetch cycle.  The ROM address actually corresponds to the MSB of the emulation-mode IRQ vector, which vector is populated with $FFFF—that part of the ROM is not programmed.

Following the spurious ROM access, three spurious stack accesses occur that appear to be pushes due to the address decrementing following each access. The accesses seem to imply an interrupt-like sequence is occurring, since in emulation mode, PC and SR would be pushed, a total of three bytes.  However, /WD (write data) is not asserted during those accesses, so RAM remains undisturbed.

Immediately following the spurious stack activity, the 816 is ready to start processing.  The address of the reset code is fetched from the reset vector at $00FFFC and we’re off to the races.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
8BIT
PostPosted: Tue Aug 27, 2024 6:19 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
Interesting.... I wonder if those wait states are responsible for your E mode LED being on so long? We understand the cycle counts but it appears not all cycles have the same period.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Tue Aug 27, 2024 6:29 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
8BIT wrote:
Interesting.... I wonder if those wait states are responsible for your E mode LED being on so long? We understand the cycle counts but it appears not all cycles have the same period.

The seemingly-asymmetric clock is due to the coarse resolution at which the logic analyzer is operating.  A real wait-state produces a noticeably-longer Ø2 high phase...also, /WSE will be low at that time.

Early in the reset code, I have a delay loop that runs while still in emulation mode so as to prove that the MCE (E-mode) LED is functioning.  The above capture ends shortly after the MPU has fetched the first instruction of the reset code.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 1 of 1
  [ 3 posts ] 

Board index » 6502.org Users Forum » Hardware

All times are UTC


Who is online

Users browsing this forum: Google [Bot], Google Feedfetcher and 65 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
6502.org is an ongoing project by Mike Naberezny and contributors.