Arduino In-Circuit Tester: Build Project

[Dave2084]

So I've been staring at pages on git for some time trying to work out how I merge Paul's changes into my branch and I'm none the wiser.

How do I do a cross fork pull request to copy Pauls 6809e branch changes to my Williams branch?

Confused of Lincoln.

I'll just copy the changes manually.

 

[Dave2084]

Actually comparing the 6809e branch with the master I was working with there are other differences before the last commit.

 

[guddler]

You need to make sure you have an 'upstream' defined (Paul's repo) and pull from that.

[EDIT] Sorry, I probably mean merge from that, not pull! Basically search for merge upstream changes. I need to do the same and get the 6502 stuff tested against Asteroids when I can finally find some spare time.
guddler2016-02-27 16:43:49

 

[Judder]

Hi Dave

Apologies - been out and about today

1. Make sure you have Paul's repo setup as one of your remotes

Here's the output from mine

alexanderjudd@Alexanders-MBP arduino-mega-ict (6802) $ git remote -v

[font="Courier New, Courier, mono"]dave https://github.com/Dave2084/arduino-mega-ict (fetch)[/font]

[font="Courier New, Courier, mono"]dave https://github.com/Dave2084/arduino-mega-ict (push)[/font]

[font="Courier New, Courier, mono"]origin https://github.com/Judder/arduino-mega-ict.git (fetch)[/font]

[font="Courier New, Courier, mono"]origin https://github.com/Judder/arduino-mega-ict.git (push)[/font]

[font="Courier New, Courier, mono"]paul https://github.com/prswan/arduino-mega-ict.git (fetch)[/font]

[font="Courier New, Courier, mono"]paul https://github.com/prswan/arduino-mega-ict.git (push)[/font]

so in my case Paul's repo is aliased as 'paul'

2. Make sure I am on my local branch that I want to update (* indicates checked out branch)

[font="Courier New, Courier, mono"]alexanderjudd@Alexanders-MBP arduino-mega-ict (6802) $ git branch[/font]

[font="Courier New, Courier, mono"]* 6802[/font]

[font="Courier New, Courier, mono"] master[/font]

3. Pull Paul's master branch to update your local branch to get all his changes

[font="Courier New, Courier, mono"]alexanderjudd@Alexanders-MBP arduino-mega-ict (6802) $ git pull paul master[/font]

[font="Courier New, Courier, mono"]remote: Counting objects: 16, done.[/font]

[font="Courier New, Courier, mono"]remote: Compressing objects: 100% (16/16), done.[/font]

[font="Courier New, Courier, mono"]remote: Total 16 (delta 7), reused 0 (delta 0), pack-reused 0[/font]

[font="Courier New, Courier, mono"]Unpacking objects: 100% (16/16), done.[/font]

[font="Courier New, Courier, mono"]From https://github.com/prswan/arduino-mega-ict[/font]

[font="Courier New, Courier, mono"] * branch master -> FETCH_HEAD[/font]

[font="Courier New, Courier, mono"] 2c5fa17..232bd6d master -> paul/master[/font]

[font="Courier New, Courier, mono"]Merge made by the 'recursive' strategy.[/font]

[font="Courier New, Courier, mono"] InCircuitTester6502/InCircuitTester6502.ino | 8 +-[/font]

[font="Courier New, Courier, mono"] libraries/C6502Cpu/6502PinDescription.cpp | 87 +++++++++++++++[/font]

[font="Courier New, Courier, mono"] libraries/C6502Cpu/6502PinDescription.h | 61 +++++++++++[/font]

[font="Courier New, Courier, mono"] libraries/C6502Cpu/C6502ClockMasterCpu.cpp | 399 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++[/font]

[font="Courier New, Courier, mono"] libraries/C6502Cpu/C6502ClockMasterCpu.h | 147 +++++++++++++++++++++++++[/font]

[font="Courier New, Courier, mono"] libraries/C6502Cpu/C6502Cpu.cpp | 128 +++-------------------[/font]

[font="Courier New, Courier, mono"] libraries/C6502Cpu/C6502Cpu.h | 1 -[/font]

[font="Courier New, Courier, mono"] libraries/C6502Cpu/CAstroFighterBaseGame.cpp | 108 +++++++++++++++++-[/font]

[font="Courier New, Courier, mono"] libraries/C6502Cpu/CAstroFighterBaseGame.h | 2 +-[/font]

[font="Courier New, Courier, mono"] libraries/C6502Cpu/CTomahawk777Game.cpp | 65 ++++-------[/font]

[font="Courier New, Courier, mono"] libraries/C6502Cpu/CTomahawk777Game.h | 4 +[/font]

[font="Courier New, Courier, mono"] 11 files changed, 842 insertions(+), 168 deletions(-)[/font]

[font="Courier New, Courier, mono"] create mode 100644 libraries/C6502Cpu/6502PinDescription.cpp[/font]

[font="Courier New, Courier, mono"] create mode 100644 libraries/C6502Cpu/6502PinDescription.h[/font]

[font="Courier New, Courier, mono"] create mode 100644 libraries/C6502Cpu/C6502ClockMasterCpu.cpp[/font]

[font="Courier New, Courier, mono"] create mode 100644 libraries/C6502Cpu/C6502ClockMasterCpu.h[/font]

4. Fix any merge conflicts (I didn't have any so just saved the auto generated Merge log message to validate the commit)

5. Check the git log to see what the last commit was (should be something Paul did if he worked on it later than you

[font="Courier New, Courier, mono"]git log[/font]

[font="Courier New, Courier, mono"]commit fd783a0bb7144c78f274021b263c5fb8eecded08[/font]

[font="Courier New, Courier, mono"]Merge: 1b6875f 232bd6d[/font]

[font="Courier New, Courier, mono"]Author: Alexander Judd <alex@skywire.co.uk>[/font]

[font="Courier New, Courier, mono"]Date: Sat Feb 27 18:11:26 2016 +0000[/font]

[font="Courier New, Courier, mono"]
[/font]

[font="Courier New, Courier, mono"] Merge branch 'master' of https://github.com/prswan/arduino-mega-ict into 6802[/font]

[font="Courier New, Courier, mono"]
[/font]

[font="Courier New, Courier, mono"]commit 232bd6d3d6c929175f2f005dd2f9ea8193dcb2f1[/font]

[font="Courier New, Courier, mono"]Merge: 2c5fa17 17fc775[/font]

[font="Courier New, Courier, mono"]Author: Paul Swan <prswan@gmail.com>[/font]

[font="Courier New, Courier, mono"]Date: Fri Feb 26 20:19:19 2016 -0800[/font]

[font="Courier New, Courier, mono"]
[/font]

[font="Courier New, Courier, mono"] Merge pull request #5 from prswan/6502_clock_master[/font]

[font="Courier New, Courier, mono"] [/font]

[font="Courier New, Courier, mono"] Implementation of 6502 clock master support verified on Astro Fighter[/font]

[font="Courier New, Courier, mono"]
[/font]

[font="Courier New, Courier, mono"]commit 17fc775a4be2c89ac824e68202b88fefc6e81144[/font]

[font="Courier New, Courier, mono"]Author: Paul Swan <prswan@gmail.com>[/font]

[font="Courier New, Courier, mono"]Date: Fri Feb 26 08:51:33 2016 -0800[/font]

[font="Courier New, Courier, mono"]
[/font]

[font="Courier New, Courier, mono"] 6502: Update various comments and clean up the Astro Fighter DRAM description.[/font]

[font="Courier New, Courier, mono"]
[/font]

[font="Courier New, Courier, mono"]commit 7afbe87854b1559e952e1c77d9b1e11d5222f842[/font]

[font="Courier New, Courier, mono"]Author: Paul Swan <prswan@gmail.com>[/font]

[font="Courier New, Courier, mono"]Date: Wed Feb 24 21:19:17 2016 -0800[/font]

[font="Courier New, Courier, mono"]
[/font]

[font="Courier New, Courier, mono"] 6502: Clock master support for testing DRAM on Astro Fighter.[/font]

6. Go make a cup of tea / pour a glass of wine / other and see what changed

HTH and any other questions PM or reply back

Alex

[font="Courier New, Courier, mono"]git whatchanged[/font]

[font="Courier New, Courier, mono"]commit 17fc775a4be2c89ac824e68202b88fefc6e81144[/font]

[font="Courier New, Courier, mono"]Author: Paul Swan <prswan@gmail.com>[/font]

[font="Courier New, Courier, mono"]Date: Fri Feb 26 08:51:33 2016 -0800[/font]

[font="Courier New, Courier, mono"]
[/font]

[font="Courier New, Courier, mono"] 6502: Update various comments and clean up the Astro Fighter DRAM description.[/font]

[font="Courier New, Courier, mono"]
[/font]

[font="Courier New, Courier, mono"]:100644 100644 670135d... 4317b8d... M libraries/C6502Cpu/C6502ClockMasterCpu.cpp[/font]

[font="Courier New, Courier, mono"]:100644 100644 bad87d3... 5be9734... M libraries/C6502Cpu/CAstroFighterBaseGame.cpp[/font]

[font="Courier New, Courier, mono"]:100644 100644 041816c... f028d0d... M libraries/C6502Cpu/CTomahawk777Game.cpp[/font]

[font="Courier New, Courier, mono"]
[/font]

[font="Courier New, Courier, mono"]commit 7afbe87854b1559e952e1c77d9b1e11d5222f842[/font]

[font="Courier New, Courier, mono"]Author: Paul Swan <prswan@gmail.com>[/font]

[font="Courier New, Courier, mono"]Date: Wed Feb 24 21:19:17 2016 -0800[/font]

[font="Courier New, Courier, mono"]
[/font]

[font="Courier New, Courier, mono"] 6502: Clock master support for testing DRAM on Astro Fighter.[/font]

[font="Courier New, Courier, mono"]
[/font]

[font="Courier New, Courier, mono"]:100644 100644 35ab295... dd8a396... M InCircuitTester6502/InCircuitTester6502.ino[/font]

[font="Courier New, Courier, mono"]:100644 100644 24080df... 670135d... M libraries/C6502Cpu/C6502ClockMasterCpu.cpp[/font]

[font="Courier New, Courier, mono"]

[/font]

[font="Courier New, Courier, mono"]:100644 100644 8e7458c... bad87d3... M libraries/C6502Cpu/CAstroFighterBaseGame.cpp[/font]

 

[Dave2084]

Hmmm, must sit down and spend some time to learn git properly.
I have the code copied over (the naughty way) and it still doesn't work. Things are very strange!

If I do the read write all test:

Previously I always got ff ff ff ff

Now I seem to get random value, though at one point all of them were the same and incremented by one every 8th time I ran the test!

Paul, are there any timing values you'd like to see photos of on my scope?

 

[PaulSwan]

Note that the 6809e changes are pending on the 6809e branch, not yet on master.

You should have needed to make a change to the CPU constructor in your Defender platform, thus

m_cpu = new C6809ECpu(3);

In terms of scope, RAS and master clock. I was going off the timing diagram in that doc and guessed at '3' from that. However you could try 2 and 4 as an experiment. You should get a bus error if it's too long.

 

[Judder]

Hmmm, must sit down and spend some time to learn git properly.

Easy way to checkout what Paul has done is create a new branch locally and base it on Paul's 6809e branch

The way I do this is:

1. Fetch all the latest changes from Paul's repo

[font="Courier New, Courier, mono"]
[/font]

[font="Courier New, Courier, mono"]alexanderjudd@Alexanders-MBP arduino-mega-ict (6802) $ git fetch paul[/font]

[font="Courier New, Courier, mono"]remote: Counting objects: 17, done.[/font]

[font="Courier New, Courier, mono"]remote: Compressing objects: 100% (17/17), done.[/font]

[font="Courier New, Courier, mono"]remote: Total 17 (delta 9), reused 0 (delta 0), pack-reused 0[/font]

[font="Courier New, Courier, mono"]Unpacking objects: 100% (17/17), done.[/font]

[font="Courier New, Courier, mono"]From https://github.com/prswan/arduino-mega-ict[/font]

[font="Courier New, Courier, mono"] * [new branch] 6809e -> paul/6809e[/font]

[font="Courier New, Courier, mono"] * [new branch] 8085 -> paul/8085[/font]

2. Checkout Paul's branch into a headless local branch

[font="Courier New, Courier, mono"]alexanderjudd@Alexanders-MBP arduino-mega-ict (6802) $ git checkout paul/6809e[/font]

[font="Courier New, Courier, mono"]Note: checking out 'paul/6809e'.[/font]

[font="Courier New, Courier, mono"]
[/font]

[font="Courier New, Courier, mono"]You are in 'detached HEAD' state. You can look around, make experimental[/font]

[font="Courier New, Courier, mono"]changes and commit them, and you can discard any commits you make in this[/font]

[font="Courier New, Courier, mono"]state without impacting any branches by performing another checkout.[/font]

[font="Courier New, Courier, mono"]
[/font]

[font="Courier New, Courier, mono"]If you want to create a new branch to retain commits you create, you may[/font]

[font="Courier New, Courier, mono"]do so (now or later) by using -b with the checkout command again. Example:[/font]

[font="Courier New, Courier, mono"]
[/font]

[font="Courier New, Courier, mono"] git checkout -b <new-branch-name>[/font]

[font="Courier New, Courier, mono"]
[/font]

[font="Courier New, Courier, mono"]HEAD is now at eca445e... 6809E: Add support for Q low to D read synchronization option for platforms that return data synchronously.[/font]

3. Create a new local branch to keep all the changes

[font="Courier New, Courier, mono"]alexanderjudd@Alexanders-MBP arduino-mega-ict ((HEAD detached at paul/6809e)) $ git checkout -b 6809e[/font]

[font="Courier New, Courier, mono"]Switched to a new branch '6809e'[/font]

4. Double check that we are totally up to date with Paul's 6809e branch

[font="Courier New, Courier, mono"]alexanderjudd@Alexanders-MBP arduino-mega-ict (6809e) $ git merge paul/6809e[/font]

[font="Courier New, Courier, mono"]Already up-to-date.[/font]

 

[Dave2084]

Note that the 6809e changes are pending on the 6809e branch, not yet on master.

You should have needed to make a change to the CPU constructor in your Defender platform, thus

m_cpu = new C6809ECpu(3);

In terms of scope, RAS and master clock. I was going off the timing diagram in that doc and guessed at '3' from that. However you could try 2 and 4 as an experiment. You should get a bus error if it's too long.

Doh, I totally forgot to set the clock cycles to 3 when constructing the CPU class!

When properly set to 3, the RAM test works!

It is slow, it takes 3 minutes to check 0x0000 to 0xbfff.

Now this is working, to prove it will detect a fault I removed RAM 33 from it's socket and ran the test again and was greeted by this which is correct as RAM 33 does indeed start at 0x0200 and is D2:

Dave20842016-02-27 22:44:06

 

[Dave2084]

I have also coded up a set of files for later games Stargate, Joust, Robotron, Bubbles, Splat! and Sinistar, I'll give these a basic test with a boardset tomorrow and upload the whole lot to github.

Dave20842016-02-27 22:42:01

 

[neutrino]

When properly set to 3, the RAM test works!
It is slow, it takes 3 minutes to check 0x0000 to 0xbfff.

This is excellent news...great work Dave!!

My ICT PCBs came in the mail the other day, so hopefully this week I'll get a set of them assembled.

I have some Williams PCBs to go through, so I'm really looking forward to trying this out. As a side note, any suggestions for how to clean Williams PCBs without loosing the stickers that are on the board? I plan on removing all of the socketed chips before any cleaning, so that will eliminate many of the stickers, but there are some (e.g., serial numbers) that are attached directly to the PCBs. As you can see, these boards are rather filthy.

 

[PaulSwan]

OK, cool. I've pushed my 6809E changes into master

The RAM test is reasonably thorough and with 48K to get through I can imagine it being slow.

Paul.

PaulSwan2016-02-28 04:22:53

 

[Dave2084]

OK, cool. I've pushed my 6809E changes into master

The RAM test is reasonably thorough and with 48K to get through I can imagine it being slow.

Paul.

Indeed on 9010A the RAM Long takes hours ...

One more Question ... how do I test the write only RAM?

 

[Dave2084]

I have some Williams PCBs to go through, so I'm really looking forward to trying this out.

Do I spy some bubbles boards there?

 

[neutrino]

I have some Williams PCBs to go through, so I'm really looking forward to trying this out.

Do I spy some bubbles boards there?

Good eye! You sure do. Two Bubbles CPU/video boards, two Bubbles ROM boards, a sound board currently strapped as a Big Strike Shuffle Alley (to become the Bubbles sound board) and a Rev C CPU/video board. I picked these boards up in 3 separate ebay auctions. I have a converted Bubbles cabinet (currently a Green Beret) that I'm in the process of gathering parts for in order to restore it.

 

[PaulSwan]

Re: write-only RAM.

Better diagnosed by symptoms of it's failure since without the ability to read it there is not much that can be done. Strategies I've used in the past have been to write specific patterns and then check the outputs on a scope. That's why there are options to write all 1's, all 0's and data==address on the tester that also apply to RAM regions declared in the Write Only segment.

If you're feeling extra fancy, you could write the RAM pattern, sync with V-Sync and then capture the RAM data output from the video reads by running the master clock a few thousand cycles. But that's *really* fancy

Paul.

PaulSwan2016-02-28 18:12:42

 

[Dave2084]

Re: write-only RAM.

Better diagnosed by symptoms of it's failure since without the ability to read it there is not much that can be done. Strategies I've used in the past have been to write specific patterns and then check the outputs on a scope. That's why there are options to write all 1's, all 0's and data==address on the tester that also apply to RAM regions declared in the Write Only segment.

If you're feeling extra fancy, you could write the RAM pattern, sync with V-Sync and then capture the RAM data output from the video reads by running the master clock a few thousand cycles. But that's *really* fancy

Paul.

I was specifically thinking about the Video Address Bus and Watchdog reset relationship, I think a custom function will do this nicely, but I have seen bus test fail if you do it after a number of other tests if we've written enough clock cycles to trigger the Watchdog (timed by the VA bus) and haven't cleared it by writing 0x38 or 0x39 to 0xc3fc. There's a handy RAM location to read VA8-13 at 0xc800.

Is there any way I can split out the Bus test function to be different for Williams games to star wars?

I've been doing some testing this afternoon and I noticed that with the QLo to D read delay set to 3, input reads fail. If I reduce this to 2 then everything *seems* to work.

I've committed all my code to the Williams branch, but I have not yet tested any of the non Defender games.

 

[Dave2084]

Good eye! You sure do. Two Bubbles CPU/video boards, two Bubbles ROM boards, a sound board currently strapped as a Big Strike Shuffle Alley (to become the Bubbles sound board) and a Rev C CPU/video board. I picked these boards up in 3 separate ebay auctions. I have a converted Bubbles cabinet (currently a Green Beret) that I'm in the process of gathering parts for in order to restore it.

Don't forget that the Rev C board WILL NOT Work with the bubbles ROM boards as Williams changed the pinouts.

Also if I remember correctly, bubbles is different to most of the games as it does not run without the interface board connected. (I think it resets in attract mode)

 

[neutrino]

Don't forget that the Rev C board WILL NOT Work with the bubbles ROM boards as Williams changed the pinouts.

Yeah, I was aware of this, but thanks for the reminder. This board just happened to be lumped in with the other CPU boards when I bought them. I'm not sure what I'll do with it yet, but I'll find a use for it.

Also if I remember correctly, bubbles is different to most of the games as it does not run without the interface board connected. (I think it resets in attract mode)

Thanks for this tip, I did not know this about Bubbles. I'll have to keep that in the back of my mind as I try and get the game going.

 

[PaulSwan]

Re: Watchdog

I just strap it disabled.

Re: Bus Test

It just needs the CPU constructor to take a flag so that specific games can turn it on or off (similar to how I added a constructor parameter for setting the QLo to D read delay).

 

[Dave2084]

Re: Watchdog

I just strap it disabled.

Re: Bus Test

It just needs the CPU constructor to take a flag so that specific games can turn it on or off (similar to how I added a constructor parameter for setting the QLo to D read delay).

Thanks Paul, I'll modify the bus test accordingly.

The Video Address Bus generator (and reset) are worth testing as the whole video timing and /RESET comes from them. I'll see what I can come up with, however I'll have to make either m_pinClock or clockPulse public to do it from BaseGame in a custom function, or I could do it in bus test with the flag discussed above set appropriately.