How to make PCE CDROMROMROMROM

[Punch]

Hi, I have IPL.BIN and I know about the -cd and -scd options of PCEAS, but what else should I take care of to be able to build a valid PCE CDROM iso? Just compiling a hucard project as-is makes no positive effect -- I have bank 0 with startup code plus 4 more banks I pull graphics from and map during startup. I imagine that there's some preparation to be done but I can't find any documentation. What's the minimum setup for an ASM CD project?

Help me get the Takaki Kobayashi seal of approval for my CD game! (he wrote the SCD bios)

Takaki Kobayashi Seal of Approval

[TheOldMan]

Just compiling a hucard project as-is makes no positive effect -- I have bank 0 with startup code plus 4 more banks I pull graphics from and map during startup. I imagine that there's some preparation to be done but I can't find any documentation. What's the minimum setup for an ASM CD project?

I'm not sure I understand what you are saying/what your question is.?.

Are you actually displaying anything yet? That's probably the first thing you need to work out. Without loading anything other than a font, can you print a test message? If not, you need to figure out how to set the display up, and get a test message displaying.

Btw, you don't need to compile the gfx into the program. If you understand the ipl, it can load vram + pallettes for you.

[Punch]

OK, I'll admit I'm completely lost here. I thought the IPL file that HuC had was just like a static signature thing the CD bios checked for copyright and disc validation. I cannot find any documentation on this thing besides the overlays.txt file from HuC which doesn't explain much.

Only thing I know from the CD bios is that there's a function table I can use to call pre-built functions, the rest I have no idea. I just want to know what do I need to have proper in my code (which MPR banks can I use? interrupt vectors are ok to be assigned on the last bank? any special function to load before doing regular game stuff?) and also what is the structure of the IPL file.

I could also use HuC to do all that hard work for me but I have no idea how that thing works... I'd prefer to stay ASM only if possible.

[Punch]

OK, I found the Hu7 pdf. So from what I can tell the important part of IPL.bin starts at $0800 and has this layout:

Code: [Select]

IPLCONFG
BANKS
O
GRAPHC
ADPCM
RESERVE
PC Engine CD-ROM SYSTEM
Copyright HUDSON SOFT / NEC Home Electronics,Ltd.
GameTitleHere!RESERVED
I still don't get how stuff is supposed to be referenced on disc ("record no."), is it a "CD frame" index or something? Do I have to generate all that stuff by hand?

Oh boy.

[dshadoff]

The CDROM startup sequence is harder than you might think.

If you want to make a CDROM project in ASM, at least take a look at HuC's "startup.asm" (and anything else it references).  That is a complete, working CDROM startup sequence in assembler, and it uses conditional compilation to determine whether to become a cartridge or a CDROM.  If you don't care about this dual-boot choice, then ignore any code that is cartridge-specific.  But 60-80% of the code is common between the boot types.

There are copious quantities of comments inside of the HuC library code - especially "startup.asm" - to try to help explain what is going on, and why.

At any point where you are trying to implement anything in ASM by yourself, if something similar already exists in HuC, please try to reference HuC's implementation as a starting point, because it was tested and works.

-Dave

[elmer]

OK, I found the Hu7 pdf. So from what I can tell the important part of IPL.bin starts at $0800 and has this layout:

Code: [Select]

IPLCONFG
BANKS
O
GRAPHC
ADPCM
RESERVE
PC Engine CD-ROM SYSTEM
Copyright HUDSON SOFT / NEC Home Electronics,Ltd.
GameTitleHere!RESERVED
I still don't get how stuff is supposed to be referenced on disc ("record no."), is it a "CD frame" index or something? Do I have to generate all that stuff by hand?

Oh boy.

PCEAS sets up the IPL for you, with HuC's default layout.

Here's a simple SCD example that uses PCEAS to make an ISO, but avoids any of the PCEAS/HuC libraries to give you a totally "clean" starting point ...

https://www.dropbox.com/s/dpj3hgkhif25kty/TestTedRam.zip?dl=0

Yes, "record num" is the same as CD frame index (i.e. 2KB block).

