View Single Post
Old 11 November 2020, 03:52   #1
SpeedGeek
Moderator
SpeedGeek's Avatar
 
Join Date: Dec 2010
Location: Wisconsin USA
Age: 57
Posts: 568
Lightbulb E clock speedup mod

Hello my fellow EABers!

As you probably know, I've spent way WAY too much time overclocking and hacking my A2630. But all of this time and effort was spent on the 32 bit "Fast" bus of the A2630.

So now, I have given some time and effort to the "Slow" bus on the A2000. I mean the snail SLOW bus on the A2000. The E clock bus!

So why bother to do a mod which tweaks the performance on the E clock bus? Because all a fast CPU can do is clock off wait states on the snail slow E clock bus. So I want the E clock cycle to be optimized for less wait states... and this is exactly what the new A2630 U506 GAL does (see below):

WARNING:
Just in case you did not RTFM, this mod assumes no real 6800 E clock devices exist in the system and the 8520 devices can handle some performance tweaks. So you should keep the original U506 PAL just in case you ever get a very rare Zorro II E clock Board!

NOTES:
A GAL16V8 or equivalent PLD is required and must be programmed with the .jed file provided! Speed is not important but a 15ns device is nominal. This can also be done for the A2620, but I don't have one to test it on. The A2620 PAL U309 is nearly identical to the A2630 PAL U506. So, A2620 owners can just rename the GAL to U309! Sorry, there is no easy fix for A3000 and A4000 owners since all the E clock logic is in Fat Gary.

DISCLAIMER:
Use at your own risk! No warranty expressed or implied, etc.

Code:
Name     U506 ;
PartNo   XXXXX ;
Date     5/6/1988 - 10/29/2020 ;
Revision 02 ;
Designer Haynie - SpeedGeek ;
Company  Commodore ;
Assembly 312828 ;
Location U506 ;
Device   G16V8 ;

/************************************************************************/
/*									*/
/*  A2630 	E clock generation, VMA generation, EDTACK generation,	*/
/*  		Refresh request, 3 bits of refresh counter, and 	*/
/*		Refresh request.					*/
/*									*/
/************************************************************************/
/*  Allowable Target Device Types: 16R6A 				*/
/************************************************************************/
/*  Clock:	7M							*/
/************************************************************************/
/*  Free Pins: 2(I) 							*/
/************************************************************************/
/*  HISTORY								*/
/*	DBH Sep 25:	Made from U309R1 from A2630 Rev 2.		*/
/* 	SpeedGeek Oct. 29: Assume no real 6800 E CLK devices	*/
/*      exist in the system and the 8520 devices can handle    */
/*	some performance tweaks.	  
/************************************************************************/

/**  Inputs  **/

PIN 1		= CLK		;	/* 7 MHz */
PIN 3		= A0		;	/* E and refresh counter bits */
PIN 4		= A1		;
PIN 5		= A2		;
PIN 6		= A3		;
PIN 7		= B2000		;	/* Board inside a B2000 */
PIN 8		= TRISTATE	;	/* Bus tristate control */
PIN 9		= !VPA		;	/* Valid peripheral address */
PIN 11		= !OE		;

/**  Outputs  **/

PIN 19		= E		;	/* the 6800 E clock */
PIN 12		= !REFREQ	;	/* Refresh request to refresh logic */
PIN 13		= IVMA	 	;	/* Internal VMA */
PIN 14		= EDTACK	;	/* DTACK for 6800 cycle */
PIN 18		= !StBit3	;	/* Refresh counter bit 3 */
PIN 17		= !StBit2	;	/* Refresh counter bit 2 */
PIN 16		= !StBit1	;	/* Refresh counter bit 1 */
PIN 15		= !StBit0	;	/* Refresh counter bit 0 */

/** Declarations and Intermediate Variable Definitions **/

count		= A0 & A3;

/**  Logic Equations  **/

E		= A2;
E.OE		= !B2000;

/* Initially, the logic here enabled IVMA during (!A3 & A2 & !A1 & A0 & VPA).
   This is the proper time to have VMA come out, just about when the 68000 
   would bring it out, actually slightly sooner since this PAL releases it on
   the wrong 7M edge.  The main problem with this scheme is that if VPA falls 
   in the case that's just prior to that enabling term (what I call CASE 3 
   in my timing), the I/O cycle should be held off until the next E cycle.
   The 68000 does this, but the above IVMA would run that cycle right away.
   The fix to this used here moves the IVMA equation up by one clock cycle,
   assuring that a CASE 3 VPA will be delayed.  This adds a potential problem
   in that IVMA would is asserted sooner than a 68000 would assert it.  We
   know this is no problem for 8520 devices, and /VPA driven devices aren't
   supported under autoconfig, so we should be OK here.
*/   

/* This was "!A3 & !A2 & !A1 & !A0 & VPA # !IVMA & !A3" but 8520
devices tolerate late assertion too! */

!IVMA.D		=   !A3 & !A2 & VPA
		# !IVMA & !A3;

/* This was "!A3 & A2 & A1 & A0 & !IVMA", but I think that may make
   the cycle end too late. So I'm pushing it down by one clock! */

!EDTACK.D	= !A3 & A2 & A1 & !A0 & !IVMA;

/*	This is the refresh counter described in the refreshcounter
 *	state machine file. We have added the holding term to
 *	The REFREQ output (REFREQ & !WIN).
 */

StBit3.D	= !count & !StBit1 & !StBit2 &  StBit3
		#  count & !StBit1 & !StBit2 & !StBit3
		#  count & !StBit0 &  StBit1 & !StBit3
		#  count & !StBit0 &  StBit2 & !StBit3
		# !count & !StBit0 &  StBit3;

StBit2.D	= !count &  StBit0 & !StBit1 &  StBit2 & !StBit3
		#  count & !StBit0 &  StBit1 & !StBit2 &  StBit3
		#  count & !StBit1 & !StBit2 &  StBit3
		#  count & !StBit0 &  StBit2 & !StBit3
		# !count & !StBit0 &  StBit2;

StBit1.D	=  count & !StBit0 & !StBit1 &  StBit2 & StBit3
		#  count & !StBit0 &  StBit1 & !StBit2 & StBit3
		#  count & !StBit0 &  StBit1 & !StBit3
		# !count & !StBit0 &  StBit1;

StBit0.D	=  count & !StBit0 &  StBit1 & StBit2 &  StBit3
		# !count &  StBit0 & !StBit1 & StBit2 & !StBit3
		# StBit0 & !StBit1 & !StBit2;

REFREQ =	count & StBit0 & !StBit1 & StBit2 & !StBit3;
Attached Thumbnails
Click image for larger version

Name:	E_clock_cycle.PNG
Views:	144
Size:	50.1 KB
ID:	69650  
Attached Files
File Type: zip A2630_U506.zip (636 Bytes, 61 views)

Last edited by SpeedGeek; 13 November 2020 at 15:40.
SpeedGeek is offline  
 
Page generated in 0.04461 seconds with 12 queries