sharing same binary among old computer?
category: offtopic [glöplog]
Quote:
Forget about it. Invest your time on more useful things. :)
That's exactly the sort of sensible advice that's killing the demoscene.
Quote:
To make it short.: Forget about it. Invest your time on more useful things. :)
You realise that if we all took that advice the scene would be pretty instantly dead? :D
Sounds like an interesting (but yes, pointless :) concept though. You could make say a multiplatform 4k, with 3k of (shared) data plus say ~200b (unshared) code for 4 platforms.
A shared binary might be tough though, assuming you can get a single file to even execute some code on different platforms. I guess if the CPUs are different but they start at the same address it might still be possible. The ops will be different, but you might find some lucky combination that does *something* on both CPUs, and somehow jumps to a different address on each to continue running the right native code. Finding the right sequence of operations isn't a job I'd want though ;)
i forgot to say that Skurk of Hoaxers did code a little program that works on both c64 and MSDOS. one only need to change the extention from .com to .prg and vice versa. some instruction the x86 can skip and then run the program whilist the c64 program sys'es to a memory location and runs the c64 program.
it would probably be possible to code a "binary-loader" for each supportet platform that can run the same binary data files but of course that wouldnt be as sexy.
Dual boot disks (Amiga/ST) were actually quite common back in the day (TM). Thalion (which were mainly ST demosceners) released quite a few of such games, Ninja Remix is one that springs to mind. As far as I remember, there was also at least one game that could be booted on Amiga, ST and PC. I just can't remember which game that was though.
Quote:
I guess if the CPUs are different but they start at the same address it might still be possible. The ops will be different, but you might find some lucky combination that does *something* on both CPUs, and somehow jumps to a different address on each to continue running the right native code. Finding the right sequence of operations isn't a job I'd want though ;)
I wouldn't think it's all that hard. If you take the 3-4 bytes necessary to say "jump to address X" on architecture A, and run that through architecture B, I'd say there's a pretty good chance that it'll do nothing, other than possibly corrupting a couple of registers. (At least, that's my experience from Z80... maybe other processors are more picky about executing random bytes, in which case you'd want to put those earlier in the sequence.)
Well, then.
Make a blob of data with binaries for multiple CPUs, knowing the default start address of each system. Load it, type SYS/USR/Whatever wherever your code starts. There you go. :P
If has to be a starting routine within the file...
$4C $11 $E0 $11 $11....
6809: ANDB #$11, JMP $11E0.... (Jumps to $11E0)
6502: JMP $E011, ORA $??11+Y... (Jumps to $E011)
Z80: ?????
8086: Profit!!! :P
According to Disks, runnable on PC and Amiga. Carrier Command does not boot on PC, but a Directory is visible. On Amiga, it boots, but no dir.
Amiga uses the boot Track to boot and simply does not use the area where DOS expects the FAT.
The PC does ignore the boot track and shows the dir with files in DOS.
Make a blob of data with binaries for multiple CPUs, knowing the default start address of each system. Load it, type SYS/USR/Whatever wherever your code starts. There you go. :P
If has to be a starting routine within the file...
$4C $11 $E0 $11 $11....
6809: ANDB #$11, JMP $11E0.... (Jumps to $11E0)
6502: JMP $E011, ORA $??11+Y... (Jumps to $E011)
Z80: ?????
8086: Profit!!! :P
According to Disks, runnable on PC and Amiga. Carrier Command does not boot on PC, but a Directory is visible. On Amiga, it boots, but no dir.
Amiga uses the boot Track to boot and simply does not use the area where DOS expects the FAT.
The PC does ignore the boot track and shows the dir with files in DOS.
Exin: and call your demo/filename "START_ADR" (where START_ADR will be 49152 if it's $C000) so after you load it, the user will do a SYS (C64) or CALL (Apple IIe) instead of entering run...
F-Cycles: I think it's easier to make a Disk that boots on Apple 2 and shows a dir on C64. Make a normal DOS 3.3-like boot block that boots your Apple 2 Code and then make a Directory with C64 readable tracks with a files the C64 can execute.
First Half of the Disk: Apple DOS3.3 like files, starting Track 18 will be C64 stuff. Both systems have a fundamentally different way of reading sectors and even the disk-layout. I have never heard of a program on each side to read disks from the other Yet. If the motor on both drives (Disk II, 1541) spins at the same speed, maybe it's possible that both sides can share the same area of data.
First Half of the Disk: Apple DOS3.3 like files, starting Track 18 will be C64 stuff. Both systems have a fundamentally different way of reading sectors and even the disk-layout. I have never heard of a program on each side to read disks from the other Yet. If the motor on both drives (Disk II, 1541) spins at the same speed, maybe it's possible that both sides can share the same area of data.
ALSO, maybe if the BASIC Bytecode of two system matches, maybe that could be a better approach.
Rudi: Doesn't work in Emulator. However, the Basic line is displayed. The SYS does nothing though. No Hello world here. :/
couldn't verfy the DOS part, since i'm still at school (64bit windows)
couldn't verfy the DOS part, since i'm still at school (64bit windows)
Rudi: Doesn't work in Emulator. However, the Basic line is displayed. The SYS does nothing though. No Hello world here. :/
couldn't verfy the DOS part, since i'm still at school (64bit windows)
couldn't verfy the DOS part, since i'm still at school (64bit windows)
oops...
you can use the MSX scheme (plain binary file loaded at 0x100) on all CP/M machines as well, provided they don't add an extra header on disk like the Amstrad CPC. But if you get the file from a BBS, it's up to the BBS client to add that header when saving to disk, right ?
Pulko: The DOS/Basic on every kind of machine adds a standard header once the file is saved. One could make a binary that runs on two platforms right from the start. That is why that approach is mentioned.
On a second thought, i take it back. I don't know about Terminal programs with download function on other systems than C64 and PC/Amiga....
all this will lead to EPIC REALTIME UNIVERSAL BINARY :D
Can't wait. :D
Looking forward to the first time someone submits the same binary for different platform compos at the same party.
Forever is near.
The AppleII seem to have a 128 header size for binary II file format which need to start with $0A $47 $4C...
Binary II file format spec on page 4
Binary II file format spec on page 4