cross-32 meta-assembler

Yes, with Assembler PreProcessor (APP), we can linkin Motorola language with C or other HLLs. I believe i can recreate the APP we were using decades ago. Just by adding '%' to A & D registers and removing L from LCLR/LTST/LSET, we get half of the instructions working. Next step is to double pass it to process macros, and dealing with Address registers. GCC does not use much of the Address registers; so, we have to pre-assemble them directly.

__13_________________RTEMP:_MOVEM.L_%D1_D4_D5_D7_%A0,_-(SP)_ __15________________________MOVEA.W_#_PORTD,_A0_ __16_????_323C_0002_________MOVE.W_#_2,_%D1_ __17______0390______________CLR.B_%D1,_(%A0)_ __19________________________CLR.B_#_5,_(%A0)_ __21_????_4284______________CLR.L_%D4_ __22_????_3E3C_000D_________MOVE.W_#_14-1,_%D7_ __24_????_1A10_______LMOP:__MOVE.B_(%A0),_%D5_ __25_????_E20D______________LSR.B_#_1,_%D5_ __26_????_E354______________ROXL.W_#_1,_%D4_ __28________________________SET.B_%D1,_(%A0)_ __29______0390______________CLR.B_%D1,_(%A0)_ __31________________________DBF_D7,_LMOP_ __33______08D0 0005_________SET.B_#_5,_(%A0)_ __35________________________TST.L_#_13,_%D4_ __36_????_6704______________BEQ.S_TSCAT_ __37_????_0044_0000_________ORI.W_#_B15+B14,_%D4_ __39_????_31C4_0000__TSCAT:_MOVE.W_%D4,_TEMPR.W_ __43________________________K10_=_20480_ __45_????_C9FC_5000_________MULS.W_#_K10,_%D4_ __46_????_4844______________SWAP.W_%D4_ __47_????_31C4_0000_________MOVE.W_%D4,_TEMPC.W_ __49________________________MOVEM.L_(SP)+,_%D1_D4_D5_D7_%A0_ __50_????_4E75______________RTS_

PS: CLR/SET are hand decoded values. Comments are removed to pass GCC

Good luck on getting to work on Windows 7.

Hul

snipped-for-privacy@highlandsniptechnology.com wrote:

If I went to the extreme of a new tool set, I'd have to run my rom compare program to make sure every byte was the same. That's a lot of work to change a half-page subroutine.

My tool chain makes a DEC-style listing, with a table of contents, page subtitles, and a nice symbol table. All that works fine. I have a rom builder too, that gobbles .s28 files from the assembler and .raw files from the FPGA compiler and pokes checksums and stuff.

Our new stuff is all ARMs and c, which other people do, but we have legacy products that annoying customers keep buying. Sometimes we have to make a change, mostly from parts going EOL.

Nice lady. I like skinny women.

Thanks, but I can't find that on my Win7pro.

I've tried all the options in the program properties/run as old code things, but it still won't run.

I guess I could buy a few more old XP netbooks and keep them in a freezer.

For that little you might just patch the code - just redirect the subroutine call to some place new, you must have that much unused ROM space. Thus your old code will remain unchanged at all, you will have to worry about the new half page only, can't imagine it would take you more than a day or two of iterations even with code that old. If you have no assembler at all to do the half page I could help, me running it on my dps machine or figuring out a way so you can do that over the net etc.

Dimiter

====================================================== Dimiter Popoff, TGI

It all runs on the old XP netbook. I'd just like to run it on my Win7 PCs.

It's tragic that IBM picked Intel instead of Motorola for their PC. The 68K had proper memory management and there was a RISC version, Coldfire.

Oh so you have no real problem. Just get a spare xp machine etc. I did run some xp emulation on windows 10, vmware, and it worked - for a while, then at some point - probably a few updates down the line - stopped doing what I used it for (non-critical, for me the windows machines are just browsers/pdf readers, well I do use ltspice occasionally not having my own equivalent). Might be worth a try, it ran OK while it did and I am not sure I was not at fault for it to stop.

