|
Post by dshadoff on Feb 10, 2019 2:41:25 GMT
I was thinking... wouldn't it be cool if the TurboEverdrive could also do Tennokoe Bank functions ? All it would really need is to write to the SDCard...
So I went on Twitter and asked the creator whether it can electrically write to SDCard, and whether he wrote any functions to write. ...He replied (tersely) that it can write to SDCard !
However, there are no clues as to whether any write-access functionality already exists or whether it would need to be written from scratch.
The key would be in the boot-up UI, which is nicely included as a separate file that you have to load into the boot folder (os.pce in \TBED\).
Has anybody already tried to disassemble and comment any part of this ? (elmer perhaps ?) I'd like to see if I can improve it.
Dave
UPDATE WITH (MINOR) PROGRESS:
1) Yes, the card does write to SDCard, and can create files in the filesystem. In fact, \TBED\CONFIG.BIN is created if it does not exist, and is updated each time the card is used, if it does exist.
2) The \TBED\os.pce program is a ROM which runs on the PC Engine, as the user interface. But it doesn't load in the same way as all the others do. I'm still working out the details to this, but the entry conditions seem to be:
a) block 0 (file offset $0000-$1FFF) may or may not be loaded into bank 0; I read somewhere that bank 0 is reserved for his hardware registers, so perhaps this is loaded into bank 1. This is mapped to MMR #4 at $8000.
b) MMR #6 is mapped to bank $F8 (RAM) as is normal convention
c) block #3 (file offset $6000-$7fff) is mapped to MMR#7 at $E000.
|
|
|
Post by dshadoff on Feb 10, 2019 17:24:59 GMT
The more I think about it, the more I think that this has to be loaded into very high memory - like CDROM memory from bank $80 and up, in order not to be clobbered when it loads a ROM.
I'll have to make a modified ROM in order to display aspects of its environment at startup.
I'm also a bit concerned that the boot loader may assume that os.pce is exactly 32KB long; although there are big empty spaces in the ROM, I might need/want to extend it.
|
|
mooz
Deep Blooper
Posts: 29
|
Post by mooz on Feb 10, 2019 20:44:22 GMT
|
|
|
Post by dshadoff on Feb 10, 2019 22:15:42 GMT
OK, let's break down the board:
Starting from the edge connector, and ignoring any simple components, we have:
1) 74LVT162245B(x2) = low-voltage 16-bit transceiver with tri-state outputs -> these must be for address and data-bus driving, but it is 3.3V logic. Must be close enough to 5V transition levels, and I suppose it's 5V-tolerant, but I wouldn't know.
2) IS66WVE4M16EBLL-70BLI = 64MBit pseudo-static RAM -> This must be all the storage that the PC Engine can see (and more)
3) ICE40HX1K-VQ100 = FPGA, Lattice, 1280 logic elements, 160 logic array blocks, 72 I/O, 64 kbit memory, 1.2V ultra-low power -> I'm assuming that this is the smarts that configures the other peripheral chips, converts SPI/I2C to parallel, drives the SDCard, and appears to implement the banking and control-line usages (such as /WE, /CE, /CS, /OE). It also appears to boot-load the "OS.PCE" to the RAM for PCE usage.
4) 24FC256 = 32Kx8 Electrically-erasable PROM (EEPROM), I2C -> this must store the "boot" configuration for the FPGA
5) Empty slots: a) 28-pin dual-row flatpack of some sort - should be something like FT232RL SSOP-28 for adding the RS-232-over-USB interface b) center-bottom, looks like a mini-USB or micro-USB connector rough-in with 5 leads and through-hole mounts ***note, I think that if this is actually mounted, the plastic cover may not mount properly** c) 10 GPIO leads of unknown use, in the bottom-right
Conclusions: - I2C is used for the FGPA's boot-up configuration, and re-programming may be possible (although you probably don't want to). It may also have something to do with the additional pins at the bottom right. - SPI in the code is basically referring to the SDCard read-write. - USB won't matter if you don't have the USB chip mounted.
If you boot the card and press "SELECT", you'll see a screen with a bunch of raw information:
One group of info identifies "assemble date/time", which seems to be when the FPGA EEPROM was programmed. He seems to do that immediately prior to shipment. "Bootloader 1" and "Bootloader 2" appear to imply the FPGA configuration and the sequence that initially loads and runs "OS.PCE".
I'm about to hack OS.PCE to figure out what kind of environment is set for it befire it runs (I don't think it can possibly be loaded into the early banks like other HuCards, but I also couldn't locate it when searching with the System Card 1.0's built-in debugger.
Dave
|
|
|
Post by dshadoff on Feb 10, 2019 23:10:04 GMT
I made a small change to check the intialization state of the card, so I can see more about the environment.
I got some answers....And I got more questions.
I wrote a quick little patch, to grab the card just after disabling insterrupts and initializing the stack, and writing MMR values into an already-existing static string. Here's what I learned:
First, the OS is loaded into memory which is not write-protected, as I had suspected. Until the disassembly is ready, we can use this fact, and overwrite existing static messages.
Initial MMR values: MMR0 ($0000-$1FFF) = $FF (this is normal, but it already initialized before card start) MMR1 ($2000-$3FFF) = $F8 (this is normal, but it already initialized before card start) MMR2 ($4000-$5FFF) = $00 (I think this is where the TurboEverDrive hardware is mapped) MMR3 ($6000-$7FFF) = $44 (What is this ?) MMR4 ($8000-$9FFF) = $01 (this is actually the first 8KB block of os.pce, which would normally be loaded into bank 0) MMR5 ($A000-$BFFF) = $02 (this is actually the second 8KB block of os.pce, which would normally be loaded into bank 1) MMR6 ($C000-$DFFF) = $03 (this is actually the third 8KB block of os.pce, which would normally be loaded into bank 2) MMR7 ($E000-$FFFF) = $04 (this is actually the fourth 8KB block of os.pce, which would normally be loaded into bank 3)
So, there is a boot loader for os.pce, which loads it into slightly unorthodox banks, and maps them prior to execution.
If I want to run os.pce in an emulator, I should create an extra prepended 8KB segment to do this (and then somehow skip I/O...)
...I'm also surprised that the code is loaded into early banks. How will it reliable load the cartridge data into those early banks prior to execution, without clobbering itself ? Can it renumber the banks ?
Does it have multiple "copies" of the first few banks, since there are a few banks in the $Fx series that it can't realistically use ?
...Lots of questions.
Dave
|
|
|
Post by elmer on Feb 10, 2019 23:52:30 GMT
I was thinking... wouldn't it be cool if the TurboEverdrive could also do Tennokoe Bank functions ? Yep. It shouldn't be too difficult. Has anybody already tried to disassemble and comment any part of this ? (elmer perhaps ?) I've only looked at enough of it to confirm that the "bios.s" that krikzz has released on his website, is indeed the low-level access code that he's using, and that the rest of the OS code is written in C (CC65) which I have no interest in trying to disassemble. 1) Yes, the card does write to SDCard, and can create files in the filesystem. In fact, \TBED\CONFIG.BIN is created if it does not exist, and is updated each time the card is used, if it does exist. Yep, the Petit FATfs C code writes files, too. Krikzz's "bios.s" provides the low-level SDcard write functions to Petit FATfs. 2) The \TBED\os.pce program is a ROM which runs on the PC Engine, as the user interface. But it doesn't load in the same way as all the others do. I'm still working out the details to this, but the entry conditions seem to be: It's a 32KB chunk of code that the ROM-bootloader built into the FPGA loads into $8000-$FFFF in memory. I don't know which actual banks it loads into (but will find out). a) block 0 (file offset $0000-$1FFF) may or may not be loaded into bank 0; I read somewhere that bank 0 is reserved for his hardware registers, so perhaps this is loaded into bank 1. This is mapped to MMR #4 at $8000. It isn't (AFAIK). The code that is in bank 0 is the boot ROM that is inside the FPGA (loaded when the FPGA is initialized). I'd like to see if I can improve it. I though of doing that, then I decided that it would be easier to just rewrite the OS and make it Open Source.
|
|
|
Post by dshadoff on Feb 11, 2019 0:26:57 GMT
Well, if you're thinking of rewriting the OS, you may need to limit yourself to 32KB and/or come up with a paging system.
I just extended the os.pce image by another 8KB block, and implanted a bunch of obvious-valued data.
Good news: The system didn't complain about the extra-long os file. Bad news: When my little hack went to map bank $05 looking for the values to print out, it only found 3C C3 3C C3... so it either didn't load, or it loaded somewhere completely different.
Dave
|
|
|
Post by elmer on Feb 11, 2019 0:27:53 GMT
Initial MMR values: MMR0 ($0000-$1FFF) = $FF (this is normal, but it already initialized before card start) MMR1 ($2000-$3FFF) = $F8 (this is normal, but it already initialized before card start) MMR2 ($4000-$5FFF) = $00 (I think this is where the TurboEverDrive hardware is mapped) MMR3 ($6000-$7FFF) = $44 (What is this ?) MMR4 ($8000-$9FFF) = $01 (this is actually the first 8KB block of os.pce, which would normally be loaded into bank 0) MMR5 ($A000-$BFFF) = $02 (this is actually the second 8KB block of os.pce, which would normally be loaded into bank 1) MMR6 ($C000-$DFFF) = $03 (this is actually the third 8KB block of os.pce, which would normally be loaded into bank 2) MMR7 ($E000-$FFFF) = $04 (this is actually the fourth 8KB block of os.pce, which would normally be loaded into bank 3) OK, thanks! That saves me from figuring that out. The layout makes total sense (to me) from the POV of it being a CC65 program, and doing what it has to do. Initial MMR values: ...I'm also surprised that the code is loaded into early banks. How will it reliable load the cartridge data into those early banks prior to execution, without clobbering itself ? Can it renumber the banks ? Does it have multiple "copies" of the first few banks, since there are a few banks in the $Fx series that it can't realistically use ? It is using the TED2's bank switching for the top 512KB of cartridge memory (used for the SFII cartridge-compatibility) to load up the cartridge image. That's what the MMR3 region ($6000-$7FFF) is for. The 1st 5 banks of the cartridge image can be loaded into one of the spare 512KB blocks (there is 4MB of RAM on the TED2), and then a small function can be copied to the PCE's RAM in bank $F8 (MMR1), and run from there to copy the data over banks $00..$04 before rebooting the PCE into the cartridge image. I documented all of the banking capabilities in my header file. It's pretty simple stuff ... which is why I figure that we might as well write a clean new OS rather than trying to patch Krikzz's code.
|
|
|
Post by dshadoff on Feb 11, 2019 2:13:52 GMT
Hmm.. I just noticed that all the HEX displays are in MSB<->LSB reversed sequence, like BYTE1, BYTE0, BYTE3, BYTE2, BYTE5, BYTE4, ... Although the ASCII displays are OK.
And I found the byte sequence that he is using for removing the US protection... it's much longer than needed, and looks like it will fail to remove the protection on some games.
I should start disassembling.
|
|
mooz
Deep Blooper
Posts: 29
|
Post by mooz on Feb 11, 2019 8:42:37 GMT
I can't see any of the spi/mmc initialization tango in Krizz bios.s, maybe this is done in the magic bootloader. Hopefully I grabbed a v2 some weeks ago. I'll try to make some tests this week.
Update: Ok this is not starting well... The following code which is just a rewrite of bi_init_os without the i2c init will boot back to the everdrive menu.
lda #$00 tam #4
lda #$A5 sta ed2_key stz ed2_cfg stz ed2_spi_cfg
lda #ED2_CFG_SKIP_EEP sta ed2_cfg
|
|
|
Post by elmer on Feb 11, 2019 21:34:37 GMT
Thank you for that! That was a massively useful starting point when I first started trying to read the TED2's SD card. Looking at the How to Use MMC/SDC webpage, while trying to understand your code, really helped me finally figure out what was going on. Well, if you're thinking of rewriting the OS, you may need to limit yourself to 32KB and/or come up with a paging system. That's plenty of memory. The code to initialize, read and write the low-level SDcard, together with detecting and mounting a FAT32 partition, is only 1 1/2 Kbytes so far. Ok this is not starting well... The following code which is just a rewrite of bi_init_os without the i2c init will boot back to the everdrive menu. How are you running that? Not from bank 0 in a cartridge image, I hope! (As explained in my TED2 documentation.)
|
|
|
Post by dshadoff on Feb 11, 2019 21:37:05 GMT
Clearly the base initialization is done in the bootloader, pre-initialization.
I am currently walking through comparing the bios.s code against the $FC00-and-above os.pce, and finding no differences - but that doesn't make it a fruitless exercise; by doing this, I am gradually getting a better understanding of how the hardware works. (It sounds like elmer already did this years ago).
If I understand correctly, the i2c stuff would more likely be for the turbo-usb.exe to read/write the FPGA config, rather than additional external devices, so my approach would be to try to look through the other half of the os.pce code, to see how USB interaction takes place.
In any case, my goal was not to rewrite an OS; it was to take advantage of already-existing access functions in order to improve functionality (i.e. baby steps).
My TED card isn't USB-capable (yet), so I'm not ready to rewrite the whole OS.
Dave
|
|
mooz
Deep Blooper
Posts: 29
|
Post by mooz on Feb 11, 2019 21:49:50 GMT
Not from bank 0 in a cartridge image, I hope! (As explained in my TED2 documentation.) Haha... erm.. cough cough... What? Update: I moved the ted code to bank 1 and it seems that sd card init is working. The next thing to do will be to test the read routine. I'll try to plug it with the fat32 driver I'm working on ( github.com/BlockoS/HuDK/blob/master/include/fat32.s )
|
|
|
Post by elmer on Feb 12, 2019 3:36:47 GMT
Clearly the base initialization is done in the bootloader, pre-initialization. I *suspect* that the OS also does its own initialization of the SDcard ... the code to do it is written in C in KRIKzz's "edio.c", so it is probably in the C code that you've not disassembled yet. Haha... erm.. cough cough... What? Haha, yep, that was an incredibly easy thing to miss if you're used to programming for the Turbo Everdrive 1. Excellent, congratulations! I hadn't seen your work on a fat32 driver before, I don't think that it was there a couple of years ago when I grabbed your sd.s file to take a look at. That's really neat! Our coding styles are so different that I'm going to keep on working on my own fat32 code at this point, but it's going to be great for folks to be able to see two different approaches to solving the problem.
|
|
|
Post by dshadoff on Feb 13, 2019 19:43:02 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. While examining this code, I see exactly what elmer was talking about, with the cc65 usage - there is stack frame usage everywhere (yuccch). But anyway, I can now provide the first of several patches. This will swap buttons 'I' and 'II', so that operation will be more natural. You'll need to have pceas and the original os.pce (labelled as "os_orig.pce") in order to make use of this. Don't forget to ensure to name the file "os.pce" when loaded onto the card. swapkeys.zip (1.05 KB) I will try to correct the hex view functionality with the next patch, and I will create an xdelta or similar patch once I've completed my original goal (Tennokoe Bank functionality). Dave
|
|