Author Topic: Address & Data bus loading  (Read 4400 times)

0 Members and 1 Guest are viewing this topic.

Offline @rtTopic starter

  • Super Contributor
  • ***
  • Posts: 1051
Address & Data bus loading
« on: May 22, 2018, 09:54:21 am »
Hi :)
Interested in Commodore Amiga specifically, but imagine most old computers are the same.
If you make an expansion, it will have to always be connected to the address bus to listen when address strobe occurs.
I figure these would best be Schmidt trigger inputs for the expansion.

I understand you can use tri-state buffers to switch connections to the data bus high impedance when not used.

Are these both correct?

In terms of stuff done with stock logic, I only have Bruce Abbot’s floppy interface to go on, and that appears to be what he did.
I want four address bus bits connected to a pic micro. Would it pay to buffer those four bits with stock logic just to get the ST inputs?

« Last Edit: May 22, 2018, 09:57:40 am by @rt »
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: Address & Data bus loading
« Reply #1 on: May 23, 2018, 05:17:59 pm »
I want four address bus bits connected to a pic micro. Would it pay to buffer those four bits with stock logic just to get the ST inputs?
You don't need ST inputs. You do need to ensure that the logic levels are compatible. Which PIC micro do you intend to use, and for what purpose?
 

Online David Hess

  • Super Contributor
  • ***
  • Posts: 16548
  • Country: us
  • DavidH
Re: Address & Data bus loading
« Reply #2 on: May 23, 2018, 08:26:09 pm »
Usually any standard logic input works just fine; if you need schmitt trigger inputs, then something is wrong.

The address bus needs to be continuously monitored to decode the address in combination with the strobe which is what your example shows.  I guess in theory you could latch the address bus using the strobe and *then* do the comparison to save power but I have never seen anybody bother and this lengthens the access time which is generally undesirable but may not matter in a specific implementation.

« Last Edit: May 23, 2018, 08:28:51 pm by David Hess »
 

Offline @rtTopic starter

  • Super Contributor
  • ***
  • Posts: 1051
Re: Address & Data bus loading
« Reply #3 on: May 24, 2018, 08:10:25 am »
Yes, ok, it would be elegant to treat the 4 address bits together with address strobe as a five bit bus, and of course easy to look for a range on that bus.
The micro would be pic 16F628A powered from the Amiga’s 5V rail. It has to emulate an RTC chip usually found in an Amiga, the Ricoh RF5C01A,
except I want to acquire the time and date externally, so the real time clock is elsewhere, probably from GPS.

I don’t know how clean the bus is, and haven’t looked, but some signals are known to be messy, hence the A1200 clock fix.


« Last Edit: May 24, 2018, 08:13:55 am by @rt »
 

Online David Hess

  • Super Contributor
  • ***
  • Posts: 16548
  • Country: us
  • DavidH
Re: Address & Data bus loading
« Reply #4 on: May 24, 2018, 12:26:02 pm »
Yes, ok, it would be elegant to treat the 4 address bits together with address strobe as a five bit bus, and of course easy to look for a range on that bus.

That should work.  See below.

Quote
The micro would be pic 16F628A powered from the Amiga’s 5V rail. It has to emulate an RTC chip usually found in an Amiga, the Ricoh RF5C01A,
except I want to acquire the time and date externally, so the real time clock is elsewhere, probably from GPS.

I am not sure if a PIC will be fast enough.  Even if you latched the valid address bits externally or did the decoding externally, it might not be.  I do not see any way to generate wait states in the above schematic.

Let's see ... PIC uses a 4-phase clock so instruction timing is Fosc/4 or 5 MHz for a 20 MHz clock; that is 200 nanoseconds per instruction.  You have to do the comparison against the data port in a tight loop, write to the data port, and enable the outputs during the read strobe ... I don't think it is fast enough to do it without some added logic unless the bus shown above is *not* the 68EC020 local bus.

Unfortunately the external hardware would not be trivial since you have several different address locations which must be provided on demand.  That implies full decoding which is easy enough and 4 or 8 8-bit latches holding the data which is essentially what is inside of the clock chip and annoying.  The clock chip also has provisions to prevent a race condition when it updates its internal registers.

Quote
I don’t know how clean the bus is, and haven’t looked, but some signals are known to be messy, hence the A1200 clock fix.

The address signals should be valid during the read and write strobes which is what the schematic shows.
 

Offline @rtTopic starter

  • Super Contributor
  • ***
  • Posts: 1051
