Compilation Of A PDS Game

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

Post Reply
Vhyrro
Posts: 10
Joined: Sun Aug 02, 2020 3:31 am

Compilation Of A PDS Game

Post by Vhyrro » Sun Feb 28, 2021 9:40 am

Recently I have taken myself to figuring out the internal workings of a game I love, Super Robin Hood (part of the Quattro Adventure series). Here's the thing, just under a year ago the game's official source code has been released in the Wireframe Magazine Issue #34, I have since then forked it where I have added extra explanations to certain parts of the code. In an effort to make modding for the game easy, I tried compiling it into a full binary.

You see, this is where the problems started to arise.

PDS, or Programming Development Systems, used to be (from what I know) a company that was the creator of the PDS cross-platform assembly language that was used to write Super Robin Hood for the NES. Within the source code there are 2 binaries, HEX2BIN.COM and PP1PACK.EXE, both DOS binaries. There are several issues that arise fairly quickly:

a) There is pretty much no documentation regarding PDS, I've only ever managed to find a PDF detailing the syntax, and that's about it.

b) The binaries are very VERY vague and give no insight as to what they are doing with the input data and how the output of the programs should be used.

Here's some of the things I gathered so you don't need to check:
- HEX2BIN.COM, as the name suggests, takes in an input file that it then magically converts into a BIN file, the ONLY file that works with this app that I've tested is MAPDATA.DAT - the program then fires up and prints "Read 317 lines, wrote 3988 bytes". It produces a binary file with the same filename but the .BIN extension. I am unsure what to do with this file, as objdump and binwalk and all others have no clue what this is. The output of the file command run against the .BIN file is just "data", leading me to believe this file needs to be somehow merged with other files in order to be complete.
- PP1PACK.EXE "intensively packs NES character sets", at least that's what it says if you run the program without arguments. The only PP1 file that works with this binary is OKCHR.PP1, all the others fail with the error message "source file is not a whole number of characters long". I am unsure how to go around this in order for it to work, maybe merge all the PP1 files into one? But if so, in what order?

Here's the actual question: Is anybody familiar/has a background in PDS, and if so, could aid me in compiling this into one full, complete, runnable binary for e.g NES emulators? Piracy is not an issue here since the source code has been officially released with the allowance of the Oliver Twins. Even the smallest bits of info can help, so please!

tepples
Posts: 22335
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Compilation Of A PDS Game

Post by tepples » Sun Feb 28, 2021 10:01 am

If you feed an ordinary CHR to pp1pack, does it come out with what tokumaru has called Codemasters format?

Vhyrro
Posts: 10
Joined: Sun Aug 02, 2020 3:31 am

Re: Compilation Of A PDS Game

Post by Vhyrro » Sun Feb 28, 2021 10:24 am

