RevC1s Debug Thread

Description of your first forum.
User avatar
stef
Posts: 64
Joined: Thu Jan 01, 1970 12:00 am
Location: Somewhere in the Universe
Contact:

RevC1s Debug Thread

Post by stef » Sat Aug 31, 2019 7:52 am

Here is the latest picture of the RevC1s
I am looking forward to post my advancement on testing the board here...

S
Attachments
IMG_20190831_001859.jpg
IMG_20190831_001859.jpg (164.38 KiB) Viewed 238 times
Mistress of All Villainy
User avatar
techristian
Posts: 14
Joined: Mon Apr 15, 2019 1:39 am
Location: Windsor, Ontario
Contact:

Re: RevC1s Debug Thread

Post by techristian » Sat Aug 31, 2019 3:33 pm

2 6581's
YEAH !!

Dan
User avatar
stef
Posts: 64
Joined: Thu Jan 01, 1970 12:00 am
Location: Somewhere in the Universe
Contact:

Re: RevC1s Debug Thread

Post by stef » Sun Sep 01, 2019 7:10 pm

stef wrote:
Sat Aug 31, 2019 7:52 am
Here is the latest picture of the RevC1s
I am looking forward to post my advancement on testing the board here...

S
After finishing the assembly on Saturday, I began making the different changes needed to fit the new RevC0 GAVIN FPGA design that was ported from RevB2, into RevC1. The same way I wanted the CPU Bus to be completely isolated from the rest of the system in RevA which I went away from in RevB, I brought this idea back in RevC0 which was a very big mistake. The whole Multiplexing shtick from the 65C816 is a big hassle and this is amongst the reason I didn't waste time with it and I moved on right away to respin a part of RevC0 so, I went back to the RevB2 architecture in RevC1 + I added the external Latch needed to get the High address because, in the FPGA, that latch was a bit of a pain. Now, each FPGA receive the Full 24Bit address from CPU without creating it for themselves.
One of the main reason I went from 144TQFP package to the FPGA package was that I was running out of IO on the 144TQFP in order to be able to have a full 24Bit access bus that allowed each Custom chip to take over the bus and memory to do DMA cycles. In other words, in RevC in general, each Chip has the capability to request the BUS from GAVIN to perform memory transfer or copy since it can issue a full 24bit address.

Now, the full migration from GAVIN RevC0 to RevC1 was relatively simple, it took me the whole day to get the whole system (video mainly) because I came across some soldering joint issue (Damn, I am so shocked right now... dhu) the first one was relatively easy to fix and obvious to find, I didn't have any clock on the CPU. Gavin is responsible to generate the Clock for the CPU. Well, the short was caused by the Chip Trinity (Xilinx) that had some shorts on it after being reflowed. Apparently I didn't do a good enough job and the Clock input was shorted with the next door pin.
The second instance is the one that got me to work till 2h00AM and forced me to reball VICKY's FPGA. It turns out that the BUS_VDA pin was stuck to ground, actually, it is still stuck to ground. There is a short somewhere. I suspect that BEATRIX might be where the short is... Besides, I implemented a workaround for it and finally, I got my video back. So, bottom line, the pin BUS_VDA was trying to switch but because of the short, it was creating a shitload of noise on the board that made the whole thing behave erratically.
So, this is pretty much it.
Today will be about tightening up the design, implement the changes for RevC0 to RevC1 for Beatrix and I hope by the end of the day, all the testing code will be working flawlessly the same way they do with RevB2. Then I need to move with the Audio section to test its entirety. First step will be to program the CODEC and then we will be moving to OPL3/OPN2/PSG and we will finish with the SID and if we are lucky then RevC1s and RevC1x might be good enough for the waiting patron... However, they would still need to be built on a machine so no soldering issues would occur.

Cheers

Stefany
Attachments
TopLevelSchematic_50%.jpg
Top Level of the Schematic C256 Foenix - FMX - Rev C
TopLevelSchematic_50%.jpg (399.19 KiB) Viewed 216 times
Mistress of All Villainy
jamesd
Posts: 4
Joined: Wed May 29, 2019 10:44 pm

Re: RevC1s Debug Thread

Post by jamesd » Mon Sep 02, 2019 2:59 pm

Building these boards sounds like an epic task.

You do great work though and I'm looking forward to these coming out.
===============================
I want a "Silence of the Lambs" lunchbox
User avatar
stef
Posts: 64
Joined: Thu Jan 01, 1970 12:00 am
Location: Somewhere in the Universe
Contact:

Re: RevC1s Debug Thread

Post by stef » Mon Sep 02, 2019 7:42 pm

