ukVac.com Homepage
Forum Home Forum Home > Technical > Tech, Maintenance & Repairs
  New Posts New Posts RSS Feed - Arduino In-Circuit Tester: Build Project
  FAQ FAQ  Forum Search   Events   Register Register  Login Login

Skin:


Arduino In-Circuit Tester: Build Project

 Post Reply Post Reply Page  <1 19202122>
Author
Message
 Rating: Topic Rating: 3 Votes, Average 5.00  Topic Search Topic Search  Topic Options Topic Options
Arcadenut View Drop Down
User
User


Joined: 29 Mar 2017
Status: Offline
Points: 104

Feedback: 0
Post Options Post Options   Thanks (0) Thanks(0)   Quote Arcadenut Quote  Post ReplyReply Direct Link To This Post Posted: 04 Aug 2019 at 8:25pm
Originally posted by wondras wondras wrote:

This is good... we're running out of things that could be the problem. :)  Seems like it has to be a physical connection issue, so I think the most likely culprit would be your 40-pin ribbon cables. 

Are yours homemade? Sometimes a pin won't make contact if the plug isn't crimped on hard enough. Or did you repurpose a CD-ROM or IDE cable? These sometimes have missing wires. I can see you don't have 80-pin cables, which is good, because these definitely wouldn't work.

Wherever they came from, doing an end-to-end continuity test between the Arduino shield and the probe head is probably worth a try.


Side note: I've been meaning to mention for a while that DigiKey will custom assemble twisted-pair ribbon cables using 3M wire and connectors. They ship right away, and the cables look and work great.



I bought the 20" version for $9.19US/each. Part number is M3CCA-4020K.




Ok, I'm making some progress...  I've been chasing my tail a bit here. LOL

I went back to your driver and made sure I was on the correct Centipede version and did a ROM CRC check and it's giving me the right results.  

What was strange is that it wasn't triggering my scope if I has hooked up to the ROM test point. Rather than hooking it up to the ROM test point, I hooked it up to the ROM 0 test point and it triggered when reading 0x2000!  

After some further testing and breaking out the Logic Probe, it appears that the ROM CS toggles between different accesses to different addresses.  So if I access 0x2000 and it's Low, it will switch to High.  Testing 0x2800 would then toggle ROM 0 test point's state... The High/Low toggling might actually be different, just trying to illustrate the issue.

Seems the hardware is functioning so this points to a problem with my driver code not returning memory results correctly.  So time to dig into that.... 

Thanks for everyone's help!
Back to Top
Arcadenut View Drop Down
User
User


Joined: 29 Mar 2017
Status: Offline
Points: 104

Feedback: 0
Post Options Post Options   Thanks (0) Thanks(0)   Quote Arcadenut Quote  Post ReplyReply Direct Link To This Post Posted: 04 Aug 2019 at 8:43pm
Ok, it was a stupid mistake on my part... Ugh... 

When reading Memory I forgot to increment the address so it was always reading the same byte over and over again.... Ooops.

It worked for the RAM test because I was always writing the same byte to all addresses...
Back to Top
Nes4life View Drop Down
Senior Members
Senior Members
Avatar

Joined: 02 Jan 2014
Location: Ashford, Kent
Status: Offline
Points: 5415

Feedback: 5
Post Options Post Options   Thanks (0) Thanks(0)   Quote Nes4life Quote  Post ReplyReply Direct Link To This Post Posted: 04 Aug 2019 at 9:39pm
Well done for getting to the bottom of it!
NES4Life
-------------
An arcade tech - not a gamer
Back to Top
Arcadenut View Drop Down
User
User


Joined: 29 Mar 2017
Status: Offline
Points: 104

Feedback: 0
Post Options Post Options   Thanks (0) Thanks(0)   Quote Arcadenut Quote  Post ReplyReply Direct Link To This Post Posted: 06 Aug 2019 at 12:19am
Ok, for Centipede:  
  • You don't need to use the Master Clock.
  • You can use either the Resistor version of the shield or the non-resistor version.

