Jump to content

Addressing logic


jbaum81
 Share

Recommended Posts

53 minutes ago, ZeroByte said:

The YM read also has one more important functionality than IRQ checking - the busy flag.

Right.  I omitted that intentionally, which makes it all the dumber.  I was thinking applications would schedule writes on their own.  But the schedule would be for blocks of writes, not individual ones. Thanks for the correction.

Anyway, I suppose it is possible reads are working on the bench but that is almost worse.  It is much better for things to be broken-broken, not sometimes-broken or sometime-in-the-future-broken.  It would suck to have a batch of slow parts causing sound problems halfway through a production run.  It's even worse if the slow parts break a bunch of DIY kits.

Link to comment
Share on other sites

13 minutes ago, picosecond said:

But the schedule would be for blocks of writes

In most real-world programs, definitely true. I wrote a VGM playback routine that used the VIA timer IRQ for exact 44.1Khz timing of the writes.... this would be "scheduled writing" and my calculation was that this method chewed up a ton of the CPU's time - I forget how I arrived at the result, but it seemed to be around 25% CPU load if I recall correctly.

I have been curious whether Kevin or anyone else has tested the ability to read the status flag from the YM2151 on real HW yet.

Back when I was helping him test the YM2151 on the prototype1 board, I wanted to make a test program for this aspect as well. Unfortunately, at the time there was no way to read software in from disk, so he would have had to type the whole thing in manually. If he's interested, I'd be more than happy to submit a quick test program, now that it's possible to load programs from SD cards on real HW. I guess it's kind of a moot point now, as the chip's going in one way or another, but it would at least be good to know so that if reads are impossible, the documentation could reflect that and the community could plan accordingly in their projects.

Link to comment
Share on other sites

50 minutes ago, ZeroByte said:

I have been curious whether Kevin or anyone else has tested the ability to read the status flag from the YM2151 on real HW yet.

He has run my game "Chase Vault" on there, and the YM2151 music plays back perfectly. I'm doing a busy loop waiting for ready before each write, and it all seems to work the same between the emulator and the prototype. The only difference is on the emulator, the status always reads as "ready", so it may be a bit faster when updates need to be made to the YM2151. Good news is, most of the time cycles go by without needing to write an update. 60Hz is pretty fast! Even loading a large patch still won't take a huge amount of time, and could be split up across cycles if necessary.

  • Thanks 1
Link to comment
Share on other sites

10 minutes ago, SlithyMatt said:

He has run my game "Chase Vault" on there, and the YM2151 music plays back perfectly.  I'm doing a busy loop waiting for ready before each write, and it all seems to work the same between the emulator and the prototype.

I knew he had run it, but didn't know what your write methodology was like (although it makes sense that I could've read your source code - lol).

That's very good to know - I've been writing my YM code as though it would work properly on the real system.

 

Link to comment
Share on other sites

On 3/16/2021 at 10:22 PM, 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.

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.

So A0 must be valid 10ns before /CS, /CS must hold for 100ns, write data must be valid 50ns before /CS releases, and must continue to be valid 10ns after /CS releases. At 8MHz, the clock pulse widths are ~60ns. With the 65C02 having a maximum write data delay of 25ns after PHI2=1 begins (at +5VCC), and a minimum write data hold time of 10ns, that is a minimum of ~35ns before /PHI2 and 10ns after ...

... so yeah, that looks like either a wait state of a pulse (that is, inverting PHI2 or not) or a cycle (that is, or-ing PHI2 and WAIT). A wait state would seem to also fix the issue with read timings, while a write latch would work best if reads are not enabled, but obviously the wait state is simplest if there are not reads and /WR is tied low, since the cycle ends with the first of /WR&/CS or /RD&/CS to rise.

 

 

Edited by BruceMcF
Link to comment
Share on other sites

  • 2 weeks later...

Well I decided to go with some PAL's to clean up the addressing logic, it runs for hours at 11mhz on the breadboard, and only a few minutes @ 12mhz. The data lines get an occasional weird artifact on high, but the address lines look pretty good, there is some small artificating here and there but doesn't seem to cause any issues, and may well be the cheapish scope.. 

The ROM is only 70NS so it's surprising it runs at all at 12mhz, with address setup time that's 100ns, in an only 83ns cycle. I did enable the rom on low clock to try to squeeze some extra performance out of it, all other OE/Write's are done on the rising edge of the clock. 

The flipflops do set the outputs low on reset, but I'm having trouble latching them, I get random results, not sure, but I think I may have fried them. I need to pull them out of the circuit to test them by themselves. 

Also strangely enough, I bought a 8mhz crystal and it says it's a hcmos output, but the wave looks like a shark tooth and my computer wont run with it, but using the wave generator I've had it running all the way up to 14mhz, although not very stable. The wave at 11mhz on the signal generator isn't very square, but it still works. Trying to figure out why the 8mhz oscillator doesn't..... Should I be shooting for something that produces more of a square wave, or is that even possible at those speeds? Or maybe my scope lacks the resolution??

 

 