Re: Address & Data bus loading
« Reply #5 on: May 24, 2018, 02:08:51 pm »
Ok, you make it sound more elegant to just use the real RTC chip.
The Amiga isn’t supposed to set the RTC, so the write enable pin of the RTC could connect directly to the pic, which reads the GPS.
The pic doesn’t need to read data from the RTC chip, so the read enable pin could connect directly to the Amiga (except maybe for the pic to verify after write).

ie. RTC is normally connected to the Amiga bus, and can be read by the Amiga at any time,
except for a duration at startup, while the pic is waiting for a valid time & date from the GPS.

I was going to have the pic hold the rest of the Amiga in reset while waiting for the GPS anyway.
So I figure I’d just have to set the RTC once, and give the RTC it’s clock crystal, and allow it to take over for that power cycle.

I’m not certain of this, but it might be that while the Amiga is in reset, I can do what I want with the address & data bus,
and not need any tri-state buffer to disconnect the Amiga while the pic is using the busses.

 

Online David Hess

  • Super Contributor
  • ***
  • Posts: 16548
  • Country: us
  • DavidH
Re: Address & Data bus loading
« Reply #6 on: May 24, 2018, 04:31:16 pm »
Ok, you make it sound more elegant to just use the real RTC chip.

When I posted, I was thinking that that might be one of the better options.  If you can find an RTC chip which functions the same as the one you want to replace, then have the Amiga read from the RTC chip as normal but use the PIC to write to the RTC chip.  So the RTC chip is just being used as a register to hold data and not for its timekeeping functions.

A dual port SRAM or register file could also be used that way or maybe even a single port SRAM with some cleverness.

I think some of the older PICs might have a parallel I/O port mode which supports external accesses so the PIC can emulate an 8-bit peripheral but I do not remember the details.
 

Offline @rtTopic starter

  • Super Contributor
  • ***
  • Posts: 1051
Re: Address & Data bus loading
« Reply #7 on: May 24, 2018, 04:58:41 pm »
It would have been a problem because I can’t find any on eBay, but I do happen to have a spare RTC. I’ll just have to be careful with it.
It’s just a one off hobby thing of course.

I understand your further suggestions, but the RTC chip provides the benefit of it’s usual purpose, being an RTC chip with battery backup,
for power cycles where the GPS time isn’t needed (if you were powering the Amiga up to just play a game or something).
It’s more likely I’d have a “get time” button that must be held at powerup for the GPS function to work at all.

... and furthermore, the whole thing could be done on a desk with the pic verifying the write to the RTC before ever bothering connecting
it to the Amiga busses. It’s already known the RTC chip works.

Thanks :)





 

Offline @rtTopic starter

  • Super Contributor
  • ***
  • Posts: 1051
Re: Address & Data bus loading
« Reply #8 on: May 25, 2018, 04:49:55 pm »
This was that time I ran out of solder with about 15 points to go.


 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: Address & Data bus loading
« Reply #9 on: May 26, 2018, 05:14:12 am »
I think some of the older PICs might have a parallel I/O port mode which supports external accesses so the PIC can emulate an 8-bit peripheral but I do not remember the details.
It's called a 'parallel slave port'. A few 40 pin 8 bit PICs have it. Many 16 and 32 bit PICs have an enhanced version with 4 I/O registers. However few have all 5V tolerant pins, and anyway you need 16 registers to fully emulate the RTC.

Quote from: @rt
I can’t find any on eBay
1pcs RP5C01 REAL-TIM​E CLOCK WITH INTERNAL RAM

You could isolate the address and data bus using a 74HCT244, activated via CPU /RD to couple the address lines into the RTC and data lines out to the bus. PIC would control  /WR, and float its I/O pins when not talking to the RTC. You may also need an AND gate so both the CPU and PIC can assert /CS.
 
   
 

Offline @rtTopic starter

  • Super Contributor
  • ***
  • Posts: 1051
Re: Address & Data bus loading
« Reply #10 on: May 26, 2018, 05:19:35 pm »
I didn’t figure on RTC CS and RTC read & write being decoded by Gayle Bruce :D This is for the CD32!
It was supposed to be simpler than that, so I’ve cut it in half, and will just have to commit to Amiga programming.
I’ve already set the battery clock, but not used the serial port before.

The UBlox module with regulator is working fine with NComm though, so hardware is fine.



The hardware was fine for the first one too, so I think that was a valid peripheral for an A1200 clock port as far as hardware is concerned.
« Last Edit: May 26, 2018, 05:22:14 pm by @rt »
 