PCEAS has some "default" settings that it puts in the IPL when it generates a CD, and if it allows you to override any of the IPL settings ... then I haven't found it yet (I've not needed to).

Just remember, most SCD games (that I've seen) start with a small "boot" program, that then runs and loads up the rest of the game.

I'm not even sure if the IPL loader even allows you to load up more that 64KB in the boot process.

[EDIT]

Minor update to the example to fix a couple of typos in the comments.

[TheOldMan]

I thought the IPL file that HuC had was just like a static signature thing the CD bios checked for copyright and disc validation

The first part of it is that. But part of it is a small program that gets loaded into RAM (yes, ram) and executed to load various things. Like the actual program itself, from cd.

(which MPR banks can I use? interrupt vectors are ok to be assigned on the last bank? any special function to load before doing regular game stuff?)

MPR 0 is I/O. MPR 1 is RAM. Mpr 7 is (usually) the bios code.  That leaves you MPR 2-6 to map for your program.  You -can- use MPR 7 for your irqs, but it's a pita; better to place them in either MPR 2 or MPR 6,  and leave them alone. IIRC, nothing 'special' is required to run the program, but you may have to do some setup at the start. (ie, set screen size, load palettes, turn display on, etc).

I could also use HuC to do all that hard work for me...

Its worth learning to write at least a working "Hello World" program in HuC, just so you know what you have to do. Once it works, you can look through the generated asm and see what is going on and then get rid of some of the HuC cruft.

I still don't get how stuff is supposed to be referenced on disc ("record no."), is it a "CD frame" index or something? Do I have to generate all that stuff by hand?

Rec H/ Rec M/ Rec L  is a 3 byte LBA address. That's generally the best way to handle most cd stuff.
The ctime stuff is a 3-byte timestamp. Its a little trickier to use. IIRC, there's a function to convert between them.
Yes, you have to know where things are ahead of time. It's not as bad as you think, though.  Most things won't move around in the iso.

[TheOldMan]

I'm not even sure if the IPL loader even allows you to load up more that 64KB in the boot process.

The ipl by itself can load all of vram, and up to 5 pages of code. But if you set the execution address (to the last part of the ipl, iirc) it can call your ipl code. At that point, you can do pretty much what you want, if you can fit it into ~1K. You have to direct execute your main program, though....

[elmer]

If you want to make a CDROM project in ASM, at least take a look at HuC's "startup.asm" (and anything else it references).

That's definitely where I started when I wanted to get a small assembly program written and booting from CD.

But OMG ... I found it damned hard going sorting through all the stuff in startup.asm to see what I actually needed to get to a "clean" starting point.

At the end-of-the-day, it all turned out to be reasonably simple (if you're happy writing in assembly).

The ipl by itself can load all of vram, and up to 5 pages of code.

So approximately 46KB of code ... but also with VRAM (if you want it).

But if you set the execution address (to the last part of the ipl, iirc) it can call your ipl code. At that point, you can do pretty much what you want, if you can fit it into ~1K. You have to direct execute your main program, though....

Do you mean actually putting your code in the IPL sector itself???


I like Xanadu's method of loading up a small section of permanent "boot/library" code in $3000-$3FFF (bank $F8), and then having that load up the "Main Menu", "Game Code", etc as needed.

Perfect for assembly, and it should be easy to do in CC65, too.

[TheOldMan]

Do you mean actually putting your code in the IPL sector itself???

Yes. As long as you don't change the signature (which is actually a routine that does the gfx/pallete/sound loading and playing), you can set the execution address to run code in RAM. Unfortunately, there's only about 1K left at the end of the ipl stuff.

Fwiw, that's how the 'aetherbyte' logo bounces in pp. The gfx and sound are loaded in the ipl, and then the logo is bouced by a custom routine. In the ipl.

[elmer]

Yes. As long as you don't change the signature (which is actually a routine that does the gfx/pallete/sound loading and playing), you can set the execution address to run code in RAM. Unfortunately, there's only about 1K left at the end of the ipl stuff.

OK, I just looked at the loading process in Mednafen.

So the 2 IPL sectors are loaded into RAM $2800-$37FF.

The contents of $2800-$2D1F are verified as a valid IPL (the signature).

Then the code jumps to $2B26 to actually run some code before loading/running the game program/data that is specified in the IPL.

So you've actually got 736 bytes of space for your own code in there if you don't overwrite that area with boot code.

It's really cool that you can do that, but, on balance, I think that I prefer Xanadu's method ... they just start loading their boot code at $2800, so you've got the whole $2800-$DFFF region to boot whatever code/data you wish.

[EDIT]

No, I've changed my mind ... that is a really neat trick, if you want to put up an animating logo as-quickly-as-possible. 

[EDIT-EDIT]

Actually, now I'm not so sure ... I was thinking for a second that your code inside the IPL would run while loading the main program code ... but I just took a look at PP on YouTube and I don't think that I'm seeing that.

If all that you're doing is to set the program execution address to $2D20 and relying on the IPL data not being overwritten, then I'm going to go back to only "reasonably cool" and preferring Xanadu's method of just starting the program load at $2800.

[TheOldMan]

OK, I just looked at the loading process in Mednafen.
So the 2 IPL sectors are loaded into RAM $2800-$37FF.

Right. Keep in mind that there is a split in the ipl though; part of it is data, part of it is boot code....

The contents of $2800-$2D1F are verified as a valid IPL (the signature).

Right. That's the first half of the ipl.

Then the code jumps to $2B26 to actually run some code before loading/running the game program/data that is specified in the IPL.

Not sure about the addresses, but ok. The code that gets run has been verified as the NEC boot code. That part loads the graphics, etc. Can't change it, or the boot fails.

So you've actually got 736 bytes of space for your own code in there if you don't overwrite that area with boot code.

Again, not sure about the size, but ok.

Now, in those 736 bytes, you can do what you want, pretty much. Soooo, let's say you load another couple of sectors at $3000, and jump to it. Those sectors could be your menu program.... Or other code....
All in all, I think it shows a lot of thought.  And I can see where it could do a lot of the things a HuC program does when it starts up....

I was thinking for a second that your code inside the IPL would run while loading the main program code .

Unfortunately not; I think the main program gets loaded last (maybe first), iirc. That is, assuming its not running from the ipl area, though maybe the main code gets loaded anyway. Don't quote me on that, though; it's been a long time since I did that stuff....

What I do remember is splitting the ipl into 2 parts; one part contained stuff that got verified - it had to match what was in bios for the cd to work.  The other part contained the data described in the ipl doc. I then disassembled the actual startup code to see how it worked...and that's when I found a check for the execution address being in the RAM page, which allowed me to run the bouncing logo routine. Except for the size constraint, I realized I could probably use any bios calls I wanted - including loading more code into ram.

fwiw, I actually had a test ipl that would check the cd card, and boot different programs for the 2.0 and 3.0 cards. Kind of gave up on that, since I would have to keep 2 different versions of things in sync, but the idea was to run a low-quality version and a higher-quality version of the same program, depending on which card it was running on....

[Bernie]

This thread makes me feel retarded...


Sent from my iPhone using your mama

[Punch]

You guys are simply the best.

Takaki Kobayashi Seal of Approval

I see that there's a lot to learn so I might not do a CD version as I was planning for my homebrew in development (I thought it would be way easier than it actually is to play with CDs), but I will look more into it later. Thanks everyone, your really did help me a lot. And also thanks for the nice discussion about the IPL itself holding some code, I'll look into that later, too.

[TheOldMan]

I see that there's a lot to learn so I might not do a CD version as I was planning for my homebrew in development

You're going to laugh, but here's my suggestion. And I'm serious.

Write a HuCard game (assembler is fine, HuC not required). Get it to work. Try to keep it under 128K.
Then, assemble it with the -cd or -scd option. Check the size, and figure out what is not getting loaded. (If anything) Then it's pretty simple to change the memory map and load more code, up to the card limit.  And you have a cd/scd game iso.
It only gets complicated when you're using overlays and/or trying to load things from cd in the game. And even that isn't too bad; you can duplicate the overlay array approach HuC uses.