jamesd wrote:
Mon Sep 02, 2019 2:59 pm
Building these boards sounds like an epic task.

You do great work though and I'm looking forward to these coming out.
Thanks Jamesd, I really appreciate it.

It is a labor of love, trust me.

S
Mistress of All Villainy
User avatar
stef
Posts: 64
Joined: Thu Jan 01, 1970 12:00 am
Location: Somewhere in the Universe
Contact:

Rev C0/RevC1s/RevC1x

Post by stef » Mon Sep 02, 2019 8:25 pm

Well, yesterday was another day of pain and fucking around...

In order of appearances:
1- The first item on yesterday's to-do list was to get the RDY signal to behave properly. One of the things I want to do in the Rev C, was to have a certain independence on the usage of the RDY because having the total control over the RDY for Beatrix and Vicky would allow Gavin to do Breakpoints in debug mode where I would not have to implement a separated wait state insertion circuitry. The idea was to have an RDY line for the BUS circuitry (everything in between BEATRIX/GAVIN/VICKY) and a separated RDY line for the CPU which is really the point here. By bringing the RDY line low, the CPU will halt where it is and stand there waiting. Then I could have tri-stated the CPU bus and then GAVIN would take control. When the debug is done, then reenable the CPU lines and then release the RDY and the CPU would resume without even knowing.
- Now, the RDY line on the CPU is an open-collector and it has an active pull-up till late last night I wasn't aware of. All this time, I was under the assumption that the RDY line was open collector only then which required an external pull-up. But when you use a Pull-up, you also introduce a longer rise time depending on the value of the resistor, combined with the capacitance load of the trace, then things start to change with your circuitry and how the CPU responds. In a nutshell, my problems that I was having were about the fact that GAVIN was very close to the CPU and that BEATRIX and VICKY are very far away which in turn change the behavior of how the Data was handled. It is important to realize that the problem was never about getting the CPU in standby, it is more about when the data is valid from the device and at the right time for the CPU to capture it. Half a clock cycle too soon or too late, the CPU would not get the right data and the jig was up. And for a while, I was only working with GAVIN and VICKY only, BEATRIX was still empty.
Long story short, until I enabled BEATRIX which ended up adding up to the load, the whole thing was pretty hectic. I did manage to make it work... the Matrix scroll down demo was a good test software since it was writing and reading from Text memory and the reading part requires the insertion of 1 wait state.

2- I found out later that the Short I had on the pin BUS_VDA that is relatively essential turned out to be a PCB short within the internal layers... So, I got a faulty PCB in my batch and I used it... What are the odds? This PCB is the RevC1s made by allpcb in China. They are supposed to be super fast, but they took 10 days to make those and they managed to ship faulty one as well... Now, I can't trust that board anymore.

3- At that point, it is around 1h00Am, I decide to get the CODEC working again so I can hear the amount of noise on the board. After re-balling and reinstalling the 3 FPGA to rule out the BUS_VDA short, I realize that I made a mistake in Beatrix code for the Address decoding of the new location of all those new devices. I fix it, I reflash the Kernel code, and I repower the whole thing at that point I just want to cry... There is this cringing noise on the right side. I begin removing all the audio chip on sockets to see if they are the source... But no, the next step is to see if it is a Rev C problem. So, update BEATRIX code on the RevC0 board and I try again. This time, the results are way better, not perfect, but good enough. So, with the history of that board, I decide that it is a one-off and I shall have to assemble another board, this time, it will be the RevC1x which came from a different manufacturer (JLCPCB) and some minor changes were made to improve a couple of things...

So, today, I have decided to take a break and take care of other stuff...

I will probably assemble the RevC1x tomorrow night after work...

Cheers
Stefany
Attachments
IMG_20190902_131837_Cut.jpg
Demo Matric Code working on RevC1 (Test RDY Signal)
IMG_20190902_131837_Cut.jpg (477.38 KiB) Viewed 151 times
Mistress of All Villainy
User avatar
PJW
Posts: 24
Joined: Wed Apr 24, 2019 12:44 am

Re: RevC1s Debug Thread

Post by PJW » Mon Sep 02, 2019 9:13 pm

Oh wow... sounds like a super-frustrating night.

With the RDY line... would that pull-up be in there for when it's used as an output? I've never made anything with the 65816, so I don't know, but I find the way they use that line on that chip to be very confusing.
User avatar
techristian
Posts: 14
Joined: Mon Apr 15, 2019 1:39 am
Location: Windsor, Ontario
Contact:

Re: RevC1s Debug Thread

Post by techristian » Tue Sep 03, 2019 1:46 am

