Arduino In-Circuit Tester: Build Project

[yorkshire_spam]

Me being thick.... mixing versions from various repos.
A clean copy sorted that, but now I'm in library/dependency hell. Again.

 

[Van Diesel]

I'd like to get in on this exciting project myself, so here's my first call for anyone selling any of the PCBs, please (here in the UK).

Also, a question please . . .

I notice that two cables are being used between the arduino board and the cpu breakout board; the original cables of which have twisted pairs. I can see the utility of this as the signals will be in the RF range, and may requre some shielding.
But many of the projects I see are using straight cable. Is there a real need for 2 x twisted cables.
Would one single 40 wire cable work?

Thanks
Van

 

[Judder]

I'd like to get in on this exciting project myself, so here's my first call for anyone selling any of the PCBs, please (here in the UK).

Also, a question please . . .

I notice that two cables are being used between the arduino board and the cpu breakout board; the original cables of which have twisted pairs. I can see the utility of this as the signals will be in the RF range, and may requre some shielding.
But many of the projects I see are using straight cable. Is there a real need for 2 x twisted cables.
Would one single 40 wire cable work?

Thanks
Van

Hi Van

Welcome to the thread and apologies for not replying (yet) to your PMs - crazy times with everything at the moment!

The cables could be totally flat ribbon cables I would think, so if you can find IDE type ribbon cables then these would work too

For the PCBs, I do have extras but they are in London, and currently I'm not, but will be back hopefully once we are out of the lockdown if you don't have a set by then

Alex

 

[yorkshire_spam]

I notice that two cables are being used between the arduino board and the cpu breakout board; the original cables of which have twisted pairs. I can see the utility of this as the signals will be in the RF range, and may requre some shielding.
But many of the projects I see are using straight cable. Is there a real need for 2 x twisted cables.
Would one single 40 wire cable work?

My first build just used 1 ribbon cable, but I had to do some messing around to get it all right with the "default" pcbs - in the end I just used 2 cables and kept it simple.

 

[Nes4life]

I'd like to get in on this exciting project myself, so here's my first call for anyone selling any of the PCBs, please (here in the UK).

I've offered some parts from my spares:

• 68000 header
• XR shield (resistorless version)
• ZIF socket
• Arduino LCD shield

You'll still need the z80/6502 & 8080 shields (and all the BOM & soldering to do).

 

[yorkshire_spam]

Comment about errors deleted...

I've read some of the source notes comments - so I might be sorted....

yorkshire_spam2021-03-02 20:36:53

 

[DaveR]

I been getting into the Raspberry Pi Pico recently and got me thinking about projects and came across this. Still reading up right now

 

[Nes4life]

The problem with the Pico is that it can't drive 5V logic so you'd need loads of logic-level converters. The Arduino can accept and drive 5v logic though. If there was a faster 5v microcontroller then perhaps that'd be better, but for now the Arduino Mega does the job quite well.

 

[Van Diesel]

I was considering the STM32 'Blue Pill' for some arcade projects but rejected it for the same reason (3.3V). Sure, you can level shift but why bother - As Nes3Life says, the Mega is pretty good and you can pick a new one up for just a tenner.

Van

 

[yorkshire_spam]

A couple of questions.....

1. 6809E / Star Wars testing.

I'm trying to get set-up to fault find a SW PCB set using the ICT.

Bus Idle says "OK"

But "Bus Check" says:

E:GND1 Hi 174

It reports this error when in circuit and out of circuit - so is it safe to assume I have a short/wiring issue on my ICT?

Edit #2: Answered my own question on this one - badly "crimped" IDC header on one of the cables - redid that and everything is fine and I'm up and running testing the PCB! Happy days.

2. ICT Speed

Is it worth considering a re-think on the CPU "head" part of the system - would aligning the pin allocations for ADR and DATA with the PORTS on the Arduino speed up access and make testing speed critical applications more viable?

Edit #1: by this I mean a different cpu head PCB for each CPU type where the adr and data lines always route to the same pins on the arduino and those pins correspond to whole or part of a "port" for high speed read/write.

Cheers, Sam

yorkshire_spam2021-03-04 11:35:00

 

[Van Diesel]

Hi people

I wondered if there were any details as to the project in relation to what should be expected when it is running, please?

I have got an Arduino Mega with the display/button panel, and have successfully uploaded the sketch/program. There are no other boards attached right now.
The only two buttons that appear to do anything at the moment are 'Right' to scroll through selections and 'Reset' to reset the device. I'm not getting it to do anything. The other buttons aren't altering anything that I can see. I was hoping (at least) to run a board test and see it fail due to no board being connected.

I've successfully run the test sketch/program to prove that the keypad and LCD are functioning fully.

Any assistance, please?
Thanks
Van
Van Diesel2021-03-06 17:54:00

 

[yorkshire_spam]

Hi people

I wondered if there were any details as to the project in relation to what should be expected when it is running, please?

I have got an Arduino Mega with the display/button panel, and have successfully uploaded the sketch/program. There are no other boards attached right now.
The only two buttons that appear to do anything at the moment are 'Right' to scroll through selections and 'Reset' to reset the device. I'm not getting it to do anything. The other buttons aren't altering anything that I can see.

Any assistance, please?
Thanks
Van

I had exactly the same problem, you need to run the sketch purity posted here: http://www.ukvac.com/forum/arduino-incircuit-tester-build-project_topic349525_page13.html

And then edit the values in ArduinolibrariesDFR_KeyDFR_Key.cpp

Cheers, Sam

 

[Van Diesel]

Hey there YorkshireSpam

Many thanks! I understand what is going on.
For my keypad (DFRobot type) the correct values needed were -

static int RIGHTKEY_ARV = 0;
static int UPKEY_ARV = 130;
static int DOWNKEY_ARV = 305;
static int LEFTKEY_ARV = 478;
static int SELKEY_ARV = 720;
static int NOKEY_ARV = 1023;

I noticed that there is a programmed tolerance of 20 included in the software but even with this the values I was getting were outside of the range of the originals (and hence the keys didn't work).
I placed the values shown above into the DFR_Key.cpp library and all the keys work now.

Van
Van Diesel2021-03-06 22:01:13

 

[Van Diesel]

Hi Guys

I hope this is an OK thread to post questions.

I have decided to build my own 8080 CPU probe head rather than use the pre-designed PCB by Alex (Judder).

I've noticed that the probe head PCB as designed by Alex is very complex in wiring and looks to be a struggle to fix on the board . . . but I was thinking . . . what would be the problem with making a very simple wired probe head (meaning that the cabled input pin almost maps on to a CPU pin directly on the board . . . just like the way the original Signetics 2650 Probe head looks) and alter the pin assignments in software accordingly to accomplish this.

If there is nothing wrong with this approach, why was this not done originally? I'm guessing there must have been a reason . . .
I know that the clocks need the potential dividers to convert to readable TTL levels, but surely the rest could have been mapped more simply?

I know that the pin maps will have to be totally different between CPU probe heads so why not have a simpler wiring with altered pin assignments (in pinMap8080.h) for 8080 version?

The only way this might NOT work is if some of the Arduino Mega pins being used cannot be set using PinMode because they have special useage (like a pin that can only be analogue). Is this the case?

What are people's opinions, please?

Thanks

Van

Van Diesel2021-03-08 15:57:05

 

[LabRat]

Disclaimer: Answer in the generic context, without having looked at the specifics of the implementation. So this may (or may not) apply explicitly in this case.

Speed. A single write to a PORT can output 8 bits at once (for these old 8bit devices) versus requiring 8 independent "set bit X in port Y" calls. In your remapped world, do you need the 8 instructions, or the one ?

 

[Van Diesel]

Ah ha! - Yes, you (and Yorkshire Spam) answered my question.
I'm going to assume (for speed), a byte read will be necessary and the pins wiring appropriately for this (certainly the data bus, maybe more . . . )
Thanks once again, guys.

Van

 

[LabRat]

@Van Diesel. What software are you using to do your layout?
I did a version in Cadsoft Eagle (mostly because I wanted to update some of the silk screen text, to aid in my not getting the cabling wrong). I'm just setting up a BLOG now (long time reader thereof.. first time poster thereof), and will be posting the eagle files there (or GitHub) if there is interest.

LabRat2021-03-09 14:56:47

 

[LabRat]

https://github.com/LabRat3K/arduino-mega-ict/tree/dev-labrat_HW/Hardware

Should find the Eagle files for board layout (please note that while I have made a batch of PCB's, I haven't finished testing that they work yet). Sharing in case others want to make further changes.

 

[Nes4life]

Good work! Not tried Eagle as I always use DesignSpark. Could you produce Gerber files and host them too? Loving all the effort put in recently. It's a great tool.

 

[LabRat]

Good work! Not tried Eagle as I always use DesignSpark. Could you produce Gerber files and host them too? Loving all the effort put in recently. It's a great tool.

Done. Pls note that the text on some of the pod headers didn't come out quite the way I had hoped. On the generic pod the rendered text (by the PCB manufacturere) was problematic, with cropping and spacing issues. On the 8080 pod, the title text ran afoul of the conduits. These should still be working just fine, but revisiting the tDocument and bDocument layers before re-submitting might be a good idea.