|
Post by 0x8bitdev on Apr 13, 2022 20:09:24 GMT
Let me know if there's anything that I can do to advise/help, either here or by private-message. It is a question of organizing the export process in the application itself. So I'll solve that moment to use assembly data. Nice! When you're done, I hope that you won't mind me seeing if I can modify your library for inclusion into the ongoing work on building a new development environment for the PCE that uses KickC. Of course I don't mind. The tilemap library is available in the latest release on the Github (sample projects: './samples/pce/tilemap_render'; compiled binaries: './samples/pce/bin/'; main header file: './samples/pce/common/mpd.h'). It provides a very simple interface, and it's quite strongly tied to specific exported data (and it's really hard to read the mpd.h, you'll know why ). So I don't know how it can be used somewhere outside.
|
|
|
Post by elmer on Apr 13, 2022 20:47:18 GMT
It provides a very simple interface, and it's quite strongly tied to specific exported data (and it's really hard to read the mpd.h, you'll know why ). So I don't know how it can be used somewhere outside. Hahaha ... excellent stuf, but yeah, that's far more C code than I want to touch, and it's all magnificently-obfuscated by the many optional bits that can make code such a pain to read and understand! Flexibility is definitely the enemy of clarity.
|
|
dogen
Deep Blooper
Posts: 30
|
Post by dogen on Apr 14, 2022 2:33:22 GMT
man... i'm so close I have the supergrafx drawing sprites.. but I can't seem to move them at all. Has anyone here programmed sgx in HuC? The sgx example didn't bother to demonstrate sprites (??!! !!??) so I've been hunting through the sgx_gfx.asm file... so far everything has been the same function calls but with sgx_ in front... including sgx_spr_x and sgx_spr_y (as far as I can tell at least) but I can't get them to move. Nevermind. Forgot to call sgx_satb_update();
|
|
|
Post by 0x8bitdev on Apr 14, 2022 14:50:06 GMT
Hahaha ... excellent stuf, but yeah, that's far more C code than I want to touch, and it's all magnificently-obfuscated by the many optional bits that can make code such a pain to read and understand! Flexibility is definitely the enemy of clarity. Everything has pros and cons. The main thing is that it works, tested and stable.
|
|
dogen
Deep Blooper
Posts: 30
|
Post by dogen on Apr 14, 2022 22:26:38 GMT
I think my demo might be getting close to where I want it. I have supergrafx and pc engine sprites working and moving around. A scrolling supergrafx background and a bit of sprite animation too. For some reason the PC engine background's colors are messed up, probably a palette issue because all of my graphics have messed up palettes lol Hope to get some music in there before too long..
|
|
|
Post by elmer on Apr 14, 2022 23:49:13 GMT
Good to hear that things are progressing.
|
|
dogen
Deep Blooper
Posts: 30
|
Post by dogen on Apr 15, 2022 2:25:57 GMT
I can't even begin to understand how you guys program this in assembly. There's more than enough details to keep track of in C.
|
|
dogen
Deep Blooper
Posts: 30
|
Post by dogen on Apr 16, 2022 3:14:13 GMT
Bros.. I've done it. 1 scrolling SuperGrafx 1 scrolling TurboGrafx background 1 SuperGrafx sprite layer 1 TurboGrafx sprite layer all working in tandem Btw I think the sgxtech.txt file floating around is wrong about the supergrafx priority bits. it says writing b10 to bits 7+6 and 3+2 in sgx registers 0x0008 and/or 0x0009 will make vdc2 sprites appear on top of the vdc1 background, but I had to write b01 to get them to show up.
|
|
|
Post by elmer on Apr 17, 2022 14:13:17 GMT
Congratulations on experimenting with what I consider to be the most-powerful home console of its generation! Note: Before somebody mentions the Neo Geo ... I don't think that it really counts as a "home console". It was really an arcade machine (and priced as such) that very-affluent home buyers could get hold of, in an era when home buyers could not normally go out and buy actual arcade machine hardware. I can't even begin to understand how you guys program this in assembly. There's more than enough details to keep track of in C. Honestly, I feel that people are far too afraid of assembly language, it's really not that hard. But what its biggest drawback is that it is *far* more verbose to write than a high-level language, and it takes longer to write it, because you do have to keep track of details that you don't have to keep track of in high-level languages. So yep, I do get your point.
|
|
dogen
Deep Blooper
Posts: 30
|
Post by dogen on Apr 17, 2022 15:46:14 GMT
Congratulations on experimenting with what I consider to be the most-powerful home console of its generation! Note: Before somebody mentions the Neo Geo ... I don't think that it really counts as a "home console". It was really an arcade machine (and priced as such) that very-affluent home buyers could get hold of, in an era when home buyers could not normally go out and buy actual arcade machine hardware. I can't even begin to understand how you guys program this in assembly. There's more than enough details to keep track of in C. Honestly, I feel that people are far too afraid of assembly language, it's really not that hard. But what its biggest drawback is that it is *far* more verbose to write than a high-level language, and it takes longer to write it, because you do have to keep track of details that you don't have to keep track of in high-level languages. So yep, I do get your point. Yeah, I mean, I've done some assembly. I'm not afraid as much as I 'd just rather not bother lol. I went through an nes 6502 asm tutorial a few months ago (https://famicom.party/book/). It was ok, but nowhere near as fun as this. All that extra detail is a drag imo, and makes it even harder to organize your code I think. I understand the benefit but man 15 chapters to get a single sprite moving and a repeating background. Obewbrew got that far by chapter 4 or 5 I think.
|
|
|
Post by 0x8bitdev on Apr 19, 2022 13:15:16 GMT
Does anyone know, is there a way to handle VDC interrupt in HuC ?
I need a VBLANK signal. The main idea is to synchronize dynamically loaded CHR data with the inner SATB. To avoid glitches, you can do that on VBLANK before screen drawing.
|
|
|
Post by dshadoff on Apr 19, 2022 14:42:13 GMT
The way I had always done it - though I’ll admit that it might be flawed - was:
In your main loop, there will be a ‘vsync()’ around which everything synchronizes. Immediately following this, you will be in vblank, so move your video data first… although you will be too late to catch the SATB transfer. Following this, do the motion logic. Following this, set up the VRAM SAT for the SATB transfer which happens at the start of VBLANK (in case you have a local copy in regular RAM). Back to the vsync() call….
|
|
|
Post by elmer on Apr 19, 2022 14:49:21 GMT
Does anyone know, is there a way to handle VDC interrupt in HuC ? Using interrupts is achievable within the HuC environment, but it's one of those things that you'll need to drop into assembly-language to accomplish. The C part of HuC just doesn't generate fast-enough code to use it for time-critical code such as interrupt handlers. You would also need to write your own asm code to upload the CHR data, because HuC's library call to copy data to VRAM uses self-modifying code, and so isn't interrupt-safe. Actually, you'll need to copy the entire HuC interrupt handler from startup.asm, because HuC (currently) uses slightly-different mechanisms to vector interrupts in the HuCARD and CD-ROM environments. On top of which, you should really save/restore the VDC VRAM write address register contents ... which isn't possibly, because they are read-only, and so again, not interrupt-safe. This might be solved (albeit imperfectly) if the library call was protected with a mutex, but since it isn't, writing to VRAM inside interrupt handlers is generally a bad idea unless you know that your main-loop is definitely waiting for the vblank (and so not writing to VRAM itself). Then again, if your main-loop is definitely just sitting there waiting for the next frame ... you're safer and better off by just doing what dshadoff has said and do a wait-for-vblank call, followed by uploading your modified CHR data as the first thing in your main-loop, where you're free to use HuC's load_vram library call. Note that another way to sync the CHR write to vblank is to write the CHR into a different area of VRAM, and then use the VDC's VRAM-to-VRAM DMA which executes during the vblank period. Does that help at all? If you really want to write an interrupt-handler, you can dig into HuC's startup.asm, but it'll take some understanding of both the underlying PC Engine hardware (which is pretty straight forward) and the HuC environment and philosophy (which is less so).
|
|
|
Post by elmer on Apr 19, 2022 15:12:49 GMT
The way I had always done it - though I’ll admit that it might be flawed - was: Actually, that sounds like a pretty-normal main-loop to me, whether you're programming in HuC or assembly-language. The biggest problem with that for both HuC developers and assembly-language developers using MagicKit, is that the standard interrupt handler mechanism in startup.asm isn't going to return control to the main-loop (following a wait_for_vblank call) until a lot of very time-consuming processing has been done, including the call to the 60Hz sound-driver update. This means that the developer has a *LOT* less time to invisibly update any dynamic CHR than would have been available if they could do their upload closer in time to the actual interrupt firing. Then again, on the PC Engine we have to be aware that VRAM is going to be busy processing the VRAM-to-SATB DMA first, so we need the interrupt-handler to be written to do *some* useful work at the start of vblank before even trying to write to VRAM. But these are really concerns for assembly-language developers that are trying to get the most performance out the the PCE hardware, and are (IMHO) not really things that HuC developers should worry themselves about.
|
|
|
Post by 0x8bitdev on Apr 19, 2022 15:38:52 GMT
dshadoff and elmer thanks for the detailed answer! I did all the synchronization logic in pure assembly. So I know how it works on a low level. But in HuC... 'vsync' is our all it's a compromise and it simplifies all the things. But brings a little more glitches at the top part of the screen, when animated metasprite appears there.
|
|