I'll hook up my Missile Command next and test that.

If that works then I'll upload the current version of my driver and the Windows software.  Then I'll move on to the Z80 support and repeat the process.


Back to Top
Arcadenut View Drop Down
User
User


Joined: 29 Mar 2017
Status: Offline
Points: 104

Feedback: 0
Post Options Post Options   Thanks (0) Thanks(0)   Quote Arcadenut Quote  Post ReplyReply Direct Link To This Post Posted: 10 Aug 2019 at 7:59am
Ok, BETA 1 is now available.

Full details can be found here.
https://github.com/Brien...ester-USB-Interface/wiki

Download .ino file here:


All Feeback is welcome!  This is BETA so I'm sure there will be some bugs and things I haven't ironed out 100%.

Back to Top
Mc-Q View Drop Down
Newbie
Newbie


Joined: 13 Sep 2016
Status: Offline
Points: 11

Feedback: 0
Post Options Post Options   Thanks (0) Thanks(0)   Quote Mc-Q Quote  Post ReplyReply Direct Link To This Post Posted: 10 Aug 2019 at 11:18pm

what are the library;s used that prevent you posting the sourcecode??

(not everybody uses windows and emulation cant handle usb drivers)

Back to Top
Arcadenut View Drop Down
User
User


Joined: 29 Mar 2017
Status: Offline
Points: 104

Feedback: 0
Post Options Post Options   Thanks (0) Thanks(0)   Quote Arcadenut Quote  Post ReplyReply Direct Link To This Post Posted: 10 Aug 2019 at 11:33pm
Originally posted by Mc-Q Mc-Q wrote:

what are the library;s used that prevent you posting the sourcecode??

(not everybody uses windows and emulation cant handle usb drivers)


DevExpress for the UI

and my own libraries used for Business Objects and Data Access, etc... that are proprietary to my company. 

I could publish the source code but it wouldn't be much help as you wouldn't be able to compile it.

If someone wants to put out a cross-platform app they can.  The device driver source on the Arduino is available.  You would just need to write something to communicate to it and deal with the results.

If you wanted to, you could simply connect via a Terminal (such as the Arduino Serial Monitor) and issue commands by hand, you wouldn't even need the Windows App really.  The app just makes life a lot easier.

It might run under something like Wine, not sure.

Back to Top
Arcadenut View Drop Down
User
User


Joined: 29 Mar 2017
Status: Offline
Points: 104

Feedback: 0
Post Options Post Options   Thanks (0) Thanks(0)   Quote Arcadenut Quote  Post ReplyReply Direct Link To This Post Posted: 11 Aug 2019 at 4:21am
Back to Top
Arcadenut View Drop Down
User
User


Joined: 29 Mar 2017
Status: Offline
Points: 104

Feedback: 0
Post Options Post Options   Thanks (0) Thanks(0)   Quote Arcadenut Quote  Post ReplyReply Direct Link To This Post Posted: 11 Aug 2019 at 4:44am
Updated Driver, now has Z80 (Tested on Dig Dug REV A) and 6809 (Untested) support.
Back to Top
wondras View Drop Down
Newbie
Newbie


Joined: 24 Mar 2019
Location: USA
Status: Offline
Points: 27

Feedback: 0
Post Options Post Options   Thanks (0) Thanks(0)   Quote wondras Quote  Post ReplyReply Direct Link To This Post Posted: 12 Aug 2019 at 8:47am
Looking good! I used DevExpress components back in my Delphi days, and they were fantastic for making a polished app quickly. Great company with great tools, but yeah, problematic for open source.
Back to Top
wondras View Drop Down
Newbie
Newbie


Joined: 24 Mar 2019
Location: USA
Status: Offline
Points: 27

Feedback: 0
Post Options Post Options   Thanks (0) Thanks(0)   Quote wondras Quote  Post ReplyReply Direct Link To This Post Posted: 12 Aug 2019 at 10:08am
In other news, I was able to write/read the video RAM for Centipede using a bit more ASM trickery.

When video RAM is active, the phi0 clock to the CPU skips every other pulse. This just required waiting an extra 6502A cycle length before firing phi2, so it would coincide with the next phi0 pulse.



This allows reliable writes to video RAM, such as:


Reading it back was a little trickier.  The data isn't available during the entire 6502 clock cycle, and the data bus is spread across four pin groups on the Arduino, so it takes a relatively long time to read. I found that by cutting the phi2 pulse short, the read could be done in one 6502 clock cycle.

So I guess it actually works...  but it's just hacked into the C6502Cpu memoryRead() and memoryWrite() functions, so currently it's used all the time. I need to think about how this could be properly integrated into the code. C++ isn't my strongest point, but I do have a couple of ideas:

  - Add read and write "strategy" parameters to the RAM_REGION struct, so multiple access timings can be handled internally by the CPU class. If multiple timing strategies were going to be reused across many game drivers, it would be great if you could just specify "async" or "1.5 Mhz with skipped cycles" for a block of RAM.
  - Allow game drivers to subclass the CPU to substitute their own memory read/write routines (could also be done with function pointers, I think.) There's less opportunity for reuse this way, but OTOH it doesn't require changes to widely used type definitions.

It's not clear to me how widely this could/would/should be used. There's no point in making big changes if it's only going to get used once or twice, or be deemed a Bad Thing that shouldn't be done at all. Curious if anyone has any thoughts/ideas for this.



Edited by wondras - 12 Aug 2019 at 10:12am
Back to Top
Arcadenut View Drop Down
User
User


Joined: 29 Mar 2017
Status: Offline
Points: 104

Feedback: 0
Post Options Post Options   Thanks (0) Thanks(0)   Quote Arcadenut Quote  Post ReplyReply Direct Link To This Post Posted: 12 Aug 2019 at 7:12pm
I think Video RAM is a bit different then normal RAM.  If you can reliably write to it should be able to see the results on screen.  The only exception being if you don't have video out, but if that's the case then there is something other than RAM that is bad (typically).

For your test above, what values were you writing?  I would like to try it with my App and see if I get the same results.

As for how to integrate it, you could make overloaded methods for read/write that take a parameter.  This way you're not touching the original methods.  Then modify the RAM_REGION to allow for the extra parameters to send to the new methods.

Something like

... memoryRead(int clockCycles)
{
...
}

Back to Top
Mc-Q View Drop Down
Newbie
Newbie


Joined: 13 Sep 2016
Status: Offline
Points: 11

Feedback: 0
Post Options Post Options   Thanks (0) Thanks(0)   Quote Mc-Q Quote  Post ReplyReply Direct Link To This Post Posted: 13 Aug 2019 at 1:32pm

i think i asked before, but is there an electrical reason for sticking with the ATMEGA and not using the ARM based boards with more memory/clockspeed??

Back to Top
GadgetFreak View Drop Down
User
User
Avatar

Joined: 13 Jul 2016
Location: UK
Status: Offline
Points: 651

Feedback: 5
Post Options Post Options   Thanks (0) Thanks(0)   Quote GadgetFreak Quote  Post ReplyReply Direct Link To This Post Posted: 13 Aug 2019 at 7:28pm
Originally posted by Mc-Q Mc-Q wrote:

i think i asked before, but is there an electrical reason for sticking with the ATMEGA and not using the ARM based boards with more memory/clockspeed??



I've certainly mentioned it before. I would say 5v digital IO is important which few boards have these days. But as I have mentioned before the Teensy 3.5 has 5v tolerant digital IO.
Back to Top
Arcadenut View Drop Down
User
User


Joined: 29 Mar 2017
Status: Offline
Points: 104

Feedback: 0
Post Options Post Options   Thanks (0) Thanks(0)   Quote Arcadenut Quote  Post ReplyReply Direct Link To This Post Posted: 13 Aug 2019 at 10:28pm
Originally posted by Mc-Q Mc-Q wrote:

i think i asked before, but is there an electrical reason for sticking with the ATMEGA and not using the ARM based boards with more memory/clockspeed??


Probably just a matter of what was available at the time when Paul Decided to do it.  (See first paragraph here: http://www.zzzaccaria.com/arcade/ArduinoMegaICT.htm)

There really shouldn't be any technical reason why this couldn't be ported to another platform as long as it has enough IO and at the right voltages.  You'll have to design up new Shields to fit other devices and port the code to that platform.


Back to Top
GadgetFreak View Drop Down
User
User
Avatar

Joined: 13 Jul 2016
Location: UK
Status: Offline
Points: 651

Feedback: 5
Post Options Post Options   Thanks (0) Thanks(0)   Quote GadgetFreak Quote  Post ReplyReply Direct Link To This Post Posted: 13 Aug 2019 at 10:35pm
Originally posted by Arcadenut Arcadenut wrote:

port the code to that platform.

Which is precisely why I mention the Teensy 3.5, no porting required as it can be used with the Arduino build environment. You just download and install the support libraries on the PJRC website!
Back to Top
Mc-Q View Drop Down
Newbie
Newbie


Joined: 13 Sep 2016
Status: Offline
Points: 11

Feedback: 0
Post Options Post Options   Thanks (0) Thanks(0)   Quote Mc-Q Quote  Post ReplyReply Direct Link To This Post Posted: 13 Aug 2019 at 11:22pm

then i'll try it soon,

i have some Nucleo dev boards with 144pins to play with and they are fully supported by the arduino software. :)

all pins are 5v tolerant


Back to Top
Arcadenut View Drop Down
User
User


Joined: 29 Mar 2017
Status: Offline
Points: 104

Feedback: 0
Post Options Post Options   Thanks (0) Thanks(0)   Quote Arcadenut Quote  Post ReplyReply Direct Link To This Post Posted: 14 Aug 2019 at 1:37am
Originally posted by GadgetFreak GadgetFreak wrote:

Originally posted by Arcadenut Arcadenut wrote:

port the code to that platform.

Which is precisely why I mention the Teensy 3.5, no porting required as it can be used with the Arduino build environment. You just download and install the support libraries on the PJRC website!

Haven't looked at the Teensy, are they pinout compatible too?  If not then you'll at least have to remap the pins but that should be pretty trivial and could probably be handled with #ifdef.


Back to Top
Mc-Q View Drop Down
Newbie
Newbie


Joined: 13 Sep 2016
Status: Offline
Points: 11

Feedback: 0
Post Options Post Options   Thanks (0) Thanks(0)   Quote Mc-Q Quote  Post ReplyReply Direct Link To This Post Posted: 14 Aug 2019 at 9:03am

Teensy are small - almost dip package-size.

the Nucleo boards have arduino headers, but AFAIK nothing has the MEGA headers on it.

so new pin mapping / adapter boards would be needed.

it does have the advantage of being able to have 40 or 64pins - all i/o

so no more active adapters for 68000's etc.

Back to Top
wondras View Drop Down
Newbie
Newbie


Joined: 24 Mar 2019
Location: USA
Status: Offline
Points: 27

Feedback: 0
Post Options Post Options   Thanks (0) Thanks(0)   Quote wondras Quote  Post ReplyReply Direct Link To This Post Posted: 15 Aug 2019 at 4:53am
The Arduino Mega isn't ideal, but it has the huge advantage that someone has already taken the time to make it work. It's also well-documented, easy to program, cheap and still widely availalble years later. There are definitely devices today that would be better, but I'm not sure they're better enough to be worth the effort to switch.
Back to Top
 Post Reply Post Reply Page  <1 19202122>
  Share Topic   

Forum Jump Forum Permissions View Drop Down



This page was generated in 1.078 seconds.