I still have in my arsenal the mcf52211 coldfire, a very useful part. Did a few things with it. The only advantage ARM have nowadays is lower power, I have yet to adapt an assembler for some of them (just the smallest, the rest (1W+) is power (PPC), thankfully still alive.

I remember Peter Alfke saying IBM chose Intel just because they had it earlier than Motorola had the 68k, about a year (he was telling the story how he tried to sell the Z8000 to Jobs IIRC, being that close to all this makes him a credible source, apart from him being the guy we remember who knew what he was talking about.

Dimiter

An XP virtual machine sounds like the answer. I use VirtualBox to run some old FPGA tools under XP, works fine including USB access for JTAG etc.

Not sure how it would cope with older programming hardware that bit-bangs the lines of a parallel port, I haven't tried that.

The XP virtual machine doesn't have any network access, for obvious reasons. The FPGA toolchain will run on slightly newer versions of Windows but I chose XP (with SP3) because it will install on a non- networked machine and not nag you about activation.

If you have the old 68332 development machine, or an image of its HDD, hanging around anywhere, there is a tool from VirtualBox that will import it for you, which saves re-installing everything.

HTH

Peter was great, I miss him. I met him when both our heads were inside a box full of books at the Foothill Electronic Flea Market. I miss that too.

One story I heard was that IBM thought they could control little Intel better than big Motorola. And little Microsoft!

You don't have to change the source code, but do need to verify the translator output.

I am almost done with translating your subroutine. But not sure about decoding the BCLR/BTST/BSET bit fields. Should it be actual number 5 (0005) or bit position 5 (0020). I.e. second arg of line 38.

__26_______________ _#_RTEMP:_MOVEM.L_D1_D4_D5_D7_A0,_-(SP)_;_SAVE_GOODIES __28_______________ _#_ __30_????_307C_0000__#_MOVEA.W_#_PORTD,_A0_;_NAVIGATE_TO_PORT,_MATEY __32_????_323C_0002__#_MOVE.W_#_2,_D1_;_NAME_THE_SPI_CLOCK_BIT __34_????_0390_______#_BCLR.B_D1,_(A0)_;_AND_MAKE_SURE_CLOCK_LINE_IS_LOW. __36_______________ _#_ __38_????_0880_0005__#_BCLR.B_#_5,_(A0)_;_CHIP_SELECT_THE_NASTY_LITTLE_BEAST __40_______________ _#_ __42_????_4284_______#_CLR.L_D4_;_NUKE_FUTURE_DATA __44_????_3E3C_000D__#_MOVE.W_#_14-1,_D7_;_NEED_A_BIT_COUNTER,_TOO __46_______________ _#_ __48_????_1A10_______#_LMOP:_MOVE.B_(A0),_D5_;_READ_THE_PORT_AND_SHIFT_RIGHT_1_BIT __50_????_E20D_______#_LSR.B_#_1,_D5_;_WHICH_PUTS_SERIAL_DATA_INTO_X-BIT __52_????_E354_______#_ROXL.W_#_1,_D4_;_SHIFT_THAT_INTO_DATA_REG __54_______________ _#_ __56_????_03D0_______#_BSET.B_D1,_(A0)_;_PUMP_CLOCK_UP __58_????_0390_______#_BCLR.B_D1,_(A0)_;_AND_DOWN. __60_______________ _#_ __62_????_51CF_FFF4__#_DBF_D7,_LMOP_;_-_DO_14_BITS_- __64_______________ _#_ __66_????_08D0_0005__#_BSET.B_#_5,_(A0)_;_CHIP_DESELECT __68_______________ _#_ __70_______________ _#_BTST.L_#_13,_D4_;_WAS_SIGN_BIT_SET? __72_????_6704_______#_BEQ.S_TSCAT_;_NO,_GO_SCALE __74_????_0044_0000__#_ORI.W_#_B15+B14,_D4_;_YES,_SIGN_EXTEND __76_______________ _#_ __78_????_31C4_0000__#_TSCAT:_MOVE.W_D4,_TEMPR.W_;_SAVE_RAW_DEGC_*_32 __80_______________ _#_ __82_______________ _#_;_NOW_FRACTIONAL_MULTIPLY_D4_BY_10/32_TO_GET_DEGS_C_*_10 __84_______________ _#_ __86_______________ _#_K10_=_20480_;_10/32,_AS_A_FRACTIONAL __88_______________ _#_ __90_????_C9FC_5000__#_MULS.W_#_K10,_D4_;_DO_MULT

It is the actual number, 5 in your example, not $20.

OK, thanks.

Almost done. Just need to handle the stack push/pop opcodes.

These are the movem.l or movem.w opcodes, they are not just limited to push/pull. Can be used with mutiple addressing mode, using with a7 predecrement/postincrement is typically used for push/pull. The expect a list of register or register ranges, like: movem.l d1-d7,-(a7) pushes d1, d2, ... d7, movem.l d1-d3,d5,a0,a3-a5,-(a7) etc., all valid variations.

OK, here is the complete translation/assembly. Yes, i cheated by editing the Push/Pop Save/Unsave Goodies. It's just easier and look better with the output.

___4_______________ _#_.SBTTL_._RTEMP_:_READ_THE_LM71_TEMP_SENSOR ___6_______________ _#_ ___8_______________ _#_;_WE_READ_14_BITS_FROM_THE_LM71,_INTO_D4_13:0,_AND_SIGN-EXTEND __10_______________ _#_;_BIT_13_INTO_15:14._THE_RESULT_IS_A_2'S_COMP_TEMPERATURE_IN __12_______________ _#_;_DEGREES_C_*_32,_WHICH_WE_THEN_SCALE_TO_DEGC_*_10 __14_______________ _#_ __16_______________ _#_;_PORT_D_BITS_ARE_B5_LM71_CS-_PIN_70_RUNTIME_=_53_USEC __18_______________ _#_;_B2_SCLOCK_PIN_67 __20_______________ _#_;_B0_SDIN_PIN_65 __22_______________ _#_ __24_______________ _#_ __26_______________ _#_RTEMP:_;_MOVEM.L_D1_D4_D5_D7_A0,_-(SP)_;_SAVE_GOODIES __28_????_48E7_4000__#_MOVEM.L_D1,_-(%SP) __30_????_48E7_0800__#_MOVEM.L_D4,_-(%SP) __32_????_48E7_0400__#_MOVEM.L_D5,_-(%SP) __34_????_48E7_0100__#_MOVEM.L_D7,_-(%SP) __36_????_48E7_0080__#_MOVEM.L_A0,_-(%SP) __38_______________ _#_ __40_????_307C_0000__#_MOVEA.W_#_PORTD,_A0_;_NAVIGATE_TO_PORT,_MATEY __42_????_323C_0002__#_MOVE.W_#_2,_D1_;_NAME_THE_SPI_CLOCK_BIT __44_????_0390_______#_BCLR.B_D1,_(A0)_;_AND_MAKE_SURE_CLOCK_LINE_IS_LOW. __46_______________ _#_ __48_????_0880_0005__#_BCLR.B_#_5,_(A0)_;_CHIP_SELECT_THE_NASTY_LITTLE_BEAST __50_______________ _#_ __52_????_4284_______#_CLR.L_D4_;_NUKE_FUTURE_DATA __54_????_3E3C_000D__#_MOVE.W_#_14-1,_D7_;_NEED_A_BIT_COUNTER,_TOO __56_______________ _#_ __58_????_1A10_______#_LMOP:_MOVE.B_(A0),_D5_;_READ_THE_PORT_AND_SHIFT_RIGHT_1_BIT __60_????_E20D_______#_LSR.B_#_1,_D5_;_WHICH_PUTS_SERIAL_DATA_INTO_X-BIT __62_????_E354_______#_ROXL.W_#_1,_D4_;_SHIFT_THAT_INTO_DATA_REG __64_______________ _#_ __66_????_03D0_______#_BSET.B_D1,_(A0)_;_PUMP_CLOCK_UP __68_????_0390_______#_BCLR.B_D1,_(A0)_;_AND_DOWN. __70_______________ _#_ __72_????_51CF_FFF4__#_DBF_D7,_LMOP_;_-_DO_14_BITS_- __74_______________ _#_ __76_????_08D0_0005__#_BSET.B_#_5,_(A0)_;_CHIP_DESELECT __78_______________ _#_ __80_????_0804_000D__#_BTST.L_#_13,_D4_;_WAS_SIGN_BIT_SET? __82_????_6704_______#_BEQ.S_TSCAT_;_NO,_GO_SCALE __84_????_0044_0000__#_ORI.W_#_B15+B14,_D4_;_YES,_SIGN_EXTEND __86_______________ _#_ __88_????_31C4_0000__#_TSCAT:_MOVE.W_D4,_TEMPR.W_;_SAVE_RAW_DEGC_*_32 __90_______________ _#_ __92_______________ _#_;_NOW_FRACTIONAL_MULTIPLY_D4_BY_10/32_TO_GET_DEGS_C_*_10 __94_______________ _#_ __96_______________ _#_K10_=_20480_;_10/32,_AS_A_FRACTIONAL __98_______________ _#_ _100_????_C9FC_5000__#_MULS.W_#_K10,_D4_;_DO_MULT _102_????_4844_______#_SWAP.W_D4_;_AND_MAKE_THAT_FRACTIONAL _104_????_31C4_0000__#_MOVE.W_D4,_TEMPC.W_;_AND_STASH_IN_RAM _106_______________ _#_ _108_______________ _#_;_MOVEM.L_(SP)+,_D1_D4_D5_D7_A0_;_UNSAVE_GOODIES _110_????_4CF9_0100__#_MOVEM.L_(SP)+,_A0 _112_????_4CF9_0080__#_MOVEM.L_(SP)+,_D7 _114_????_4CF9_0020__#_MOVEM.L_(SP)+,_D5 _116_????_4CF9_0010__#_MOVEM.L_(SP)+,_D4 _118_????_4CF9_0002__#_MOVEM.L_(SP)+,_D1 _120_????_4E75_______#_RTS_

Can you post the script which does this? I am not a gcc user but I have done things of that sort, like doing the entire HC11 assembler using macros in my a32 (some 20+ years ago I suppose), some other more obscure stuff (SDMA opcodes for the 5200 SDMA) etc., would be curious to look at what yours looks like. BTW the order by which you push/pull is reversed to the order the 68k does. Although your push and pull are consistent with each other if there are accesses to the stacked registers.... :-). The pull order is d0 first, d7 last, then a0, a1 etc., IOW if you push all registers you will have d0 at the lowest address and a6 at the highest (presumably you don't push a7 itself, not impossible BTW). Oh here, I have uploaded the hc11 macros some time ago:

Dimiter

I believe the M68K assembler parse them out in the manner i indicated. Left to Right for -(SP) and Right to Left for (SP)+. Even if it's reversed, it should be OK as well.

The rest is done by the following main loop.

main() { char *cp, s1[10], s2[10], s3[10], buf[100], buf2[100]; int i;

while(fgets(buf, 100, stdin) > 0) { strcpy(buf2, buf); del_eoln(buf, ';');

cp = strchr(buf, '#'); if(cp && *(cp+1) == ' ') del_char(cp+1);

s1[0] = 0; s2[0] = 0; s3[0] = 0; sscanf(buf, "%s %s %s", s1, s2, s3);

cp = strchr(buf, 'B'); if(cp) { if(!strncmp(cp, "BCLR", 4) || !strncmp(cp, "BSET", 4) || !strncmp(cp, "BTST", 4) ) del_char(cp); }

ins_percent(buf, 'D'); ins_percent(buf, 'A'); ins_percent(buf, 'S');

fputs("# ", stdout); fputs(buf2, stdout); if(match(s1, "BCLR.B", s2, "D1,", s3, "(A0)")) fputs(".word 0x0390\n", stdout); else if(match(s1, "BSET.B", s2, "D1,", s3, "(A0)")) fputs(".word 0x03D0\n", stdout); else if(match(s1, "BCLR.B", s2, "#5,", s3, "(A0)")) fputs(".word 0x0880, 0x0005\n", stdout); else if(match(s1, "BSET.B", s2, "#5,", s3, "(A0)")) fputs(".word 0x08D0, 0x0005\n", stdout); else if(match(s1, "BTST.L", s2, "#13,", s3, "D4")) fputs(".word 0x0804, 0x000D\n", stdout); else fputs(buf, stdout); } }

This is probably the easiest/best soln...

box is *really* handy.....be sure to install the guest additions....

How won't it run? BSOD or some other error message.

Depending on the vintage of old software it may be dependent on some prehistoric DOS settings like environment variables and/or want to open its .ini file with read/write privileges (Win7 won't allow this).

You may have to mess about giving the program (which I assume you trust) higher level privileges to get it to run. I'd recommend moving the code to a new directory and allowing it naughty read/write access there.

Simplest approach is create a DOS window with maximum possible privileges and invoke the errant programme manually from there on the command line. With any luck you will actually get to see something more about why it actually refuses to run - maybe enough to fix it.

"Path not found" would be my first guess.

For software a virtual machine running an old license of XP is usually good enough. You only need real physical hardware for things that do bitbanging on parallel ports to drive ancient chip programmers. I harvest software license keys from physical hardware before I scrap it.

I still have physical hardware around back to Win ME. Quite a lot of my clients are stuck on Win XP since big scientific instruments have a 25 year lifespan and manufacturers CBA to do drivers for newer OS's. They would much prefer to sell more (very) expensive new improved hardware.

OS/2 based stuff is now reaching end of life. Great OS - shame about IBM's piss poor marketing conflating it with the crap PS/2 hardware.

Windows7 pops up a box and tells me that I should buy a later version of the program, which is what I'm trying to do.