Addressing logic

[jbaum81]

48 minutes ago, picosecond said:

Yes, TTL and CMOS have different specifications for low and high voltage levels.  Let's assume a minimum VCC of 4.5V for this example.



For the F521, a "1" at the output means a voltage greater than 2.5V.  This is the VOH(min) parameter in the datasheet.



For the AC11032, a "1" at the input is guaranteed to be recognized only if the voltage is 3.15V or greater.  This is the VIH(min) parameter in the datasheet.



So a perfectly valid "1" for the F521 could be wrongly interpreted as a "0" by the AC11032.  Obviously that would be bad.  If you ever wondered why there are both AC and ACT logic families this is the reason.  ACT input voltage thresholds are shifted downwards to be compatible with TTL output voltages.



This article has a more complete explanation:  https://www.allaboutcircuits.com/textbook/digital/chpt-3/logic-signal-voltage-levels/



As an aside, in your last schematic you could connect RW to that unused 'F521 input and save some glue logic.

 

I think I was under the assumption that eventually the signal levels would reach 0 or 5v and that'd be totally okay given the amount of time, of course this would be predicated on stable power, right? I'll definitely look into alternatives, but finding low propagation delay logic gates has been somewhat challenging. 

As for running RW through the grounded input on the low address range F521, it's definitely a good idea, and would work, but I'm using the CLKWR signal out of that AND gate for write enable on the ram chips anyways. I don't think it's required, but I do have the time and wanted to try to make sure all address and select logic is taking place on low clock, with writes only occurring during high clock. I got lazy and didn't give the same consideration for reads, but meh, not really necessary, at least as far as I can tell. Trying to learn, the best I can, from my understanding of the mistakes Adrian pointed out on the 2nd proto board with timing. 

As an aside, I just updated my PCB layout and seen all the logic IC's and their associated rats nests drop into my, so far, beautifully laid out board and traces. I admit, I leaned back in my chair and started wondering why in the hell I'm trying to do this all through hole lol. I may just scrap my progress and switch to SMD. If I can figure out how to program the ROM while it's soldered onto the board I may switch to SMD and try to shoot for some faster RAM/ROM chips and maybe shoot for 12mhz.... Oh I think I could use a clock divider and leverage another flipflop in the IO area to change the speed on the fly. I think that'd be kind of fun.

 

 

[picosecond]

36 minutes ago, jbaum81 said:

I was under the assumption that eventually the signal levels would reach 0 or 5v

That's not an unreasonable intuition but TTL doesn't work that way.

41 minutes ago, jbaum81 said:

Trying to learn, the best I can, from my understanding of the mistakes Adrian pointed out on the 2nd proto board with timing.

Timing is an interesting subject.  If you are interested in testing your understanding, can you explain which violated timing parameter Adrian fixed on proto #2?

[Wavicle]

5 hours ago, jbaum81 said:

I think I found my solution!!! 



Using some 8 bit comparators. All logic is >= 10ns at each phase. 



I think my only gap here is the flip-flop for the rom. I think I need to hold OE high with some pull down resistors on it's outputs to keep the rom on bank 0 for boot. Was thinking maybe a 555 timer tied to the yet to be created reset circuit.... The thought would be to hold RST low during power on with some additional logic to keep OE high long enough to execute an instruction to latch it at 00. Anyone have a better idea for boot?



 

Depending on what you're trying to achieve, you might consider replacing most of those components with the Atmel ATF16V8C. SPLDs are the evolutionary descendants of the PAL chips used by early computers like the C64. Two of these cascaded should give you the ability to do address decoding of 16 address lines + R/W in 15ns (maybe 15 address lines + R/W, I'm a little uncertain what the deal with I9/OE is). Less than $2 each and they're reprogrammable.

[jbaum81]

On 3/6/2021 at 10:59 AM, jbaum81 said:

 



I think I was under the assumption that eventually the signal levels would reach 0 or 5v and that'd be totally okay given the amount of time, of course this would be predicated on stable power, right? I'll definitely look into alternatives, but finding low propagation delay logic gates has been somewhat challenging. 



As for running RW through the grounded input on the low address range F521, it's definitely a good idea, and would work, but I'm using the CLKWR signal out of that AND gate for write enable on the ram chips anyways. I don't think it's required, but I do have the time and wanted to try to make sure all address and select logic is taking place on low clock, with writes only occurring during high clock. I got lazy and didn't give the same consideration for reads, but meh, not really necessary, at least as far as I can tell. Trying to learn, the best I can, from my understanding of the mistakes Adrian pointed out on the 2nd proto board with timing. 



As an aside, I just updated my PCB layout and seen all the logic IC's and their associated rats nests drop into my, so far, beautifully laid out board and traces. I admit, I leaned back in my chair and started wondering why in the hell I'm trying to do this all through hole lol. I may just scrap my progress and switch to SMD. If I can figure out how to program the ROM while it's soldered onto the board I may switch to SMD and try to shoot for some faster RAM/ROM chips and maybe shoot for 12mhz.... Oh I think I could use a clock divider and leverage another flipflop in the IO area to change the speed on the fly. I think that'd be kind of fun.



 



 

Almost positive he mentioned the vera needing writes on high clock, and im thinking the audio chip, but simce none of the tests were working im thinking there might have been a yiming issue woth the rom. I dont remeber the specifics as it relates to the cx16, but it motivated me to try to read and understand the data sheets. Ben Eater also has some pretty good material on understanding it. My main take away was to attempt to have address and and data stable prior to writes, the 6502 doesnt seem as sensetive on reads as long as its stable by, iirc, something like 30ns from the falling edge. 

