6502.org Forum Projects Code Documents Tools Forum
It is currently Sun Nov 24, 2024 2:35 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 4 of 4
  [ 50 posts ]  Go to page Previous  1, 2, 3, 4
  Previous topic | Next topic 
Author Message
8BIT
PostPosted: Sun Jul 20, 2014 2:44 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
Glad to see some positive results!!

_________________
Please visit my website -> https://sbc.rictor.org/
Top
 Profile  
Reply with quote  
Klaus2m5
PostPosted: Sun Jul 20, 2014 9:55 am 
Offline

Joined: Sat Jul 28, 2012 11:41 am
Posts: 442
Location: Wiesbaden, Germany
Good to hear it is fixed and it is not a reset issue.
8BIT wrote:
Hi Klaus,

I tested your code and it indeed works. One issue that many cause a problem is the possibility of a misguided write to the VIA SR or to the V_idle byte will get the handshake bit out of sync. If that happens, the video output will lock up. If adding the delay in the reset fixes the problem, I think its best to keep the handshaking the way it is. If not, then we may need to explore this option further.

Thanks again for your contribution!

Daryl
You are welcome! I need to make you aware of one of my earlier posts:
Klaus2m5 wrote:
...The 8 µs minimum duration of pb7-hs=1 after a write to the AVR internal shifter may still not be enough, if an interrupt delays the loop after label VOutput1...
...waiting for the AVR to signal busy.

This was not an issue in Martin's case, but when users start to experiment with interrupts it may cause the video driver to miss the busy window of the AVR and lock up, unless it is only called with interrupts disabled. That was another reason for the proposed change, but of course there are other ways to fix it.

The possibility of a misguided write to the VIA SR or to the V_idle byte getting the handshake bit out of sync is of course a valid concern. It would take a timeout detection in the video driver to detect and cure such problems.

The minimum fix for the video driver to prevent it from missing the busy window if interrupted by IRQ:
Code:
;----------------------------------------------------------------------
; Output contents of A to the Video Display
;  A & Flags are preserved.
;----------------------------------------------------------------------
VOutput
                php                 ;* save flags including IRQ disable
VOutput2
                bit  Via2PRB        ;  read handshake byte (pb7)
                bmi  VOutput2       ;  if pb7=1, wait for AVR to be ready
                sta  Via2SR         ; send to display via shift register
                sei                 ;* disable IRQ during wait for busy
VOutput1
                bit  Via2PRB        ; read handshake byte
                bpl  VOutput1       ; if pb7=0, wait for AVR to ack
                plp                 ;* restore IRQ disable state
                rts
                                    ;* = hotfix to prevent video driver to
                                    ;    miss the busy window when IRQed
An NMI could still cause the video driver to hang.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5
Top
 Profile  
Reply with quote  
RichCini
PostPosted: Sun Jul 20, 2014 1:01 pm 
Offline
User avatar

Joined: Wed Sep 03, 2003 6:53 pm
Posts: 153
Location: Long Island, NY
Klaus/Daryl --

Thanks for this fix, Klaus!

No, so that I get this right, the consensus is to make the fix ONLY to the video driver code as Klaus recommends, or am I to also make the earlier change Klaus recommended to the firmware in the AVR itself? It seems that the latest post contradicts the earlier one here http://forum.6502.org/viewtopic.php?p=34133#p34133 .

Thanks!

_________________
Rich Cini
Build Master and maintainer of the Altair32 Emulation project
http://cini.classiccmp.org
http://altair32.classiccmp.org
Top
 Profile  
Reply with quote  
Klaus2m5
PostPosted: Sun Jul 20, 2014 3:12 pm 
Offline

Joined: Sat Jul 28, 2012 11:41 am
Posts: 442
Location: Wiesbaden, Germany
Rich,

as it is now, both fixes are not optimal. The first fix lacks a timeout in case the video driver gets out of sync with the ATMega88. The second fix fixes only IRQ and not NMI at the cost of a disabled IRQ for the time that the ATMega88 finishes drawing a line on the CRT. Let's see, which way Daryl wants to go. If you are currently not using 6502 interrupts for anything, then there is currently no issue and no need to apply either fix.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5
Top
 Profile  
Reply with quote  
8BIT
PostPosted: Sun Jul 20, 2014 4:05 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
Rich/Klaus,

This has been a good discussion. I agree that the 8us timer is not optimal. I was running my SBC-4 at 12MHz and with the original code, the display was missing data. It didn't freeze up, but having missing characters is not acceptable. If the SBC-2 user decided to increase the clock above 1MHz (I ran my SBC-2 at 5MHz), It could become an issue. Using Klaus' toggle method allowed my 12MHz machine to run without locking up or missing characters. However, the possibility of user code getting the system out of sync needs to be addressed.

Since Martin's issue seems to be resolved for the moment, lets not change anything yet. I would like to come up with a more secure solution if possible.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 4 of 4
  [ 50 posts ]  Go to page Previous  1, 2, 3, 4

Board index » 6502.org Users Forum » Hardware

All times are UTC


Who is online

Users browsing this forum: No registered users and 39 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.