Online David Hess

  • Super Contributor
  • ***
  • Posts: 16548
  • Country: us
  • DavidH
Re: Address & Data bus loading
« Reply #11 on: May 26, 2018, 06:15:43 pm »
I think some of the older PICs might have a parallel I/O port mode which supports external accesses so the PIC can emulate an 8-bit peripheral but I do not remember the details.
It's called a 'parallel slave port'. A few 40 pin 8 bit PICs have it. Many 16 and 32 bit PICs have an enhanced version with 4 I/O registers. However few have all 5V tolerant pins, and anyway you need 16 registers to fully emulate the RTC.

16 registers?  Ouch.  Oh, but if I am reading the Ricoh RF5C01A datasheet correctly, it is 16 x 4 bits which leads to the following solutions.

A dual port memory or dual port register file can be placed between the PIC and interface.  Then the PIC can update the memory as needed and access at high speed is always provided to the interface.

A dual port SRAM like the IDT 7130LA55PDGI is suitable and there are lots of other alternatives.  Most of the space is being wasted but so what?

Or four 74LS670 4x4 dual port register files can do the same thing in a more traditional way.  It takes eight of them though to support the dual bank idea below so the dual port SRAM is probably a better solution.

The problem is that unlike the RTC, the PIC cannot make atomic updates of the dual port memory but there is a way to fix that.  Double the memory up, which is free with the IDT SRAM, and have the PIC drive one of the read address bits so it can select which "bank" the interface is accessing.  Now the PIC can update the entire memory contents of one "bank", and swap banks without the interface knowing for an atomic update.

A standard asynchronous SRAM can be converted into a slower dual port SRAM with some external logic but the IDT part above or equivalent is probably more economical.
 

Offline @rtTopic starter

  • Super Contributor
  • ***
  • Posts: 1051
Re: Address & Data bus loading
« Reply #12 on: May 26, 2018, 06:50:57 pm »
I have the SX-1 expansion, and it decodes the extra RTC bits, but I guess the bits are from the PGA, and aren’t open collector.
I have a DIP chip socket adapter too, so with some arrangement for switching the pic high impedance, it could have gone in there.

My next thought would have been to use an EPROM to translate the wider address bus. Maybe that’s illegal and shouldn’t be talked about.
I haven’t checked, but assume there’d be enough EPROM address bits to decode for Gayle and the RTC address bits.

The serial module looks like a cop out in one way, but the serial for Amiga will be more of a pain that software for the pic would have.
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: Address & Data bus loading
« Reply #13 on: May 27, 2018, 01:39:53 am »
I didn’t figure on RTC CS and RTC read & write being decoded by Gayle Bruce :D This is for the CD32!
Since the CD32 has no built-in clock port signals you are free to implement it whichever way you like, however activating /CS permanently may have undesirable side effects (eg. higher current draw, greater chance of corruption during power transitions).

Quote
The problem is that unlike the RTC, the PIC cannot make atomic updates of the dual port memory
That shouldn't be a problem unless the CPU tries to read the RTC while the PIC is writing to it.

Amigas normally only read the RTC once at startup. The time is loaded into a CIA counter which then provides system Time Of Day while the machine is running. To be effective your PIC needs to load the RTC with the correct time before this happens, or afterwards run the command 'SetClock LOAD' to load the RTC's current TOD into the CIA.

Which leads to the next option - write your own 'SetClock' command which reads your RTC hardware, then you don't need to provide or emulate the stock RTC chip at all. You could interface the PIC to the data bus via a tristate buffer IC, with decoded /RD and /WR connected to interrupt inputs on the PIC. Writing to the RTC port could trigger an interrupt telling the PIC to start outputting a data sequence, then the CPU reads the port causing another interrupt which tells the PIC to output the next nibble in the sequence.
     

 

Online David Hess

  • Super Contributor
  • ***
  • Posts: 16548
  • Country: us
  • DavidH
Re: Address & Data bus loading
« Reply #14 on: May 27, 2018, 02:06:09 am »
Quote
The problem is that unlike the RTC, the PIC cannot make atomic updates of the dual port memory
That shouldn't be a problem unless the CPU tries to read the RTC while the PIC is writing to it.

I was just being thorough.  Real time clocks often include special provisions internally which are similar to what I described to avoid this problem.  All of the data registers for the clock are latched internally so that one of the registers is not updated during the read process.

If you know the Amiga's access pattern, then this should be possible to avoid without extra complexity.
« Last Edit: May 27, 2018, 02:14:05 am by David Hess »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf