Custom software for RV1S/RV4S

Started by arvydas, August 20, 2015, 12:33:35 PM

Previous topic - Next topic

Mike

Quote from: Jason on August 21, 2015, 07:57:12 AM
Quote from: Mike on August 20, 2015, 11:55:05 PM
Quote from: Jason on August 20, 2015, 08:29:39 PM
so I can wire the FT2232H mini module up to the RV ISA card via some appropriate
glue logic
Maybe an FT4232H so you can also do the COM ports via USB with the same chip? .

I'd forgotten about that. I'll put a check in my exception handler .dll which looks
for the UART io address and, optionally, reroutes the data to/from the standard
Windows COM port API. This would allow use of FTDI or any other COM port.

Although thinking about it, if you're talking to th ISA card you might just as well redirect the calls to the UARTs on the card...
I have seen a card without the UARTs though. May have been an early machine.

arvydas

Wow, it's great to know that members have been doing quite some reverse engineering on the machine :) This is excellent news!

Quote from: phonoplug on August 20, 2015, 09:34:14 PM
I'm vaguely aware of the guy that wrote the software on these machines. He only lives a few miles away from me. I have considered trying to get in contact with him in the past to see if he is open to the possibility of releasing the source code, if he even still has it. But then you would need the compiler too. Perhaps for a small amount of money he could be persuaded? He's got nothing to lose now.

Thoughts?

I think that this should be our top priority. If you could get in contact with him and find out if he still has the source code and if he would be willing to share it for some fee or no fee at all would be fantastic. I would definitely chip in. Getting a compiler for the source code is easy.

If we could get the source code and understand how the machine works internally, then it opens up so many possibilities to fix the software and even modernize the hardware.

But if the source code for the software is no longer available, then we would need to pursue plan B which would be the reverse engineering of the ISA communication. I'll look into getting an ISA bus analyzer.

Mike

Ths ISA bus is simple and slow enough that any scope or logic analyser with enough channels would probably be adequate for analysis.
Maybe one of the cheap PC based LAs to allow logging.

However if Jason's method works, as it works at a low level it may not actually be necessary to understand the meaning of the conversation between the SW and the DSPs. It could just work!

I wonder if there is a disassembler (IDA Pro?) that supports the DSPs' instruiction set?

Mike

Quote from: phonoplug on August 20, 2015, 11:52:23 PM
The ISA card only uses /IOR /IOW and AEN control signals (not /MEMR or /MEMW, or any interrupts), the 8-bit data bus and address lines A0-2, A5-9.
..and as the ISA card would be the only card in the "system" you could almost certainly hardwire most of the address pins - all the ones used to select the card within the ISA address space. 

arvydas

Any suggestions on a reasonably priced 16 channel logic analyzer? :)

I had a play with IDA Pro this morning. It provides a lot of information about the internals of the application, classes and methods. It should be possible to hook into the functions on a live machine and this way log the communication with the ISA board.

Mike

Quote from: arvydas on August 21, 2015, 04:40:00 PM
Any suggestions on a reasonably priced 16 channel logic analyzer? :)
Something like this perhaps ?
http://www.ebay.co.uk/itm/100MHz-16CH-250MHz-8CH-PC-USB-Logic-Analyzer-with-support-I2C-SPI-UART-and-PWM-/131452875075?hash=item1e9b33b143

AFAICS this isn't one of the saleae clones that expect you to steal the Saleae software to use.
Though that probably means flaky Chinese software, but you can hardly argue with the price.

arvydas

Looks good. Will buy it as a last resort if I can't hook into the application which seems doable.

Jason

Going back to customer software, I was wondering whether an P&P module to extend
something like Meowcad could be an option (with RV support, of course!).
The RV export tools Mike and I did for Pcad and Eagle were what kicked off that idea
as I always thought it daft to have two different board databases.

phonoplug

Quote from: arvydas on August 21, 2015, 04:40:00 PM
Any suggestions on a reasonably priced 16 channel logic analyzer? :)

I've got the LeCroy Logic Studio box (software you can download free). I'm not entirely sure whether I want to lend it out, but conversely I don't know how much help I can offer as my skillset isn't in the domain of PC software. Hmmm. What would be involved, and how long would it likely take?

Mike

