|
Post by elmer on Feb 14, 2019 6:07:33 GMT
OK, My disassembly is proceeding. I now have the following: - initialization - font location (offset $0179-$0478) - text constants/display messages (roughly offset $5C8D - $5F5A) - bios.s (offset $7C00 onward) - joypad read function, and some clues about where/how it is used - note, the nybbles are reversed compared to how the system card stores/accesses them. Cool stuff, excellent! I *really* hope that you'll find and document the USB communication sequence with KRIKzz's "turbo-usb2.exe" downloader program so that we can recreate-or-rewrite it in any new TED OS, and make the downloader available on platforms other than Windows. While examining this code, I see exactly what elmer was talking about, with the cc65 usage - there is stack frame usage everywhere (yuccch). Yep, when I really started looking at CC65's code-generation, I was pretty horrified. Given that both CC65 and HuC started off with Ron Cain's Small C source, the CC65 developers have done a lot more work on ANSI standards-compliance than is in HuC, and they have done a lot more work on their code-sequence-optimization pass too, but their basic code-generation scheme itself is ugly. IMHO, HuC is a lot more elegant in its foundation design, and you guys put some really smart stuff in there. That's why I abandoned CC65 and started working on improving HuC instead. I've had some success with my own TED2 code. I can now parse the FAT32 directory structure, and handle long filenames. Here's the code running on a CoreGrafx and reading the root directory of my SD card, showing each of the volume/directory/file entries, together with their associated long filenames. It's still some way in the distance, but its not too horribly far from here to actually being able to select and run cartridge images.
|
|
|
Post by dshadoff on Feb 14, 2019 7:49:10 GMT
Wow, that's also looking pretty cool ! I'm thinking an extensible OS like the you're building is a better long-term goal, but it's quite ambitious. I'll do a few smaller things to help gather information. By the way, if you're looking to build a whole new os.pce, why do you need the existing USB tool's protocol ? It might be easier (and would certainly be more powerful) to build a new one from scratch... In fact, since it's really just an RS-232, why not go for one of the old download protocols from modem days of old ? (with a supervisory command system like a BBS). ...Or perhaps you're just looking for the initialization setup... I'll keep an eye out for that. On my disassembly, I'm still a long way from understanding the USB usage, but I've made some good progress in other areas. I was able to find and fix the HEX display that - although probably nobody else even noticed - was *really* bugging me for some reason. Patch #2 now fixes this in addition to correcting the I/II keymapping: Swapkeys2.zip (1.86 KB) Quick notes: - I'm getting closer to where it reads the USB for loading things (i.e. HEX display and loading ROMs) - I see 2 big reasons why it might not remove protection from all USA games (one is that it check too many bytes for exact match, and the other is that it only checks the first instance of an "AD" (LDA ABS) byte in the ROM). - I didn't see any calls to the I2C functions, so I guess higher-level I2C I/O is not supported by the OS. - It looks like Populous support only works if the ROM is spelled POPULOUS... but I'll check whether this is case-specific or requires a specific extension. And, the stack frames are killing me. They are ugly, difficult to follow, and wasteful of space (and time). My next step will be to try to read/write BRAM like a Tennokoe bank. If I'm lucky, I'll be able to manage it before the end of the weekend... Although probably the user interface part will take longer. Dave
|
|
|
Post by dshadoff on Feb 15, 2019 0:33:35 GMT
One piece of information that would be helpful to me (in case you know how), is how the card maps its own memory.
That is to say, bi_set_bank_8k sets the PC Engine side memory bank number to the $6000-$7FFF bank, which is really only a 8KB aperture into the total memory available. ...This is not rocket science, since it is already well-understood. In the OS.PCE, this is set at various intervals to $43, $44, $4F and so on.
bi_set_bank_512k sets something on the card, which would seem to correspond with the bank numbers of the PC Engine's memory map. Since my card has 64Mb of memory, it has 8MB, or 16 available blocks of 512KB each. (Unless half of this is wasted)
512KB would span, for example, from bank $00-$3F, from bank $40-$7F, and from bank $80-$BF - assuming that they are only aligned to 512KB boundaries.
This would make some sense: 4Mb HuCard would occupy $00-$3F; 8Mb from $00-$7F. Super CD-ROM and CD-ROM require memory from $60-$7F (Super only), and $80-$88. Since we already knew that Super CD-ROM allocates $40-$7F as RAM, I suspect that $80-$BF are allocated as well.
But the question I have is, what values are passed to bi_set_bank_512k to set an arbitrary bank of TED memory to one of these 512kb banks ? In bi_start_game, we can see that some of the bits in reg_map define whether the memory is mapped at all, writable, etc.
Dave
|
|
|
Post by elmer on Feb 15, 2019 2:18:43 GMT
One piece of information that would be helpful to me (in case you know how), is how the card maps its own memory. Take a look at TED_REG_MAP in my header file/documentation. KRIKzz is mapping the PCE's banks $40..$7F into different regions of his 4MByte PSRAM chip. Banks $00..$3F always refer to the same region. It's a system that is designed to be compatible with the Street Fighter II hucard. There's a spare bit that could be used to map the 8MByte PSRAM chip on your TED2, but he only ever talked about having 4MB of onboard memory, so maybe the extra is wasted, either with an unused address bit, or by ignoring the top or bottom half of a 16-bit-wide PSRAM chip.
|
|
|
Post by dshadoff on Feb 15, 2019 3:28:17 GMT
OK, I think I understand...
1) Bottom 512KB (bank 4 apparently) is always mapped to $00-$3F, with the exception of an 8KB cutout when the registers are active 2) Top 512KB ($40-$7F) is selectable among the 8 (or possibly 16) available banks, by 3 of the top 4 bits (or perhaps all 4) of TED_REG_MAP 3) In addition, the SF2 mapper can also select among 4 of those 512KB banks, if active
I think it would be interesting to test whether the additional RAM is accessible, but I'm not yet in a position to do so.
One more interesting thing is that the OS uses $0F and $4F as parameters to the 512KB bank mapper while the TED OS is running, and switches it to $04 when it comes time to start the game. The reason this is interesting, is that your header mentions that three of these bits are unknown ($08, $02, $01), and two of them cause hangs ($02, $01).
|
|
|
Post by elmer on Feb 15, 2019 5:20:20 GMT
OK, I think I understand... Yep, I think that you've got it. The info in my header was found by looking at bios.s and then using KRIKzz's "turbo-usb2.exe" to upload test ROMs to my PCE. One more interesting thing is that the OS uses $0F and $4F as parameters to the 512KB bank mapper while the TED OS is running, and switches it to $04 when it comes time to start the game. The reason this is interesting, is that your header mentions that three of these bits are unknown ($08, $02, $01), and two of them cause hangs ($02, $01). That's very, very interesting indeed. Are you *sure* that the TED os.pce is actually setting those $0F and $4F values, and not the bootloader in the FPGA? As you've found, KRIKzz's bios.s is a piece of assembly source code that is used in both os.pce and the FPGA's built-in bootloader. I suspect that those bits ($02 & $01) could be something to do with the hardware setup for the PSRAM, heck, they could even be left-over settings from the flash-rom programming on the TED1!
|
|
|
Post by dshadoff on Feb 15, 2019 5:36:39 GMT
Yes, I am certain - $4F is an initialization value. There is a spot where it sets it with a stack value (which I didn't trace back yet), but $4F and $0F are definitely in there.
I'll send a PM...
|
|
|
Post by dshadoff on Feb 15, 2019 6:58:16 GMT
I'm not sure what you mean by PSRAM, but the more I think about it, those 2 bottom bits probably indicate which bank is mapped in the bottom 512KB.
Here's how I arrived it: The bottom 512KB can't be fixed to a specific 512KB bank. The OS is running in banks $01-$04 in it. While you can map the same bank into the upper portion in order to load banks $00 to $3F for playing a HuCard, you would necessarily overwrite the OS itself before completing it.
My thought is that the bottom two bits control whether the bottom 512KB bank is using BANK 4, 5, 6, or 7. ...And the OS is running in BANK 7, since the register is written with $xF.
When the ROM is loaded, it starts with $4F (i.e. BANK 4 in top half, Bank 7 in bottom half); for a larger ROM, this switches to $0F in the second half (BANK 0 top half, bank 7 bottom half).
Then when the game is to start, there is no large amount of data copying, just bank-switching (done from within user RAM @ $FE). Then $04 is written, which (BANK 0 top half, BANK 4 bottom half).
It would also make sense that changing these two bits from within a running program would cause a hang.
I'm going to have to run a test.
|
|
|
Post by elmer on Feb 15, 2019 7:46:35 GMT
I'm not sure what you mean by PSRAM Pseudo-Static RAM ... aka CellularRAM ... it's what the TED2 is using. I just wanted to distinguish the area from the PCE's RAM, or from any kind of ROM. I'm sorry if I wasn't clear. My thought is that the bottom two bits control whether the bottom 512KB bank is using BANK 4, 5, 6, or 7. ...And the OS is running in BANK 7, since the register is written with $xF. ... It would also make sense that changing these two bits from within a running program would cause a hang. Dang! That is truly excellent thinking! That makes a lot of sense, and would be far more elegant than just shuffling banks around from a subroutine in RAM. I don't *know* if you're right, but the idea *sounds* right. It's the sensible way of doing it. As you already know, you'll be able to confirm this by switching the memory in the upper bank and scanning for the code-signature in the different banks. Bloody brilliant work!
|
|
|
Post by dshadoff on Feb 15, 2019 8:31:06 GMT
Two test for the price of one:
1) Even though my RAM is 8MB, it doesn't seem to allow me to choose BANK 8 for the upper RAM area (this aliases to BANK 0) 2) Yes, the lower RAM area is mapped as BANK 7 initially, out of the way of all the other operations.
|
|
|
Post by elmer on Feb 16, 2019 0:44:26 GMT
Thanks Dave!
I've updated the TED2 documentation/header in my stickied thread.
|
|
|
Post by dshadoff on Feb 16, 2019 18:38:20 GMT
By the way, in case you are trying to re-implement the os.pce, be aware that the FPGA zaps values into the memory, overwriting whatever was there. Specifically, in the $8106-$810B area, several "System Information"-type values are placed there during boot, which aren't otherwise available via registers. These include Serial Number, assembly date and time, etc.
If you are building a program in that area, I suspect that you will be getting crashes without understanding why.
Dave
|
|
mooz
Deep Blooper
Posts: 29
|
Post by mooz on Feb 17, 2019 16:46:23 GMT
|
|
|
Post by elmer on Feb 17, 2019 22:17:08 GMT
If you are building a program in that area, I suspect that you will be getting crashes without understanding why. Thanks! I hit that exact problem yesterday when I added the code to relocate the OS to the TED's 512KB bank 7 (when it is run as a cartridge image). You've saved me a ton of time and head-scratching. My test code is designed to runs as either a HuCard on the TED, or as a replacement TED OS.PCE ... or as a HuCard in Mednafen. Thanks, that's really, really cool. Isn't linux wonderful sometimes! I already created an image of my TED's SDcard (using "dd" in linux), so I've been extracing sectors from that and caching them in the cartridge in my Mednafen tests. It's a heck of a lot more tedious manual work than your system, but it has allowed me to get familiar with the FAT32 math, and it means that I can directly compare tests in Mednafen with tests on a real TED.
I've looked at your github again, and we definitely seem to have different goals in mind. It looks like you're working on creating a full-featured FAT32 driver that can provide all the features that an operating-system needs. Perhaps you're taking the FatFs C code as an inspiration?
My goal is to provide only the features that a console game/bios needs, which is much closer to Petit FatFs (although I'm looking directly at Microsoft's FAT32 specification instead). So ... single volume, single file, and no file creation (but file overwrite allowed), with an interface that will eventually allow for using the SDcard to simulate a CD image. I really don't want to write the code to go through all of the pain of file creation and FAT32 cluster allocation, when in pratical terms, you can just do that by plugging your SDcard into your Windows or Linux system and copying over a few blank "placeholder" files. Writing the code to overwrite the data in existing files is quick and easy, and is all that is really needed (IMHO) for the scenarios that I can think of, especially something like a Tennokoe-style Backup RAM utility.
|
|
mooz
Deep Blooper
Posts: 29
|
Post by mooz on Feb 17, 2019 23:28:44 GMT
Yeah creating new files seems to be a pain in the ark, but I need it for a project :/ I don't know if I'll add directory creation and file removal. The todo list is already pretty huge.
|
|