|
Post by monstersgoboom on Mar 18, 2020 18:50:43 GMT
I changed src\Make_src.inc to include this line CC = gcc May I ask why? Some HuC users build on BSD systems, and then there are also people building on Mac. That's not something I'm comfortable pushing. but that's what worked for me to make it build on windows.
|
|
|
Post by turboxray on Mar 22, 2020 15:51:22 GMT
Edit: "- no support for MinGW (Windows users are recommended to use Cygwin)" It was actually you that helped to fix the MinGW build years ago. I build with msys2/mingw-w64, and *never* with cygwin. I have no idea if it even builds with cygwin anymore. As for CMD or PowerShell ... why-on-earth do you want to use those? MSYS2 and mingw-w64 is the current-best way of building Unix programs on Windows ( www.msys2.org/), cygwin has become pretty irrelevent. Or to flip your question on its head; why would you restrict yourself to msys when mingw-make is perfectly capable of building it in cmd/ps? I mean this is a pretty simple build setup. CMD is trash 95% of the time, but it's also extremely convenient for windows platform. We use CMD all the time at work, because you can make python scripts directly executable with by making the first line of the file @setlocal and have it call python with itself being the argument and all other arguments past in, and just rename the .py file to .cmd. Also, not all the make files have clean in them.
|
|
|
Post by elmer on Mar 23, 2020 0:01:44 GMT
but windows build under mingw throws a fit for the makefiles. I had to edit a lot of them to get it to build. There was also a reference to 'cut' in the Date variable in make, which doesn't exist on cmd or powershell. Or to flip your question on its head; why would you restrict yourself to msys when mingw-make is perfectly capable of building it in cmd/ps? As you pointed out yourself in the first message, no, mingw-make is *not* perfectly capable of building it in cmd/ps ... you had to edit a bunch of stuff to make it work, and to remove the use of standard Unix tools that don't exist on default Windows systems. Heck, and it's not as though mingw-make exists on a default Windows install either. If you've got to install something (including Python, if you want it), then why not install something that does the job properly, and provides a comprehensive set of Unix tools for build-compatibility, but yet still generates standard Windows executables that don't involve the need for a bunch of DLLs (in the way that cygwin does)? Next question ... where does your mingw-make itself come from? The old MinGW32 project stagnated and died years ago. If you're using a version compiled with mingw-w64, as used by all modern Linux distributions to cross-compile for Windows, then why not commit to using the full modern toolchain and install MSYS2? MSYS2 is just a wrapper project around mingw-w64 that creates a usable Unix-like environment that runs natively on Windows, without any of the emulated-computer and linux-kernel rubbish that Microsoft is pushing in their recent Windows Subsystem for Linux. Using MSYS2/mingw-w64 allows building stuff far more complex than HuC, and I use it for building lots of software from source, and so I don't just use it for HuC. Hacking everyone's build scripts just so that I could use the gawd-awful PowerShell really doesn't seem like much of a step forward to me, and neither does using MSYS2 seem like a restriction, it is actually the opposite, it opens up the ability to compile hundreds of packages that don't natively exist on the Windows platform. Also, not all the make files have clean in them. Most do, but nope, as you say, not all. It's not annoyed me enough to fix it, yet. Please feel free to fix the makefiles and submit a patch!
|
|
|
Post by monstersgoboom on Mar 23, 2020 0:32:08 GMT
I've made some other changes . Added .dd keyword for definition of 32bit numbers to the assembler.( Not HuC ) And added support for load_vram2 which was documented but either removed or never added. I assume nobody else needs those otherwise it would have come up before
|
|
mooz
Deep Blooper
Posts: 29
|
Post by mooz on Apr 15, 2020 8:58:02 GMT
Ho crap and I have my own fork of pceas that I modified in order to make it compatible (to some extent) with ca65.
|
|
|
Post by spenoza on Apr 15, 2020 13:19:15 GMT
You guys need to do less forking and more spooning.
|
|
nicole
Gun-headed
Posts: 50
Fave PCE Shooter: Magical Chase
Fave PCE Platformer: Legendary Axe II
Fave PCE RPG: Ys III
|
Post by nicole on Sept 20, 2020 1:34:11 GMT
Hope this isn't too much of a bump. I'm working on a CD-ROM HuC game using the jbrandwood fork of HuC; I'm having a lot of trouble though getting the CD-ROM error overlay functionality working with isolink; I simply get a black screen and judging by the contents of RAM, none of my code has run. Is this feature supposed to work?
|
|
|
Post by elmer on Sept 20, 2020 2:46:51 GMT
Are you building HuC from the latest source in my github, or are you using the last "release" build that I made available in my stickied thread here?
There have been a *lot* of code changes in that area that aren't checked into github because they're work-in-progress, and I *may* have accidentally checked something into github that breaks the functionality that you need ... ISOLINK and the whole startup process have had some major work done to them.
OTOH, you *may* just be using things incorrectly (since the example documentation isn't as clear as it could be).
What kind of CD error handling are you trying to do? Super System Card missing, or something else?
|
|
nicole
Gun-headed
Posts: 50
Fave PCE Shooter: Magical Chase
Fave PCE Platformer: Legendary Axe II
Fave PCE RPG: Ys III
|
Post by nicole on Sept 20, 2020 14:52:58 GMT
Are you building HuC from the latest source in my github, or are you using the last "release" build that I made available in my stickied thread here? There have been a *lot* of code changes in that area that aren't checked into github because they're work-in-progress, and I *may* have accidentally checked something into github that breaks the functionality that you need ... ISOLINK and the whole startup process have had some major work done to them. OTOH, you *may* just be using things incorrectly (since the example documentation isn't as clear as it could be). What kind of CD error handling are you trying to do? Super System Card missing, or something else? Yes, I'm trying to do a Super System Card message missing.
I was using a custom-built version of HuC from github, but the release version doesn't change whether it works or not. (I did have to rebuild the release version using the Makefile, but I think that's just because I'm running it on Windows Subsystem for Linux)
I'm building the CD error using "-fno-recursive -msmall -cd -over" flags, and "-cderr" option on isolink. It does use "cd_loadvram" to load graphics into VRAM; is that not allowed in an error overlay?
|
|
|
Post by elmer on Sept 21, 2020 17:02:03 GMT
Yes, I'm trying to do a Super System Card message missing. I was using a custom-built version of HuC from github, but the release version doesn't change whether it works or not. (I did have to rebuild the release version using the Makefile, but I think that's just because I'm running it on Windows Subsystem for Linux) OK, thanks for the information! I'm building the CD error using "-fno-recursive -msmall -cd -over" flags, and "-cderr" option on isolink. It does use "cd_loadvram" to load graphics into VRAM; is that not allowed in an error overlay? IIRC that certainly sounds like the correct process, and also IIRC you should be able to use those library functions. The whole overlay system was confusing the heck out of me, which is why I started to take a look at it many months ago ... especially since there doesn't seem to be a good example/test actually built into either the original HuC, or Uli's new HuC (although Dave did release a nice-and-simple overlay example many years ago). Let's continue this by PM and we'll see if I can help debug what is going wrong.
|
|
|
Post by dshadoff on Sept 21, 2020 20:46:59 GMT
Hmm... I'm not sure whether this will be helpful, but I placed a bunch of sample code here, nearly 20 years ago: www.zeograd.com/creation_download.phpIn those examples, I tried to demonstrate some basic patterns for people to expand on. I just looked, and there is a "Sample Code - CDROM Overlays" there. Unfortunately, while it shows transfer of control from one program to another (including data), it doesn't explicitly demonstrate the System Card error overlay functionality. I don't think I have an example of that anymore. (Note that examples worked as of HuC 3.21, but I am not familiar enough with subsequent versions to judge). elmer is your best bet to get this going for you.
|
|
|
Post by elmer on May 10, 2022 20:46:36 GMT
Are you building HuC from the latest source in my github, or are you using the last "release" build that I made available in my stickied thread here? There have been a *lot* of code changes in that area that aren't checked into github because they're work-in-progress, and I *may* have accidentally checked something into github that breaks the functionality that you need ... ISOLINK and the whole startup process have had some major work done to them. OTOH, you *may* just be using things incorrectly (since the example documentation isn't as clear as it could be). What kind of CD error handling are you trying to do? Super System Card missing, or something else? Yes, I'm trying to do a Super System Card message missing. I was using a custom-built version of HuC from github, but the release version doesn't change whether it works or not. (I did have to rebuild the release version using the Makefile, but I think that's just because I'm running it on Windows Subsystem for Linux)
I'm building the CD error using "-fno-recursive -msmall -cd -over" flags, and "-cderr" option on isolink. It does use "cd_loadvram" to load graphics into VRAM; is that not allowed in an error overlay?
Well, back then I was worried that my changes to ISOlink had broken HuC's handling of the "Super System Card missing" error message/overlay ... but nope, it looks like Uli broke it all the way back in 2014! This should be fixed now ... finally.
|
|
|
Post by elmer on May 10, 2022 20:54:10 GMT
Oh, as a side-effect, this should hopefully cure HuC's limitation of requiring the first CD-ROM overlay to be a maximum of 192KB, instead of 256KB for other overlays.
|
|