tepples wrote:
Sun Feb 28, 2021 10:01 am
If you feed an ordinary CHR to pp1pack, does it come out with what tokumaru has called Codemasters format?
Maybe, I'm unsure. After running tokumaru's compressor alongside PP1PACK.EXE on the same file (OKCHR.CHR, the only file that didn't cause pp1pack to error out), they both produce different results, although the first byte is the same on both. PP1PACK's output is actually way shorter than tokumaru's version. The output of PP1PACK said that the packed size is 11 bytes (5 bytes saved) with a 68.75% compression ratio; tokumaru's compressor produces 82 bytes of output.

User avatar
tokumaru
Posts: 12056
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Compilation Of A PDS Game

Post by tokumaru » Sun Feb 28, 2021 10:40 am

Even compressors targeting the same decompressor are unlikely to produce e same results, due to the use of different parsing strategies, but my compressor doesn't even generate binaries compatible with Codemasters' decoder, I made a few changes to the format.

Are you saying that my compressor is expanding a 16-byte file to 82?!? That's pretty weird... I wrote that ages ago, so I have absolutely no idea why something like this would happen.

Vhyrro
Posts: 10
Joined: Sun Aug 02, 2020 3:31 am

Re: Compilation Of A PDS Game

Post by Vhyrro » Sun Feb 28, 2021 12:03 pm

tokumaru wrote:
Sun Feb 28, 2021 10:40 am
Even compressors targeting the same decompressor are unlikely to produce e same results, due to the use of different parsing strategies, but my compressor doesn't even generate binaries compatible with Codemasters' decoder, I made a few changes to the format.

Are you saying that my compressor is expanding a 16-byte file to 82?!? That's pretty weird... I wrote that ages ago, so I have absolutely no idea why something like this would happen.
Sorry for late response but yeah, it's expanding the file, I don't know either :P

On a side note, it's really annoying because there's so little info anywhere about any of this stuff. I heard from somewhere that you need specialized hardware to compile PDS source code but I have no way of verifying that.
Best bet is to just contact the Oliver Twins themselves I suppose?

Oziphantom
Posts: 1115
Joined: Tue Feb 07, 2017 2:03 am

Re: Compilation Of A PDS Game

Post by Oziphantom » Sun Feb 28, 2021 10:50 pm

PDS, we have the 6502 manual, the main manual and the software ( although it needs to be patched to run on DOS 4 or higher)

apart from the PDS assembler directives what more documentation do you need?

PDS has a .HEX directive, which is how it does .byte/.db etc so the tools probably read a text files with .HEX directives as that is how PDS likes to work.

Vhyrro
Posts: 10
Joined: Sun Aug 02, 2020 3:31 am

Re: Compilation Of A PDS Game

Post by Vhyrro » Mon Mar 01, 2021 12:27 am

Oziphantom wrote:
Sun Feb 28, 2021 10:50 pm
PDS, we have the 6502 manual, the main manual and the software ( although it needs to be patched to run on DOS 4 or higher)

apart from the PDS assembler directives what more documentation do you need?

PDS has a .HEX directive, which is how it does .byte/.db etc so the tools probably read a text files with .HEX directives as that is how PDS likes to work.
Yup, those are the things we have figured out, but documentation isn't an issue here, neither is understanding the code, it's about compiling it. The assemblers reportedly don't work without a PDS ISA card installed on the system, which I certainly don't have :P

Are you trying to recommend that I write a program to convert the source code into regular assembly? Because now that I think about it that shouldn't be too much of an issue.

Oziphantom
Posts: 1115
Joined: Tue Feb 07, 2017 2:03 am

Re: Compilation Of A PDS Game

Post by Oziphantom » Mon Mar 01, 2021 12:37 am

porting the code would be the easiest way, its not a very complex assembler. Either use a find and replace and some patch ups, there is a PDS to ACME converter around as well, not sure how good it is. ACME would probably not be a good choice for NES development. There was a hacked version of 64tass that has "more PDS" support, not sure if that was publically available or not.

I hacked PDS to work in a DOSBOX kinda, but its not really going to be that useful as PDS doesn't really make a bin file for you to use on your machine, i.e so you can save it to a Disk drive on the target. I think it will assemble to HEX though, which is probably why there is a HEX2BIN program ;) But keeping this in a PDS format is more pain than it is worth.

Vhyrro
Posts: 10
Joined: Sun Aug 02, 2020 3:31 am

Re: Compilation Of A PDS Game

Post by Vhyrro » Mon Mar 01, 2021 12:43 am

Oziphantom wrote:
Mon Mar 01, 2021 12:37 am
porting the code would be the easiest way, its not a very complex assembler. Either use a find and replace and some patch ups, there is a PDS to ACME converter around as well, not sure how good it is. ACME would probably not be a good choice for NES development. There was a hacked version of 64tass that has "more PDS" support, not sure if that was publically available or not.

I hacked PDS to work in a DOSBOX kinda, but its not really going to be that useful as PDS doesn't really make a bin file for you to use on your machine, i.e so you can save it to a Disk drive on the target. I think it will assemble to HEX though, which is probably why there is a HEX2BIN program ;) But keeping this in a PDS format is more pain than it is worth.
I see, well it was certainly interesting looking through the internet looking for old relics of weird compilers hah. I'll get to work on a converter for PDS source code, maybe even put it up on github so if anyone else has troubles with their own code they can just run the program and convert it to 6502 or whatever else I'll end up supporting. Thank you for the tips! I'll get back to this thread when I'm done or if I end up getting stuck :)

Oziphantom
Posts: 1115
Joined: Tue Feb 07, 2017 2:03 am

Re: Compilation Of A PDS Game

Post by Oziphantom » Mon Mar 01, 2021 5:31 am

you seem to be a bit confused about what this is.

1.) Its an Assembler not a Compiler
and thus
2.) it is already in 6502

Vhyrro
Posts: 10
Joined: Sun Aug 02, 2020 3:31 am

Re: Compilation Of A PDS Game

Post by Vhyrro » Mon Mar 01, 2021 5:41 am

Oziphantom wrote:
Mon Mar 01, 2021 5:31 am
you seem to be a bit confused about what this is.

1.) Its an Assembler not a Compiler
and thus
2.) it is already in 6502
1) Oh whoops, that's just me mixing up terms, I do that a lot since I'm really used to saying "compile" and compiler hah.
2) From what I read PDS has minor differences that need to be accounted for and can't be used in a regular 6502 assembler (please correct me if I'm wrong!). It has things like macros and small loop jmps (things like !1, !2 etc.). It's a cross-platform assembly language, right? Therefore I need to write something that will automate the process of assembling it into raw 6502 for me, like a small CLI program. Am I looking at it the right way or am I just dumb :P

tepples
Posts: 22335
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Compilation Of A PDS Game

Post by tepples » Mon Mar 01, 2021 7:34 am

I wrote translators from NESASM to ca65 and from ca65 to ASM6 in Python that you can use for reference.

Oziphantom
Posts: 1115
Joined: Tue Feb 07, 2017 2:03 am

Re: Compilation Of A PDS Game

Post by Oziphantom » Mon Mar 01, 2021 7:39 am

There is no standard assembler syntax

!byte ACME
.db CC65
.byte 64TASS

macros, if you are using an assembler for 1984 yeah maybe it won't support macros, but any modern assembler will handle them just fine.

!1
!2
are local variables
.variable ACME
@variable CC65
_variable 64TASS

some also allow annonomis such as

bne +
; code here
+

and
-
; code here
dex
bpl -

other odd limits of PDS, labels can only be 8 letters long so you will see lots of meaningless label names etc

PDS is an assembler from 86 or so, designed for 640K PCs, modern day assemblers will out do it in ever aspect easily. But you can't choose a common "min" and "support" all assemblers, so you will need to pick and choose a new assembler syntax to target.

Vhyrro
Posts: 10
Joined: Sun Aug 02, 2020 3:31 am

Re: Compilation Of A PDS Game

Post by Vhyrro » Mon Mar 01, 2021 9:49 am

Thank you all a lot! I'll definitely look at the "reference" programs and I'll take into account what Oziphantom said, didn't even know about the label limitation lol

Post Reply