[BruceMcF]

2 hours ago, jbaum81 said:

Almost positive he mentioned the vera needing writes on high clock, and im thinking the audio chip, but simce none of the tests were working im thinking there might have been a yiming issue woth the rom. I dont remeber the specifics as it relates to the cx16, but it motivated me to try to read and understand the data sheets. Ben Eater also has some pretty good material on understanding it. My main take away was to attempt to have address and and data stable prior to writes, the 6502 doesnt seem as sensetive on reads as long as its stable by, iirc, something like 30ns from the falling edge. 

The YM sound chip needs A0 to be set up minimum T_AS or more before /CS and/or /WR and/or /RD, and remain set up until after they are released, because A0 decides whether the register address latch or the register with the currently latched address is being selected, so the timing is not that different from a PIC style bus. If A0 can be asserted early enough before PHI2 rises, having /WR /RD and /CS synchronous with PHI2=1 would ensure that. The Address/Data port is not strictly clocked ... the clock input is for operation of the FM synthesis ... the cycles are from the later of /CS and either /WR or /RD, respectively, through to the earlier of CS and either WR or RD, respectively.

(I would not be surprised if the OPM chips they are using are the CMOS versions, and since the datasheet I have is the original OPM, the minimum set-ups, holds and releases may be shorter than the timing I am looking at.)

By contrast, the VIA's need address, /CS and R/W to be setup tACR/tACW before PHI2=1, which at +5VCC is given as a minimum of 10ns, so R/W and /CS synchronous with the clock would violate that.

And Vera, the SRAM and the FlashROM, I wouldn't have any idea, all of that is well after my time.

[jbaum81]

So much to learn and so little time haha. At least I can say it's a hell of a lot cheaper of a hobby than my previous reef keeping or RC Helicopter hobbies. I'm thinking it might be time to retire the old DSO nano scope and move into a benchtop 2 channel scope. 

I can't believe how cheap it is to have boards printed now. Last time I had a board done was about 10 years ago and you had to join in on a group buy type thing and wait till the board was filled and printed in china. Took like 6 weeks. 

 

[Wavicle]

1 hour ago, jbaum81 said:

I can't believe how cheap it is to have boards printed now. Last time I had a board done was about 10 years ago and you had to join in on a group buy type thing and wait till the board was filled and printed in china. Took like 6 weeks. 

Interestingly, you are still effectively waiting for the board to get filled and printed, but the manufacturer has streamlined the process to the point that the wait queue is on the order of a few hours. E.g. the thumb nail of this video which shows at least two different PCBs or around 16:09 there is a shot of a board that looks like it has 7 or 8 different designs on it. The last time I checked on having a board made locally, it was 20x more expensive and would take twice as long to get it. I'm pretty sure they catered to companies that could not offshore PCB production for secrecy reasons.

 

[Yazwho]

It is amazing. Imagine, in the next 10 years, maybe we'll be able to get our own chips printed for a similar cost!

 

[picosecond]

On 3/11/2021 at 2:36 AM, BruceMcF said:

VIA's need address, /CS and R/W to be setup tACR/tACW before PHI2=1

Exactly.  Gating the raw decoded chip select with PHI2 obviously puts /CS well after PHI2 rise.  They missed the setup window.

On 3/11/2021 at 2:36 AM, BruceMcF said:

having /WR /RD and /CS synchronous with PHI2=1 would ensure that

Controlling only the YM2151 /CS is sufficient.  All of the data timing parameters reference the last control signal change.

Zero wait state operation isn't so easy at 8MHz.  Access time is 180ns so reads are totally broken.  But those are used only to check interrupt status.  Interrupts might not even be connected.  The easy fix is to simply disallow reads.

Zero wait state writes cannot meet the timing requirements by using PHI2 edges for pulse forming.  Using the typical design pattern will violate Tcw(100ns) and Tds(50ns).  That probably works fine on the bench at room temp but may not be reliable across a production run.  Some kind of /CS pulse stretching is needed to satisfy the datasheet requirements.

After the VIA timing problems I imagine the team reviewed every chip's timing requirements, and have a plan to address this in proto#3.  Or maybe they just plan to screen YM2151s before using them.

On 3/11/2021 at 2:36 AM, BruceMcF said:

(I would not be surprised if the OPM chips they are using are the CMOS versions, and since the datasheet I have is the original OPM, the minimum set-ups, holds and releases may be shorter than the timing I am looking at.)

Do such versions exist?  I have never encountered a reference that suggests this, let alone a datasheet that quantifies the timing differences.

[ZeroByte]

2 hours ago, picosecond said:

Zero wait state operation isn't so easy at 8MHz.  Access time is 180ns so reads are totally broken.  But those are used only to check interrupt status.  Interrupts might not even be connected.  The easy fix is to simply disallow reads.

Hmm - I've been wondering whether the real YMs could support reads @8MHz or not. The YM read also has one more important functionality than IRQ checking - the busy flag.

This isn't an issue in the emulator because the YM2151 library being used doesn't emulate the chip's busy state anyway. The real chip requires 64 YM clock cycles after writing data before you can write to it again. The real HW will obviously have this issue, and the fastest way to write data to it reliably is to read the busy flag until it's zero, then do your write. (That's how the sound CPU does it in Street Fighter II, for instance). Otherwise, you have to just do some busy loops which probably take an average of n/2 clock cycles longer than necessary away from your program if you just busy loop yourself.

Then again, that would just become one of the challenges of coding on the platform, eh?