6502.org Forum Projects Code Documents Tools Forum
It is currently Wed Sep 25, 2024 2:39 am

View unanswered posts | View active topics


Board index » 6502.org Users Forum » Programmable Logic

All times are UTC




Post new topic Reply to topic  Page 3 of 3
  [ 37 posts ]  Go to page Previous  1, 2, 3
  Print view Previous topic | Next topic 
Author Message
BigDumbDinosaur
PostPosted: Tue Jun 24, 2014 3:40 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8395
Location: Midwestern USA
lordbubsy wrote:
I'll keep on trying different timings. Perhaps getting BE involved?

What is else is driving the address and data buses beside the '816? Could it be you are seeing a good old fashioned case of bus contention?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
lordbubsy
PostPosted: Tue Jun 24, 2014 5:42 pm 
Offline

Joined: Wed Sep 11, 2013 8:43 pm
Posts: 207
Location: The Netherlands
BigDumbDinosaur wrote:
What is else is driving the address and data buses beside the '816? Could it be you are seeing a good old fashioned case of bus contention?
To eliminate even more potential problems, I removed I/O and leave a bare minimum to let MARC-2 function without any I/O.
It doesn't look like there is any contention.

Code:
RDY.clk = DIV2;
when DIV25  then RDY := 0
  else           RDY := 1;

BE         = 1;

// System clock generator / divider
DCLK.clk  = CLOCK.pin;                                  "System clock input
DCLK     := DCLK + 1;                                   "Increment DCLK at CLOCK rate 14,7456MHz
PHI2      = DIV3;
                                                        "DIV7 = PHI2 = CLOCK / 256 =  57,6kHz
                                                        "DIV6 = PHI2 = CLOCK / 128 = 115,2kHz
                                                        "DIV5 = PHI2 = CLOCK /  64 = 230,4kHz
                                                        "DIV4 = PHI2 = CLOCK /  32 = 460,8kHz
                                                        "DIV3 = PHI2 = CLOCK /  16 = 921,6kHz
                                                        "DIV2 = PHI2 = CLOCK /   8 = 1,8432MHz
                                                        "DIV1 = PHI2 = CLOCK /   4 = 3,6864MHz
                                                        "DIV0 = PHI2 = CLOCK /   2 = 7,3728MHz

// UPPER address bus control
UADDR.le = PHI2;                                        "create transparent latch to get the
UADDR.d  = CDATA.pin;                                   "UPPER address bus from the CPU data bus

// CPU RAM address bus control
RADDR      = [CA18..CA0];                               "Connect CPU address to RAM address bus

// CPU RAM data bus control (bi-directional) [taken from ABEL reference]
CDATA      = RDATA;                                     "RAM data moves to CPU data bus
RDATA      = CDATA;                                     "CPU data moves to RAM data bus
CDATA.oe   = PHI2 & N_RW;                               "i.e. read from RAM
RDATA.oe   = PHI2 & !N_RW;                              "i.e. write to RAM

// MEMORY Read Write Qualification
!N_MEMRD    = PHI2 & N_RW;                              "MEMORY Read qualified with PHI2
!N_MEMWR    = PHI2 & !N_RW;                             "MEMORY Write qualified with PHI2

N_RAMCS    = 0;                                         "$000000-$FFFFFF all RAM

// I/O Chip Select
N_DUARTCS  = 1;
N_VIA0CS   = 1;
N_VIA1CS   = 1;

N_ABORT    = 1;                                         "Needs to be high for normal operation
N_IRQ      = 1;                                         "IRQ is not in use yet
N_NMI      = 1;                                         "NMI is not in use yet

// Reset circuit
N_RES.clk= PHI2;                                        "Sync N_RES on PHI2???
N_RES.d  = 1;                                           "
N_RES.ar = !N_RESET.pin;                                "Drop N_RES when N_RESET is brought low
RES.clk  = PHI2;                                        "Sync RES on PHI2???
RES.d    = 0;                                           "
RES.ap   = !N_RESET.pin;                                "Rise RES when N_RESET is brought low

// Tri-stated pins during N_RESET = low
N_MEMRD.oe = N_RESET;                                   "tristate during N_RESET
N_MEMWR.oe = N_RESET;                                   "tristate during N_RESET
N_RAMCS.oe = N_RESET;                                   "tristate during N_RESET
RADDR2.oe  = N_RESET;                                   "tristate during N_RESET

// Selecte RAM Segment during RESET
when N_RESET==0 then RA14 = 1;                          "Selecte RAM Segment during N_RESET low to
when N_RESET==0 then RA15 = 1;                          "$00C000 = %0000 0000 1100 0000 0000 0000
when N_RESET==0 then RA16 = 0;                          "RA13..RA0 is controlled by the AVR
when N_RESET==0 then RA17 = 0;                          "and have to be tristated
when N_RESET==0 then RA18 = 0;                          "RA18..RA14 in controlled by the CPLD 00011


That reminds me, I have RDY directly connected to the CPLD, RDY is also pulled up by a 3k3 resistor.

