6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Sep 22, 2024 4:31 pm

All times are UTC




Post new topic Reply to topic  [ 60 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
 Post subject: Re: New 65C02 project
PostPosted: Thu Sep 03, 2015 11:01 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8390
Location: Midwestern USA
Aslak3 wrote:
A trivial point, but I believe the cap on the MAX238 on the V+ pin is backwards.

Well spotted! I didn't see that earlier.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: New 65C02 project
PostPosted: Fri Sep 04, 2015 3:50 am 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
Aslak3 wrote:
A trivial point, but I believe the cap on the MAX238 on the V+ pin is backwards.


That's why I use ceramics :)


Top
 Profile  
Reply with quote  
 Post subject: Re: New 65C02 project
PostPosted: Fri Sep 04, 2015 7:59 am 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
Now that I've had a chance at having a proper sit down and think: I qualified the CS for the RAM with PHI2, not read/write signal. Is this incorrect?


Top
 Profile  
Reply with quote  
 Post subject: Re: New 65C02 project
PostPosted: Fri Sep 04, 2015 8:24 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8511
Location: Southern California
banedon wrote:
Now that I've had a chance at having a proper sit down and think: I qualified the CS for the RAM with PHI2, not read/write signal. Is this incorrect?

If you're nearing the speed limit of the RAM, having the RAM's CS\ qualified by phase 2 is not ideal. (It's fine at lower speeds though.) What BDD was saying to qualify with phase 2 was the RAM's WR\. The idea of the logic for that and the OE\ is shown in the last diagram of the clock generation page of the 6502 primer.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
 Post subject: Re: New 65C02 project
PostPosted: Fri Sep 04, 2015 2:38 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8390
Location: Midwestern USA
banedon wrote:
Now that I've had a chance at having a proper sit down and think: I qualified the CS for the RAM with PHI2, not read/write signal. Is this incorrect?

You should not qualify any chip selects with Ø2. Where Ø2 qualification should be applied is in generating your /RD and /WR signals. In CUPL, the logic is written as /RD = RWB & PHI2 for fetches, and /WR = !RWB & PHI2 for stores, where & is logical AND and ! is logical NOT.

The preceding does not apply to 65xx I/O devices, which should be directly driven by the MPU's RWB output.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: New 65C02 project
PostPosted: Fri Sep 04, 2015 3:04 pm 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
Okey dokey. I'll re-do the GAL code this evening and rewire the RAM R/W pin. Cheers.

[edit] Here's an updated schematic:
Attachment:
65C02v2_b2_rev3.png
65C02v2_b2_rev3.png [ 126.23 KiB | Viewed 607 times ]


GAL 1 - Main Decoder (IC 2)

Code:
Name       AddressDecoder1;
Partno     Lattice22V10B;
Date       11/07/15;
Revision   01;
Designer   shalewyn.com;
Company    shalewyn.com;
Assembly   1;
Location   1;
Device     g22v10;

/*
 * Lattice GAL 22V10B pinout, DIP, top view
 *
 * I/CLK.[ 1     24 ].VCC
 *     I.[ 2     23 ].I/O/Q
 *     I.[ 3     22 ].I/O/Q
 *     I.[ 4     21 ].I/O/Q
 *     I.[ 5     20 ].I/O/Q
 *     I.[ 6     19 ].I/O/Q
 *     I [ 7     18 ].I/O/Q
 *     I [ 8     17 ].I/O/Q
 *     I [ 9     16 ].I/O/Q
 *     I [ 10    15 ].I/O/Q
 *     I [ 11    14 ].I/O/Q
 *   GND.[ 12    13 ].I
 *
 */


/*
 * Inputs
 */

Pin 1 = phi2;
Pin 2 = cpuRW;
Pin [3..10] = [A7..0];

/*
 * Outputs
 */

Pin [16..21] = ![S0..5];

Pin 22 = aRD;
Pin 23 = aWR;

aRD = !cpuRW;
aWR = cpuRW;

/*
Pin [16] = s[0];   nROM select;
Pin [17] = s[1];   nRAM select;
Pin [18] = s[2];   nLatch1 select;
Pin [19] = s[3];   nVIA #1
Pin [20] = s[4];   nVIA #2
Pin [21] = s[5];   nACIA
 
Pin [22] = aWR;   
Pin [23] = aRD;   
*/


/*
 * Main
 */

FIELD AddressBus = [A7..0];
FIELD Selects = [S5..0];



TABLE AddressBus => Selects {
   [00..1F] => 'b'000010 & cpuRW;       /* Non-swap RAM read */
   [00..1F] => 'b'000010 & !cpuRW;    /* Non-swap RAM write */

   [20..7F] => 'b'000010 & cpuRW;       /* Swap RAM read */
   [20..7F] => 'b'000010 & !cpuRW;    /* Swap RAM write */

   [81..81] => 'b'001000 & cpuRW;       /* VIA #1 read */
   [81..81] => 'b'001000 & !cpuRW;       /* VIA #1 write */

   [82..82] => 'b'010000 & cpuRW;       /* VIA #2 read */
   [82..82] => 'b'010000 & !cpuRW;       /* VIA #2 write */

   [83..83] => 'b'100000 & cpuRW;       /* ACIA read */
   [83..83] => 'b'100000 & !cpuRW;       /* ACIA write */

   [84..84] => 'b'000100 & cpuRW;       /* Latch read */
   [84..84] => 'b'000100 & !cpuRW;       /* Latch write */
   
   [90..FF] => 'b'000001 & cpuRW;       /* ROM read*/
}


GAL 2 - Secondary Decoder (IC 3)

Code:
Name       AddressDecoder2;
Partno     Lattice22V10B;
Date       11/07/15;
Revision   01;
Designer   shalewyn.com;
Company    shalewyn.com;
Assembly   1;
Location   1;
Device     g22v10;

/*
 * Lattice GAL 22V10B pinout, DIP, top view
 *
 * I/CLK.[ 1     24 ].VCC
 *     I.[ 2     23 ].I/O/Q
 *     I.[ 3     22 ].I/O/Q
 *     I.[ 4     21 ].I/O/Q
 *     I.[ 5     20 ].I/O/Q
 *     I.[ 6     19 ].I/O/Q
 *     I [ 7     18 ].I/O/Q
 *     I [ 8     17 ].I/O/Q
 *     I [ 9     16 ].I/O/Q
 *     I [ 10    15 ].I/O/Q
 *     I [ 11    14 ].I/O/Q
 *   GND.[ 12    13 ].I
 *
 */


/*
 * Inputs
 */

Pin 1 = phi2;
Pin 2 = cpuRW;
Pin [3..6] = [A15..12];
Pin 7 = !IRQin1n;
Pin 8 = !IRQin2n;
Pin 9 = !IRQin3n;
Pin 22 = !IRQin_od;

Pin 10 = sbr0n;
Pin 11 = sbr1n;
Pin 13 = sbw0n;
Pin 14 = sbw1n;

/*
 * Outputs
 */

Pin 16 = sramA15n;
Pin 17 = sramA16n;
Pin 23 = !IRQout;

/*
 * Main
 */

 
/* IRQ set up */
IRQout = IRQin1n # IRQin2n # IRQin3n # IRQin_od;


/*
   R/W   SBR0 SBR1 SBW0 SBW1 A15 A16
   ---   ---- ---- ---- ---- --- ---
   1   0    0    0    0    0   0
   1   0    1    0    0    1   0
   1   1    0    0    0    0   1
   1   1    1    0    0    1   1

   0   0    0    0    0    0   0
   0   0    1    0    0    1   0
   0   1    0    0    0    0   1
   0   1    1    0    0    1   1
*/



FIELD BankCtrl = [cpuRW, sbr0n, sbr1n, sbw0n, sbw1n];
FIELD BankOut = [sramA15n, sramA16n];
FIELD AddressBus = [A15..12];

TABLE BankCtrl => BankOut {
   'b'100xx => 'b'00;      
   'b'101xx => 'b'10;      
   'b'110xx => 'b'01;      
   'b'111xx => 'b'11;      
   'b'0xx00 => 'b'00;      
   'b'0xx01 => 'b'10;      
   'b'0xx10 => 'b'01;      
   'b'0xx11 => 'b'11;      
}


Top
 Profile  
Reply with quote  
 Post subject: Re: New 65C02 project
PostPosted: Sat Sep 05, 2015 4:19 pm 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
Having some issues trying to qualify the A15 and A16 output so that it only gives 0 on each when an address of $0000-$1FFF comes up.
This doesn't work, so will need have a think:

Code:
FIELD Addr = [A15..12];
FIELD BankCtrl = [cpuRW, Addr, sbr0n, sbr1n, sbw0n, sbw1n];
FIELD BankOut = [sramA15n, sramA16n];


TABLE BankCtrl => BankOut {
   /* $0000-$1FFF detect */
   'b'x000xxxxx => 'b'00;   

   'b'10xxx00xx => 'b'00;      
   'b'10xxx01xx => 'b'10;      
   'b'10xxx10xx => 'b'01;      
   'b'10xxx11xx => 'b'11;      
   'b'00xxxxx00 => 'b'00;      
   'b'00xxxxx01 => 'b'10;      
   'b'00xxxxx10 => 'b'01;      
   'b'00xxxxx11 => 'b'11;   
}


Top
 Profile  
Reply with quote  
 Post subject: Re: New 65C02 project
PostPosted: Sat Sep 05, 2015 5:26 pm 
Offline
User avatar

Joined: Sun Oct 13, 2013 2:58 pm
Posts: 491
Location: Switzerland
Hi banedon,

here some input to your design files.

Table is not well suited for your purpose, you should really use equations for that case. Also you need to be very careful when using variables with subscripts, like A12, A13, A14, A15 etc. WinCUPL now allocates a 32-bit chunk and places the bits according to the subsript. This said you should change your code.

FIELD Address = [A15..0];

sramA15n = Address:[0000..1FFF] & RW & !sbr0n & !sbr1n
# Address:[0000..1FFF]

if the address ranges you use do not require the address lines A0 to A11 WinCUPL will accept that there are no pins for these signals. Also your code gets much more readable as you now use the "real" addresses in the square backtes as they are seen by the CPU.

Then in your first post with in the first GAL the read and write signals must be qualified with PHI2

aRD = phi2 & !cpuRW;
aWR = phi2 & cpuRW;

you have no registered outputs (no flip flops used) so pin 1 is used as input and not as clock and you can use phi2 as normal input signal. As already said in a former response, pin 1 is only activated as clock input if you have registered outputs. And you should use the FIELD statement with the full 16-bit address, it makes your code clearer.

Cheers

Peter


Top
 Profile  
Reply with quote  
 Post subject: Re: New 65C02 project
PostPosted: Sat Sep 05, 2015 5:28 pm 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
Ok we have a possible winner:

Code:
FIELD Addr = [A15..12];
FIELD BankCtrl = [cpuRW, Addr, sbr0n, sbr1n, sbw0n, sbw1n];
FIELD BankOut = [sramA15n, sramA16n];


TABLE Addr => BankOut {
   [0..1FFF] => 'b'00;
   [2000..7FFF] => 'b'00 & cpuRW & !sbr0n & !sbr1n;
   [2000..7FFF]  => 'b'10 & cpuRW & !sbr0n & sbr1n;
   [2000..7FFF] => 'b'01 & cpuRW &  sbr0n & !sbr1n;
   [2000..7FFF] => 'b'11 & cpuRW &  sbr0n &  sbr1n;

   [2000..7FFF] => 'b'00 & !cpuRW & !sbw0n & !sbw1n;
   [2000..7FFF] => 'b'10 & !cpuRW & !sbw0n &  sbw1n;
   [2000..7FFF] => 'b'01 & !cpuRW &  sbw0n & !sbw1n;
   [2000..7FFF] => 'b'11 & !cpuRW &  sbw0n &  sbw1n;
}


Am testing and tuning atm. Looking good, though


Top
 Profile  
Reply with quote  
 Post subject: Re: New 65C02 project
PostPosted: Sat Sep 05, 2015 5:36 pm 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
cbscpe wrote:
Hi banedon,

here some input to your design files.

Table is not well suited for your purpose, you should really use equations for that case. Also you need to be very careful when using variables with subscripts, like A12, A13, A14, A15 etc. WinCUPL now allocates a 32-bit chunk and places the bits according to the subsript. This said you should change your code.

FIELD Address = [A15..0];

sramA15n = Address:[0000..1FFF] & RW & !sbr0n & !sbr1n
# Address:[0000..1FFF]

if the address ranges you use do not require the address lines A0 to A11 WinCUPL will accept that there are no pins for these signals. Also your code gets much more readable as you now use the "real" addresses in the square backtes as they are seen by the CPU.

Then in your first post with in the first GAL the read and write signals must be qualified with PHI2

aRD = phi2 & !cpuRW;
aWR = phi2 & cpuRW;

you have no registered outputs (no flip flops used) so pin 1 is used as input and not as clock and you can use phi2 as normal input signal. As already said in a former response, pin 1 is only activated as clock input if you have registered outputs. And you should use the FIELD statement with the full 16-bit address, it makes your code clearer.

Cheers

Peter


Hi Peter

Thanks for your advice.
Given that TABLE is one of those commands that makes me want to uninstall WinCUPL, I was on the edge of doing as you're suggesting and splitting it all down, but I think I've now cracked it. I do notice that my solution and your are pretty much the same, except I'm using a TABLE.
The phi2 is there from before but you're right: I don't need it in the second GAL. I'll keep it there as I don't need the pin, but will get rid of it in the schematic and will ditch it if I need to re-purpose pin 1. I know (from you previous advice :)) that I do not need to have that as PHI2.


Top
 Profile  
Reply with quote  
 Post subject: Re: New 65C02 project
PostPosted: Sat Sep 05, 2015 6:20 pm 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
Ok that works. I now have the following parts of the memory map working (I've reduced the base RAM in favour of expanding the RAM banks):

$0000-$0FFF = non-swap/base RAM
$1000-$7FFF = RAM banks 0, 1, 2 and 3 selectable via Latch #1
$8400-$840F = Latch #1. Lines 0-1 used to select the active RAM bank for read operations, lines 2-3 for write operations
$9000-$FFFF = OS EEPROM

H/W-wise, I still need to implement:

Fully connecting VIA#1, VIA#2 and the ACIA (+line drivers)
IRQ support for all of the above

The above gives access to 116KB of RAM in total (28KB per bank (4) + 4KB for the base), 28KB for ROM and 4KB for memory mapped I/O devices


Top
 Profile  
Reply with quote  
 Post subject: Re: New 65C02 project
PostPosted: Sun Sep 06, 2015 5:28 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8390
Location: Midwestern USA
banedon wrote:
[edit] Here's an updated schematic:
Attachment:
65C02v2_b2_rev3.png

You have a 10K pull-up resistor on the IRQ line going to the UART. I recommend you reduce it to 3.3K. Otherwise, you may run into spurious interrupt problems.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: New 65C02 project
PostPosted: Sun Sep 06, 2015 7:54 am 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
I know that if the resistance of a pull up resister is too high then it can slow reaction times of state changes within a connected IC pin. Is this what you're referring too?


Top
 Profile  
Reply with quote  
 Post subject: Re: New 65C02 project
PostPosted: Sun Sep 06, 2015 8:42 am 
Offline
User avatar

Joined: Sun Oct 13, 2013 2:58 pm
Posts: 491
Location: Switzerland
Good to see your project is making progress.

banedon wrote:
Given that TABLE is one of those commands that makes me want to uninstall WinCUPL, I was on the edge of doing as you're suggesting and splitting it all down, but I think I've now cracked it. I do notice that my solution and your are pretty much the same, except I'm using a TABLE.


Yes exactly, that's the way to do it with tables. When starting with CPLDS (ATF15xx) I also often used tables, but I abandoned them, as I think the method using ADDRESS:[from..to] is often more readable and easier to maintain. There are of course times when tables are very useful, like in the thread which discussed the use of a GAL instead of a small ROM to boot a system http://forum.6502.org/viewtopic.php?f=10&t=3383

As for the pull-ups for IRQ et.al. I normally use 2k2 or even 1k8. Faster is always better and as these signals are high for 99% of the time some mA more or less don't matter, especially considering that a fast GAL alone uses 100mA and more.


Top
 Profile  
Reply with quote  
 Post subject: Re: New 65C02 project
PostPosted: Sun Sep 06, 2015 9:27 am 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
cbscpe wrote:
Good to see your project is making progress.

banedon wrote:
Given that TABLE is one of those commands that makes me want to uninstall WinCUPL, I was on the edge of doing as you're suggesting and splitting it all down, but I think I've now cracked it. I do notice that my solution and your are pretty much the same, except I'm using a TABLE.


Yes exactly, that's the way to do it with tables. When starting with CPLDS (ATF15xx) I also often used tables, but I abandoned them, as I think the method using ADDRESS:[from..to] is often more readable and easier to maintain. There are of course times when tables are very useful, like in the thread which discussed the use of a GAL instead of a small ROM to boot a system http://forum.6502.org/viewtopic.php?f=10&t=3383

As for the pull-ups for IRQ et.al. I normally use 2k2 or even 1k8. Faster is always better and as these signals are high for 99% of the time some mA more or less don't matter, especially considering that a fast GAL alone uses 100mA and more.


Thank you :)

I'll have a play around with the ADDRESS command to see if it suites me better.
With regard to your suggestion regarding 2k2 or 1k8 - We're taking about 2.2mA for 2k2 and 2.7mA for 1k8? If so, then I tend to agree. Apart from the power usage are there any downsides of doing this?


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 60 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC


Who is online

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