POLY-88 emulator now available (Intel 8080 based system from 1976)

[Istarian]

@Istarian

I think I was never able to make it compile - I know I did try compiling it on a C compiler on an IBM-370, as I have some fragments of line printer listings from that. But it isn't clear to me I was ever able to run it. My memory around this is not great because my hobby interest in C moved quickly from Tiny-C to Small-C (CPM/80 product), to real C on an Apollo workstation (Unix like 68020) not long after that.

If I get my Bigboard CPM/80 machine going, I might find that I got tiny-c running on that. Although I'm not sure why I would have done that.

If the DDJ archive copy looks complete - that's surely the right place to start.

I was able (with a lot of effort) to correct a number of typos and get it to compile, but it isn't producing sensible results and my understanding of the expected syntax is not the best. I could try starting over and typing in the code directly from the article, but the interchangeable use of char and int is problematic to say the least.

void doif() {
    int flev;
    int fsp;
    int flab1;
    int flab2;
  
    flev=locptr;
  
    fsp=sp;
  
    flab1=getlabel();
  
    test(flab1);
  
    statement();
  
    sp=modstk(fsp);
  
    locptr=flev;
  
    if (amatch("else",4)==0) {
        printlabel(flab1);col();nl();
        return;
    }
  
    jump(flab2=getlabel());
  
    printlabel(flab1);
    col();
    nl();
  
    statement();
  
    sp=modstk(fsp);
  
    locptr=flev;
  
    printlabel(flab2);
    col();
    nl();
}

Notice that 'flev' (an integer) and 'locptr' (a char *) are traded back and forth here... I believe char is still an 8-bit value in most cases, but int can be 16-bit, 32-bit, or even 64-bit depending on what you compile this with.

I wasn't really expect it to produce a valid executable or anything, especially since I'm not pulling in runtime libraries, but I can't even get it to spit out assembly mnemonics..

I think this just might be a dead end for the moment.

 

[voidstar78]

Tonight (EST US Midwest), I'll see if I can try both the python script you have and my C++ code to generate a WAV file for, say, LIFE.CAS. The only thing I can do here is to use the program sox to generate a spectrum analysis - that might tell us something about what is going on.

Oh!! I can use your CAS->WAV converter and see if my tape recovery code can recover it - that'll tell me something too.

Which emulator are you using, out of curiosity?

The Bob Bylee emulator (of the original post).

EDIT: Also, the B(BYTE)/P(POLYPHASE) switch is working on my hardware. And indeed, I have to alternate Phase between different tapes. I'm going to refer to Phase A as when the phase jumper is towards the rear of the box (towards the PSU) and Phase B as when that phase jumper is more towards the front of the system. It is absolutely faster, I can see why "once you PolyPhase, you never go back to Byte-mode" I'm not sure if it's 2400 or 4800 baud, but the 256 load segments scream across the screen. I got BASIC A00 loaded via PolyPhase, now to explore what else might still be loadable from these not-loaded-in-35-years audio tapes.

 

[powool]

@voidstar78 wow that is awesome! I think I read you were using the original cassette tape deck (superscope?), too. I don't have the one we used - I don't know what happened to it. So far, my stereo tape deck has done ok reading them, but it might explain some of the problems I've had.

Yeah - Polyphase is a single bit per clock cycle, so 2400bps instead of 300. There's a lot less redundancy in the signal, however.

I am not sure how common it was to run 4800bps. I believe we had to do a bunch of fussing around to make it work reliably.

 

[Istarian]

I realize this is tangential at best, but I think I've finally gotten somewhere with that compiler even though I'm still getting some errors.

The results (see below) still make it seem like the C code is not getting translated properly, especially with regard to where it puts 'PUSH H'. But it's still a lot more complete than what I had been getting before.

I'm not sure if it's a quirk of the compiler, a bug in my code, or a very simple attempt to optimize but it doesn't seem to like plain variable = value assignments.

I started typing up the original, but boy does that get tedious quickly.

INPUT:

int a;
int x;
int y;
int z;

dostuff(){
    x=3;
    y=4;
    z=5;
    a=x*y*z;
}

OUTPUT:

dostuff:
    LXI    H,3
    LXI    H,4
    LXI    H,5
    PUSH    H
    PUSH    H
    POP    D
    CALL    ccmult
    POP    D
    CALL    ccmult
    RET
a:    DS    2
x:    DS    2
y:    DS    2
z:    DS    2

 

[Istarian]

I tested the assembly code by pasting it into an online i8080 simulator that assembles and then runs the program.

To properly run the code, it was necessary to do the following:

- add an instruction to load the stack pointer (SP)
- change DS to DW (or omit those lines)
- move the 'PUSH H' lines so that the values 3, 4 are pushed onto the stack
- copy the 'ccmult' routine from DDJ #48 and place it below this code

 

[Dwight Elvey]

I don't know if I mentioned this is that the Tiny Basic is available for the Poly88. It fits on the two empty ROM socket. It may not have every instruction you'd like but it is relatively easily expanded. It has been some time since I fiddle with it but I recall I wrote a PEEK and POKE that can be loaded into RAM, from tape, that made it easier to do all kinds of things. I have a StarTrek as well.
I'm about retire and will have more time to fiddle to such things I'll dig it up.

 

[voidstar78]

I had some hardware issues with the POLY-88, but it is back in action.

Was there someone here who had a script to convert a raw .BIN Machine Code POLY-88 program into a PolyPhase WAV? From original tapes, I've verified I can load PolyPhase format. But I've not yet loaded PolyPhase via a WAV file.

I can do .CAS to .WAV for BYTE format, but not yet PolyPhase format (which has two phase options).