|
Post by gameblabla on Jan 25, 2022 1:48:24 GMT
According to Matej Horvet and Alex Marshall : In addition to the CD-ROM drive, the PC-FX can also boot code from its other ports : - External backup memory. This is used by the FX-BMP card to store data. - Rear expansion slot. This was used by a cable to turn the PC-FX into an external SCSI CD-ROM drive. He also suggested that controller 2 could be used as some sort of a debug cable. This was notably done on other consoles like the Megadrive and Master System for multiplayer. But yeah, Matej corrected Alex's documentation and this is how it should be layed out : Marshall's doc about the backup memory : daifukkat.su/pcfx/data/backup.htmlMatej's : matejhorvat.si/en/pcfx/index.htmNow, i actually tried to see if it would boot a simple hello world from the backup memory with their instructions on the header but so far no luck. This is what i came up with : 42 6F 6F 74 : PCFXBoot 00 00 00 40 : Offset of code on backup memory (word) 00 00 80 00 : RAM address to load to (word) 00 00 10 00 : Transer size in bytes
And this one, i'm not actually sure ? According to marshall, it's "RAM run length", whatever that is. Matej says it's the "Starting PC", which isn't really more clear to me. I wrote it as : 00 00 00 00
But unfortunately, i'm not having any luck so far. It would be nice if this could be figured out so that in the future and in case the PC-FX's drive fails, that we also have a nice alternative to the CD for homebrew games. EDIT: I realized that i forgot it is little endian lol... Not a problem, could fix that but still unsure about the Starting PC stuff tho.
|
|
|
Post by dshadoff on Jan 25, 2022 2:07:17 GMT
He didn't have a sample file, huh ? I read this once in the past, and I had ideas about making a FX-BMP which could be read/programmed by USB, partly for save game extraction and partly for hacking like this. I even got the slot half-documented, but lost interest when I started to disassemble the case, in order to trace back wiring to the main board (and saw the many layers of disassembly required). I still plan to do it, but only when I have more time on my hands.
One thing that bothered me was that Mednafen only supports 32KB of extrnal backup, when the FX-BMP is 128KB.
But anyway, I've read both of your references, and based on them, I've come to the conclusion that: - The code isn't run in-place; rather, it is copied into main memory first, and executed there. - This copy uses: -> source address: (base + (value in 0x30)) -> destination is (value in 0x34) -> length is (value in 0x38) -> after the copy, jump goes to (value in 0x3c)
So based on this, it's more of a bootstrap or mini-loader, than for full-scale programs (also limited by the size of the external backup memory).
|
|
|
Post by gameblabla on Jan 25, 2022 2:21:36 GMT
Sadly no (and not even for his own homebrew game hehe). Matej isn't the kind of person to share stuff like that sadly . I could ask him again though. So if say, i have my small hello world that i want to copy to memory, 0x34 and 0x3C can basically be the same right ? Yes but according to matej, you can address up to 128MB from the Backup memory slot so with a custom PCB and flashrom, it should be in theory possible. If you want to give it a try yourself , here's a compiled binary build of the hello world example from liberis : gitlab.com/gameblabla/gameblabla-website-files/-/blob/simp/files/pcfx/hello.bin
|
|
|
Post by dshadoff on Jan 25, 2022 2:37:18 GMT
Sadly no (and not even for his own homebrew game hehe). Matej isn't the kind of person to share stuff like that sadly . I could ask him again though. Please do; it could help advance the state of the art. Even if he doesn't want to share, it would be great if assumptions could be confirmed. Yes, this is how I interpret it. Does Mednafen's debugger allow breakpointing this ? I'd imagine that breakpointing 0xE8000028 might be able to hook the bootstrap process... That is also very interesting; I'm curious to know how this number was arrived at. Also, since the PC-FX cartridge has address lines and data lines, and isn't port-mapped, I'm curious how that is "supposed to" work - some kind of paging scheme ?
|
|
|
Post by elmer on Jan 25, 2022 15:54:12 GMT
That is also very interesting; I'm curious to know how this number was arrived at. Also, since the PC-FX cartridge has address lines and data lines, and isn't port-mapped, I'm curious how that is "supposed to" work - some kind of paging scheme ? There are 128MBytes of directly-mapped CPU address space for the cartridge memory at $E8000000 (and for internal memory at $E000000). Both memories are on the low 8-bits of a 16-bit bus, so every other byte of address space is wasted. I have no idea just how many address bits are taken out to the cartridge, but mednafen is mirroring the data every 64KB of CPU space, i.e. 32KB of cartridge space. Does Mednafen's debugger allow breakpointing this ? I'd imagine that breakpointing 0xE8000028 might be able to hook the bootstrap process... Yes, it does. It's a simple boot process, and you may find the code for reading the internal/external cartridge memory interesting. The boot detect and loader code is at $FFF00236 in the firmware, and the boot signature is at $FFF05DB8. $FFF0016C is the final routine that is run to jump to the user's program. Here's a zip file containing a mednafen save for Zeroigar (the English version), with a boot signature and one of liberis's examples embedded, and "yes" it runs fine ... zeroigar.57a5926ab48addef98bf271ab12f9d27.zip (3.43 KB) <EDIT> For those that don't know ... PC-FX executables load (and usually execute) at address $8000, which is the first free RAM location after the firmware's reserved area at $7E00-$7FFF. GCC (both the archaic 2.95 and newer 4.7.4) produce binary files that load and run at that address. Adding the boot signature and inserting a file into cartridge memory in mednafen is trivial using the memory debugger (ALT-D,ALT-3).
|
|
|
Post by elmer on Jan 25, 2022 18:26:14 GMT
The PC-FXGA documents, particularly "filelib.txt" mention backup cartridge sizes up to 8MBytes, so that's probably the hardware limit.
The cartridge is formatted with the FAT filesystem, and so a bootable file would normally be written out with the library functions ... which means that you'd want to re-format the cartridge before writing a boot file just to make sure that it isn't fragmented on the cart, which is something that the firmware's boot loader can't handle.
|
|
|
Post by gameblabla on Jan 26, 2022 4:52:31 GMT
Thanks elmer ! I was able to get it to work with the 7up example as well although attempting to insert anything else just seems to result into a hang... I've been told by matej that you cannot really execute code from the backup memory so this does put a celling limit on code size but i believe that it should still be possible to load read-only data from backup memory. This will probably need a proper linker however. I suppose a small tool could be done to package things up for the backup memory.
|
|
|
Post by gameblabla on Jan 28, 2022 5:30:09 GMT
Ok so decided to write up a tool based on what you guys said and elmer's example binary that works.
This time, i was able to get it working on all examples that does not use the CDROM drive. I've set a hard limit to 2MB as we are limited by the PC-FX's RAM and because we cannot execute code from ROM.
In the future, this should be changed with a proper linker so that read-only data is also supported...
Right now if you want to load stuff from ROM, you have to manually specify an offset in your source code, which isn't ideal.
But i don't exactly have the right skills for that
|
|
|
Post by dshadoff on Jan 29, 2022 3:43:47 GMT
Cool stuff ! I guess it's time to start porting 240P suite...
|
|
|
Post by elmer on Jan 29, 2022 16:29:00 GMT
This time, i was able to get it working on all examples that does not use the CDROM drive. I've set a hard limit to 2MB as we are limited by the PC-FX's RAM and because we cannot execute code from ROM. In the future, this should be changed with a proper linker so that read-only data is also supported... Right now if you want to load stuff from ROM, you have to manually specify an offset in your source code, which isn't ideal. I don't know why you're so hung-up on the idea of putting games into the FX-BMP's cartridge backup-memory and booting them from there ... that isn't what the feature was designed for, and you're just going to end up screwing up people's consoles! Once the boot signature is written to the FX-BMP, the PC-FX will *always* boot from the cart, and will *not* boot from CD ... heck, it doesn't even *seem* to properly initialize the CD so that you can read from it in your program. This is *why* NEC made it so that you can't boot from internal backup-RAM ... because that could completely brick your console and make it unusable! As it is, to get control back after writing a program to the FX-BMP, you have to wipe its contents ... by pulling it out of the console, taking out the battery, and waiting for it to discharge any internal capacitor. That is going to get frustrating for anyone, and will eventually bring a premature end to your FX-BMP. Booting from an FX-BMP, or from a newly-designed piece of hardware (such as a PC-FX DevKit that someone like dshadoff might design) *can* be accomplished in a way returns to the PC-FX and continues the normal boot process, but the program's startup code will need to be modified, and there may be other hardware-specific things that we have to do or avoid in order for it to work properly. And if we do decide to experiment with that, it will take assembly-language and hardware debugging skills that you just don't currently appear to have. The system is designed to boot games from CD, so for gawd's sake, please just do that for now, and have fun experimenting with the PC-FX in a less-dangerous way. Apart from that ... even when it has a boot-signature, the FX-BMP still has its normal FAT12 file system, so there is absolutely no need for anyone to mess around putting some other file system into backup memory, and we can/should just use the existing structure so that we don't confuse the PC-FX firmware or other games. Writing a file to the FX-BMP, and then *blessing* the cart by writing a boot-signature that points to that file, is going to be easy to accomplish once the liberis hooks are written to access the firmware's FAT12 routines. Doing the same thing to a .sav file on a PC isn't *much* more difficult ... and IMHO it would be a far-more-useful utility to have for testing than just corrupting the cartridge's file system in the way that we're doing now in our experiments.
|
|
|
Post by gameblabla on Jan 29, 2022 18:21:31 GMT
"I don't know why you're so hung-up on the idea of putting games into the FX-BMP's cartridge backup-memory and booting them from there ... that isn't what the feature was designed for, and you're just going to end up screwing up people's consoles! Once the boot signature is written to the FX-BMP, the PC-FX will *always* boot from the cart, and will *not* boot from CD ... heck, it doesn't even *seem* to properly initialize the CD so that you can read from it in your program. This is *why* NEC made it so that you can't boot from internal backup-RAM ... because that could completely brick your console and make it unusable!" It's not technically a brick. And sure, it wouldn't be desirable to write it to a stock FX-BMP but couldn't you just in theory remove the FX-BMP anyway ? Of course it prevents the booting of the CDROM but if it gets formatted again later, then it should end up being the same as before right ? To be honest, i'm not sure if it is hot-swappable (the port probably isn't). I guess you're afraid that people would put this on their FX-BMP and then wonder why they can't boot to the BIOS to play their CD games. Or that an official game tries to write to it again (if they hotswap it) and fail in spectacular fashion. But if say we somehow manage to make our own PCB for a FX-BMP replacement and they wouldn't really use it for saving, how would that be a brick when they can just remove it after powering it off ? I did talk about putting nCraft on the FX-BMP but ideally, it should be on its card. But you're right that it's probably not a good idea to make the "flasher" as it might be a bit confusing for people.
Besides, 64KB is too small for games anyway, nCraft just happened to be small enough to fit...
|
|
|
Post by dshadoff on Jan 29, 2022 18:26:19 GMT
Here's what I would do for a few steps in devkit:
Stage 1: - Write a program (on CDROM) to send data from PC to PC-FX (protocol to be defined) -> Once the protocol is established, I think I can modify the PC-FX Mouse adapter to send it via FX-PAD port 2; python or whatever can be used on the host -> This CD program may initially be used for sending/receiving FX-BMP contents, like savegames.
Stage 2: - Data to transfer could be executables, similar to the cartridge bootstrap approach, but less restricted (although several joypad actions per download cycle) -> one option *could be* to be format the FX-BMP as boot device - Such a boot program should have options: (a) reformat/erase FX-BMP if a pad key is held at boot, (b) download another program if another key is held, (c) fall-through to the original program. - This type of "code preamble" would allow quick-turn development, and prevent the situation elmer mentions above
...With FX-BMP carts in the $250 range, I understand the concern, but I intend to make a cart which is reprogrammable. However, with the world parts situation as it currently is, that won't happen soon. I would like to be able to do some dev work whenever I get some time off.
|
|
|
Post by gameblabla on Jan 29, 2022 18:36:28 GMT
Here's what I would do for a few steps in devkit: Stage 1: - Write a program (on CDROM) to send data from PC to PC-FX (protocol to be defined) -> Once the protocol is established, I think I can modify the PC-FX Mouse adapter to send it via FX-PAD port 2; python or whatever can be used on the host -> This CD program may initially be used for sending/receiving FX-BMP contents, like savegames. Yeah i thought of something like that as well except that it would just execute the uploaded code from memory. Probably beyond my expertise a little but i think it should be possible in theory for testing.
I do admit, inserting "special games" from CD games themselves is perhaps kind of like the VMU or Pocketstation games, except not as neat nor portable...
Your flasher idea could work for formatting but unless somehow we embed that very program in the FX-BMP or whatever, you would still have to hotswap it no ? Because as elmer noted, it takes over the boot process.
|
|
|
Post by dshadoff on Jan 29, 2022 18:56:03 GMT
Yes, I am talking about taking over a FX-BMP and forcing it be a dev unit. But with a self-destruct override to make it a normal (but empty) one again, in case you need to use it as a FX-BMP.
Down the road, when I get a chance to understand the other bits of the cartridge (like when the select logic is activated), I was planning to make a version with FeRAM which doesn't need batteries, and a version with a microcontroller with a PC interface, so that the data can be directly read/written.
|
|
|
Post by elmer on Jan 29, 2022 19:32:27 GMT
It's not technically a brick. And sure, it wouldn't be desirable to write it to a stock FX-BMP but couldn't you just in theory remove the FX-BMP anyway ? I said *internal* backup-RAM ... there is no way to unplug that or wipe it. Your console would be dead until the internal backup-RAM discharged. Which is why you can't boot from internal backup-RAM. For the external FX-BMP, "yes" you can remove it to get control back ... which wears out the unreplacable connector if you keep on doing it for no reason. For games, just use CDs, that's what the system was designed for. To be honest, i'm not sure if it is hot-swappable (the port probably isn't). I guess you're afraid that people would put this on their FX-BMP and then wonder why they can't boot to the BIOS to play their CD games. Or that an official game tries to write to it again (if they hotswap it) and fail in spectacular fashion. It *could* be hot-swap, but it probably isn't given the size. And "yes", if a game overwrites your FX-BMP boot-code because you've not written it as a FAT12 file, or because someone has deleted the file, then ... oh, dear. But if say we somehow manage to make our own PCB for a FX-BMP replacement and they wouldn't really use it for saving, how would that be a brick when they can just remove it after powering it off ? It wouldn't be a brick ... see above. It would just be an expensive way of delivering games that completely misses the whole point of the console having a drive that reads cheap-to-manufacture CDs that have *far* more data space than a cartridge.
|
|