In normal use, all pins of the ATMega are tri-stated.

At all times, all pins of the SRAM are connected to the ATMega, but in normal use, they are tri-stated.

_________________
Marco
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Tue Jun 24, 2014 8:39 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8395
Location: Midwestern USA
lordbubsy wrote:
That reminds me, I have RDY directly connected to the CPLD, RDY is also pulled up by a 3k3 resistor.

Does the CPLD high-Z its RDY connection when not asserting RDY?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
cbscpe
PostPosted: Tue Jun 24, 2014 9:53 pm 
Offline
User avatar

Joined: Sun Oct 13, 2013 2:58 pm
Posts: 491
Location: Switzerland
Just a remark, if I remember rigth, you jumped from CPU only and VGA only directly to the full blown solution with RDY and stopping the CPU during display. I would suggest that you first try an intermediate solution with just interleaving CPU and VGA access and go with 4 bits per pixel. Just to make sure that there is not more thAN just the issue with RDY, which as far as I have studied the information should work as it is.

Peter
Top
 Profile  
Reply with quote  
nyef
PostPosted: Tue Jun 24, 2014 11:18 pm 
Offline

Joined: Sun Jul 28, 2013 12:59 am
Posts: 235
lordbubsy wrote:
nyef wrote:
When fetching for the CPU, CPU A0 indicates which SRAM output-enable to trigger, along with which set of 8 data lines to use. When fetching for the VGA, both SRAM output-enables get triggered, and all 16 data lines get used. You feed the same address (A1 and up) to both SRAMs. Similar logic for writing to RAM as well.
Still not clear how to get 16 bit at once, I guess I'm not Vulcan enough :oops:

To be fair, the entire idea is predicated on having a 16-bit channel to RAM, which is two 8-bit data busses at once, which you might not be able to do if you're short on spare I/O pins. This is the bit of background that was mentioned almost in passing for this approach, and would plausibly be easily missed.
Top
 Profile  
Reply with quote  
lordbubsy
PostPosted: Wed Jun 25, 2014 1:02 pm 
Offline

Joined: Wed Sep 11, 2013 8:43 pm
Posts: 207
Location: The Netherlands
BigDumbDinosaur wrote:
Does the CPLD high-Z its RDY connection when not asserting RDY?
Obviously not, but I "think" we're getting somewhere!

So I arranged what you're suggesting by:
Code:
// Halt the CPU with RDY low

rdy_en.clk = PHI2;               "rdy_en synced on rising edge of PHI2

when DIV25  then  rdy_en := 0    "CPU should halt when DIV25 is high
  else            rdy_en := 1;   "CPU should run when DIV25 is low

when rdy_en == 0 then RDY = 0;   "when rdy_en is low then RDY should be forced to low
                                 "I'm not sure if en 'else' is strictly necesary???

// RDY.oe = 1; NOT tri-statated
// RDY.oe = 0; tri-statated

RDY.oe = !rdy_en;                "when rdy_en = 1 the RDY is tri-stated

For a moment I thought this fixed the problem, but after monitoring a bit longer, the computer crashed at roughly 80 seconds. :-/
Attachment:
111.png
111.png [ 63.84 KiB | Viewed 935 times ]

Attachment:
112.png
112.png [ 60.97 KiB | Viewed 935 times ]

cbscpe wrote:
Just a remark, if I remember rigth, you jumped from CPU only and VGA only directly to the full blown solution with RDY and stopping the CPU during display. I would suggest that you first try an intermediate solution with just interleaving CPU and VGA access and go with 4 bits per pixel.
That’s right, I'd probably be happy with a "one byte per PHI2" solution. Be it 4 bits per pixel, half the x resolution or composite.

However, at some point I want to use wait states to be able to use slow devices on MARC-2. I'd rather do that with RDY than with clock stretching, because that would mess up any VIA timings when I should need them, right?

cbscpe wrote:
Just to make sure that there is not more thAN just the issue with RDY, which as far as I have studied the information should work as it is.
Well, I hope it is something that will pop up and can be fixed. Otherwise I would be stuck without being able to use RDY.

nyef wrote:
To be fair, the entire idea is predicated on having a 16-bit channel to RAM, which is two 8-bit data busses at once, which you might not be able to do if you're short on spare I/O pins.
It certainly is a quite nice solution, but I'm not sure if it's worth the extra needed pins and the effort of piggybacking an extra SRAM.



Next, I'll probably try the intermediate solution cbscpe suggested.

_________________
Marco
Top
 Profile  
Reply with quote  
BigEd
PostPosted: Wed Jun 25, 2014 1:18 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10938
Location: England
Yes, RDY should be a neater solution than messing with the clock directly - not only should it be more straightforward with no concerns about glitching the clock, but as you say it helps to keep timers running at a steady rate.
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 3 of 3
  [ 37 posts ]  Go to page Previous  1, 2, 3

Board index » 6502.org Users Forum » Programmable Logic

All times are UTC


Who is online

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