Arduino In-Circuit Tester: Build Project

PaulSwan · Feb 29, 2016

clockPulse is a member of C6809ECpu so you can cast ICpu to it. See CStarWarsBaseGame::testClockPulse for an example of custom function that uses it. You could add custom function that tests the watchdog. Because it's clock master, you can be quite exact in terms of watchdog time measurement in clock pulses.

Dave2084 · Feb 29, 2016

PaulSwan said:
clockPulse is a member of C6809ECpu so you can cast ICpu to it. See CStarWarsBaseGame::testClockPulse for an example of custom function that uses it. You could add custom function that tests the watchdog. Because it's clock master, you can be quite exact in terms of watchdog time measurement in clock pulses.

Thanks Paul, I can see how that will work.

Just need some time to code it ...

C++ is starting to make more sense now!

PaulSwan · Mar 2, 2016

Dave, if your 6802 work is settled on your working branch I can integrate it into the master. LMK.

Thanks,

Paul.

Dave2084 · Mar 2, 2016

PaulSwan said:
Dave, if your 6802 work is settled on your working branch I can integrate it into the master. LMK.

Thanks,

Paul.

I'd like to do some tidying up of the code and complete the IRQ test to check the correct PIA status flag is set (as I have on 6809). Wont get a change till the weekend now. I'll give you a shout when it's ready.

Judder · Mar 5, 2016

Quick results interpretation needed if possible...

One of the Williams sound boards I was testing accidentally got +5V and +12V sent to it the wrong way around (*user error) and the RAM part of the board is now giving dodgy results

DAC is fine as we get audio on the tests, and Inputs and fine as Interrupt check is working as are input to ground Hex code tests

However some of the RAM tests are now giving errors as below, but strangely some of the other ones that I thought should fail, still pass.

RAM Read All = OK!

RAM Write All Hi = OK!

RAM Write All Lo = OK!

RAM Write All AD = OK!

ROM Read All = OK!

RAM Write-Read = OK: 11 22 44 88

RAM Check 0000 ff U11 = E:U11 0000 91 e3

ROM Read = OK: ff 0f 8e 00

ROM Check = OK!

RAM Check All CS = E:11 0000 0f 63

RAM Check All = E:U11 0000 91 61

ROM Check All = OK!

Bus Check = OK!

Bus Idle = OK!

Any thoughts?

Also would this be a good time to install a 6802P and switch to the RAM on that instead?

Alex

PaulSwan · Mar 6, 2016

It's as expected, all the RAM tests are failing consistently. The RAM writes are only writes, no verifications. The write only tests would only fail if the bus cycle fails.

Paul.

PaulSwan · Mar 7, 2016

I've just pushed support for the Intel 8085 CPU & Phoenix into master.

Paul.

Dave2084 · Mar 7, 2016

PaulSwan said:
I've just pushed support for the Intel 8085 CPU & Phoenix into master.

Paul.

Nice!

As it was mothers day on Sunday and on Saturday a new game arrived (Mr & Mrs Pacman Pinball) I didn't get a chance to check over the 6802 branch, I'll try and do it in the week.

The arrival if this game will probably mean I'll have incentive to support 6800 for the Bally CPU and add Squawk and Talk support to 6802.

Dave2084 · Mar 9, 2016

PaulSwan said:
clockPulse is a member of C6809ECpu so you can cast ICpu to it. See CStarWarsBaseGame::testClockPulse for an example of custom function that uses it. You could add custom function that tests the watchdog. Because it's clock master, you can be quite exact in terms of watchdog time measurement in clock pulses.

I now have the full watchdog test working in the C6809ECpu.cpp, however I still need to move it to DefenderBasegame, it could stay there I guess, but it takes perhaps 10 seconds to run and would need to be different on the later games like Robotron, however I can't figure out how to access /Reset pin.

My code would be something like this:

Code:

PERROR

CDefenderBaseGame::watchdogAndVABusTest(

    void *cDefenderBaseGame

)

{

    CDefenderBaseGame *thisGame = (CDefenderBaseGame *) cDefenderBaseGame;

    C6809ECpu *cpu = (C6809ECpu *) thisGame->m_cpu;

    PERROR error = errorCustom;

for (UINT32 clock = 0 ; clock < 0x31000 ; clock++) 

    {

        int value = ::digitalRead(g_pinMap40DIL[s__RESET_i.pin]); // <----HOW DO I DO THIS?

if (value == HIGH) 

        {

            break;

        }

cpu->clockPulse();

    }

    return error;

}

PaulSwan · Mar 10, 2016

I knew you were going to ask that

The answer is to use the waitForinterrupt function and add a RESET "Interrupt" source:-

typedef enum {

RESET,
NMI,
INT
} Interrupt;

This addition will need to be supported across all CPU's. Further, for clock master CPU's it's never been implemented so far (timeout would have to be in clock pulses rather than real time). Something like this:

https://github.com/prswan/arduino-mega-ict/commit/23faba79f01f31bcda6ccdcfaf4c073da10f4c3b

Paul.

PaulSwan2016-03-10 03:32:02

Dave2084 · Mar 10, 2016

Thanks Paul,

I can see what I need to do now!

Actually I already implemented the interrupt for 6809 but I guess it does need changing from time to clock cycles. I'll take a look at the weekend as I'm out tonight.

Still need to finish up the 6802 code too ...

Dave2084 · Mar 10, 2016

Just spotted a typo in a comment:

Code:

+        // Most CPU's have reset, none maskable & normal interrupts.

Non maskable?

Battlezone · Mar 10, 2016

Paul do you know if anyone is working on the software for Tutankham boards?
I wouldn't want to duplicate someones existing effort.

They have 6809 (and z80 for sound) and given I have schematics and both
working and broken boards I thought it might be a good place to start playing
with this exciting bit of kit (once I have the PCBs). The other currently supported
boards would be less easy for me to test.

Dave2084 · Mar 10, 2016

Had a quick look at I have something that compiles, but I think timeout will need to be UINT32 due to the number of clocks I need to run and there will be times when I'll need to check for intPin going high and not just low so I've added an extra parameter to waitForInterrupt.

Will test at the weekend.

PaulSwan · Mar 10, 2016

BZ: I've been working on adding "generic" support so that basic ROM & RAM tests don't need to have a specific game description added to the code base. It's not as convenient as adding a full game description but useful for the quick tests of odd boards:

https://github.com/prswan/arduino-mega-ict/tree/generic

Dave: Yes, something like this would be fine:

virtual
PERROR
waitForInterrupt(
Interrupt interrupt,

bool active,
UINT32 timeout
) = 0;

Where "active" == true means wait for the interrupt to be asserted and false means de-asserted (independent of whether the pin itself is active high or active low).

Paul.

Dave2084 · Mar 11, 2016

PaulSwan said:
Dave: Yes, something like this would be fine:

virtual
PERROR
waitForInterrupt(
Interrupt interrupt,

bool active,
UINT32 timeout
) = 0;

Where "active" == true means wait for the interrupt to be asserted and false means de-asserted (independent of whether the pin itself is active high or active low).

Paul.

I've already added code to pass a highLow parameter with the default being LOW, that way existing uses of the call don't need updating ... I'll see how that works out when I get to try this out over the weekend.

Battlezone · Mar 11, 2016

PaulSwan said:
BZ: I've been working on adding "generic" support so that basic ROM & RAM tests don't need to have a specific game description added to the code base. It's not as convenient as adding a full game description but useful for the quick tests of odd boards:

Ah yes these were added since I cloned.

It probably makes most sense for you to work on infrastructure and
generic tests, and maybe others can help you fill in some of the game
specific stuff from Mame and schematics.

One thought is maybe we could try and auto detect ROMs/RAMs in say 1 or 2K
chunks through the entire 64K range. That way the ICT might just
list the working RAM addresses and ROM checksums. The user may
need to enter the ROM size via the LCD before the test is run. Maybe
this is where you are heading with the generic games?

PaulSwan · Mar 11, 2016

The problem with such automatic ID's is that if the board has a fault then they won't work correctly. The way I've implemented generic is that you need to know (e.g. from MAME) where you expect to find ROMS, how big they are and what the CRC should be. Similarly, you need to know where RAM should be to expect it to work or not

Paul.

Battlezone · Mar 14, 2016

PaulSwan said:
The problem with such automatic ID's is that if the board has a fault then they won't work correctly. The way I've implemented generic is that you need to know (e.g. from MAME) where you expect to find ROMS, how big they are and what the CRC should be. Similarly, you need to know where RAM should be to expect it to work or not
Paul.

Agreed should expect the boards to have faults. Either the software needs to know where the ROMs/RAMs are expected to be or the user needs to know this. The thought I was having is that both don't need to know. We can imagine a system where the software auto-detects whatever it can find and then reports this to the user so they can decide if it's good or not (e.g the software reports 5 ROMs and there should be 6, or the software can only find 6K of RAM at such and such address and there should be 8K). From a user perspective board specific code will be best (if it exists).

To speculate even further it may even be possible to auto detect the processor (provided there are enough differences in pin positions of power/ground and clock). The advantage here isn't that the user doesn't know the processor, after all they've just removed a Z80 or whatever. The advantage might be that might not need to load different code onto the Arduino for different boards, one bit of software might be able to do it all.

We don't need to worry about any of this at the moment. These are just thoughts for me to try out later to see if they pan out and are useful in practice.

PaulSwan · Apr 13, 2016

The 16-bit T11 support is quite a large set of changes so I've adjusted the GitHub to use topic branches that represent the last known tested baseline for each of the CPU's.

For example...
https://github.com/prswan/arduino-mega-ict/tree/Z80
...would be the last baseline tested on a Z80 platform.

I won't bring down changes into the CPU branches unless I happen to have a board on the bench to test them with, or someone here signs off that master looks good to merge into a particular CPU.

Paul.

PaulSwan2016-04-13 04:01:32

Arduino In-Circuit Tester: Build Project

ZZZ

Active member

ZZZ

Active member

Active member

ZZZ

ZZZ

Active member

Active member

ZZZ

Active member

Active member

Active member

Active member

ZZZ

Active member

Active member

ZZZ

Active member

ZZZ