It's been ~years since I've really done anything with libfxcg, but motivated by multiple people recently looking for help in getting set up, I've done some work to build complete SDK packages again.

Before I go releasing a new SDK package and trying to find pointers to the old ones and update them so people don't go trying to use old things, I'd like to hear if anybody has major comments on what I've changed. Highlights:
  • Removed examples using alternate build systems, instead blessing the "prizmsdk" style makefile as the one supported approach. This seems to be what everybody uses in practice, and there's nothing stopping people from doing whatever they like in the privacy of their own repositories. Blessing a single approach should make it easier to anybody to build a given program given the source without needing to figure out how the author expected things to be configured.
  • Continue using a sh3eb-elf- toolchain, since in practice that appears to be what everybody uses (rather than a prizm- toolchain that's preconfigured with include paths and whatnot).
  • Automatically build an up-to-date toolchain and package it with the libraries. To do, also package just the libraries to drop into an existing SDK or custom configuration.

If I don't hear anything soonish I'm going to go ahead and make a new release with these changes, under the assumption that everybody things they're good, but I'm particularly interested in whether this might motivate people who've been doing their own thing to use our provided system- because the regularity will be beneficial to all developers.

TL;DR: Will a new release convince you to use the "official libfxcg" PrizmSDK?
A new release would convince me to use the "official libfxcg" PrizmSDK, especially since that's what I used back in the day. I can't guarantee I'd actually create anything, but it would certainly make it easier for me.
I'd be super behind this! I'm actively working on my "fork" of the SDK here:

https://github.com/tswilliamson/PrizmSDK

I made it a bit more windows friendly and changed the make files to be smarter about using the current folder structure rather than having to specify a FXCG folder in the environment.

In addition to the utils in there, I'm still working on stable utils for sounds, performance profiling, etc that I haven't pushed to github yet.

I would very much like to switch this to a real fork of an official SDK, but it would need to have the utils folder concept I added in incorporated. It's nice to be able to have dependencies for common use cases built into separately linkable utility libraries, so my code can all sit in appropriate repos, and incorporate this into the official project make system.
Cool, that's helpful. I suppose you haven't seen that I already filed an issue to look at adopting some of your changes so I'm happy to work with you to figure out how to do that nicely.
Let there be v0.5!

I also added some "getting started" documentation to the repo, including a quick walkthrough (with screenshots) for Windows users who aren't familiar with these things. Consequently, I've also updated some of the SDK documentation on WikiPrizm to point to libfxcg rather than now-obsolete ad-hoc documentation/packages.
Cool! I will be able to update my toolchain the easy way Smile I will look into updating my version with this so it makes for an easier merge.

Covid is killing my productivity these days, but April 11th was my birthday! Thx for the present
Thank you all for resurrecting this project - i will give it a proper try at some point when I have more time and will try to rebuild some of my projects with new sdk and make them compatible where possible with cg50 and os3.+. I did try just your libc.a library and it seems to be not producing the expected result with longjmp system call - i was trying to compile the part of gbl08ma’s utilities add-in which uses longjmp and unlike his original addin this one forces the calculator restart Sad. I wonder if the new sdk will make it easier to compile many open source addins we have including programmernerd’s ones which may need fixing for cg50 for example. I don’t mind testing compiling gbl08ma’s eigenmath (or its remake by parisse), as well as image viewer, utilities, as well as programmernerd‘s mpeg2 viewer and parisse’s khicas - if i remember correctly i could never succeed compiling any of them on windows and most of them had additional libraries for math, image etc - I think it will be a huge boost for community to be able to compile them on windows and perhaps an ultimate test of the new sdk. Good luck and let me know if I can help with some of the tests for the above
It's possible I misconfigured something terribly because I don't have a calculator available to test the emitted binaries.

If you could try to nail down what's changed, I expect I've done something silly.
Hi Tari, I finally got to a good point to integrate all of your new binaries/toolchain. Pretty much everything I am throwing at it after adapting my makefile is crashing on boot w/ a pretty weird PC register.

In order to get NESizm to build I had to:
- remove my c std lib malloc/free calls to use sys_malloc and sys_free, as _calloc was failing to be found on link
- revert mkg3a to the version from the previous SDK version. The mkg3a in the release is failing to read the .bmp files I'm using for my icons (reading past EoF for some reason)
- include a few cygwin dlls in the bin folder that were in previous releases, Windows was still depending on them.
- removed the ilram references in the prizm.x toolchain file, as I am using ilram with direct addressing so it can free the system bus for screen DMA, I don't want the compiler utilizing that space

The final .bin file was about 13kb smaller. I'm hoping this is because the latest gcc would be that much more efficient, not due to a bug, because that would be amazing! Anyhoo, yeah something's misconfigured. Let me know how I can help.
If I can reproduce what you've got we can try to inspect the differences and see what's going on. I'm guessing at the moment that the compiler is misconfigured and simply emitting binaries for a slightly-wrong CPU.

So, how do you build NESizm right now? Is it with https://github.com/tswilliamson/PrizmSDK and the sources at https://github.com/tswilliamson/nesizm?

Then if you can provide the source that you're building against the new SDK I can see what they're doing differently.

Quote:
- remove my c std lib malloc/free calls to use sys_malloc and sys_free, as _calloc was failing to be found on link
- revert mkg3a to the version from the previous SDK version. The mkg3a in the release is failing to read the .bmp files I'm using for my icons (reading past EoF for some reason)
Can investigate these given your sources.
Quote:
- include a few cygwin dlls in the bin folder that were in previous releases, Windows was still depending on them.
The new builds never touch anything cygwin, so I think you have something old kicking around.
Quote:
- removed the ilram references in the prizm.x toolchain file, as I am using ilram with direct addressing so it can free the system bus for screen DMA, I don't want the compiler utilizing that space
Anything in the ilram section gets put there, the compiler won't use it on its own. You shouldn't need to remove it.
Here is the link to a 7z of the last state I had it in:

https://drive.google.com/open?id=1OB9pO-zlMV3X-9GskcJSYxuVvXwFMFPS

Let me know when you've pulled it so I can free up my Google Drive space Smile

I am building through VS for nesizm but the make-DeviceRelease.bat file should do the same exact thing as my VS NMake setup in terms of calling make. I didn't figure it out yet but it fails to rebuild because the intermediates folder still exists and I'm guessing RM isn't working.

The Cstdlib change I made is in platform.h in projects/nesizm, stuff related to including fxcg/heap.h and the defines below it.

The Cygwin DLL's were only needed in my separate utils make. I'm guessing it was because it uses $(RM) instead. Of note: this works to clean up intermediates/object files correctly.

Per ilram: sure, but I don't trust it! lol but really was trying to figure out if that was crash related.
Okay, I've pulled your archive. No promises on when I'll get to dig into it, but this should at least give me the tools to investigate what it's doing.
Thanks. If you want me to try anything specific I'm happy to help! Looking forward to an updated gcc, maybe we'll get auto and lambdas working Smile
Can you try inserting pauses in your early code to see if the problem is only after it jumps into your code (and if so where) or whether it's in the SDK startup code?
It wasn't ever able to get into main()

I did some digging for you. It is crashing at PC=0x0810946C TARGET=0x0031C36B, which from the output.map file (link: https://www.dropbox.com/s/mr6jkyd28sz7xhc/output.map?dl=0 ) is initial ctors, possibly stdout:

.data._impl_stdout
0x0810945c 0x10 C:\Users\Thomas\Documents\Prizm\PrizmSDK-Tari\projects\nesizm\proj\/../../..//lib\libc.a(stdio.o)
0x0810945c __impl_stdout
0x0810946c _edata = .

.ctors 0x0810946c 0xc load address 0x003257d3
.ctors 0x0810946c 0x4 frontend.o
.ctors 0x08109470 0x4 nes_apu.o
.ctors 0x08109474 0x4 nes_cart.o

0x31C36B is a bit more cryptic:

.data 0x08100004 0x9468 load address 0x0031c36b
0x0031c36b _datald = LOADADDR (.data)
0x08100004 _sdata = .

My best two guesses: either some data area is wrong, OR this is a 4-byte alignment issue that the compiler is not protecting against with its symbol placement.
The LMA for the data section you've given me is definitely wonky. Disassembling a g3a I see v_datald is 0x31C95F, and crt0 does a wordwise copy to RAM, so I don't expect that to work.

Can you try tweaking the linker script to ensure .data and .bss are word-aligned for crt0?
Code:
diff --git a/toolchain/prizm.x b/toolchain/prizm.x
index 9b64317..0d15d6d 100755
--- a/toolchain/prizm.x
+++ b/toolchain/prizm.x
@@ -36,7 +36,7 @@ SECTIONS
         } > rom

         /* RW initialized data, VMA in RAM but LMA in ROM */
-        .data : {
+        .data : ALIGN(4) {
                 _datald = LOADADDR(.data) ;
                 _sdata = . ;
                 *(.data)
@@ -45,7 +45,7 @@ SECTIONS
         } >ram AT>rom

         /* Uninitialized data (fill with 0), in RAM */
-        .bss : {
+        .bss : ALIGN(4) {
                 _bbss = . ;
                 *(.bss)
                 *(.bss*)

If this doesn't work I'd like to see the resulting g3a to inspect it further.
ALIGN(4) worked! NESizm runs now. Though this isn't strictly the best way to do it. It should theoretically be aligning based on the data type for SH4. Any words are bytes can be safely loaded at 2 and 1 byte boundaries, respectively. It appears to be adding several kB to the package.

What remains:
* There are numerous errors for me in the program itself, which are probably related to a few fixes in libfxcg I've made over the years. I will try to dig them up over the next couple days. Mostly related to bad string and memory routines
* mkg3a is still the old one, the new one is erroring trying to read the .bmp files
* the linker didn't define _calloc so I am still directly calling syscalls for malloc and free which isn't very portable
* I haven't solved my requiring cygwin problem yet

Unfortunately there doesn't seem to be a speed increase, in face it looks a smidge slower (like 0.5%). I can probably find the right compiler options to remedy that. Additionally just being able to use more C++ features will be a breath of fresh air. I'd love to have the option to select sh4 as a compile target. I think I could get some more speed there.
Great to see you are making progress - I’m too scared to try it properly yet (too many failed attempts over the years trying to compile gbl08ma and programmernerd’s excellent addins) - I hope your progress will eventually allow trouble free compiling of many more addins on windows. Thank you again
tswilliamson wrote:
It should theoretically be aligning based on the data type for SH4. Any words are bytes can be safely loaded at 2 and 1 byte boundaries, respectively. It appears to be adding several kB to the package.
Huh? Our startup code (crt0) only includes code to do work-aligned initialization, and I don't think it's worth including code to handle misaligned sections since that would end up being larger than the maximum waste of 6 bytes in aligning them.

Quote:
* There are numerous errors for me in the program itself, which are probably related to a few fixes in libfxcg I've made over the years. I will try to dig them up over the next couple days. Mostly related to bad string and memory routines
I look forward to it.
Quote:
* mkg3a is still the old one, the new one is erroring trying to read the .bmp files
I've released mkg3a 0.4.1 which fixes this (at least in CI), turned out there were some rather embarrassing memory errors (use-after-free) in mkg3a. You can grab an updated package from the CI status page until there's a new release.

Quote:
* the linker didn't define _calloc so I am still directly calling syscalls for malloc and free which isn't very portable
Right now the headers #define malloc and friends to the syscalls so you're probably missing a header or something. But I have a better plan to make this nicer.

Quote:
* I haven't solved my requiring cygwin problem yet
I assume this is because you haven't picked up the makefile changes that remove the need for unixy tools on windows.

Quote:
I'd love to have the option to select sh4 as a compile target. I think I could get some more speed there.
Isn't it already targeting sh4 via -m4a-nofpu?
Hi there, I see there is still activity on development methods for the fx-CG around here. I just wanted to let you know that we also develop stuff for the fx-CG 50 (specifically the French Graph 90+E) on Planète Casio, and I'd be happy to bring our communities closer together to share the projects. (I know we were closer in the past and I'd like that to happen again!) Smile

We have a whole different setup than you since our methods diverged at some point, most of us develop fully under Linux; we no longer use the PrizmSDK as we have developed custom kernels. For instance I have written one for add-ins with all custom drivers, another member (Yatis) developed one that can trace and debug system calls.

But ultimately projects work the same way and the hardware documentation can be shared, and that's what I'd like to do. I've seen Tswilliamson's awesome sound method which we never discovered, and I'm sure some of our stuff could be useful here as well.

Cheers!
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 3
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement