Arduino In-Circuit Tester: Build Project

[yorkshire_spam]

Just thought I'd share a little quick-n-dirty debugging technique I've just used.
In CRomCheck::calculateCrc I've added a serial begin and a message:

Serial.begin(9600);

Serial.println("Rom read start");

Then as it loops through reading the ROM I've written the HEX form of the byte to serial and a space.

Essentially it slowly dumps the rom to serial.

Then I can convert online the string to a BIN file (https://tomeko.net/online_tools/hex_to_file.php?lang=en) and compare it with the rom in hexedit to see where the errors start in the rom and whether they relate to particular address bits etc.

I did this because the first 4 reads that the test did were correct but the roms failed verify (but were ok out of circuit) and the other roms on the board passed.

If anyone wants the nasty code I wrote LMK.

 

[Ace`]

It's about time I got one of these, does anyone in the uk have extra pcbs / parts they'd sell?

 

[sharp]

Hi all,

New person here as well. Been reading through this whole thread for an hour or more.

I see the parts list up on Paul's site. Is eBay just the best place to buy all of these parts?

Would these simple ribbon connectors work fine?

https://www.ebay.com/itm/391776118674

If anyone has the PCBs in the US or a whole set of parts I've be happy to buy a set.

 

[sharp]

Got my boards and parts to make one of these (well 3 sets of PCBs if I really want to).

I'm trying to compile the software on a Mac running 11.1 using Arduino 1.8.15 IDE. I assume I am just supposed to load one of the processor specific .ino files like InCircuitTester6502.ino? I did that but can't compile it because of include path problems with what looks like all the include files in that files. Is there some IDE settings I need to make for include paths? I did some searching and haven't seen anyone complain about this issue.




Thanks for any information. Maybe I'll go do some soldering for a while.







EDIT: Moved the libraries from the GIT repo into Users/sharp/Documents/Arduino/libraries folder and everything is running fine.

SECOND EDIT: I had to change DFR_Key.cpp and #define DF_ROBOT_V1 to get all the buttons on my keypad to be read properly. Looking forward to trying this out when I get the kit assembled.

sharp2021-08-18 01:41:18

 

[Nes4life]

Well done for progressing with it as it's worth it in the end. Which game are you going to try it on first?

 

[Phils Arcade]

Great to see you've got it running on a Mac.

I've been trying to get an Arduino to connect to the iPad Pro through USC-C. Even just trying to get a serial basic breakout of a CH340C from Sparkfun running. I can see it on the Mac but the iPad not so much. Maybe it doesn't have the driver for it, or Apple has it locked down.

Fun to experiment with these things.

 

[sharp]

Nes4life, thanks! Got the 48 resistors soldered in last night. I have several dead Atari boards I will try out with it and might add Millipede support.

Infurious, thanks! iPad support sounds challenging.

I would like to eventually be able to control it through a Mac/PC computer via USB and try to tweak it to be more Fluke 9010 like (such as "test ram 0000-03FF" instead of a specific game). But that is a long way down the road when I have more free time. I was thinking Python+tkinter because my daughter loves Python and can help me on that side of things.

 

[sharp]

Finished my hardware build tonight. Ugh, so much small soldering!

Stupid questions:

For 6502 Atari games, it looks like we just need to disable the watchdog? Is there any changes needed to disable the clock? Or is that specific games and if so, where is the list of those games? I see some in Paul's old notes about some games but wondering about "clock mastered" CPUs and regular CPU games in the source code.

What is the proper orientation for the probe head into the CPU? Where it says "In Circuit Tester" is the top of the probe head and corresponds to pin 1 of the CPU?

I was going to experiment with a Millipede first with a graphics problem and the code from here:

https://github.com/Phillrb/Arduino-ICT-PVAP

I may write some of my own code to tickle the color RAMs for each plane since that is the problem with the board.

 

[sharp]

Got it up and running on my Millipede board with the non-clock mastered option in Phillrb's code. Discovered one issue which I opened in the GIT repro.

This table is backwards:

static const UINT32 s_ROM_ADDR_H1 = 0x4000;
static const UINT32 s_ROM_ADDR_JK1 = 0x5000;
static const UINT32 s_ROM_ADDR_L1 = 0x6000;
static const UINT32 s_ROM_ADDR_MN1 = 0x7000;

Strangely, the ROM CRC checks showed success either way but with different results. Seems like a separate bug in the CRC check code independent of millipede.

 

[sharp]

One other issue I've seen. The "RAM CHECK AD" test fails on both a known bad board (with just a color selector problem) and a good board. I am running the regular Millipede game option not the "clock master" one.

 

[sharp]

Feel like I'm talking to myself but oh well. I dug through the code and realize that "Rom CRC" is just displaying the CRC not actually checking anything.

I wrote two custom routines for the Millipede game to test each of the color ram sets individually. Pretty cool to see it working.

PERROR CMillipedeGame::bgColorRamWrite(void *cMillipedeGame)

{

CMillipedeGame *pThis = (CMillipedeGame *) cMillipedeGame;

PERROR error = errorSuccess;

// 0x2480 to 0x248F

for (int val = 255; val >= 0; val--) {

for (int i = 0; i < 16; i++) {

error = pThis->m_cpu->memoryWrite(0x2480 + i, val);

}

// sleep for a bit

delayFunction(cMillipedeGame, 25);

}

return error;

}

This ended up with the background being black if the board was working. I could run this and watch it on my scope and determined that the RAM at 11B was bad and holding high the upper nibble for the background colors. Did a bunch of other debugging on this board before I got to this point but it was nice to have something so precise to narrow it down.

 

[yorkshire_spam]

It took me a while to realize, but when Paul talks about "clock master", you have to "knobble" the UUT clock and hook the arduino shield pin (sorry can't remember which one) to the clock line on the UUT.

This is done because the arduino can't keep up with UUT clock speeds and, so allowing the arduino to drive the UUT clock at a much slower speed prevents contention between other UUT circuits accessing ROM/RAM/IO at the same time as the ICT.

Sometime you "get lucky" and the UUT circuits and the ICT don't contend and the checks work fine.

Nice custom code for the Millipede!

 

[sharp]

I posted this over on KLOV but I have a kit (or two) available for sale if anyone wants to build one of these. I've really been enjoying experimenting with this kit. The cost for all the parts (minus the Arduino and keypad) is $47 plus shipping. This is just my costs for all the parts off ebay or digikey.

US buyers make the most sense based upon shipping charges.

KLOV post:

https://forums.arcade-museum.com/threads/fs-paul-swans-in-circuit-tester-kit.494333/

Please excuse me if I am breaking any rules here with a FS post.

I used the tester last night to find a bad P2 RAM on a Tempest as well as a suspect ROM.

 

[yorkshire_spam]

Nice work Sharpy!

 

[sharp]

Been playing around with it this weekend. I wrote the basics of a vector script generator and use the ICT to write to the vector RAM and issue a VGGO...

I have a misbehaving Tempest board where something is wrong in the digital AVG circuitry. But it is working enough to handle simple commands to lineTo, center, etc. It seems the AVG circuitry always wants to return to the center of the screen at some point in time. I tried just generating a rectangle in the upper left but the AVG analog section (I think) somehow centers the image. (or it's my scope doing it). In any case, kind of fun to play with. I'll write some more complex commands as I go to see when the AVG starts to fail.

 

[guddler]

I'm hoping to get back into looking at some boards in the next few weeks so I've been going through this thread. I have a couple of catch up questions - well, actually I have many, but I'll start with these two

1. Why all the talk about different CPU heads? Is it just 68000 and 8080 that have unique hardware requirements? If so, I have no need for them at the moment. I'm aware of the potential requirement for lower value protection resistors on certain CPU lines of certain PCBs.

Initially I want to look at a Phoenix board which from Paul's original page looks like it's supported out of the gate on the initial version of the header PCB.

2. Is ArcadeNut still about doing his thing? I'd really like to get back into the Windows App (well, I'd prefer it if it was a Mac app but beggers can't be choosers so I'm hoping VMWare Fusion will suffice!). I feel kind of bad there because I did a bit of initial feedback / testing and then real life issues got in the way and 3 years have passed!

The PC / Mac based client remote controlling the Arduino head was always going to be my preferred way of approaching this rather than fiddling about with tiny buttons and squinting at small LCDs.

[EDIT] Looks like the "Arcade PCB Debugger" software so far only supports 6502, Z80 and 6809. I wonder what's involved in implementing some of the other ones supported by the original head (8085 obviously!) and while I appreciate the reasoning for the client application being closed source, wonder if help could be offered on the non-client side of things? I guess that's something I could look at given that side of it is open source and on GitHub.

Further: Unless I'm misreading it, it looks simple enough to add 8085 in. I have only had a very, very initial skim though so will dig deeper probably later tonight. I'm obviously only talking about adding it to the USB interface side of it, ArcadeNut would have to add the client support but at least I could manually send commands to it which let's face it, is all you do with a 9010 in non-scripted mode.

guddler2022-05-10 16:27:46

 

[yorkshire_spam]

Ref #1 I think the CPU head thing is about the hard-wired VCC/GND combinations on the different CPUs.
What brings you back to arcade shiz Mr Guddler? We've missed you!

 

[Arcadenut]

2. Is ArcadeNut still about doing his thing? I'd really like to get back into the Windows App (well, I'd prefer it if it was a Mac app but beggers can't be choosers so I'm hoping VMWare Fusion will suffice!). I feel kind of bad there because I did a bit of initial feedback / testing and then real life issues got in the way and 3 years have passed!

[EDIT] Looks like the "Arcade PCB Debugger" software so far only supports 6502, Z80 and 6809. I wonder what's involved in implementing some of the other ones supported by the original head (8085 obviously!) and while I appreciate the reasoning for the client application being closed source, wonder if help could be offered on the non-client side of things? I guess that's something I could look at given that side of it is open source and on GitHub.

Further: Unless I'm misreading it, it looks simple enough to add 8085 in. I have only had a very, very initial skim though so will dig deeper probably later tonight. I'm obviously only talking about adding it to the USB interface side of it, ArcadeNut would have to add the client support but at least I could manually send commands to it which let's face it, is all you do with a 9010 in non-scripted mode.

Yes, I'm still around. Been focusing on the FPGA Cat Box support and adding new features. Adding support for the 8085 shouldn't be that hard. A lot of Copy & Pasting I'm sure and is done on the Arduino side, my software shouldn't need to change at all.

I also picked up a Fluke 9010A and the Repro 6502/Z80 Pods so will be messing with those to see if I can interface with them as well.

 

[yorkshire_spam]

I also picked up a Fluke 9010A and the Repro 6502/Z80 Pods so will be messing with those to see if I can interface with them as well.

You may find interesting: https://forums.arcade-museum.com/threads/flukeemu-flucom-fluke-9010a-microsystem-troubleshooter-emulator.503305/

 

[guddler]

Yes, I'm still around. Been focusing on the FPGA Cat Box support and adding new features. Adding support for the 8085 shouldn't be that hard. A lot of Copy & Pasting I'm sure and is done on the Arduino side, my software shouldn't need to change at all.

Cool, that's good to hear - especially that your software shouldn't need to change. I'll have a nose when I get the chance. Half my workbench is taken up with something completely unrelated at the moment but that should only be a week or two.

I really liked the idea of what you produced but unfortunately I first saw it at a time when there was some real life stuff going on that meant my interest in the arcade stuff was at an all-time low so I never got into it at all beyond firing it up and making a bit of initial feedback.

What brings you back to arcade shiz Mr Guddler? We've missed you!

Thank you! - Well, without going into gory detail in a public forum the things that we had been going through are hopefully a thing of the past, we've moved house and I've finally managed to get a roof, floor and door on the garage (all kind of essential) and a new workbench built so at the weekend I was able to go and get my jamma cabaret out of storage and had room for 3 or 4 PCBs in the car too. Because it's all set up right next to me in the garage I actually feel like doing a bit with it. There was something about it all being in a shed at the bottom of a 120' garden in the old house I didn't like.

The rest of the machines and PCBs will have to wait until later in the year though because we're still not that sorted yet. Stuff seems to take forever when you're paying for storage!