Arduino In-Circuit Tester: Build Project

[Arcadenut]

Ok, so I'm making progress on the software....

The (Very) ALPHA version of the Arduino code is here:

https://github.com/BrienKing/Arduino-2560-In-Circuit-Tester-USB-Interface

Here are some screen shots of the Windows App...

Arcadenut2019-06-24 03:43:40

 

[Arcadenut]

Not sure why the images are scaled down, makes them a little harder to see

Anyway....

I'm going to need a bit of help on the Arduino side.

I'm starting with trying to get Centipede working, so some questions...

1) How do I need to setup the CPU and what methods do I need to call?

2) In the Arduino code that I have I call

m_currentCpu = new C6502Cpu(true);

cpuResult = m_currentCpu->idle();

cpuResult = m_currentCpu->check();

Does it matter if I call idle() first or second? Are they both required?

3) I'm assuming that different games will need the CPU setup differently, so what kind of options would be necessary?

 

[Judder]

I'm trying to see if I can extend the RAM testing in the System 2 tests that are on the Github

I've been working on SlapFight and have a similar question for those that have added extra game drivers - what's the fundamental difference between:

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

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

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

The three are passed to the game constructor in the other games, but I'm struggling a little to easily match it up with the Mame driver memory stuff

[font="Courier New, Courier, mono"]CTigerHeliBaseGame::CTigerHeliBaseGame([/font]

[font="Courier New, Courier, mono"] const ROM_REGION *romRegion[/font]

[font="Courier New, Courier, mono"]) : CGame( romRegion,[/font]

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

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

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

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

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

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

 

[Nes4life]

what's the fundamental difference between:

s_ramRegion,

s_ramRegionByteOnly,

s_ramRegionWriteOnly,

For an example see https://github.com/Phillrb/Arduino-ICT-PVAP/blob/master/C6502Cpu/CAsteroidsGame.cpp

• s_ramRegion
  • This is the total area of 'read/write' RAM that you want the ICT to test via the CPU socket.
  • Each RAM is individually described
  • Its address space and the specific data bits it controls are listed
    • e.g. If you have a couple of 4-bit RAMs working as a pair (2114s for example) you can specify which controls the upper bits and which the lower
  • You can even break the individual RAMs down into sub-address regions if you know that a specific address range is for a specific task on that RAM. This will let you test sub-address ranges of a specific RAM.
  • I've used this area in the example above to break 6x 2114 RAMs down into a number of logical address regions
    • There are 2x 2114s for the 'working RAM' of Asteroids:
      • One 2114 controls the lower 4 bits of address range 0x0000 to 0x03FF
      • See lines 97 to 100 in the example
        • I've chosen to split it into 4 separate regions as I know each is used for a different purpose by the CPU - that was documented by Atari
      • A 2nd 2114 controls the upper 4 bits of address range 0x0000 to 0x03FF
      • See lines 102 to 105 in the example
    • The remaining 4x 2114s are split into 2 pairs and together they are the 'Vec RAM' of Asteroids:
      • M4 & R2 control the lower and upper data bits of address range 0x4000 to 0x43FF respectively
        • I didn't split them into further subregions
        • See lines 107 and 108 in the example
      • N4 & P4 control the lower and upper data bits of address range 0x4400 to 0x47FF respectively
        • I didn't split them into further subregions
        • See lines 109 and 110 in the example
• s_ramRegionByteOnly
  • Here you can only test read-write RAMs that affect all data bits of their respective address space. As Asteroids only has 4-bit RAMs working as pairs, these were grouped and treated as pairs.
  • Line 119 shows the two 2114s at D2 & E2 as a pair (covering 8-bits of data together)
  • Line 120 shows the two 2114s at M4 & R4 as a pair (covering 8-bits of data together)
  • Line 121 shows the two 2114s at N4 & P4 as a pair (covering 8-bits of data together)
• s_ramRegionWriteOnly
  • This is for all 'write-only' RAMs. Some games have RAMs (or at least some address space) that the CPU can write to but can't read from! I've not had to implement this for any games yet but Paul Swan has.

 

[Arcadenut]

Ok, I'm not finding any documentation on this header.

Can someone help me fill out the chart. Once I have the information I'll put together a nicer image with it all documented.

Want to know what the Pin is and what it's used for.

Thanks!

 

[Judder]

For an example see https://github.com/Phillrb/Arduino-ICT-PVAP/blob/master/C6502Cpu/CAsteroidsGame.cpp

I have to say that is one of the most comprehensive and super informative sharing of knowledge that I have seen in a long time - and all that this forum, and really what I wanted this thread, to be all about - so a huge thanks from me!

Now I both understand a. how the arcade boards talk to their memory more and b. how I need to break down the driver for Tiger Heli / Slap Fight - next week I am on the case

Many thanks again,

Alex

 

[Arcadenut]

Bump... anyone know the pinout of that connector?

 

[Arcadenut]

Wiki Started here:

https://github.com/BrienKing/Arduino-2560-In-Circuit-Tester-USB-Interface/wiki

Obviously a Work In Progress... but should be a good start.

 

[Nes4life]

Bump... anyone know the pinout of that connector?

OK, in your diagram:

• J13 (pins 1 & 2 in your picture) are GND
  • if you are planning to make use of pins 3 to 10 then connect pin 1 or 2 close to a GND point to what you are probing on the arcade board so that GND signals are the same on the board and the Arduino
• J14 (pins 3 to 10 in your picture) are connected to Arduino pins 15 down to 8 (via J15)
  • e.g. pin 3 in your picture is Arduino pin 15
  • pin 4 in your pic is Arduino pin 14 etc
  • Use these to connect extra probe points to the PCB

The pins are great for creating extra probes to the PCB. So far I've seen them used to create a clock signal at a particular point and also as a way of reading a data line that is not CPU accessible. ROTJ uses it to get a data dump and many games like Pacland use it to pass the CLK signal in (also called 'clock mastering').

You can create your own tests to make use of these probe points if you wish. It's just making the last remaining Arduino pins available to you.

Nes4life2019-06-30 14:09:35

 

[Arcadenut]

Bump... anyone know the pinout of that connector?

OK, in your diagram:

• J13 (pins 1 & 2 in your picture) are GND
  • if you are planning to make use of pins 3 to 10 then connect pin 1 or 2 close to a GND point to what you are probing on the arcade board so that GND signals are the same on the board and the Arduino
• J14 (pins 3 to 10 in your picture) are connected to Arduino pins 15 down to 8 (via J15)
  • e.g. pin 3 in your picture is Arduino pin 15
  • pin 4 in your pic is Arduino pin 14 etc
  • Use these to connect extra probe points to the PCB

The pins are great for creating extra probes to the PCB. So far I've seen them used to create a clock signal at a particular point and also as a way of reading a data line that is not CPU accessible. ROTJ uses it to get a data dump and many games like Pacland use it to pass the CLK signal in (also called 'clock mastering').

You can create your own tests to make use of these probe points if you wish. It's just making the last remaining Arduino pins available to you.

Awesome, Thank you!

Here is the cleaner version:

For the Star Wars driver (and the 6502 Clock Mastering CPU), Pin 15 is used for the Clock Mastering. This seems to be true for a lot of Atari boards. Centipede has the same clock setup as SW.

From this page:

http://www.zzzaccaria.com/arcade/ArduinoMegaICT.htm

To connect the clock output from the ICT as the master clock input I removed the IC 1N (74S04) and fitted a socket. The replacement '04 was then fitted in the socket with pin 1 angled out of the socket to disconnect it from the oscillator and allow the IC clip to be attached to the pin instead. The ground pin can be attached to the GND4 ground test tab. Some boards don't have the GND4 tab fitted so an alternative location for the ground connection is the left pin of capacitor C91.

Arcadenut2019-07-01 00:54:29

 

[wondras]

Not sure why the images are scaled down, makes them a little harder to see

Anyway....

I'm going to need a bit of help on the Arduino side.

I'm starting with trying to get Centipede working, so some questions...

1) How do I need to setup the CPU and what methods do I need to call?

2) In the Arduino code that I have I call

m_currentCpu = new C6502Cpu(true);

cpuResult = m_currentCpu->idle();

cpuResult = m_currentCpu->check();

Does it matter if I call idle() first or second? Are they both required?

3) I'm assuming that different games will need the CPU setup differently, so what kind of options would be necessary?

idle() is the important call... It configures pins as inputs and outputs, so it should be called before any reads/writes take place.

check() verifies that the Vcc and Reset pins are high, and does a 'bus check' that looks for stuck bits on the address and data buses. The bus check doesn't work for all games, so it is an option passed to the C6502Cpu constructor. Battlezone, for instance, puts a ROM on the bus when all address bits are high, which the bus check would see as stuck bits.

wondras2019-07-02 01:08:27

 

[wondras]

I started working on Centipede support (before I read that Arcadenut was doing it), and I was disappointed to find that the video RAM can't be tested without using 'clock master' mode. (The phi0 clock to the CPU is suppressed while the graphics hardware is accessing this RAM, so unsynchronized reads/writes from the ICT wouldn't be reliable.)

I keep running into things I'd like to do that need to be synchronous with phi0 (sending commands to the Battlezone mathbox, giving the Asteroids Deluxe vector generator the "go" signal, and now tests and patterns for the Centipede video RAM. Clock master mode doesn't really work for things that have to run full speed like display outputs.

So I'm wondering... is there any way for the ICT to do reads/writes in sync with the phi0 clock? It could probably be done in hardware with latches or a CPLD, but I'd love to find a software solution. I've been pondering the use of carefully optimized bit-banging, or interrupts. If someone knows for sure that it's just not possible, it might save me a lot of time and heartache.

 

[Arcadenut]

I started working on Centipede support (before I read that Arcadenut was doing it), and I was disappointed to find that the video RAM can't be tested without using 'clock master' mode. (The phi0 clock to the CPU is suppressed while the graphics hardware is accessing this RAM, so unsynchronized reads/writes from the ICT wouldn't be reliable.)

Well, I'm not working on it as a normal driver, I'm working on it through my client app. I think we'll be able to help each other out possibly.

I keep running into things I'd like to do that need to be synchronous with phi0 (sending commands to the Battlezone mathbox, giving the Asteroids Deluxe vector generator the "go" signal, and now tests and patterns for the Centipede video RAM. Clock master mode doesn't really work for things that have to run full speed like display outputs.

So I'm wondering... is there any way for the ICT to do reads/writes in sync with the phi0 clock? It could probably be done in hardware with latches or a CPLD, but I'd love to find a software solution. I've been pondering the use of carefully optimized bit-banging, or interrupts. If someone knows for sure that it's just not possible, it might save me a lot of time and heartache.

Not sure, but doesn't the 6502 have a Clock Output? If so, couldn't that line be used to drive the Video software wise? Just thinking out loud (I'm a software guy

)...

 

[wondras]

Well, I'm not working on it as a normal driver, I'm working on it through my client app. I think we'll be able to help each other out possibly.

Very likely, I'd say. Once I have something that's confirmed useful, I'll post it (probably in Phillrb's GitHub project)

Not sure, but doesn't the 6502 have a Clock Output? If so, couldn't that line be used to drive the Video software wise? Just thinking out loud (I'm a software guy

)...

The 6502 does have two clock outputs (phi1 and phi2), and the ICT sends pulses on these lines during read/write operations. The problem is in the early 80s Atari boards I mostly seem to work on, things like display hardware don't use these clocks, but their clocks are derived from the same crystal oscillator as the phi0 clock for the CPU, so they still expect CPU access to be synchronous.

