Request For EMCO C5 Lathe Mk4 ROM Code. ( FAO Dieter)
Context : This post follows on from conversation on a separate thread. ( Compact 5CNC CPU schematic ). I am looking for the ROM code for the later EMCO C5 lathe.
Hello again Dieter - and others....
It is me who is after this later code version. I do have an IC programmer :-)
This is the background -
To provide a spare and for interest - I have adapted an F1 mill MPU card to work in either my C5 or F1 machine. Actually, there are no changes to the board itself except "socketing" 2 of the logic ICs. The necessary "adjustments" (almost all due to the heavily revised memory map of later version EMCO boards) are achieved with a daughterboard which connects to these + a ROM socket. I include a picture of the prototype.
A couple of very minor parameter tweaks (about 8 bits !!! ) are needed in the code to support the change.
Removing the daughterboard and re-inserting the logic + PROM ICs returns the board to absolute standard.
The PROM shown currently holds 4 code sets - 2 each for an F1 and C5. These sets are jumper (middle left) selectable. To actually fit the MPU board in a C5 cabinet requires temporarily removing some keypad switches and a LED - this is a physical constraint. Also, my prototype is a little too tall (thick) for the cabinet fitting but I plan to lower the IC socket profile on the daughterboard to bring it within ~0.75mm.
I would like the extra Mk4 code function - but not all the time - as I am using the DNC interface for a pulsewheel pendant for manual jog. (+ switches for single touch up / down load, run-hold etc). The point is - I currently understand the later code reduces this DNC capability so I will switch versions "on the go" as required.
While at it - I did the usual tweak to the serial port parameters and the image shows a switch -far right- for selecting 9600 / 1200 baud for upload / download. I plan to couple this switching to the load/ save controls.
To avoid questions on why this effort on obsolete hardware - I should mention that I am also (slowly) upgrading the machine's overall CNC control in the typical way - but I will retain all the original functionality as a switchable option. I like to keep old machines as original as practical and I also like the "switch on - do a job - switch off" simplicity of the original controls for day to day convenience. But I also want enhanced controls and a part design tool-chain at other times.
I did nearly the same. My F1 CPU is the "Development board", you can install the EPROM's from the C5 on the F1, only some VIA I/O's are different.
With an EPROM emulator I code and test directly on the F1 CPU.
As you explained the F1 CPU supports 2764 EPROMS's, the older C5 only 2732, but with the daughterboard also 2764.
-I would like the extra Mk4 code function - but not all the time
-as I am using the DNC interface for a pulsewheel pendant for manual jog. (+ switches for single touch up / down load, run-hold etc). The point is - I currently understand the later code reduces this DNC capability so I will switch versions "on the go" as required.
You don't loose to much with MK4, the single up / down load, run-hold etc is already made on my machine with the DNC.
Unfortunately on MK4 the X/Z +/- inputs are no more supported and the STOP PROGRAM is missing to.
How do you switch between 2 versions without Reset? Reset in the original version deletes the memory.
But for the jog you could connect directly to the keyboard matrix, on the CPU the holes are provided to solder 2.54 spaced pins.
It's easy to do without cutting traces on the PCB or soldering directly on the keys.
On my machine the old owner (a school) soldered (rather glued) directly on the keys and used a Centronics connector for an external keyboard
to save the original keys. The START key was already damaged when I purchased the machine.
I did it for emulating the INP/REV because STOP is not supported on the DNC and I made an endstop board which emulates the 4x X/Z keys.
When endstop is reached the axis stops. By pressing an new "OVERRIDE" key the slide moves then in the opposite direction to free up the endstop switch.
I used an CMOS 4066 in parallel to the keys, it provides the isolation needed because the matrix works with PA and PB of the VIA and the keys
are "floating" between PA and PB.
Switching would be no more needed.
Hello JG and all others,
More sketches from my modification. The drawings are not at all professional, I'm a bit lazy. :-)
Hope they are sufficient explanatory, the text is mostly German.
I thought about the pulsewheel. It can only work smoothly with the key matrix method if the pulse rate is lower than the scanning rate of the matrix.
For example: the scan for the "Intermediate Stop" from the DNC is just behind the scan of the key matrix for INP+FWD, so I guess the
scan rates are similar for the X/Z +/- on MK2. Works it in the same manner as the X/Z keys, a short stroke for one step and when
holding down a continuously move?
Can you post infos about the pulsewheel please and how you interfaced it with the DNC, this is a useful accessory.
I added absolute indexing for the tool revolver (sketches DNC), the M04 for spindle motor reverse and switching functions (Relay board), the extended keyboard (Zusatztastatur)
and extended the RAM to hold 2x 990 blocks with memory backup (EPROM modif).
That is good work there. You are creating new "EMCO control" versions by modifying the original code at "assembler" level then, yes ? You have a much better understanding of the code than I have :-]
>> "I did nearly the same. "
Yes, our activities on the F1/C5 & remote/pendant/DNC side seem very similar. Using your work for an improved basic system is definitely a future option :-)
I have had to pause my EMCO work while working on a similar project - a virtual MC6800 (emulator) to reverse engineer / operate some old real time ROM code for a pinball machine.
There is a lot of detail in all this - so, one part at a time :-)
Just for background - I had 4 objectives -
1) Having enough spare parts + knowledge to maintain/repair my EMCOs - in standard form.
2) Making small adjustments for convenience - eg higher baud rates.
3) Adding simple features for easier use - eg pulse wheel jog / 1 press upload.
4) Enabling the next goal - selectable "PC based CNC" / "EMCO control".
It's also partly for "the challenge" of course :-)
At this stage I decided to limit changes to -
A) "plug in/out" fully reversible mods to hardware - no changes except for sockets and maybe "breakout" connections.
B) Simple machine code level edits - ie changes to "operands", not "opcodes".
If it is of interest - and for comparison with your approach - this is what I did -
The F1 / C5 interoperation.
My thinking is that EMCO upgraded the original "small ROM" C5 boards for use on the F1 mills - so more code and a 3rd axis. Then they used these boards back in the later C5 (Mk4) machines with the extra G code function.
The main EMCO changes & my fixes for interoperation are -
**New memory map to support bigger ROMS - done by EMCO in fairly "hack" way. Fortunately this is reversible for standard older C5 code by a single PLD replacing the 138 decoder. (pic included) But for "multi boot" I made the daughterboard previously pictured.
**Extra key switches/LED - fortunately backward compatible (but have to remove switches to fit board in C5)
**Extra Y axis drive signals + connector. EMCO had to move a control line for the 7 segment display controller from one PIO to another. but this just needs a small rom code tweak to correct.
A bigger problem is - the extra Y axis lines "mess up " the DNC interface so -
I) need modified different cables to use F1 board in C5 with DNC ....
II) lose DNC "jog, etc" on F1 (& Mk4 C5 ???? )
Therefore I anticipate a solution like yours on the F1 - using the pad strip. This strip shows "forward" thinking" by the designer - there are some other small "Easter Eggs" on the boards - but prob not v useful.
>> "How do you switch between 2 versions without Reset?"
Yes, a reset/ reboot is needed to change between code versions - my bad choice of words :-(
I'll respond to your questions on the jog pendant in another message.
This proof-of-concept "remapping PLD " plugs into the 74138 socket - with overhanging pins !!!! This + the 7Seg control line code tweak allows Mk2 c5 code to run on F1 board.
-1) Having enough spare parts + knowledge to maintain/repair my EMCOs - in standard form.
Yes, I have a stock of all component, and spare "untouched" C5 CPU, Video/RS232, DNC etc. I could convert back at any time.
-2) Making small adjustments for convenience - eg higher baud rates.
It was the first modif I did without any knowledge on MP's, I downloaded the datasheets and with an old Eprommer I searched for the 300 Bd values
and by trial and error (4 -5 EPROM burns) found the the parameter address for baudrate.
-3) Adding simple features for easier use - eg pulse wheel jog / 1 press upload.
This is made not very user friendly from EMCO, one wrong key stroke and the program in CNC mode or the X/Z values in Hand mode are deleted.
I changed the code to press at least 3 buttons to delete a program, G64 + INP or the new RS232 key loads when memory is empty
or sends if a program stored, you must first delete a program before loading with with DEL + INP + -->.
INP + DEL delete now the X/Z values.
FWD, REV, MINUS + DEL allow fast scrolling or testing a program, when releasing DEL it switches to slow scrolling,
but only after finishing the oiling system.
-4) Enabling the next goal - selectable "PC based CNC" / "EMCO control".
For the moment I don't consider it, I want to replace the 6502 by a 65C816 to improve the math routines to 16 bit and the memory moves.
-I) need modified different cables to use F1 board in C5 with DNC ...
This was at beginning a challenge, I had to find the correct I/O to make the DNC working with C5 code on F1 CPU.
Try to find a C5 CPU, I'm sure if you make a query on our site you can get one.
-II) lose DNC "jog, etc" on F1 (& Mk4 C5 ???? )
The pad strip is a simple solution. And "easter eggs"? Yes there are some on the video board, 1 DIP switch was free and I use it for recognition
of the CNC memory bank switch. Also an unused decoded address range on X51 pin 30-C (aAF00 - aAFFF I found no track on the CPU side)
and a free 1/2 74 155.
-Yes, a reset/ reboot is needed to change between code versions - my bad choice of words :-(
How to use it in practice? You switch to MK2 (loose the program) and make the jog, switch to MK4 and load the program again........etc.
The programs are no more deleted, I had to modify the Reset routine to delete only dynamic variables. After a Reset or turnoff the X/Z positions, M98, Absolute
or Relative mode are not loosed (the Goldcap backs up the RAM, but originally even a Softreset deletes the whole RAM area.)
After a long non using period or when things go wrong the variables areas are deleted by holding down the DEL key when turning on or resetting and
the CNC program with DEL + INP + -->.
You could add all this modifications by editing the code, except the memory extension to 2x 990 blocks (bank switching) if you keep the original RAM's,
however 12 more to get 222 blocks.
I can send you the ROM code MK4 Version 4.1 (Tape messages, 210 blocks) and the F1A 001 in HEX and BIN format, but you are not in the mail directory.
Hope it works as attachments.
Thank you for the files :- ) They will be useful.
I will save them off now and look in more detail when I get a minute. Right at this time I have my head full of MS .Net, C# & MC6800 machine code.
To try the files on my board I will have to reload my head with the EMCO stuff again.
You cover a lot of topics !
Spare Parts : Good to know we can keep the machines working :-)
Baud rate : Did you "fall into the trap" of the dummy port initialisation in the startup code - like I did ?
Accidental erase etc. : I currently upload every few minutes/changes to the host PC - for a recovery option. Not actually to a file but just to Hyperterminal so the NC programs are in its data buffer - so no human PC interaction needed while using the EMCO - except if I need to download. Yours is a more complete solution.
CNC Upgrade : I considered running the original EMCO code on another processor such as Arduino etc - connected to the 6502 socket to access the address / data / control lines. But the EMCO code put me off. The single biggest issue is that they didn't use a (the) timer interupt - to regulate the system event timings for stepping, tape data streaming etc etc etc
They have used delay loops for everything - it makes it all so complicated and slow - and unresponsive. There are even delay loops inside the ISR - which is shocking IMO for a real time system. No wonder the system just does 1 user (sub)task at a time and can't manage >1200 baud.
Spare C5 board : I am ok now :-) The "memory map" correction PLD means the F1 board will run the C5.
Multi boot : I (want to) use my machine in two ways - a) (now) mostly in a semi-manual mode for small quick jobs - hand entered short g-code progs to make a few repetitive cut-and-steps for mostly simple facing, turning, boring, chamfers, threads etc. b) When I get properly set up with a CAD-CAM-Gcode tool-chain I will use an upgraded CNC control for the more complicated parts.
Cabling / IO : Yes - initially was confusing. Now I have all the memory, PIO maps and connectors sorted out it is not so bad. Just need a cable from the F1 Y axis connector to the DNC board really + minor mods.
Pad strip: This will be the only answer for a pendant on my F1 mill, I think - but that is the future.
Hot Reset: I don't see a need (for my use) to change code sets while a program is loaded - I plan to only use the C5 Mk4 code for jobs needing the G-code enhancements. My normal Use-Case a) above only needs the Mk2 system.
You are certainly seriously into the code structure there. Have you considered re-coding the whole system using the better parts of the existing code along with a proper system "tick" clock, separate "finite state" task threads and so on ?
I am making a couple of drawings of my (prototype) pendant set-up and will reply again. You are correct - getting a reasonable transition through step-slow-faster-rapid in jog mode was the tricky part. My solution is not perfect - but it is acceptable, I think.
-To try the files on my board I will have to reload my head with the EMCO stuff again.
I have always to reload my head after a few days, I forget in a heartbeat. I made this modifications over years and must
"Restart" for all new idea.
-Baud rate : Did you "fall into the trap" of the dummy port initialisation in the startup code - like I did ?
Don't remember, was in 2012/2013, I had no knowledge and no disassembled code only the Eprommer, I played "Battleships" to find the position in the EPROM.
When I started to decode I made some experiments with RTS/CTS HS without success.
I got later 9600 Bd with the terminal program generating a line delay of 20 ms. This give a real rate of approximately 6000 Bd, better then 300 or 1200.
Even later when I overclocked the CPU to 1.5 MHz a line delay of 10 ms worked.(I had to adapt all the delay loops, a hardware timer would be better)
This year I tried again, but when activating HS the 6551 caused endless interrupt loops.
I use now a free VIA output for RTS and after each loaded line the RTS drops and when the whole interrupt loop is terminated
RTS raise again, some sort of HS. Now the line delay is not necessary but I discovered that not all terminal program work properly with HS.
It's improvisation, a 65550 or similar with FIFO and non blocking HS is the solution, but even more hard/soft ware to modify.
Curiously the Windows Hyperterminal is the most reliable.
-You are certainly seriously into the code structure there. Have you considered re-coding the whole system using the better parts of the existing code along with a proper system "tick" clock, separate "finite state" task threads and so on ?
Yes, I dived a bit in the code. But I'm not skilled enough, I was never a real programmer to write proper structured code, its more or less improvisation.
I write the hex code directly in the EPROM emulator.
A workmate who learned programming in college writes very structured programs, I wrote Linux scripts and he was somewhat loosed in my "chaos code",
I write programs like EMCO did., this is perhaps an advantage in this case. :-)
baud Rate : Yes - the data transfer rate is always lower than the bit rate. I don't like using character and newline delays because it is so inefficient and there is no "fine adjustment" - but it is the only simple option. Like you, I experimented with a hardware handshake based on the ISR duration - as the actual data handling code is so convoluted it is hard to find the best place to put it otherwise.
I use a "USB to the cabinet" method with a USB-serial module attached to the serial/video card and that can give some odd buffering effects too. Switching between 1200 and 9600 for downlink/uplink gives reasonable performance tho - esp as I mostly upload at this time - for recovery backups while making parts.
Code Structure: The benefit of some reasonable structure is not just that you get a 'better' solution but mostly that it takes a lot less time to debug and future changes are much easier - especially after a year or so has passed :-)
Creating new/modified system versions. : Wow, - if I understand that correctly - that's a lot of work producing them by direct machine coding. That is an impressive feat ! I have programmed small systems long ago in machine code and it's like "re-arranging a beach full of pebbles".
Have you considered creating a dis-assembly of the (a) whole original system, then using an assember. Once you had proved your dis-assembly is correct by assembling it back to an identical ROM image (only needed once for each original version), you would be able generate a new ROM code image in literally seconds ! - and it would be documented !
I have found a (Windows based) dis-assembly tool I like and used it for just the reverse engineering so far. But it will output an Assembly listing ready to (edit and) re-assemble. I've included an image showing part of the code in it - you may recognise it.
It has features for automatically generating labels and for then assisting the optional replacing of parameters and jump/subroutine targets etc with symbols to make the code more readable. Also a facility to add comments and notes ! It is also extendable with c# plug-ins so you can automate parts of the process if you wish.
You could make your modifications and then run it through your choice of Assembler - there are several on the Web.
Dieter ... again...
The pendant jog operation...
As you say, the jog via the DNC interface operates in the same manner as keypad arrows. So, we have -
a) single presses for stepping,
b) sequences of presses for slow traverse,
c) hold down for ( after a short pause ) traverse at the speed determined by the panel potentiometer.
d) (potentially) rapid traverse if (rapid) key is held down.
Therefore it is not possible (that I know) to get fully proportional axis movement speed with pulsewheel rotation via the DNC (or keypad) interface.
[Aside - it could be done by connecting the p-wheel output to/instead-of the MPU 555 timer. Then p-wheel rotation would be made to cause continuous movement and the rate of turn would control speed from 0 to max either via an analogue input to the 555 or directly triggering the 6821 interupt.]
As you will know - the p-wheel generates two 180-out-of-phase quadrature signals (A & B) and we use one (A) to simulate the button press - and the state of the B when A changes to determine the direction. The problem comes when the pulse rate hits the maximum the EMCO will accept as discrete pulses.
My simple solution was to use the A pulse to trigger a monostable ic which then provides a fixed length pulse to the EMCO - equivalent to an arrow press. By using a re-triggerable monostable, at a certain p-wheel rotation speed the monostable output becomes continuous. Then the axis moves a the speed set by the panel pot.
The monostable pulse width has to be a compromise -if too long then movement a) b) above is awkward - too short and the transition to c) is awkward. This is an ergonomic issue.
Also for ergonomic/convenience reasons, I found the axis movement direction in relation to p-wheel direction needs to sometimes vary according to what you are doing (!!!) - sometimes for just x or z and sometimes for both together (so 4 combinations). I made the direction sense selectable by a pushbutton near the p-wheel.
I used the pendant as a convenient place to put all the other function control buttons - CNC/Man, Start/Stop, Run/Hold, Alarm Clr, Load, Save, etc and also the system status LEDs.
I've only used a prototype pendant version so far till I get time to make a final one :-( Currently I use a cable to connect the pendant but I might switch the design to using a couple of "Arduino" ATmel329 microcontrollers connected via, say, Bluetooth for a 'wireless' version (and simpler hardware).
Whichever - I plan to use the same pendant hardware when I operate with upgraded CNC control as well as standard EMCO control - and also on my F1 mill with a modified interface to the MPU board (pad strip).
NB. This all operates using completely standard EMCO software and hardware.
I incude a pdf showing the schemes.
- Creating new/modified system versions. : Wow, - if I understand that correctly - that's a lot of work producing them by direct machine coding. That is an impressive feat !
- I have programmed small systems long ago in machine code and it's like "re-arranging a beach full of pebbles".
Do you say I'm crazy? :-)
- It has features for automatically generating labels and for then assisting the optional replacing of parameters and jump/subroutine targets etc with symbols to make the code more - readable. Also a facility to add comments and notes ! It is also extendable with c# plug-ins so you can automate parts of the process if you wish.
- You could make your modifications and then run it through your choice of Assembler - there are several on the Web.
Indeed, this would greatly simplify the coding. Can you give me the name/link of the disassembler please and your favorite assembler.
Saying the DNC works like the keyboard there is no excuse for not using the keyboard solution with 4066 and staying only on the MK4 :-)
If I'm correct the F1 DNC works similar as the C5 MK4 without jog I/O's.
Could you post the detailed sketch/schematic of "Pendant 1" please to avoid reinventing the wheel.
I have some more "wishes":
Replacing the 6502 NMOS by a 65C802 or 816 for accelerating the math routines and memory block move.
Constant surface speed for X-Axis by using a D/A converter and a IL300 Opto OP, no mods needed on the controller board except the pot wires,
I found already a free I/O address on the Video board.
Feed override, resetting G92 to the first origins with a new command and more...
I know its overkill, just for fun.
Many topics .. as usual .......
>>> Do you say I'm crazy? :-)
Maybe we are all crazy here with this obsolete equipment :-)
That's not what I meant to imply tho :-) I was referring to the scale, detail & and repetetive aspects of the task :-)
The tool I mentioned is here - https://6502bench.com/ There is, of course, a fair learning curve with it - which I haven't completed yet ! - so have not explored and understood all the features but I found it very helpful.
For simplicity I created a full 64kb initial binary around the ROM data to locate the RAM, ROM etc in the right places and went through parts of the code adding symbols, constants etc. and identifying some variable & function/addresses and so on.
As I was only really interested in (partial) reverse engineering I haven't completed the activity or re-assembled the result back to a working system. You have a big head start because you've explored and identified much (all ?) of the code and variables already.
Clearly it is only necessary to go through this process once (with a few iterations, that is) to generate a "readable / understandable" source file. If you do follow this up, I could give you a few pointers to using it - setting up initial symbol tables, code entry points, redefining operands etc. I'm sure you would soon pick it up anyway.
I only briefly looked at system re-building so can't comment on the "best" Assembler but this is the more straighforward task - so almost any 6800 symbolic assembler should do (ideally one that accepts "local" symbol scope) - you don't need "advanced" features such as macros, high level constructs and so on IMO.
>>> there is no excuse for not using the keyboard solution with 4066 and staying only on the MK4 :-)
Your point is very valid. The path to "where I am" involved incomplete knowledge and experience with the different systems. Only near the end did the various issues become clearer.
OTOH - I do like the idea of adding features (eg jog pendant) just by "plugging in" (to the DNC connector in this case.)
I'll put together some more info on that.
>>>> constant surface speed....
Not sure how that works - need a bit more info :-)
>>> Future plans..... Just a thought ..........
If you do something "serious" like changing CPU, have you considered a slightly different approach - using a more modern microcontroller package patched into the 6800 socket ?
I'm doing something similiar on another project and only recently started using Arduino stuff. I find these are very low cost , very quick to "get into", (<£15 and <30 mins to get up-and-running to the "Hello World" stage) widely supported and they work well.
All the flash ROM, RAM + some EEprom + communication ( up to ~2Mbaud !!! ) is in the 1 chip and they have ample i/o lines to manipulate the addr/data/ctl buses to talk to the 6821s and the 7Seg controller on the EMCO MPU board. The USB interface(s) can provide a "side door" into the target system during operation - as well as giving a way to have a full GUI on the PC with (eg) the MS .net/VS stuff..
You could either "interpret" the EMCO 6800 machine code at run time or - it wouldn't take too long to re-code the EMCO stuff in 'c' "line for line" (for a start). You'd have high level functions for, eg, the arithmetic pulse/unit conversion sections. Also, i/o pin & timer interupts are straightforward and you'd even have PWM / analogue / SPI / I2C / etc interfaces built in.
I've become quite a fan of them - as you can guess :-) They're fairly fast altho I'm moving from a "MEGA" to a "DUE" for more performance (32bit wide architecture at 78MHz vs 8bit at 12MHz)
OTOH, this would take you a little further away from the original EMCO concept of course. + yet another learning curve !
PS Do you have more information on your "slide oiling" scheme ?
- explored and identified much (all ?) of the code and variables already.
There is still a lot to do, we have several 100th of variables in the ZP and in page one
(a0100 - a01CC, stack is the rest, the deepest access found was a01E8, a distance of #$1B)
and the memory copy/move to display the CNC code and scrolling is not yet decoded.
I never touched the cassette routines, I simply disabled the commands. (I could adapt it for storage on SD card, even more programming instead of making swarf.) :-)
When I disassembled first years ago text and parameters where interpreted as code, so I needed to isolate them manually, by the way I found many "code corpses".
Are the data fields identified when disassembling with "6502bench"? The original locations must be untouched when assembling, they are spread over the ROM area.
There is even code inside a data field. Absolute no experience with assemblers for the moment, I'm "hardcore machine coder" :-)
The advantage when direct writing to the EPROM emulator is the fast testing of new code.
The constant surface speed is not yet implemented:
I want to use the X-axis value by sending it to an 8-bit D/A converter (I found the free decoded address aAFxx on the video board connector X51/C30 unused on the CPU side),
then an IL300 linear optocoupler provide the control voltage for the controller board instead of the potentiometer. (Unfortunately the controller has mains potential).
The pot must be switched of when using constant speed, this would need an a further output from the VIA to switch between manual or CPU control.
Here is the application note for IL300: https://www.vishay.com/docs/83708/appnote50.pdf
And in the "Files": Emco5cnc Original circuits, Retraced circuits for the spindle motor drive and speed readout.
Don't know if the added code has an impact on the stepper routine, have to try first with estimated NOP's before unnecessary building the hardware.
I will stay with the 65xxx, as you said "this would take me a little further away from the original EMCO concept of course. + yet another learning curve !"
I'm working on the oiling system, when finished I post the pictures.
>>> much more to explore..
It is a lot of time & effort ! I think you have sorted enough out to make a good start with eg 6502-Bench, as below, if you choose that route.
>>> Corpse code.
Some might be accessed via jump tables or self modifying code maybe. It looked to me like EMCO use a "constructed" call in RAM ??.
>>> 6502-Bench - code /data
A vital issue - and one reason I like this tool.
First - you can give code "entry" points - the four high vectors are an obvious start - in a "start up" symbol file along with other constants, addresses etc. and update it as you explore. It/you can also label the data fields (and corresponding operands) so the data/code is relocatable.
Second - very powerful :-) - it partially "executes" the code to follow all possible paths. Except self-mod code - which is less of a problem with ROM based code.
Third - if you find jump tables etc you can label the data as vectors for further entry points - and these paths are followed.
The tool is not a 1-pass "static" dis-assembly listing. It is fully interactive/iterative.
There is a video linked in the homepage - which I didn't bother viewing until yesterday :-(
( who reads instructions ???!! ) This gives a very useful, quick intro to basic techniques. I even learnt it has built in assembler(s) - and comparison of source to re-generated code.
>>> Constant cutting speed..
Ah yes, I am with-it now. That would be directly useful - and also partly re-usable after/with a CNC upgrade. Presumably a user would need to be able to indicate "offsets" to the spindle speed and "centre to tool" distance - but that is straighforward-ish. Yes, the link to the analogue HV speed control needs thought. Electronics is not my main thing so I would take advice/do more research on that. And yes, I'd def want an opto-coupler in the line.
It is tricky to know how far to go :-) My similar 6800/Arduino setup is because I don't have the original MPU hardware for that system - just the ROM-code.
I look forward to it. Are you including leadscrew lubrication ?
Next - Assembling stuff !
With "Corpse code" I mean really unused code. I found it spread every where , rest of subroutines and even assembler instructions!Some might be accessed via jump tables or self modifying code maybe. It looked to me like EMCO use a "constructed" call in RAM ??.Corpse code.
The constructed instruction, the routines calling it sets the z7B and z7C values.
SBR e007A instruction in RAM
used from SBR: e9517, e951D, e9588, e9594, e9658, e968D, eEC55, eEC85, eEC9F.
e007A z7A LDA ABS,X BD
e007B z7B Adr L
e007C z7C Adr H
e007D z7D RTS 60
Yes, the offsets from different tools must be calculated to give the real distance but all would be done automatically.Ah yes, I am with-it now. That would be directly useful - and also partly re-usable after/with a CNC upgrade. Presumably a user would need to be able to indicate "offsets" to the >spindle speed and "centre to tool" distance - but that is straighforward-ish. Yes, the link to the analogue HV speed control needs thought. Electronics is not my main thing so I >would take advice/do more research on that. And yes, I'd def want an opto-coupler in the line.Constant cutting speed..
Just the belt can not be changed by software. :-(.
We must use an optocoupler, otherwise we have a lot smoke. :-)
I have not started yet with the IL300, have to make some experiments first to understand the function, the application sheet shows some solutions.
First I wanted to use the D/A on the controller side but then it need 8 optocouplers for the 8 bits. The IL300 solution would be simpler,
it must just emulate the panel potentiometer with a range from 0 - 7.8 V.
It's tricky, all parts of the C5 are so small. I will try and when centralising is not possible I use a simple oiler or an knurled screw to oil regularly the X-leadscrew.OilerI look forward to it. Are you including leadscrew lubrication ?
The bed ways oil is claimed to be compatible with ball bearings.
For the Z-axis I never thought about, here access is simple to use the oil gun and spread oil over the whole length of the leadscrew.
>>> (I could adapt it for .... SD card, .... instead of making swarf.) :-)
Swarf ??? That would just dirty the machine :-)
I did consider adapting to a more convenient storage media but I concluded it is best to use a host PC. So, my next effort would be on faster transfer - more efficient serial or ... DMA ?!?
>>> belt can not be changed by software
Could make a V-belt "variator" with servo operated sliding pulley sheave(s) :-) :-)
>>> Corpse code
Using 6502Bench on my C5 ROM code set - there seems to be very little unused code and almost no inline data. The only significant data blocks are at the end just before the message tables. Includes what appears to be 7 segment encoding information. I haven't made sense of the RAM subroutine yet :-(
>>> "hardcore machine coder"
I really wouldn't want to stop you :-) :-) but - assembler is just "more readable" machine code + labels & symbols to automate some of the detail. Not sure what to use for EMCO work - maybe https://sourceforge.net/projects/acme-crossass/ - but I have just downloaded a PC GUI based IDE Asm for 6800. It's v simple - no frills - can learn everything about it in 5 mins. Even for ~10 line patches it saves a lot of time :-)
To experiment for 6502 - you don't need to download one. Try this - https://www.masswerk.at/6502/assembler.html
I include a screenshot of a few lines of ~EMCO code I put in to try. ok for patches but too simple for serious use. Need something a little bit more capable - and more "standard".
A 'c' IDE with a modern microcontroller is so much more effective for new projects tho IMO :-))
>>> ... fast testing of new code ...
Once you have generated a workable source file, the mod / re-assemble / program cycle could be under 30 seconds. A lot less pebbles to re-arrange :-)
(Thinking aloud again) With a little hardware, could download to eeprom "in-circuit". Or ... "go mad" and use cpu "Halt" line to do it "live". Or ... create a small bootloader ROM to load a new code set on RST (or NMI)(from SDcard ??? ... or 2Mbaud USB<>serial module or ...).
I may try that using my "memory re-map daughterboard" when I get back to the EMCO stuff. I have 512kb(+) of EEPROM/RAM/... storage to play with :-)
Thanks for the links, have to try and change my habits.
Is 9600 Bd not fast enough for max 210 lines of code? With 20 ms of line delay it takes ~60 s to load 990 lines, ~13 for 210.
But it needs several % characters to start reliably. Sending to the PC takes ~50 s for 990 lines.
I'm happy now with the HW flow control for loading, sending to PC works fine without flow control so I made no modification.
I thought also about a variomatic and have a blueprint somewhere in the infinite heap of magazines. :-)
Only from curiosity. Did you ever use the old EMCO cad DOS program?
>> change habits...
Not necessarily ! Worth a look I think, but whatever suits your activity/ methods best :-)
>> Is 9600 Bd not fast enough...... ***
I find computer stuff has 2 (perceived) speeds ....... "Instant" and "too slow" !
9600 baud used to my "goto" bit rate - but I've now been spoilt by the USB<>serial devices :-(
In practice - xfer speed will be ok if I adopt your hardware handshake around the ISR for download :-)
>> EMCO CAD DOS.
I have it on an old PC which came with my F1 - complete with a dongle. I had a quick look but not had a chance to explore it more.
***Just for comparison, my first ever code development cycle was......
- remove EPROM
- m/cycle 1/2 mile to mainframe
- edit, simulate, assemble (i8080) using 110 baud teletype or when free, the 1200 baud VDU :-)
- find/borrow/steal the paper tape punch
- punch tape @75/110baud
- m/cycle 1/2 mile to eraser
- find/borrow/steal the programmer
- program from tape @300 baud
- walk ~300m (+8 flights of stairs) to industrial robot retrofit
- plug in EPROM
- add init code .. in binary using switches & leds
- press 'run'
- work out why nothing good happened
....altho it did once throw a 25l oil drum (empty) at my supervisor :-]
Success in the end ! Great days !
I tried on the test CPU with an 65C816 without an 74 245 transceiver simply by connecting phi2 with BE.
It works with real EPROM's but not with the EPROM emulator.
I will try with the transceiver but first finish the "oil splashing device".