EVERYTHING EFFECTS EVERYTHING. I'm learning that with my own software project. I keep adding features thinking that everything is NAILED DOWN and then something I haven't looked at for almost a year starts to go bad.

Anyway with SOUND, look at your GROUNDING, and proximity to to other devices . You may need to add some additional CAPS for filtering .

I also had another thought.
If you are not INITIATING the sound chips with some code to turn them off, they will boot up in a random state....perhaps even with a 15-20khz hum AT FULL VOLUME.



Dan
User avatar
stef
Posts: 64
Joined: Thu Jan 01, 1970 12:00 am
Location: Somewhere in the Universe
Contact:

Moving on from RevC1s to RevC1x

Post by stef » Wed Sep 04, 2019 4:54 pm

Stefany's log, stardate : 73140.7

alright, I tend to make life difficult for myself because apparently I love to struggle. :o) I have assembled a RevC1x late Monday night and I did it with Lead Free paste since the BGAs have lead free balls. I can tell you right now this is not something I will do again. At that point, I would rather have to reball the chip from their original bag than to deal with this shit again. The next time I will deal with lead-free paste is when I do the final production. In that case, I won't have any choice, however, I will have the right equipment.

I finished the assembly yesterday night where I finished the backside (decoupling cap for the FPGAs) and I installed some connectors (power/J-tag/DVI/Audio Jack for headphone) and the power switch. Since I inspected and checked for shorts before, by the time I powered it up everything was fine. SO usually, when all the power rails are good and nothing is smoking away. Usually the next very important step is to test the JTAG connection because without it. You will be stranded. And of course, the JTAG didn't work. So, back to the heating plate and shit load of flux. I had to reflow these puppies again and make sure they would be in happy land underneath each BGAs by fill it with no-clean liquid flux and also give them a little tap, to make sure everybody would be melted properly. After I was done with that... Tha dha dha... The JTAG port works. The next step was to actually program the parts with the latest code. I put a fresh Kernel in there and right from the start I could tell something wasn't right... it turns out I inverted the 25.175Mhz with the 14.318Mhz oscillator which made the SuperIO blinking light go a lot faster than it usually does and the CPU didn't boot. So now we know that the 65C816 @ 3.3V doesn't work @ 25Mhz.

This is my report from Discord after I inverted the Oscillator:
Okay good news... After switching the oscillators the CPU started to run the code and it initialized the codec. At first I ended up having the same kind of screeching sound that I used to have with the RevC1s. Then I finally found the reason why I was having that problem. What happened is that I left the DAC input pin floating. So after putting it to ground it stopped doing the screeching sound.
However, apparently the level of noise on the 3.3 volts power supply is noisy enough to get out of mute mode. In the revision b2 the 3.3 volt power supply was driven by a low noise, low dropout linear regulator. In the revision c1x 3.3 volt power supply is a switching power supply so the amount of noise on the power rail is superior than on the reversion b2. The deal now is that I can hear the noise of the power supply in the headphones.
So tomorrow I will set up the board with a linear regulator the same way revision b2 was set up so that way I will see if this is really the problem and possibly the hissing sound will go away. The deal usually is that if there is no input on the codec then the mute is engage and when there's an audiosignal coming in then usually the noise of the power supply will be mixed in and we won't hear it unless the level of the audio that is being fed to the codec is low enough.

Which for the time being would be good enough for me.

So if tomorrow's patch turns out to give good results that means that revision c2 will require more attention on the 3.3/5V power supply for the audio section.

This is where I am now, tonight ought to be interesting and I have yet to get the video back since it is not showing anything.

Cheers

Stefany
Mistress of All Villainy
User avatar
stef
Posts: 64
Joined: Thu Jan 01, 1970 12:00 am
Location: Somewhere in the Universe
Contact:

Re: RevC1s Debug Thread

Post by stef » Tue Sep 17, 2019 4:48 am

I am posting here to give an update on the RevC1X.

Well, after I realized that I would be stuck with a truckload of problems if I kept going with that board with BGAs, I decided to stop, something I should have done a while ago.

I decided to step back and see if there was not a different route I could take so I could have the same kind of features but to come back to the RevB2 board layout with only 4 layers and no BGA. After some research, I did find a solution and not only I found a solution I did find a somewhat cheaper solution and that would give me a total late 1980's look. So much better than BGAs that would break the retro magic.

So, I present to you the upcoming version RevCX:
Attachments
Bareboard_95%_Routed_Black_FrontView_40%.jpg
C256 Foenix RevCX - FMX Ready
Bareboard_95%_Routed_Black_FrontView_40%.jpg (464.39 KiB) Viewed 49 times
Mistress of All Villainy
Post Reply