|
Post by enthusi on Aug 4, 2022 14:16:15 GMT
Yes, I see. Well, I get around so far. Building up some Make-framework still. So little time. It seems the auto-increase in KING of size HALF? Also things I didnt fully get yet: - what are pages? (in KING content) - KING has two banks and I can't crosstalk between them - ok. But anything else that matters regarding those banks? And what is that talk about Data 2(R/W) 0x606 in KING? I thought it might enable me to OUT words into 0x604 which would then auto-magically hit both ports and auto-increase ONCE one word but humm... no. A simple 256 bitmap image gets displayed now, at least ;-) Maybe I already reached the point where I really need to reverse and read up even more, but if there is wisdom to share, I'm all eager to learn ;-) Thanks alot!
Edit: I had issues with auto-increase which falsely let me to belief it would be WORD size.
|
|
|
Post by enthusi on Aug 5, 2022 23:42:03 GMT
Oh my I guess the good news is that my King BG kinda works as well as my asm mandelbrot code (and some sprite test as well). I'm not sure if I can call the palette code a success and BOY, does this differ from mednafens output... Some of it I understand (one probably should not update the palette anytime during display) but something else is hardcore-weird. At first I thought it's my out.w to the KING data (which themselves appear to work) but this might be supertricky to debug. Transfers to KRAM appear to kind of double the image horizontally and not in mednafen. You can even crudely tell from the Mandelbrot image. Does the autoincrease maybe require the READ address to be set as well?
|
|
|
Post by enthusi on Aug 6, 2022 0:15:47 GMT
Phew Fixed it all. I had the 64k color mode microprogram somehow but assumed 8bit colors. Actually mednafen happily ignored the 0,1,2,3,4,5,6,7 microcode and acted as if it was that plain 0,1,2,3. Well, I am very happy now and may go to bed, eventually. A few CDs used but then again, I'm happy running homebrew is so easy after all. \o/ For those that can't be put off by a boring length video with little action: Thank you for your help so far. I hope no one minds me keeping posting progress every now and then. Actually you can zoom in rather nicely and keep the details. Beautiful PC-FX <3
|
|
|
Post by dshadoff on Aug 6, 2022 2:10:13 GMT
This is pretty cool ! If you find discrepancies between Mednafen and real hardware, please post about that too. Particularly if you have code that can demonstrate the issue.
|
|
|
Post by enthusi on Aug 6, 2022 10:02:45 GMT
Yes, after some cleanup I will happily render an example case of that behavior and report it to the mednafen forum. That worked rather well with some VirtualBoy issues. I still think fully assembly is possible for the PC-FX but I haven't really seen much of it's features yet. Is there an Audio engine available for the FX? Haven't seen anything and what I heard in homebrew screamed 'no'.
|
|
|
Post by dshadoff on Aug 6, 2022 13:19:20 GMT
Yes, after some cleanup I will happily render an example case of that behavior and report it to the mednafen forum. That worked rather well with some VirtualBoy issues. Yes, you should report it there, but also report it here, please. I have been working on a Mednafen fork specifically to fix issues which have been reported but never addressed (especially when fix code has been provided). 95% of the work has targeted the PCEngine module, but I’ve got a soft spot for the PC-FX too (though Ihaven’t done any programming for it yet). (Though I’m less likely to support the other modules). of course, the best solution is to get an official bugfix.
|
|
|
Post by enthusi on Aug 6, 2022 15:33:03 GMT
Ah, yes. I saw a fork aiming at improving PCR dev/debugging. Compiled that (or a fork thereof, I forgot and had no proper overview) last night and didn't detect any changes for the PC-FX. I think it helped accidentally in realizing that I had the wrong microcode. Also I saw no changelog or help indicating what's new and how to access it.. but maybe I should have tried it for PCE instead. If you can recommend anything for PC-FX?? I lack the time right now but someone really should patch the BIOS for dev cycle purposes. It's on my list. There is no commented disassembly of the BIOS, right?. It is painfully huge though. Exciting beast this console for sure 😊
|
|
|
Post by dshadoff on Aug 6, 2022 17:33:10 GMT
|
|
|
Post by enthusi on Aug 6, 2022 18:38:10 GMT
I saw those screen shots (cool!) But for PC-FX all looks like default mednafen? Or should I have reset the classic mednafen config or anything like that? Also I do not seem to find a way to show KRAM as Bitmaps? I'm really not too experienced with mednafen so I may have overseen things that were not even new in the fork and hence not discussed. Is there anything you feel I should know/realize when it comes to plain PC-FX? In my code I currently have no 7up sprites even...
|
|
|
Post by dshadoff on Aug 6, 2022 18:56:13 GMT
Well, I don't program on the PC-FX, but "one day" maybe. Currently I only know bits and pieces of the architecture, so those are the pieces I can comment on.
Most of the "new in fork" things for PC-FX relate to debugger formatting and backup memory, not the video so much. - The debugger formatting was easy to do , since it was just a natural extension of PC Engine-related new functionality. - The Backup RAM originated from my desire to eventually create a programmable FX-BMP cartridge for transfer of save games, and to use for bootable demos and tests (but more information is still needed before I can make one of those).
If you feel there's something missing from Mednafen that should be in there, I'm open to suggestions as long as they are well-defined and the behaviour is understood. Elmer will know more than I will about current functionality and limitations, and whether a function is unnecessary. We know that although Mednafen does a good job of emulation, there are still discrepancies between it and the real machine; it would be great to document these when they are known, as another long-term goal of mine is to get PC-FX running on MiSTer one day.
|
|
|
Post by enthusi on Aug 7, 2022 0:05:20 GMT
Yes, thanks for clarification. One question to you or maybe elmer : the KING only has ONE palette with 256 16bit entries? The offset only makes sense for the 4,16 color modes effectively? So all KING palette-based BG maps together can only have 256 different colors in total, correct? So I'd have to go for direct color bitmaps or less colors otherwise then. And if I wanted to mix bg0 as 256 col and bg1 as 64K wouldnt the microcode be 0,1,2,3,40,41,42,43,44,45,46,47, NOPs...? I thought it should be such, that there are NOPs to fill up such that the 4x values are all in either the first8 or last8 micro-code entries. Is there any place to REALLY read up on this? AND: I can not have any transparency for the non-palette-bitmap modes, right? I found an answer to my last question already. I CAN have transparency. Nice. Still missing solutions to having the proper microcode
|
|
|
Post by enthusi on Aug 7, 2022 9:51:06 GMT
Oh, at least I spam my own thread. It seems to me now that no two 64k + 256col bitmap backgrounds are possible. Unless you can utilize them being in Bank A and the other in B (and then in high RAM in KRAM?). Also I'm about to go on laptop free vacation but that won't stop me from reading and as Elmer pointed out in the very early beginning, the actual details appear to be in the (half-auto-translated) docs that came with the PX-FXGA SDK. Maybe things are less obscure then and I feel more comfy with banks A/B and microcode PS: mednafen accepts and displays a 256col palette bitmap at 0x00000 and 64k bitmap at 0x20000 (adr given as 0x80*1024) and the microcode for the latter in the second half of the 16 bytes. But the real hw shows nothing instead so back to the reading up on this plan...
|
|
|
Post by elmer on Aug 7, 2022 13:11:00 GMT
PS: mednafen accepts and displays a 256col palette bitmap at 0x00000 and 64k bitmap at 0x20000 (adr given as 0x80*1024) and the microcode for the latter in the second half of the 16 bytes. But the real hw shows nothing instead so back to the reading up on this plan... I think we mentioned before ... Mednafen, like most other emulators, is designed to play existing published games, which by-definition work on the original hardware. It's not been concerned with enforcing the limitations of original hardware, which is something that only effects those of us that are trying to write *new* software for these old machines. One question to you or maybe elmer : the KING only has ONE palette with 256 16bit entries? The offset only makes sense for the 4,16 color modes effectively? So all KING palette-based BG maps together can only have 256 different colors in total, correct? Yes, there's just one palette, but it's 512-color not 256 (as you can *clearly* see by reading the HuC6261 document). From a display hardware POV, it's another render-as-you-go architecture, rather than a render-to-backbuffer architecture like the PS1, so just one overall palette. I thought it should be such, that there are NOPs to fill up such that the 4x values are all in either the first8 or last8 micro-code entries. Is there any place to REALLY read up on this?Yes, in the documents that you have been provided, which are the same ones given to the professional developers back-in-the-day. The microcode limitations (caused by accessing two channels of 16-bit RAM simultaneously) are *extensively* explained in documents, although the English versions of the docs really should be put through another round of Google Translate to make them more readable. Please keep on reading, and use Google Translate if something isn't clear.
|
|
|
Post by enthusi on Aug 7, 2022 13:40:44 GMT
Thank, again. Yes, I will follow your recent, first and ongoing advice. I just went in trying out lots of things while having hands-on time. I'm in a happy state. I understand (or so I believe) why most of what I did works and also to some extent why other things failed. The 512 colors I really missed. Possibly immediately assuming 256 halfwords (still used to bytes from 65c02 world and didn't even consider. Regarding medafen, I'm still impressed that it (and the general stuff that's being out there) is in such a good state given that there is practically no actual homebrew game that anyone had the drive/motivation/nerves to bring to an end. My brain starts on some who-is-who in this 'scene' but it's a bit messy I promise to get back to you/this on my return and at least publish my working examples.
|
|
|
Post by elmer on Aug 8, 2022 0:22:30 GMT
I promise to get back to you/this on my return and at least publish my working examples. You are far ahead of me on actually trying stuff and getting it working, and so hearing about your successes (and failures) is good information for all of us that care about the PC-FX. For myself ... I needed to take a break from the PC-FX after getting the compiler working and doing what I felt it needed to do, and I've just never got around to continuing the work on liberis and in putting together a fully-usable PC-FX development kit. At the moment, I've got at-least another 6-months of work on the PC Engine before I can even think of getting back to the PC-FX ... but having folks like you turn up and both enjoy learning about the machine, and help advance everyone's knowledge about it, really helps to motivate me to get back to it. Best wishes!
|
|