Commander X16

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.

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.

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.

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.

 

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.

 

 

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??

 

 

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.

 

 

 

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.

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

 

 

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).