Page 4 of 5
Re: Simulating an 8080. Is there a better way to do this?
Posted: Sun May 16, 2021 1:12 pm
by 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.
Re: Simulating an 8080. Is there a better way to do this?
Posted: Sun May 16, 2021 9:58 pm
by teamtempest
Re: Simulating an 8080. Is there a better way to do this?
Posted: Mon May 17, 2021 12:24 pm
by BillG
Very interesting. That is very recent.
Re: Simulating an 8080. Is there a better way to do this?
Posted: Mon May 17, 2021 8:56 pm
by 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.
Re: Simulating an 8080. Is there a better way to do this?
Posted: Tue Jun 01, 2021 2:30 am
by 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
Re: Simulating an 8080. Is there a better way to do this?
Posted: Wed Jun 02, 2021 2:53 am
by BillG
It turns out that the line
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
Re: Simulating an 8080. Is there a better way to do this?
Posted: Fri Oct 08, 2021 3:02 am
by 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.
Re: Simulating an 8080. Is there a better way to do this?
Posted: Fri Oct 08, 2021 9:09 am
by BigEd
I am following with great interest!
Re: Simulating an 8080. Is there a better way to do this?
Posted: Fri Oct 08, 2021 12:26 pm
by BillG
The running 8080 code on 6502 part or 6800 on 6502 part?
Re: Simulating an 8080. Is there a better way to do this?
Posted: Sat Oct 09, 2021 6:57 am
by BigEd
The FLEX idea certainly caught my eye, but both really.
Re: Simulating an 8080. Is there a better way to do this?
Posted: Wed Nov 24, 2021 5:25 am
by IamRob
Did this hit a dead end or is it complete?
Re: Simulating an 8080. Is there a better way to do this?
Posted: Wed Nov 24, 2021 2:05 pm
by BillG
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...
Re: Simulating an 8080. Is there a better way to do this?
Posted: Wed Nov 24, 2021 4:50 pm
by 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.
Re: Simulating an 8080. Is there a better way to do this?
Posted: Sat Nov 27, 2021 12:37 pm
by BillG
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?
Re: Simulating an 8080. Is there a better way to do this?
Posted: Tue Nov 30, 2021 5:32 am
by 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.
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