6502logic.PNG

20210327_175754.jpg

20210327_175825.jpg

20210328_175734.jpg

20210328_175738.jpg

  • Like 1
Link to comment
Share on other sites

23 hours ago, jbaum81 said:

Also strangely enough, I bought a 8mhz crystal and it says it's a hcmos output, but the wave looks like a shark tooth and my computer wont run with it, ...

Don't actually know, but from what I read, the crystal won't be a square wave without a circuit to square out the wave ... that's what else is inside the clock generator modules in addition to the crystal. So perhaps "HCMOS output" indicates that it's compatible with a CMOS square wave circuit. EG, see,  https://circuitdigest.com/tutorial/quartz-crystal-oscillator

The third circuit down gives a CMOS crystal oscillator circuit, though the cap and resistor values would need adjustment as IIRC that circuit example is for a 20MHz.

Any quartz oscillator will oscillate between it's low and high value like that ... AFAIR the crystal provides the stable frequency, not the square wave form.

According to the datasheet, the test circuit should have 30 pF capacitance on the clock output line, including the capacitance of the probe, and under those conditions (and 0.01uF capacitance between VCC and GND), the rise and fall times should be a maximum of 10ns, which would be a long way from that sharks tooth that looks more like the crystal inside the can.

 

 

 

Edited by BruceMcF
fixing link
Link to comment
Share on other sites

1 hour ago, jbaum81 said:

Also strangely enough, I bought a 8mhz crystal and it says it's a hcmos output, but the wave looks like a shark tooth and my computer wont run with it, but using the wave generator I've had it running all the way up to 14mhz, although not very stable. The wave at 11mhz on the signal generator isn't very square, but it still works. Trying to figure out why the 8mhz oscillator doesn't..... Should I be shooting for something that produces more of a square wave, or is that even possible at those speeds? Or maybe my scope lacks the resolution??

It's possible that the parasitic capacitance on your board (especially on a solderless breadboard) is rounding out the peaks. Can you probe the output of the clock off the board? One possible workaround is to use a schmitt trigger to square the clock input to the CPU. I haven't tried that myself, your mileage may vary, it should work "in theory". Just be aware that this will probably invert and add a slight delay to the clock - if you have anything else that using the clock, it will need the same treatment.

Link to comment
Share on other sites

3 hours ago, Wavicle said:

It's possible that the parasitic capacitance on your board (especially on a solderless breadboard) is rounding out the peaks. Can you probe the output of the clock off the board? One possible workaround is to use a schmitt trigger to square the clock input to the CPU. I haven't tried that myself, your mileage may vary, it should work "in theory". Just be aware that this will probably invert and add a slight delay to the clock - if you have anything else that using the clock, it will need the same treatment.

Think I may have figured it out, the wave goes from ~2.5v to 5.0v, this is the device I got, says hcmos/ttl format. Not sure if it's bad or I'm misunderstanding something, but I never get 0 logic levels so that's probably why it isn't running it. Can't take a picture right now, phone is dead. I'll follow up tomorrow. 

https://www.mouser.com/ProductDetail/774-MXO45HS-3C-8.0

 

 

Link to comment
Share on other sites

6 hours ago, jbaum81 said:

Think I may have figured it out, the wave goes from ~2.5v to 5.0v, this is the device I got, says hcmos/ttl format. Not sure if it's bad or I'm misunderstanding something, but I never get 0 logic levels so that's probably why it isn't running it. Can't take a picture right now, phone is dead. I'll follow up tomorrow. 

https://www.mouser.com/ProductDetail/774-MXO45HS-3C-8.0

 

 

Oh, I see. Your last picture is looking at the signal generator's 11MHz output. In that case, I more strongly think you are seeing the result of stray capacitance on the scope.

According to the datasheet for that part, the swing on a TTL load should go from V_OL = 0.4V max to V_OH = 2.4V min (i.e <= 0.4V to >= 2.4V). A 2.5V bias doesn't sound quite right - is there anything attached to the clock output that might have a pull up? I'm guessing not, in which case I'm going with capacitance again. The shark fin pattern is something I've seen when probing I2C lines which tend to be fairly long and have a lot of stray capacitance. (Here is an example I2C probe I found from a quick search). It may be that the crystal doesn't have enough drive strength to pull the line all the way down before it meets the rising edge of the next cycle and that is why you see what appears to be a 2.5V bias (I'm speculating here without a scope photo).

  • Like 1
Link to comment
Share on other sites

9 hours ago, jbaum81 said:

the wave goes from ~2.5v to 5.0v

 

2 hours ago, Wavicle said:

I more strongly think you are seeing the result of stray capacitance on the scope

Here is my speculation: It's the low impedance of the scope probe.  Try switching to 10x mode.

  • Like 1
