CPCWiki forum

General Category => Programming => Topic started by: zhulien on 18:58, 13 April 20

Title: crossplatform apps: 6502 + 8086 + z80
Post by: zhulien on 18:58, 13 April 20
I was wondering if anyone has written any cross platform software before for multiple incompatible CPUs... an example being: 6502 + 8086 + z80...  perhaps more can be added: 68000?


Anyone want to expand on this and prove it works by filling in the Hello World printing code?



nopjrjp/jmpcall/jsrand a
z800018 xxc3cda7
6502ea-4c20-
8086eb xx




bad clashes:
- &00: z80 'nop' is 'brk' in 6502
- &ea: 6502 'nop' is 'jp pe' in z80
- &c3: z80 'jp xxxx' is 'dcm' in 6502


good clashes:
- &18: z80 'jr xx' is 'clc' in 6502 and 'sbb' in 8086
- &eb: 8086 'jr xx' is 'ex de,hl' in z80 and 'sbc xx' in 6502


manageable clashes:
- &4c: 6502 'jmp xxxx' is 'ld c,h' in z80
- &cd: z80 'call xxxx' is 'cmp' in 6502

- &a7: z80 'and a' is 'lax ab' in 6502 and 'cmpsw' in 8086
- &20: 6502 'jsr xxxx' is 'jr nz xxxx' in z80 and 'and' in 8086
Title: Re: crossplatform apps: 6502 + 8086 + z80
Post by: zhulien on 19:15, 13 April 20

Example 1:


org &0800; good for c64 & cpc
dw &0800; c64 load address: 'ex af, af' for z80, 'nop' for z80. logical or for 8086, add for 8086
; cross platform logic to get to correct jump table entry
db &18, &18; 'jr &18' for z80. 'clc; clc;' for 6502. 'sbb' for 8086
db &eb, entry_8086; 'jr' for 8086. 'sbc' for 6502
db &4c, entry_6502; jmp entry_6502 for 6502
ds 19; to ensure z80 starts 24 bytes after jr &18. space for other cpus?
; cross platform jump table
entry_z80:db &c3, main_z80; z80 jp
entry_8086:db &e9, main_8086; 8086 jr 16bit
entry_6502:db &4c, main_6502; jmp again for 6502
; cross platform code
main_z80:; use z80 instructions
main_8086:; use 8086 instructions
main_6502:; use 6502 instructions
shared_data:
db 'Hello, World!', 0
Title: Re: crossplatform apps: 6502 + 8086 + z80
Post by: norecess on 20:02, 13 April 20
I was wondering if anyone has written any cross platform software before for multiple incompatible CPUs... an example being: 6502 + 8086 + z80...  perhaps more can be added: 68000?

SDCC C compiler targets multiple 8-bit CPUs.
Title: Re: crossplatform apps: 6502 + 8086 + z80
Post by: zhulien on 20:18, 13 April 20
SDCC C compiler targets multiple 8-bit CPUs.


yes, but... it only targets one at a time.
Title: Re: crossplatform apps: 6502 + 8086 + z80
Post by: norecess on 20:22, 13 April 20
OK lol I just understood what you are trying to achieve. Funny idea..
Title: Re: crossplatform apps: 6502 + 8086 + z80
Post by: zhulien on 20:26, 13 April 20

Example 2: simplier 6502 and z80



org &0800; good for c64 & cpc
dw &0800; c64 load address: 'ex af, af' for z80, 'nop' for z80
db &a7, &20, main_6502; 'and a; jr nz' for z80. 'lax ab' and 'jsr' for 6502
; cross platform code
main_z80:; use z80 instructions
main_6502:; use 6502 instructions
shared_data:
db 'Hello, World!', 0
Title: Re: crossplatform apps: 6502 + 8086 + z80
Post by: robcfg on 21:10, 13 April 20
I think that what you are suggesting is just too complicated, when you can just compile one file for every platform and then concatenate them.
Title: Re: crossplatform apps: 6502 + 8086 + z80
Post by: andycadley on 22:43, 13 April 20
Does this not boil down to being able to construct a sequence of CPU instructions that will eventually be a valid jump on different machines (without jumping on others). Once you've branched once on any given CPU you need never necessarily share code again.


It would be neat if you could, but I suspect viable programmes would be very limited.
Title: Re: crossplatform apps: 6502 + 8086 + z80
Post by: AMSDOS on 03:04, 14 April 20
I think what you wrote the other day about having a Small BASIC implementation across a number of systems could work, though it's simply a matter of understanding the code, I'm still only at a basic level of understanding the Z80. :(

It doesn't stop anyone from asking how my small BASIC works, though it's been setup to perform as if it would perform on a real machine. If it were crossed over to CPCBasic Unchained (https://www.cpcwiki.eu/forum/emulators/cpcbasic-unchained/), it wouldn't have the same memory restrictions because BASIC code doesn't occupy memory and I suspect Garbadge management (e.g. Strings being stored to Memory) isn't a problem either.
 
A lot of the PEEKed variables would need to be changed to variables as they wouldn't need protecting from the CLEAR that Locomotive BASIC uses to clear space. Code would have to be converted to DATA as it wouldn't be possible to run under CPC BASIC, though as I mentioned elsewhere, Console output is available to copy and paste into a file.
At the moment I think it needs more work done I think before CPCBasic Unchained can step in, though it may become an useful tool for that kind of project.