Paul's 'clock master' mode is a partial solution for this, where you remove the clock oscillator IC from the board, so the ICT can inject its own clock pulses from a spare pin on the Arduino. It's enough to allow additional testing in some cases, but you lose realtime functions such as raster/vector display in the process. I'm not knocking it; it's a good way to get around limitations of the Arduino hardware. I'm just wondering if there's another way...

 

[Arcadenut]

Spent a bit of time today updating the Wiki for my software here:

https://github.com/BrienKing/Arduino-2560-In-Circuit-Tester-USB-Interface/wiki

Will be spending time this weekend working on getting Centipede working through my software.

 

[Arcadenut]

Made some good progress today.

Realized how rusty my C++ is and how spoiled C# makes me.

As I'm going through this I find more features I want to add to the client side

So I'm able to do RAM tests on Centipede by writing a specific byte and reading it back.

For some reason I cannot read the ROMs though.

Wondras, do you have that part working in your driver?

I'm also able to write to and read video memory (1024 - 1984) with no problem. Nothing is on the screen however, so it would be nice to figure out how to get the video to display.

 

[Arcadenut]

Looking at the Schematics for Centipede, can we just pull 4H low to get it to display video?

It appears that 4H comes off the same chip N1 that is needed to drive Centipede.

 

[Arcadenut]

This is also an interesting read.

Wonder if we could create an Cat Box mode for the ICT... seems like we have enough pins on the device, I just don't know enough about the hardware to know how plausible it is.

http://pdf.textfiles.com/manuals/ARCADE/S-Z/Signature%20Analysis%20%20[Atari%20How%20to%20Guide]%20[English].pdf

 

[wondras]

Looking at the Schematics for Centipede, can we just pull 4H low to get it to display video?
It appears that 4H comes off the same chip N1 that is needed to drive Centipede.

Unfortunately, the 1H/2H/4Hetc signals create the timing for the video. (The "H" is one horizontal pixel.) You can't control them without modifying the hardware (similar to the ICT's 'clock master' mode), and if you do, you lose the display.

With the current ICT code, I _think_ you could reliably write some test patterns by holding R/W' low for at least a full 4H cycle. You wouldn't be able to read the data back, so it would be a visual check only. To actually read the bits, you'd have to clip a pin somewhere in the counting/clocking logic to give the CPU full-time access to it.

That said, I'm attempting to write some assembly code to do reads/writes in sync with the 1.5 MHz CPU clock, which is gated to avoid simultaneous access to video RAM by the CPU and graphics hardware. If I'm counting my instruction cycles correctly, the synced reads/writes will be jittery, but fast enough and tight enough to get the job done. Stay tuned...

 

[wondras]

This is also an interesting read.

Wonder if we could create an Cat Box mode for the ICT... seems like we have enough pins on the device, I just don't know enough about the hardware to know how plausible it is.

http://pdf.textfiles.com/manuals/ARCADE/S-Z/Signature%20Analysis%20%20[Atari%20How%20to%20Guide]%20[English].pdf

Wow, that's a great guide to how Atari's SA works. I knew vaguely that it was a combintion of counting and checksumming, the result of which is compared to known-good values, but this fills in a LOT of details I was missing.

You might be able to do this in software for parts of the circuit that are clocked entirely by the phi1/phi2 outputs from the CPU, since the ICT controls these. For anything that runs directly off of the existing oscillator, you'd need to pull it and use the ICT in clock-master mode. (Side note: I haven't actually tried using clock master mode; I'm having more fun trying to do things without modifying the hardware.

)

Alternatively, one could likely make an add-on board using 74-series logic or a CPLD that handles the critical parts of the signal capture, and then hands the results over to the Arduino.

This definitely needs further investigation...