Link to comment
Share on other sites

2 hours ago, picosecond said:

 

Here is my speculation: It's the low impedance of the scope probe.  Try switching to 10x mode.

The datasheet says the output current of the part is 16mA, so I'd think that a 1MOhm probe wouldn't have a significant effect... but I'm honestly not sure. It sounds like the circuit wasn't working when not being probed, but maybe there are two different problems going on here. Very interested to hear if switching to 10x mode fixes the problem.

Link to comment
Share on other sites

Nope, I cooked the Oscillator 😞 , I must have hooked something up backwards, Ordered a new 8mhz oscillator and it's fine.

Also figured out the issue with the flipflops on the banks. I was sending the clock signal to the flipflops when the address was set and clock went high, but for some reason the datelines were not ready fast enough, which doesn't seem consistent with 65c02 data sheet?!?. None the less I changed the programming of the PAL to send the clock pulse to the FlipFlops on the falling edge instead, where I could tell the data and address is held at least for a few NS. This did work, but does have the negative effect of sending two clock pulses per cycle to the flipflop but even if it does mess up the address lines for the ROM/ HiRAM it's okay since the lines are set right at the completion of the cycle prior to any attempt to read / write from ROM/HiRam. 

Incidentally I did order a couple SST39SF040's ROM's which are rated at 70NS,  and was able to run the clock up to 14.75MHZ overnight and was stable. 15mhz did produce some corruption haha. This is on a breadboard so the theory is that on the printed board it should be awesome at 8mhz... But wait, not so fast!! 

I did order up a batch of boards, I did forget the pullup resistor on the reset line 🤫.. Can't find any other issues with the board, but it doesn't run :(. I'm using Ben eaters Arduino monitoring and it looks like data lines are floating ?? I pulled the PAL's ran a more simple addressing scheme (Ben's) through some NAND gates jumped over on a breadboard and it was stable. Running a much much slower clock I'm on occasion able to get it to behave for a while just flashing some LED's back and forth on the 65c22, but it's by no means stable. Thinking I screwed up the board I soldered up another and same stuff. It's a 4 layer board with really small traces that go between pins so I'm worried something may have gone wrong somewhere there. Need to run through the logic chips and check for continuity issues maybe with an address line somewhere? I'm really not sure at this point, I can't find anything wrong in my CAD software. If anyone is interested in providing an extra set of eyes, I have no issues sharing my files, just PM me. I'll update back when i find the issue. 

Link to comment
Share on other sites

1 hour ago, jbaum81 said:

Nope, I cooked the Oscillator 😞 , I must have hooked something up backwards, Ordered a new 8mhz oscillator and it's fine.

Also figured out the issue with the flipflops on the banks. I was sending the clock signal to the flipflops when the address was set and clock went high, but for some reason the datelines were not ready fast enough, which doesn't seem consistent with 65c02 data sheet?!? ...

Now THAT seems like it makes sense, even to a software hand ... if it happened to be an HCMOS crystal oscillator circuit in the can, fry the inverters, which are the source of the VCC input, and seeing the crystal oscillation instead of a square wave seems likely, since the inverters are what squares up the wave.

But anyway, that's second timing is what the August 2018 datasheet says on page 26 ... the fourth line in the timing chart is the write data ... it begins with the data written the previous cycle, which should be valid tDHW after the start of the new cycle with the PHI2=0 transition ... it then crosses over since it is indeterminate until it crosses over again tMDS after the PHI2=1 transition for the rising clock cycle. So the valid write data is from tMDS (max 25ns[+]) after the rising clock cycle until tDHW (min 10ns) after the falling clock cycle. With a glue logic latch, data can be latched on the fall of the clock after the part is selected, as long as the latch is effective within 10ns of the falling clock.

_________________________________
[+ At +5VCC, 40ns at +3.0/3.3VCC, 70ns at +2.8VCC, 140ns at +1.8VCC.]

Edited by BruceMcF
Was confused at first about the VCC to GND paths.
Link to comment
Share on other sites

DANG IT!!! 

Found the last issue, Labeled the RW pin RWB in on the main sheet and RW in the logic sheet. Had to run a bodge from the RW input on my PAL to RWB net and now the board runs stable at 15Mhz!! woot!! 

Already started the 2nd revision with a few other enhancements like an LED array to show activity on the devices. It will be helpful when running slow and a cool light display when running full out. 

 

  • Like 1
Link to comment
Share on other sites

3 minutes ago, BruceMcF said:

With a glue logic latch, data can be latched on the fall of the clock after the part is selected, as long as the latch is effective within 10ns of the falling clock.

_________________________________
[+ At +5VCC, 40ns at +3.0/3.3VCC, 70ns at +2.8VCC, 140ns at +1.8VCC.]

Yup, that's essentially what I'm doing, just using just switched out the logic in the SPLD to trigger the clock pin on the latch on the falling edge. 

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use