byuu's message board

For discussion of projects related to www.byuu.org/


Can anyone else confirm this schematic is retarded? 
Author Message
Board Admin
User avatar

Joined: Fri 10 Apr 2009, 23:48:17

Posts: 1690
Location: 囧国
Post Can anyone else confirm this schematic is retarded?
I'm trying to interface a 2A03 with an Arduino and all the projects I've found appear to be based on Kevtris' old hardware. For example:

Quote:
Image


Now, let's go down the list for what's really fucking weird here:

  • He's using one-way shift registers (74LS595) to set pins on a bi-directional bus transceiver. Why the fuck would you not just hook it up directly?
  • He's using an octal->binary converter (74HCT138) to set pins on another bus transceiver that is being used to emulate opcodes.
  • All three of these are tied to the same data bus.
  • He's programming it over SPI and still using interrupt lines to the ICs, meaning it's wasting about the same number of pins :(

WHY would you EVER do this if you are using a microcontoller? WHY? Unless he had NO FUCKING CLUE what any of these chips are doing?

From looking at this, it appears to me this is what Kevtris was doing:

  • A0-A2 == 0000 (state after reset)
  • Gates write 0xa0 (B10100000) to the opcode IC (EN1), enable output on opcode IC
  • A0-A2 == 0001
  • Disable output on opcode IC, enable output on data IC (EN2)
  • A0-A2 == 0010
  • Disable output on data IC, gates write 0x8c (B10001100) to opcode IC, enable output on opcode IC
  • A0-A2 == 0011
  • Disable output on opcode IC, enable output on address IC (EN3)
  • A0-A2 == 0100
  • Disable output on address IC, gates write 0x40 (B01000000), enable output on opcode IC
  • A0-A2 == 0101
  • Gates write 0x00 (B00000000)
  • A0-A2 == 0110
  • Gates write 0x00 (B00000000)
  • A0-A2 == 0111
  • Gates write 0x00 (B00000000)

Which translates to:

Code:
LDY <data IC>
STY 0x4000 + <address IC>
BRK
BRK
BRK
(loop)


Can anyone confirm my interpretation of this is right? If yes, couldn't you just wire A0-A2 into the Atmel's ports, wait till it matches the expected values, and write the correct value out a single serial shifter? Wouldn't this be the smart way to do it, using one IC instead of SEVEN?

Or, could I just attach an interrupt to the clock output pin of the 2A03 and just know when to write each byte to the shifter by watching the rise and fall of the clock pin? Since the CPU has an internal clock of like 1.6MHz it should be trivial for the 16MHz Atmel to stay ahead of the clock.

Would appreciate some advice.

Edit: Address values are not 100% confirmed yet. I'm still working out the logic gates on paper to figure out the exact inputs to the '138 is to generate the necessary values.

_________________
web :: deviantArt :: 微博 :: Last.fm :: Twitter

Mon 10 Feb 2014, 00:49:09
User avatar

Joined: Tue 02 Nov 2010, 01:00:37

Posts: 181
Post Re: Can anyone else confirm this schematic is retarded?
I have

Code:
A210 Y43210 IC5 87654321 EN1 EN2 EN3
 000  11110     10100000  0   1   1
 001  11101     00000000  1   0   1
 010  11011     10001100  0   1   1
 011  10111     00000000  1   1   0 --> Interrupt
 100  01111     01000000  0   1   1


Which would confirm your observations. No confirmation on the opcode decoding tho, I don't have a SNES opcode table handy.

Reasons for doing this... Well, one reason I can think of is voltage translation. Eagle has the nasty habit of hiding VCC on all chips, which I really hate. However, I think this is not the case here, so we'll ignore that.

The other reason I can think of is exactly what you described: The µC would have to read its input pins in a tight loop, decide what to do, then output on the data bus. My first observation is that you expect a divider of 13.42329375 (that's 2537/189 or roughly 27/2 ratio) for the 2A03 clock. Where does that come from? Anyway...

Now, let's think of a tight loop that will do "everything right" on an Atmel (8bit):

Code:
/* initial setup */
/* Port A0..A2 are address lines; input; A3..A7 are tied to GND */
/* Port B0..B7 are data bus, input with PU */
/* Port C0..C7 are R/#W, input with PU */
uint8_t my_static_data[...] = { /* <-- X (R27:R26) and Y (R29:R28) point to this. It's aligned to 8 bytes */
    0xA0u, 0x00u, 0x8Cu, 0x00u, 0x40u, ...
    };
my_tight_loop:
0 in r0, PINA;       // 1ck
1 mov r28, r26;      // 1ck
2 add r28, r0;       // 1ck
3 ld r1, Y;          // 1ck
4 in r2, PINC;       // 1ck
5 out DDRB, r2;      // 1ck
6 out PORTB, r1;     // 1ck <-- we ignore that we mess up PU here
7 rjmp my_tight_loop // 2ck


That's about the tightest code I can come up with right now. Notice how it's 9 clock cycles. So we're down to ~1.77 MHz for effectively reacting to address bus changed and writing correct data on reads. However, that's compounded by the fact that it's also 9 clock cycles between port B directionality changes. So if push comes to shove (R/#W changes on line 5 of the loop), there will be ~562 ns of pure bus clash (two drivers on the same bus) - that's not too good!
Also, address lines might not be perfectly stable in the beginning of a bus access or phase aligned to R/#W in general => this means we have run the loop at least twice n order to be somewhat sure we're a) processing the correct operation (read of write) and b) put the correct data on the bus (depending on A2..A0). That's 18 clock cycles, that's ~888.88 kHz, that's bad.

Notice how I skipped reading the bus, skipped writing dynamic data and skipped all interrupts and pull-up behavior is less than desirable. Notice how your 16 MHz Atmel was not able to trivially keep up with even a 1.6 MHz clock let alone a ~21.5 MHz/n clock.

And that's why it's not retarded to have this external circuit. I actually think timing will still be critical, because you only have 3 bus clock cycles from interrupt to data buffer access. This means you will have to a) pre-load the first data word before starting the 2A03 (hence DIGITAL_3 to turn 2A03 off; bad solution... Power should be cut high-side...; and DIGITAL_4 to hold 2A03 in reset), then quickly use SPI to write predefined word data to the data buffer, twice (for 16 bit data). Luckily this is parallel, so for 1.6 MHz, you'll indeed have just enough time to spend in the interrupt ISR and SPI ISR, though everything will have to be coded by hand, because a standard pre- and postamble created by e.g. gcc will blow up your precious timing.

EDIT: Depending on your needs and the 2A03's clock network, you could directly interface with a µC and use an external programmable oscillator, like for instance DS1077 (dual output to save on components for the µC). Clock the 2A03 extremely slow (but with steep rising and falling edges) while programming the registers, then clock it at the right speed to get the sound output. This might not work if the 2A03 has an internal PLL, DLL or special timing requirements for register reads/writes (think multiplication, division).

cYa,

Tauwasser


Tauwasser


Mon 10 Feb 2014, 01:54:41
Board Admin
User avatar

Joined: Fri 10 Apr 2009, 23:48:17

Posts: 1690
Location: 囧国
Post Re: Can anyone else confirm this schematic is retarded?
Tauwasser wrote:
My first observation is that you expect a divider of 13.42329375 (that's 2537/189 or roughly 27/2 ratio) for the 2A03 clock. Where does that come from?

Was mistaken. It should be divide by 12. The 2a03 does this internally. I was planning to clock it at 20MHz externally so the internal clock result would be 1.66MHz.

Thanks for the details. I hadn't expected the Atmel code to actually require that much time. I could probably drop down to an input clock of 18MHz (1.5MHz internally) but that would really mean turning over 100% of the Atmel to driving the 6502, which doesn't make a whole lot of sense.

This is definitely a bit more complicated to interface with than the OPL/M/N class Yamaha chips I've been working with, but I can see why.

I am still guessing two of the ICs are superfluous. The shifters have an OE pin that should let them function in place.

_________________
web :: deviantArt :: 微博 :: Last.fm :: Twitter

Mon 10 Feb 2014, 02:22:17
User avatar

Joined: Tue 02 Nov 2010, 01:00:37

Posts: 181
Post Re: Can anyone else confirm this schematic is retarded?
D-- wrote:
Thanks for the details. I hadn't expected the Atmel code to actually require that much time.


Yeah, doing any interfacing to parallel components is somewhat tough. I used to think my Atmel 8515 was the greatest invention since water, too. Until you really hit a snag when you want to do any kind of slaving to a parallel bus master.

D-- wrote:
I am still guessing two of the ICs are superfluous. The shifters have an OE pin that should let them function in place.


Yes, absolutely. I was still hung up on how there were no power pins. My initial reaction was that shifters might be 3.3V driving 5V logic. If that's not the case, just use the shifters.

However, overall you might be better off with another µC or possibly a little CPLD. <Blatant advertisement for STM32F4 here>

cYa,

Tauwasser

Mon 10 Feb 2014, 06:36:31
Board Admin
User avatar

Joined: Fri 10 Apr 2009, 23:48:17

Posts: 1690
Location: 囧国
Post Re: Can anyone else confirm this schematic is retarded?
Tauwasser wrote:
Yes, absolutely. I was still hung up on how there were no power pins. My initial reaction was that shifters might be 3.3V driving 5V logic. If that's not the case, just use the shifters.

There should be power pins, I think he just forgot to include it in the schematic. They are all running on +5V off the Arduino board. I've used the same chips in other projects (the HC CMOS versions, which are pin compatible with LS).

Tauwasser wrote:
However, overall you might be better off with another µC or possibly a little CPLD. <Blatant advertisement for STM32F4 here>

If I were totally without constraints I would probably use a Loongson 1B prototyping board. I'd prefer working with a familiar MIPS chip rather than ARM (personal preference).

_________________
web :: deviantArt :: 微博 :: Last.fm :: Twitter

Mon 10 Feb 2014, 08:57:50

Who is online

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