Debian buster installation with 32-bit RTAI Source

You maybe right on the Windows 98, but the first non DOS we used was Windows 3.1 on the original IBM PC. We did have a co-processor but it was not required for our application. My last specs are on imapro.com. The larger memory size required was for image rotation, postscript ripping and resampling.

Without modification I would agree that my laptop would not be able to drive my Sherline Mill. I have the old 1 GHZ desktop will old code that still can run it worst case.

Your right about having to twiddle pins. My thought was that all the pin twiddling could be a pre-process to make a Byte Queue that could be fed to the stepping motor drivers by DMA. Perhaps you are doing this already? Looking over the code would help me determine it.

If I remember correctly the Sherline driver box hardware chips handle the micro-stepping function of the motors and the parallel port just feeds the step and direction pins for the XYZA axis.

In the film recording application the the image size was 3 files of approximately 50MB, one each for red, green, blue. Does the amount of data you need to feed on a typical CNC run exceed these sort of numbers? If you need to feed the motors every 25uS a 50MB file would be equivalent to a 20 minute CNC run.
We would be "Ripping the G-code" just like we ripped images.

Vescovo wrote:
2) I am using a Dell Inspiron laptop with 512 MB of ram 2GHz Mobile Pentium 4 processor, NVidia GForce4Go 32MB VRam and a PCMCIA Wireless N card.

Search the web for "debian dog" or "coolcnc" ISO, the firts is a Puppy Linux distro with LinuxCNC and RTAI kernel at 250MB size, the second is even smaller at 50MB total size. They do not have all the luxury of new distros but they are both very usable with very old laptops or PC's.

Thank you Tommy, I will check them out!

Linuxcnc is preforming the motion control. ie it is doing the timing. It is different to just sending out data.
Back in my Win 95 days I wrote a Vxd to handle parallel port interrupts that were generated by a PIC 16F84. The PIC then generated a bit stream that was based on the byte received, yes similar to a serial port but not quite.
Now if the OS had to generate the timing I would want a system that had lower & more regular latency.
I guess one way of thinking of what linuxcnc does is generating 6 streams of serial data (3 steppers, step & dir for each) that require to be synchronised. Now if you lose that synchronisation your part will not come out as expected. The thing is there is no hardware, as in an serial port, that does the conversion. Imagine having to write a driver for Windows, say pre NT, that does the same. 6 streams of synchronised serial data with all timing and hardware access done in software.
I don't believe generating the data stream & buffering it would work as Linuxcnc has to respond to various inputs, such as limit switches, spindle encoders in real time. How would you accomplish threading on a lathe or rigid tapping on a mill if there was no real time feedback of spindle data ?
It's not actually the absolute horsepower of your system that is important, it is how regular the system is that is important. A 1.2GHz that has low latency is better than a 4GHz that is all over the place.

I guess one way of thinking of what linuxcnc does is generating 6 streams of serial data (3 steppers, step & dir for each) that require to be synchronised. Now if you lose that synchronisation your part will not come out as expected.

Thats not correct. A parallel port does not use serial data. A port at a specific memory address contains a bit map corresponding to each data pin in the parallel port. So internally, a series of bitwise operators set the data bits and writes it out (as an integer) in one operation. Its a long time ago but I did once write software to control a parallel port as a breakout board before CNC BOB's ever existed. If only I knew what I could have done with this method well before Linuxcnc and Mach existed.

What you say is 100% correct. That is why I was looking on how to route one of the counter timers to the parallel port to act as the strobe to out put the data or input the status at a constant frequency of 40KHz. This would give you the Realtime response you require at a very low jitter rate. Unfortunately the IRQ response time of the Intel product is not good. Too many clock cycles. A z80 processor running at 8MHz had more reliable interrupt response time.

It is the difference between running a "Synchronous State Machine" and an "Asynchronous State Machine".

Do you conclude that even if we can get a constant frequency output the scheme of pre-ripping the stepping sequence would NOT work for stepping motors?

I do agree that if you are running a DC servo motor system with encoders feedback pre-ripping is not practical.

Spindle speed control and tapping remain issues.

Are the ARM processors any better?