Monday, December 8, 2014

Sozobon's JAS runs at CP/M 68K

As I expected, JAS from Sozobon C compiler for Atari was easy to port back to CP/M 68 and it works natively.
To do it, do the following: compile Sozobon C on unix host (see (or mirrored on my site), then compile jas by xhcc, now using makefile , not make.unx.
First, make a small patch in main.c:
        if ( freopb( ofile, "w", stdout ) ==  NULL )
                error( 0, "can't open object file for writing" );
      if ( freopen( ofile, "bw", stdout ) == (FILE *) NULL )
             error( 0, "can't open object file for writing" );

Then take CP/M-68 1.3 distribution files; here you'll find DISK4 and header files on it. You have to convert them to lowercase and erase all symbols after (and including) ^Z.
Then edit makefile to became smth like that:
CC = ./xhcc
CFLAGS = -c -v -O -I/home/dtz/8BIT/68K/CPM1.3/DISK4
Run make, you'll get 10 *.s files; then assemble them by jas:
foreach f [glob *.s] {
 exec ./xjas -8 $f
You'll get 10 .o files. Transfer them to CP/M 68K host and link by DRI's LO68: c:lo68 -R -u_nofloat -o jas.68k c:s.o CBUF.O CPY.O GEN.O HDR.O LEX.O MAIN.O OPS.O OPT.O PARSE.O PASS.O SCAN.O SYM.O c:clib And know what? It works! (do not forget to add -8 switch when calling jas). However, that's not very useful as assembler, but better to have an assembler with SOURCE as alternative to AS68.
Get it from here ;-) [ok from here]


  1. Wow, that's pretty cool! Have you tried to cross compile and transfer over the rest of sozobon to CPM/68k? I'd also love to see why JAS has issues with more than 32kb of code (another size constraint?) or why on earth sozobon has 16 bit ints, instead of 32bit..

    1. Jason, later I found Matter Brandt's compiler, and it is much better then Sozobon. Be sure to finding the latest version of his site, the code is arounbd 1999/2000. So I gave up playing with Sozobon, at least currently.

      As for 16 bit.... Oh, the problem is that CP/M-68 is 16 bit system! Really! The int is 16 bit! So most the CP/M calls! And that leds to malloc() limits!
      That really bores me! From all the other points, CP/M 68 is a very good, balanced system designed with Unix in mind, but 16 bit for most the calls is really dread!

      I suppose that libc can be patched and malloc32 could be added, but I've not tried yet - I'm builing an 68EC000 computer with 16 bit bus, so currently I'm mostly busy with soldering.

      How did you get into CP/M 68K world? Tell me something about your's researches ;-)

    2. See on Mattew Brands compiler notices.
      Well, it works on unix host, not exactly what you want. I run it on Solaris10/Sparc even (and on Mac OS X 10.4, if I remember that properly)

    3. Wow so much to go on. I mostly played with sozobon to attempt to get something to work on a sega genesis (I really should have gotten a flash cart to see if it even ran on real hardware).

      I was messing with system 16 0.53 a few days ago, I found the source, and was playing with it, and got a very corrupt version of altered beast to run, although Im not sure if it's GCC 4's fault or mine. I was then thinking of a C compiler that could make ROM'able code that wouldn't be a big deal to fight with... which led me back to Sozobon, and I just tried to see if I could make the stock version run on an emulator, which in a round about search led me here. And it was kind of funny how you'd fished out the source to JAS from my search page. Talk about crazy!

      I've not messed much with CP/M 68k, only in emulators, and ones that I see that you've found. I should have guessed it was 16bit, a 32bit OS would be too advanced I guess for the mindset of the time, as most people put the 68000 as a 16bit processor, and the 68008 as an 8bit CPU, completely disregarding it's native word length of 32bits.

      Sozobon has a 32bit long type.. from the doc:

      int 2
      long 4

      so I would imagine it should be possible to 'hack' the internal representation of an int into a long.

      Now that MAME is mostly free, and perhaps ripping the 68000 emulation out of WinUAE (much like how Pervious the NeXT emulator does) to cobble something up.

      OK I guess I'm rambling..

      Of course, GCC is still a possiblity.

    4. What's System 16 0.53?

      Do you know Vincent Rivière's m68k-atari-mint cross-tools?

      Yes, most of comilers for 68k can work with long as 4 byte values. The problem that designers of CP/M-68 decided that 16 bit is enough for everyone. That was really very simple to make mostly 32 bit calls on 32 bit CPU (even on 68008, who cares), but they were still living in 8 bit world and 64K.

      You can recompile whole the CP/M from the source to be 32 bit, but it will brake compatibility for all the applications.

  2. Oh yeah, not exactly anything sane, but I did hack up an infocom parser to run on a cisco router (PowerPC one, I haven't tried an actual MIPS one, but it crashes in emulation)

    It doesn't need much of anything, the 'disk io' is 100% fake, just an object loaded into the image, although I guess I'm dependant on how binutils does it, so I get a start pointer, size, and end so I can fake that out, although I guess I could do it any which other way.

    But it'd be cool to see run on a 68000. Even if emulated. Although looking how you transported over JAS I suppose InfoTaskForce ought to be portable.