Simulating an 8080. Is there a better way to do this?

[BillG]

From what I can tell, the KIX compiler generates 6502 assembly language code, not a P-code. The run-time library code resides in a separate file unless the user bought the library source code to integrate it.

It, at least the Atari version, has been released into the public domain, so I will have to look into that. There was an effort on AtariAge to collect all files and manuals, but I do not think they have everything yet.

Speaking of P-code, there are versions of Lucidata Pascal for the 6800 and 6809. It does compile into a P-code (not compatible with the UCSD P-System) and requires an interpreter to run. The compiler itself is also in P-code so that if a compatible interpreter is implemented for another processor, the compiler comes along for the ride. I have begun to reverse engineer its interpreter, but have not gotten very far. It has also been released into the public domain, unlike the P-System.

[teamtempest]

There's also the P5 Pascal compiler: http://www.standardpascaline.org/p5.html

[BillG]

teamtempest wrote:

There's also the P5 Pascal compiler: http://www.standardpascaline.org/p5.html

Very interesting. That is very recent.

[IamRob]

I don't know where I read or why I thought KIX compiled to P-code, but I may have got confused what I was working on.

I am working on Tiny Pascal which is on disk for the Apple II, but the code is hard to follow as it seems to jump to a bunch of short routines that do nothing, but yet it seems to display results. It only gets to the menu and selecting any item either hangs or exits to the prompt. It seems to be in P-code as the code is in part 6502 assembly and part random bytes. But honestly, I wouldn't know P-code if I saw it.

[BillG]

I am happy to be able to report that the prototype for converting the Z80 code produced by the CP/M Turbo Pascal compiler to 8080 code is going well. So far, no Z80 instructions have been encountered. Unfortunately, the same cannot be said for the subroutine library; it makes extensive use of the index and alternate registers as well as instructions like subtract with carry of register pairs.

The original Pascal code:

Code: Select all

  procedure Greet;

    begin
      writeln('Hello world.')
    end;  { Greet }

  begin
    Greet
  end.

The Z80 code generated by the compiler:

Code: Select all

0100 C3E320      jp      20E3
Command? u20e3l23
20E3 310001      ld      SP,0100
20E6 21C2EC      ld      HL,ECC2
20E9 0100FF      ld      BC,FF00
20EC CD6503      call    0365
20EF 212021      ld      HL,2120
20F2 11D0EA      ld      DE,EAD0
20F5 0142ED      ld      BC,ED42
20F8 3E01        ld      A,01
20FA CDD504      call    04D5
20FD C31A21      jp      211A
2100 CD9C14      call    149C
2103 CDBB17      call    17BB
Command? d2106ld
2100                    0C 48-65 6C 6C 6F 20 77 6F 72  '      .Hello wor'
2110  6C 64 2E                                         'ld.             '
Command? u2113
2113 CDCE17      call    17CE
2116 CD1C20      call    201C
2119 C9          ret
211A CD0021      call    2100
211D C3D520      jp      20D5

The 8080 code generated by the recompiler:

Code: Select all

        org     100h

        jmp     L_20E3

        org     20E3h

L_20E3:
        lxi     SP,0100h
        lxi     H,0ECC2h
        lxi     B,0FF00h
        call    R_0365
        lxi     H,2120h
        lxi     D,0EAD0h
        lxi     B,0ED42h
        mvi     A,01h
        call    R_04D5
        jmp     L_211A
L_2100:
        call    R_149C
        call    R_17BB
        db      12,'Hello world.'
        call    R_17CE
        call    R_201C
        ret
L_211A:
        call    L_2100
        jmp     R_20D5

        end     100h

[BillG]

It turns out that the line

Code: Select all

20EF 211921      ld      HL,2119

actually points HL just past the last instruction in the program, I am guessing to initialize the heap, so the generated code is now this:

Code: Select all

        org     100h

        jmp     L_20E3

        org     20E3h

L_20E3:
        lxi     SP,0100h
        lxi     H,0ECC2h
        lxi     B,0FF00h
        call    R_0365
        lxi     H,L_End
        lxi     D,0EAD8h
        lxi     B,0ED42h
        mvi     A,01h
        call    R_04D5
        call    R_149C
        call    R_17BB
        db      12,'Hello world.'
        call    R_17CE
        call    R_201C
        jmp     R_20D5
L_End:

        end     100h

[BillG]

I hit a wall getting ED, the CP/M text editor to even start up.

The problem turned out that the copy I had been using was missing a byte around the middle of the image. The tip off was that many of the jumps to the second half were obviously into the middle of instructions.

There are still a number of issues around fundamental differences between the FLEX and CP/M file systems remaining to be worked out.

With the experience gained from this effort, I am about to relaunch work on a 6800 simulator to allow running 6800 FLEX programs on a 6502.

[BigEd]

I am following with great interest!

[BillG]

The running 8080 code on 6502 part or 6800 on 6502 part?

[BigEd]

The FLEX idea certainly caught my eye, but both really.

[IamRob]

Did this hit a dead end or is it complete?

[BillG]

IamRob wrote:

Did this hit a dead end or is it complete?

It is on a back burner.

I did not originally intend to build an 8080 simulator. The plan was for a 6800 one, but I ran into problems because the memory map for 6502 FLEX was still changing. So until that got resolved, I decided to try the 8080 and CP/M.

The file systems are substantially different between FLEX and CP/M that I ran into some more issues to think through before making any more progress.

In the meantime, I started this project

https://www.vcfed.org/forum/forum/genre ... -into-8080

for two reasons:

* to get a feel for how real programs use the CP/M file system
* to make test programs for the 8080 simulator

Once I hit several major milestones with it, I started working on FLEX again and somehow got sidetracked with this

viewtopic.php?f=2&t=6823

in the past couple of months.

Such is life with no schedules for delivery...

[IamRob]

If you have either 6800 or 8080 simulation done to work on a 6502, I could add the Prodos OS file system to work on an Apple II. I don't have much interest in the CPM file system.

[BillG]

IamRob wrote:

If you have either 6800 or 8080 simulation done to work on a 6502, I could add the Prodos OS file system to work on an Apple II. I don't have much interest in the CPM file system.

I'm not sure I follow what you are saying. Are you wanting versions to run as native ProDOS programs?

[IamRob]

BillG wrote:

IamRob wrote:

If you have either 6800 or 8080 simulation done to work on a 6502, I could add the Prodos OS file system to work on an Apple II. I don't have much interest in the CPM file system.

I'm not sure I follow what you are saying. Are you wanting versions to run as native ProDOS programs?

I would like to use your simulator to be able to run MBasic on a 6502 to add another language to my collection that I can run on the Apple.
And I would add any file handling requirements needed by MBasic to work under Prodos.

For the simulator to work natively, I think would require converting CP/M file commands to Prodos commands, which would probably be a little too complex, and more than I need.

I would appreciate a copy of the simulator that can run MBasic on a 6502.

Thanks