Quote from: phonoplug on August 23, 2015, 09:45:54 PM
I don't know how much help I can offer as my skillset isn't in the domain of PC software.
Contacting the software guy could potentially be more help than any logic analyser...  ;)

spiyda

Quote from: Mike on August 23, 2015, 11:56:46 PM
Quote from: phonoplug on August 23, 2015, 09:45:54 PM
I don't know how much help I can offer as my skillset isn't in the domain of PC software.
Contacting the software guy could potentially be more help than any logic analyser...  ;)
I'll second that !
I can't help much programming wise, but I have a complete and working spare machine to play with that doesn't need to be placing chips if that helps.

arvydas

Quote from: phonoplug on August 23, 2015, 09:45:54 PM
Quote from: arvydas on August 21, 2015, 04:40:00 PM
Any suggestions on a reasonably priced 16 channel logic analyzer? :)

I've got the LeCroy Logic Studio box (software you can download free). I'm not entirely sure whether I want to lend it out, but conversely I don't know how much help I can offer as my skillset isn't in the domain of PC software. Hmmm. What would be involved, and how long would it likely take?

It's difficult to tell at this point. I think that hooking into the application and logging all communication at the lowest level would beat any logic analyzer, because it's possible to get a lot more information about the application and it's states. I will let you know if my primary method of getting the communication protocol fails.

Mike

Quote from: arvydas on August 24, 2015, 09:58:40 AM
Quote from: phonoplug on August 23, 2015, 09:45:54 PM
Quote from: arvydas on August 21, 2015, 04:40:00 PM
Any suggestions on a reasonably priced 16 channel logic analyzer? :)

I've got the LeCroy Logic Studio box (software you can download free). I'm not entirely sure whether I want to lend it out, but conversely I don't know how much help I can offer as my skillset isn't in the domain of PC software. Hmmm. What would be involved, and how long would it likely take?

It's difficult to tell at this point. I think that hooking into the application and logging all communication at the lowest level would beat any logic analyzer, because it's possible to get a lot more information about the application and it's states. I will let you know if my primary method of getting the communication protocol fails.
Except that with a LA you can also probe the step/dir outputs so see the effect of the commands to it, and how things like ready/done type signals are implemented. 

arvydas

Made some good progress! It's just a start of course, but a very good start. The communication with the DSP board takes place in stepDsp.dll file. There are two functions that do the low level stuff:

Stepdsp::OutPort(int, uchar)
StepDsp::ReadPort(int)

As described by Jason, the addressing is done at lowest level with IN OUT assembly calls. This happens at addresses 0x00402F5B and 0x00402F84. The board is addressed over ports 0x300 - 0x303 and during initialization for the board, the application sends 0 to each port, then sends a sequence 0x80,0x40,0x0 for each port again.

When you click on the user controls for the machine to move by 1 to the right, the data sequence looks like this:

# right 1
OUT 302, 8A
OUT 302, 40
OUT 302, 0
OUT 302, 20
OUT 302, 10
OUT 302, 0
OUT 300, 80
OUT 300, 40
OUT 300, 0
OUT 300, 20
OUT 300, 10
OUT 300, 0
OUT 301, 80
OUT 301, 40
OUT 301, 0
OUT 301, 20
OUT 301, 10
OUT 301, 0
...

Didn't check the IN requests, but they should have ACK responses from the board. I suspect that 80-40-0 sequence is a deceleration for the DSP board which is handled automatically within software.

I'll write a proxy DLL for the stepDsp.dll so that I could log all interesting function calls in sequence and capture parameters. Then it's just a matter or playing around with the machine, capture the output and analyzing the communication. There are about 4 levels of abstraction within the machine and the one described above is the lowest level. There are classes to handle feeders, arm movement, nozzles, calibration, job processing, imaging and etc.

This opens up a huge amount of possibilities. For example, it should be possible to write a device driver for the DSP board, proxy the stepDsp.dll to another DLL and handle all communication with the DSP board via the driver this way making it possible to run the software on Windows XP and up. Alternatively it should be possible redirect all DSP board requests to a USB device as Jason planned, because all communication is a super basic direct addressing of IO ports.

I've read somewhere that DSP board has internal COM ports too? Does anybody have any info regarding them?

I'll keep updated with the progress.

Mike

I think the UART is just a couple of bog-standard PC UART chips at a standard address..