CC65 and the PCE

[elmer]

Does anyone know of any kind of organized attempt to get PCE support finalized for the CC65?

The toolchain already supports the HuC6280 ... so from what I can see, it just needs to have the memory descriptor and startup code done, and then any custom library routines written.

Is this an everyone-fend-for-themselves situation?

[Arkhan Asylum]

yep.

Tom (bonknuts) might have done that awhile ago or tried to.  I can't remember.

I think there's not much of a push for it because C is too slow to get anything done really, so you end up in ASM faster than you think.

[elmer]

It will certainly be a lot easier for me, personally, to just go my own way and strip the C compiler and libraries out of the CC65 source, and be left with the decent quality macro assembler and linker that I want.

In fact ... it only took about 10 minutes ... all done!

The point of going the CC65 route for assembly-langauge programmers like me, is that the CA65 assembler and LD65 linker are much more capable than PCEAS.

[EDIT]
The actual CC65 compiler looks like it's much nicer than HuC ... but I still don't personally think that C really has any place on the PCE.

I thought that some other people here might have wanted a better C compiler, though.

[Arkhan Asylum]

More capable how?

[elmer]

More capable how?

If you are asking about CC65 vs HuC, then I'll just point you to Bonknuts's blog ...
https://pcedev.wordpress.com/2014/02/22/small-c-on-the-pc-engine/

Krikzz has also said that he's using it now.

If you are asking about CA65 vs PCEAS, then I'll say that first of all, I'm more comfortable with a traditional linker-based workflow.

The entire game development industry moved to that workflow instead of the early monolithic all-in-one development systems, and the surrounding tool environment supports it better. The last all-in-one system that I used was in the late 1980's.

From my POV, I can set up an assembler/linker environment for the PCE that flows just like a C-based environment for the PC-FX (or for the PlayStation4 for that matter). That's especially useful when doing cross-platform development.

When the PCEAS documentation says that it is "perhaps" unique due to its concept of "Data Grouping" ... it isn't.

It was common in the better romable environments for the C64/Atari, and then the professional dev environments like SNASM supported it on the ST/Amiga/Genesis/SNES/PlayStation/Saturn/etc.

The bank/origin abstractions in CA65 are much more like SNASM's abstractions and so much more familiar to me than PCEAS ... and, unless I'm missing something about PCEAS, more powerful.

[EDIT]
The lack of any sensible debugging information output from HuC/PCEAS has left the entire PCE homebrew toolset in a state that would have been seen as sub-par for professionals in 1987.

Even the hacker/homebrew scene in the 1990s had better tools ...
http://otakunozoku.com/rednex-gameboy-development-system/

Carsten Sørensen & Justin Lloyd's free RGBDS, together with the nocash's No$GMB emulator, was used by a lot of professional developers to avoid the horrible official Nintendo devkit.

I believe that Mednafen's Ryphecha knows nocash, and I'm still horrified that Mednafen doesn't offer source-level debugging.

At least part of the reason could be that tools such as HuC/PCEAS just don't output the necessary information.

[dshadoff]

The lack of any sensible debugging information output from HuC/PCEAS has left the entire PCE homebrew toolset in a state that would have been seen as sub-par for professionals in 1987.

Even the hacker/homebrew scene in the 1990s had better tools ...
http://otakunozoku.com/rednex-gameboy-development-system/

Carsten Sørensen & Justin Lloyd's free RGBDS, together with the nocash's No$GMB emulator, was used by a lot of professional developers to avoid the horrible official Nintendo devkit.

I believe that Mednafen's Ryphecha knows nocash, and I'm still horrified that Mednafen doesn't offer source-level debugging.

At least part of the reason could be that tools such as HuC/PCEAS just don't output the necessary information.

Feel free to create any toolchain you see useful.  We're all very interested to see what can be done !

HuC/PCEAS were put together as a hobby project (and initially I didn't even agree that HuC was appropriate... but I still contributed because I thought it was an interesting thing to study and learn from).

Feel free to take whatever fragments you like from the assembler libraries for your own project - I wrote a large part of the HuC libraries with the original thought that HuC would be too slow, but that there also wasn't enough documentation about the system: it was my thought that people would prototype in HuC, then hand-optimize appropriate sections of the code in assembler.

Without "in-context" examples of how to get the hardware to do what you want, there would be no development and no interest whatsoever, so the libraries were written.

As for the tools themselves, David Michel (who originally grabbed both the assembler and C compiler from open-source projects) wasn't aware at the time of any others to start from, so he grabbed what was available.  Everything else at the time (mid-90's for ASM; late '90's for HuC) seemed to be 16-bit and 32-bit dependent, including (in most cases) assuming that 'byte' arithmetic could never be more efficient than (at least) 16-bit 'int', so there was a lot of excess casting and 16-bit math inefficiency going on.  Maybe other tools were available and usable, but either he didn't know about them, or it seemed like a *LOT* more work at the time.

Whatever the case, anything you can do to help improve the condition of dev tools would be very much appreciated.

[TurboXray]

Yeah, the full control over where subroutines are placed in banks/addresses is incredibly powerful.

A linker would be nice (I used AS for 68k stuff for Genesis dev, it was nice), though I've gotten used to not having it for PCE stuffs (relocating self-modifying code being the only thing I remember wishing I had a linker for; all the addresses/labels had to resolved to relative values using equates). IIRC, for debugger support - shouldn't the symbol file that PCEAS outputs be enough to a debugger to use?

 On a side note, I read that most C compilers usually tended to use only 1 or 2 address vectors (pointers) for compile code (two if you need a source and destination). HuC treats all pointer access as long, which is one reason the why local array access is soooo slow. I guess the vector address registers of the arcade card would make a decent speed up in this respect. This is something I wouldn't mind in the extended system card, but I didn't mention it because it deals specifically with C and not ASM. That, and it would have required additional hardware from something that's specifically a compiler level issue.

 I used snasm for a while, but it didn't allow including a binary file and then reassembling on top it, which is why I switched to another 68k assembler.
 
 Which reminds me of something. The mednafen author and I worked on creating a subtitling device for PCE CD game. It was basically a 68k+bitmap device that overlaid video on top of the PCE. The 68k had shared memory with the PCE via in the open bus range of the hardware bank. The 68k also had its own ram. The idea was to initialize and enable the 68k on boot of a CD game (your own routines), copy custom data over to the 68k memory via that port (the 68k had a boot rom). Then when you wanted subtitles, you would hook the games routine to jump to an alt place in which it would copy over the arguments from the bios function call to the 68k device, to which it would look up in a data base for a script to display as an overlay. There's a special build of mednafen for this, and the idea was to make a real composite signal overlay device (a composite pass through) that would function on a real machine (no physically opening up the machine, this was an external device). Though the MCU didn't need to be 68k based for the real device, since the script data being uploaded was the important part, we decided on the 68k to prototype how the device would work (plus that 68k would manually create the bitmap overlay in realtime).

[Bernie]

I feel so dumb after reading this...so damn dumb...

[synbiosfan]

I feel so dumb after reading this...so damn dumb...

You're not alone.

I keep reading,  hoping to one day to figure it out myself.

[elmer]

I feel so dumb after reading this...so damn dumb...

Please don't ever feel dumb or intimidated just because other people have a bunch of crazy domain-specific knowledge/experience that you don't.

I'm sure that there's a hell of a lot of stuff that you know that would have me scratching my head.

Feel free to create any toolchain you see useful.  We're all very interested to see what can be done !

I'll release everything that I do at some point. That is part of the fun in doing it.

But be forewarned ... it will be tailored to my personal way of doing things, and probably won't be to everyone's tastes.

That's another part of the fun ... that programmers can modify other people's stuff to suite their own tastes.

From what I've seen, there's very little difference between good homebrew programmers and good professional developers ... it's all about the investment in, and access to, good tools.

Until Unity came around, the average small team just didn't have access to an expensive-to-create toolset.

HuC/PCEAS were put together as a hobby project (and initially I didn't even agree that HuC was appropriate... but I still contributed because I thought it was an interesting thing to study and learn from).

People like you and David Michel and Charles MacDonald created the possibility for the rest of us to play here; you have nothing but my respect.

What you guys did to create MagicKit, HuC and PCEAS was amazing ... and doing so entirely without access to the official documentation is mind boggling.

One of the biggest things that drives toolchain improvement is competition ... because each competitor comes up with ideas to outsmart their competition ... and the cycle keeps repeating.

From what I can see, HuC and PCEAS have had no real competition, and stopped evolving in the early 2000s after they'd reached the point that they did everything that the people that created them needed them to do.

I'm just stirring things up a bit with a different set of expectations.

If I don't back up my observations with some action to improve things ... then you'll have every right to just dismiss me as a whining idiot.

Feel free to take whatever fragments you like from the assembler libraries for your own project.

Thank you. 

I'll grab what I can ... but I do have to admit to like writing as much of my own stuff as I can ... I find the learning part to be fun.

I didn't really want to have to mess around inside GCC to get the PC-FX C compiler updated ... but I have to say that it's been an interesting experience (although combined with considerable grief from the never-to-be-sufficiently-damned GNU build system).

Yeah, the full control over where subroutines are placed in banks/addresses is incredibly powerful.

Definitely agree! 

IIRC, for debugger support - shouldn't the symbol file that PCEAS outputs be enough to a debugger to use?

Yep, what's there should be enough to move things up to the next step ... symbolic debugging.

But in the last decade, nobody has actually taken that step!

I suspect that it's because, for whatever reason, most people are interested in hacking old games and not in creating new ones.

It doesn't help that while symbolic debugging is a great improvement for assembly language programmers, it's nearly useless for C programmers where the compiler writes most of the assembler code.

For C you need to have much more debugging information to get source-level debugging (with structure browsing), and HuC/PCEAS definitely doesn't output that.

To be honest, I'm not sure if CC65 does either, but as an assembly language programmer, I don't really care.

I am certainly not going to write a C source-level debugger for the PCE!

But I would like to try to get GDB hooking up to Mednafen for PC-FX debugging.

I used snasm for a while, but it didn't allow including a binary file and then reassembling on top it, which is why I switched to another 68k assembler.

Yeah, it's got the regular old INCBIN, but the capability that you're talking about ... nope.

It isn't really something that I've ever heard of being needed when developing new games, but I can certainly see that it would be extremely useful when hacking existing games.

SNASM was definitely designed for (and priced for) new game development.

Which reminds me of something. The mednafen author and I worked on creating a subtitling device for PCE CD games.

That's really cool! I've always wanted to do hardware stuff, but seem to be a bit of a physical clutz with a soldering iron. I'm a master at creating dry joints.

Your memory just sent me off on an investigation about creating a TMS99000-based SBC. It's the craziest CPU architecture that I've ever seen, and I always wanted to see what it was like to program. But there are too many other interesting things to do.

Did you get as far as a prototype, or were you still in the design phase?

[EDIT]
Totally off topic, but OMG ... both the TMS99105CPU and the V9990 (the VDP that didn't make it into the MSX Turbo R) are actually still available on eBay. That would make one heck of an interesting 1992-era homebrew SBC. It's a pity that I'm too dumb to design a board that would put them together. Especially in these days when board manufacturing has gotten so affordable. 

[Aladar]

From my little experience in developing a commercial-grade game(Bubble Bobble) I can say that PCEAS is adequate.
A nice addition would be the possibility for the code to go beyond the 8kB limit(PCEAS2 v3.22(Tomaitheous release) don't work correctly).

What I really need is a symbolic debugger...

[elmer]

From my little experience in developing a commercial-grade game(Bubble Bobble) I can say that PCEAS is adequate.

From what I seen that you've posted, you're doing a wonderful job on the game! 

Lots of early commercial games were written with far worse tools than PCEAS. I'd agree that it's perfectly adequate for developing good games.

A good programmer can work within almost any environment. Some early games were done with hand assembly and pieces of paper.

But in 2015 ... we don't need to do that anymore. You get to choose for yourself whether to keep on using PCEAS as it is, work on improving it, or move on to something else.

A nice addition would be the possibility for the code to go beyond the 8kB limit(PCEAS2 v3.22(Tomaitheous release) don't work correctly).

You can manually fix the bank crossings when they occur ... and just like bonknuts pointed out, you can do a bunch of equate hacks to fix up the relocations in self-modifying code.

With more sophisticated tools, you don't need those hacks, and your code is easier to write and clearer to read. It's not about whether you can ... it's about making it more pleasant to develop.

What I really need is a symbolic debugger...

Yep. That's my big complaint ... not my personal perception of weaknesses in PCEAS.

But if I'm going to be the one that has to try to hack Mednafen to provide that, then I think that it's going to be based upon whatever CA65 outputs, or that I can get it to output with some modifications.

[elmer]

Feel free to take whatever fragments you like from the assembler libraries for your own project - I wrote a large part of the HuC libraries with the original thought that HuC would be too slow, but that there also wasn't enough documentation about the system: it was my thought that people would prototype in HuC, then hand-optimize appropriate sections of the code in assembler.

...

As for the tools themselves, David Michel (who originally grabbed both the assembler and C compiler from open-source projects) wasn't aware at the time of any others to start from, so he grabbed what was available.

Aaaarrgggghh!!! 

OK, I think that I remember seeing this before, but since I'm taking a break from the PC-FX and looking at the PCE it has hit me over the head.

There is absolutely no copyright, licensing or attribution information that I can see in the HuC or MagicKit files. The closest thing is David's comments above.

Now I understand that back in the late 1990's and early 2000's people didn't care as much about that, and that nobody even cares about it today if it's just something that you hack around with yourself ... but ...

In order to get a cleanly licensed toolchain that I can put up on github ... I can't take any of the old HuC or PCEAS library code or includes, and so will end up with something that's almost certainly totally-incompatible with any current source code.

That sucks, and will only serve to make it harder for anyone but me to benefit from what I'm doing. 

David ... is there some way that you can sort out who wrote what and put some copyright and licensing information into the files?

The includes and library source are all the files that could be moved over to CA65, so just those files would need to be looked at.

If not, then it's back to typing in the includes from the Develo docs.

[dshadoff]

Aaaarrgggghh!!! 

OK, I think that I remember seeing this before, but since I'm taking a break from the PC-FX and looking at the PCE it has hit me over the head.

There is absolutely no copyright, licensing or attribution information that I can see in the HuC or MagicKit files. The closest thing is David's comments above.

Now I understand that back in the late 1990's and early 2000's people didn't care as much about that, and that nobody even cares about it today if it's just something that you hack around with yourself ... but ...

In order to get a cleanly licensed toolchain that I can put up on github ... I can't take any of the old HuC or PCEAS library code or includes, and so will end up with something that's almost certainly totally-incompatible with any current source code.

Well, I can break it down a bit for you:

Hints usually exist in the main.c files...

Assembler:
In src/mkit/as/main.c, there is an attribution for the Assembler:
/*
 *  MagicKit assembler
 *  ----
 *  This program was originaly a 6502 assembler written by J. H. Van Ornum,
 *  it has been modified and enhanced to support the PC Engine and NES consoles.
 *
 *  This program is freeware. You are free to distribute, use and modifiy it
 *  as you wish.
 *
 *  Enjoy!
 *  ----
 *  Original 6502 version by:
 *    J. H. Van Ornum
 *
 *  PC-Engine version by:
 *    David Michel
 *    Dave Shadoff
 *
 *  NES version by:
 *    Charles Doty
 */


HuC
David did mention once which C compiler he took over - it was the only one he could find that both supported 6502 and allowed for other people to take and modify it.  David was very specific on that point.  I did see the author's name once (And I would probably recognize it), but it escapes me at the moment, and I can't seem to find it easily at the moment.

It was, of course, heavily modified to support things like banks, an optimizer, inline code, an output memory space larger than 64KB, and so on.

Hint (from src/huc/main.c):
/*   File main.c: 2.7 (84/11/28,10:14:56)
 *
 * PC Engine C Compiler
 * Made by <unknown guy>, hacked to work on Pc Engine by David Michel
 * resumed work by Zeograd
 *
 * 00/02/22 : added oldargv variable to show real exe name in usage function
 */

While this doesn't name the author, it specifies 1984/11/28 as a key release date, so that should help.  It also explains why K&R C is supported, but ANSI C is not.    ;)

Update:
Doing a Google search for "P. L. Woods" who made numerous updates in functions such as getarg() (in src/huc/function.c), I found this:
https://github.com/begoon/smallc-85/blob/master/function.c
Pretty much verbatim for an earlier version of the code.

Looking further, I see that certain functions have the same original code as this C Compiler, published in Dr. Dobbs Journal:
http://gaby.de/ftp/pub/cpm/znode51/pcwworld/l101/user_0/zsc_1.c

Attribution:

Code Select Expand

SMALL C COMPILER  -  (Part 1)

Original version published in Dr Dobbs Journal of Computing Calisthenics and
Orthodontia, May 1980 , No. 45. by Ron Cain.

...Looks like this came from a source which was already multiply-duplicated, 30 years ago - but is closest to "smallc-85" already on github.



Libraries
Written completely from scratch.  I can tell you specifically which ones I wrote, but probably 70% of the library code was mine, especially the dual-boot targetting, overlays, ISOLINK, and mouse support.  David did the original startup (machine initialization), sprites, and scrolling.  Zeograd did the macros and some other pieces (hard to remember).

We got a lot of information from Develo books (before any of us started studying Japanese, this was hard to decipher), and pretty much everything else from reverse-engineering.

David ... is there some way that you can sort out who wrote what and put some copyright and licensing information into the files?

If you're looking for me to annotate the source code of PCEAS and HUC, that's a huge amount of work, which I can't undertake.  At best, I can try to find snapshots of earlier versions of these so you can see by diff what was added.  As I mentioned earlier, the PCE assembler libraries and macros are all from scratch, written by myself, Zeograd, and David Michel.

The includes and library source are all the files that could be moved over to CA65, so just those files would need to be looked at.

Oh, if I understand correctly, then we're fine as it is.

If not, then it's back to typing in the includes from the Develo docs.

Don't do that... it hurts.

[elmer]

Attribution:

Code Select Expand

SMALL C COMPILER  -  (Part 1)

Original version published in Dr Dobbs Journal of Computing Calisthenics and
Orthodontia, May 1980 , No. 45. by Ron Cain.


Yep, Ron Cain's Small C has gotten everywhere in the last 35 years!

I can tell you specifically which ones I wrote, but probably 70% of the library code was mine, especially the dual-boot targetting, overlays, ISOLINK, and mouse support.  David did the original startup (machine initialization), sprites, and scrolling.  Zeograd did the macros and some other pieces (hard to remember).

That's my problem ... you've stated that it's the work of 3 different authors over some unknown time period with unknown licensing restrictions.

You 3 guys need to agree on what license you want to release the libraries and include files under.

I can't, in good conscience, just make something up and put it on the files.

By modern practices, EVERY file needs a copyright author, copyright date and license information.

Some countries apparently don't have the concept of "public domain", so you can't even just wash your hands and be done with it.

The least restrictive license that I know of is the Boost license, which basically comes out as ...

• We wrote this.
• Don't pretend that you did the bits that we wrote.
• Do whatever you like with it.

... but put in a nice legal way.

So, if all three of you guys agree to use that one, then it might go something like ...

Code Select Expand

Copyright David Shadoff, David Michel and <whatever-zeograd's-real-name-is> 1995-2005.

Distributed under the Boost Software License, Version 1.0.
 (See accompanying file LICENSE_1_0.txt or copy at
  http://www.boost.org/LICENSE_1_0.txt)
Now, I'm happy to do the actual editing to add something like that to the library and include files ... but you've got to publicly state what the names (real ones), dates (years will do) and the license are ... and that you've got the other guy's agreement on this. Or they can post here to confirm it.
Or there can be a new release somewhere the appropriate information added.

It might seem silly for stuff that you guys just did as a hobby, but this is important legal stuff here.

It's the only way that I can think of to sanitize those files for distribution.

Sorry, I know that it's a pain, and I sympathize ... I've had to do it with both recent code that I've written and released, and also with old code that I released recently.

FYI, the last release of HuC on zeograd's site was 2005 ... so that would be the 2nd date.

If not, then it's back to typing in the includes from the Develo docs.

Don't do that... it hurts.

Well ... let's just say that I might have a better option than that. 

[Arkhan Asylum]

I was asking about PCEAS vs. CC65's assembler.  Not HuC.   

[dshadoff]

OK, I'll see what I can do.

I have contacted Zeograd - real name Olivier Jolly, and will try to get in touch with David Michel.  We'll see what we can do.


There is one file which is a potential problem, if you're being extra-careful:

ipl.bin is a 4,096-byte extract from the boot sector of a CDROM.
During CDROM load, a byte-for-byte compare is done by the ROM card, to ensure that the CDROM is a PCE CDROM.  The information contained in this sector includes a couple of copyright/license messages in cleartext.

The idea (in those days) was that a third-party would either need to license everything (and thus use this sector under contract), or self-incriminate by using the sector without license.  However, I recall this type of behavior was ruled as a form of entrapment (on another system) as this sector does not actually become part of the code path; it is merely checked byte-for-byte for a match.

As you mention, not all countries would see this the same way - and Games Express created their own CDROM controller for this purpose (it implements an ISO-9660 filesystem, BTW), rather than try to gain the rights to the original system card by going through a costly court battle.

[elmer]

OK, I'll see what I can do.

I have contacted Zeograd - real name Olivier Jolly, and will try to get in touch with David Michel.  We'll see what we can do.

Thank you, I really appreciate it ... I know that it's a pain. But it will get things cleared up.

There is one file which is a potential problem, if you're being extra-careful:

ipl.bin is a 4,096-byte extract from the boot sector of a CDROM.

Yes, I know about that little hurdle. All of the console manufacturers do that trick.

It makes sense given their business model, but I really do wish that they'd just release them as free software 5 or 10 years after the console stops being manufactured.

I can't distribute that file, but I can have the toolchain offer to rip it off a game CD, or use one that someone has got from somewhere else ... like HuC!

When it comes to pressing a CD, the developer will either have to get a license, take the risk, or require the hacked system card that's being talked about in the "System Card Dreams" thread.

As you mention, not all countries would see this the same way - and Games Express created their own CDROM controller for this purpose (it implements an ISO-9660 filesystem, BTW), rather than try to gain the rights to the original system card by going through a costly court battle.

Japan in particular has some strangely different laws.

It's the only country that I've know where a license was required to use the image of a font character.

In Western countries with roman script, the actual style that a letter is drawn in usually has very limited protection. There is the concept of a Design Patent, but that usually has a much, much shorter period of protection than regular copyright.

That's why you'll still find some developers shipping pre-rasterised fonts instead of TrueType fonts ... the TrueType fonts count as software and fall under the regular copyright laws.

Or you can do what Activision did, which was to buy one of the old font production companies.

sanskritweb.net has a slightly biased, but highly eye-opening take on the history of forgery and theft when it comes to the outline font industry.

[Psycho Punch]

ipl.bin is a 4,096-byte extract from the boot sector of a CDROM.

Sega v. Accolade?

[dshadoff]

Sega v. Accolade?

That's the one.

[elmer]

Sega v. Accolade?

That's the one.

There's certainly the hope that "fair use" would cover us all these days ... we're certainly not competing with NEC's busy release schedule any more! 

But I do want to have the toolchain source available on github, and so I've got to be squeaky clean about it. That means no "ip.bin" on there.

If there's a prebuilt binary distribution somewhere ... then things may be different, but not if the binaries were on somewhere like SourceForge.

In general, I'm leaning against doing a binary distribution myself because, in part, with the GPL it would probably mean hosting a lot of GNU source code, too. I need to check on the specifics of that.

On windows I'm currently using msys2 to compile the GCC for the PC-FX, and will be using it to compile mednafen. The msys2 installation is approximately 1GB by itself ... and that's before you decompress hundreds of MB of binutils and GCC source code. My aim is to be able to delete msys2 after the build and just be left with the PCE/PC-FX toolchain ... but I'm considering leaving it around because it's so useful to have some of the unix tools on windows.

Things sure have got complicated!

[Arkhan Asylum]

So overall, Elmer, what's the end goal here?   

Being one of the only people with a handful of finished games for PCE, I can say that symbolic debugging would be nice, but really isn't a necessity.   

Printing to screen, stepping through code , and generally just paying attention/planning before spewing code seems to work.

It exists for MSX with the OpenMSX debugger, and I rarely use it there either.   Most of the logic in games is not complicated, and if it is, you're probably doing something you don't need to.    So, the symbolic debugging is likely only going to be a real necessity if you're doing weird system stuff.

TL;DR: I think that sort of thing is really only extremely useful for esoteric projects.  This might be because I am generally familiar enough with my own code that I know where I am even with out symbols.



So, is the goal to just create a CC65 setup that ends up being similar in functionality to HuC, complete with functioning libraries to facilitate writing games?

I ask because, if I am going to start writing Apothecary this year after I finish Inferno, I'd rather wait and see what you're doing before starting.   

Otherwise, I'll likely invest effort into the usual HuC/PCEAS setup and then have chunks of code that aren't compatible with whatever you have setup.   Kind of like that new HuC that took a giant dump when I tried building even the simplest of stuff I had setup.

Do you have a timeframe on when any of this might be complete?   

How similar will the libraries be compared to HuC?   

It would suck a bit to have to relearn the libraries, so it might be great if you could maintain the same signatures/functionality.  (A lot of them call right into MagicKit ASM stuff, so I feel like this is probably a reasonable thing to do.)


HuC/PCEAS has at least proven to be usable to write fully functioning games.   I do what dshadoff assumed, which is C---> optimize assembly where needed.

You mainly have to do this for array access, and really only have to worry about crap like that when there's speed involved (shooters).


I also ask because, now would be a good time for you to check out Squirrel, and see if you want to incorporate that into things so people can have access to a fully functional chiptune library that doesn't require anything mental.

It's tweaked out for HuC, but you can likely modify and shove the stuff in. 

The only stipulation to that would be that it come with the terms that it not be modified (outside of whatever was required to get it to behave with CC65 instead of HuC), and that credit for it be given. 

..and if you release a commercial game, we get a freebie.  ;)   Pretty reasonable, I think.


It also comes with the full support of me explaining to people how to use MML since it's apparently still a huge brainfart for most people.

[elmer]

So overall, Elmer, what's the end goal here?

I want to develop a game for the PCE. I've become interested enough in the PC-FX that I'd like to see if I can develop a game for that, too.

I want to use a development environment for the PCE and PC-FX that's comfortable to me.

What I'm seeing currently available doesn't match up to my personal minimum requirements for modern development ... even on a "retro" platform like the PCE and PC-FX. I know that things can be better.

I'm willing to spend some of my time to try to make them (IMHO) better.

I'm happy to share what I come up with since I would like to encourage more development on this platform.

Being one of the only people with a handful of finished games for PCE, I can say that symbolic debugging would be nice, but really isn't a necessity.   

Printing to screen, stepping through code , and generally just paying attention/planning before spewing code seems to work.

We can replay Monty Python's Four Yorkshiremen sketch if you like, but I think that you might find that my battle-stories win.

Yes, you can do all of those things, and there are also other old tricks that you haven't mentioned.

But why not make it easier on yourself?

We've passed those days when "real men don't each quiche", and "real programmers" should be able to rattle off every hexadecimal opcode of their favorite processor.

Being able to step through the code as it runs and see your source code and comments is really nice ... it makes the whole job faster and more pleasant.

If you write such clean code that you never have bugs ... then you're a much better man than I am.

So, is the goal to just create a CC65 setup that ends up being similar in functionality to HuC, complete with functioning libraries to facilitate writing games?

Nope ... I want the CA65 assembler, and the LD65 linker.

I've seen bonknut's comments on his blog and the comments on krikzz's forum from people pointing out deficiencies in HuC and talking about wanting to use CC65 instead of it.

I wanted to know if there's been any kind of organized attempt to make that happen that so I could take advantage of it and work to help it.

Apprently there hasn't.

So I'm moving ahead on my own with CA65 and LD65.

The LD65 configuration file is an amazingly powerful thing ... it outsmarted me yesterday by being even more flexible than I expected.

I'm happy to spend the time to fix up some of the HuC equates and library files so that they work with CA65. It's good practice, and someone may find it useful.

But I'm really not interested in taking the time to get a CC65 setup fully working on the PCE, and especially not in trying to set it up to work just like HuC ... which people other than you have complained about.

CC65 and LD65 seem to offer a lot more flexibility than HuC. Since I don't know/use HuC, I'm entirely the wrong person to set up CC65 to try to overcome what some guys feel are weaknesses in the HuC setup, and to take advantage of some of the strengths of CC65.

I'm more than happy to trailblaze the environment and so be able to advise anyone that wants to do the work, and I'll probably help track down bugs in the compiler/assembler/linker.

But if you want to use C on a platform that I feel that isn't suited to it ... then please don't expect me to do the heavy lifting.

http://www.dwheeler.com/6502/

I ask because, if I am going to start writing Apothecary this year after I finish Inferno, I'd rather wait and see what you're doing before starting.   

Otherwise, I'll likely invest effort into the usual HuC/PCEAS setup and then have chunks of code that aren't compatible with whatever you have setup.   Kind of like that new HuC that took a giant dump when I tried building even the simplest of stuff I had setup.

If you want to step up and help make CC65-on-the-PCE happen, then I'm willing to help you out with my advice and some of my time.

If you're not, and nobody else is, then I expect that HuC/PCEAS is going to continue to be your best choice.

Do you have a timeframe on when any of this might be complete?

No toolchain is ever "complete" ... there are various levels of works-well-enough, and then you keep on improving over time.

How similar will the libraries be compared to HuC?   

It would suck a bit to have to relearn the libraries, so it might be great if you could maintain the same signatures/functionality.

Constant relearning is a part of the games world, and life in general.

I also ask because, now would be a good time for you to check out Squirrel, and see if you want to incorporate that into things so people can have access to a fully functional chiptune library that doesn't require anything mental.

It's tweaked out for HuC, but you can likely modify and shove the stuff in. 

The only stipulation to that would be that it come with the terms that it not be modified (outside of whatever was required to get it to behave with CC65 instead of HuC), and that credit for it be given.

I really appreciate your offer, but I'm afraid that those conditions don't work for me, or for anything that I intend to publicly release.

Even the most rabid of the GNU "all-software-must-be-free" guys realized that if they didn't make their library code usable without the GPL2-or-3 restrictions, then nobody would use their compilers.

I believe that library code must be released under a fairly non-restrictive license. Of course you can't just go and delete the the author's copyright notice and credit, that's part of any reasonable license. But I won't incorporate something that has a "you-can't-modify-me" restriction.

Everything will be released on github ... so you'll be free to fork it, improve it, and release your own version that incorporates your own code with whatever license you choose.

Or you can reconsider what license you're willing to release your code under ... there are plenty of alternatives out there.

BTW ... I've written a number of soft-synths over the years. They're not that hard to do, and I have a lot of existing code to refer to. While it would be very nice indeed to use one that's been tailored to the platform and is already known ... it won't be a huge hardship to have to write another one.

[Arkhan Asylum]

We can replay Monty Python's Four Yorkshiremen sketch if you like, but I think that you might find that my battle-stories win.

Couldn't give two shits less, as I wasn't really interested in battle stories, or some sort of competition.  I am just pointing out, from a "stuff has been completed" standpoint, that symbolic debugging isn't a dire requirement...

Also, I find Monty Python to be boring, so, your reference is lost on me there. 

Yes, you can do all of those things, and there are also other old tricks that you haven't mentioned.

But why not make it easier on yourself?

We've passed those days when "real men don't each quiche", and "real programmers" should be able to rattle off every hexadecimal opcode of their favorite processor.

Being able to step through the code as it runs and see your source code and comments is really nice ... it makes the whole job faster and more pleasant.

I wasn't around for the whole "real programmers" thing.  I was born in 1988. 

I'm just saying, for such simple, self contained little things like PC Engine games, doing the whole debug-printout/test case/etc. thing really isn't that big of a hassle.  I actually find it a bit less of a pain in the ass to setup the screen to print values out, and then I manipulate things with the controller and watch what happens.

This is for me at least.  Maybe the way I write games is different than others who would really like step-through-able-with-symbols coding.

Like I said, I rarely use it on a platform (MSX) that has it readily available.

If you write such clean code that you never have bugs ... then you're a much better man than I am.

Much of my code is written out on paper/diagrams/planned before it hits the screen.  So a lot of bugs are sorted out with a pencil+eraser. 

I'm happy to spend the time to fix up some of the HuC equates and library files so that they work with CA65. It's good practice, and someone may find it useful.

But I'm really not interested in taking the time to get a CC65 setup fully working on the PCE, and especially not in trying to set it up to work just like HuC ... which people other than you have complained about.

CC65 and LD65 seem to offer a lot more flexibility than HuC. Since I don't know/use HuC, I'm entirely the wrong person to set up CC65 to try to overcome what some guys feel are weaknesses in the HuC setup, and to take advantage of some of the strengths of CC65.

You maybe misunderstood what I meant by "like HuC".   I just mean "A C environment that supports writing PCE games".   It doesn't have to function exactly like HuC.   It'd be better if it didn't, as you've noticed.

HuC's biggest weaknesses are doofy pointers, no structs, and slow as shit array access.  These are not life-shattering issues though.  You can work around them pretty reasonably, once you know how to access an array with ASM.   

But if you want to use C on a platform that I feel that isn't suited to it ... then please don't expect me to do the heavy lifting.

Noted.   It's just, you said you wanted to encourage PCE development.   The whole "accessible C environment" thing would probably go a longer way in encouraging new people since:

1) Assembly is daunting to new people (especially 6502).  If they're not already excited about ASM, this just provides them with another confusing option, lol.
2) Those of us who are already doing it have projects already tied up in HuC/PCEAS's ways, so that counts those out if those projects can't easily shimmy over to a supposedly better toolchain.
3) As was noted before, and has proven extremely true in practice, C, while not really well suited to 6502, is great for prototyping and testing before optimizing.

Also, the whole "C is bad on 6502" concept doesn't seem to really take into account the fact that the PCE has a faster-than-average 6502 CPU in it.   You can actually get some solid speed going with C and no ASM on the PCE.  I am honestly leaning towards expecting my next game to function without any heavy optimizing. 

So, you'd basically be working on an ASM setup for the not-so-plentiful bunch of budding 6502 ASM PCE coders, or the people who are mostly just hacking/toying around.

This doesn't sound like encouragment or kickstarting to me, is all.  I would've figured if you truly want to give PCE development an encouraging kick in the tits, you'd want to provide readily available C stuff to provide a better alternative than what is already there.

But, if you're not into that, the open-source-ness of what you're doing will at least leave the door open for somebody to come in and fart around with it.

If you want to step up and help make CC65-on-the-PCE happen, then I'm willing to help you out with my advice and some of my time.

If you're not, and nobody else is, then I expect that HuC/PCEAS is going to continue to be your best choice.

I'm not going to invest time writing C compiler crap.  I honestly find it a bit mind numbing and boring, and would rather divert the time to my game projects, as I have a few going.

You sound like you are into that stuff more than anyone around here, honestly.   If you're not going to bother, I wouldn't hold my breath for any of the current PCE people to bother. 

No toolchain is ever "complete" ... there are various levels of works-well-enough, and then you keep on improving over time.

Yeah.  You knew what I meant.

Constant relearning is a part of the games world, and life in general.

You mean constant *learning*.  Not relearning.  Relearning is the result of disabilities. 

Learning is for new hardware.   This is the same hardware, with a possible newish backend.  The API would want to be reasonably similar, or you're possibly discouraging the current people (like myself) from adopting the new thing in the first place.  I personally don't have a strong tickle in my pants to take steps backwards for in one regard, so I can take steps forward in another regard.   Don't see a huge gain there.

I just think going in a radically different direction than MagicKit's library+HuC's layer-on-top might not be a great idea.

I really appreciate your offer, but I'm afraid that those conditions don't work for me, or for anything that I intend to publicly release.

Ah yeah, I forgot you're releasing it this way.   Oh well.   I guess if you get it all done, we can see about shoehorning it into whatever you setup as a separate fork that's Squirrel Ready.

BTW ... I've written a number of soft-synths over the years. They're not that hard to do, and I have a lot of existing code to refer to. While it would be very nice indeed to use one that's been tailored to the platform and is already known ... it won't be a huge hardship to have to write another one.

Fair enough, and have fun. 

There's more to it than writing the player portion that produces convincing beepboopery. 

Squirrel comes with a complete MML compiler so you can make the songs in a meaningful way and get them quickly playing.  Sound effects included.

Squirrel makes use of the hardware's PSG player built into the BIOS and recreates it in the absence of the CD hardware (for HuCard games).  It's all done straight from Develo+Hu7's CD documentation, and it operates fairly similarly to commercial MSX MML setups with regards to creating music and SFX.

So, it's a decades-old, proven process for putting tunes/sfx into a game with little headache/pain.

Probably the best available option, really.

[elmer]

I wasn't around for the whole "real programmers" thing.  I was born in 1988.

Wow, 26 or 27 ... I'd have guessed younger.

You have my immense respect for being one of those sadly-rare people that have gotten passed the talking stage and actually made something significant happen.

For Aetherbutt to have finished games and actually pushed things forward with the AbCARD is highly commendable.

But "yes", we're coming from a very different perspective. I've "relearned" a lot of things over the years as my world has expanded ... and I've often re-evaluated my opinions.

So, you'd basically be working on an ASM setup for the not-so-plentiful bunch of budding 6502 ASM PCE coders, or the people who are mostly just hacking/toying around.

Yep. Assembly on the PCE, C on the PC-FX.

This doesn't sound like encouragment or kickstarting to me, is all.  I would've figured if you truly want to give PCE development an encouraging kick in the tits, you'd want to provide readily available C stuff to provide a better alternative than what is already there.

IMHO, if people don't want to deal with assembly language, then there are much better platforms for them to unleash their creativity on, from C on the Sega Genesis's 68000, all the way up to C# in Unity on any modern computer/console.

But that's just my opinion, and I'm not doing anything to stop people coding in C on the PCE, nor am I going to look down on them for doing so ... at the end of the day, it's all about the results that you get.

But, if you're not into that, the open-source-ness of what you're doing will at least leave the door open for somebody to come in and fart around with it.

Yes, and I've already offered to help in the process of getting CC65 up and running.

Your unwillingness to be a part of that is ... noted.

I wish you the best with Atlantean and your upcoming games.

[Arkhan Asylum]

People are using C on MSX and C64, too.   The right kind of games (Read: Most simpler homebrew projects) are well suited to C.   

I'd be way more open to creating higher level libraries if I didn't have 2 MSX projects, a PCE, and a PC project in the works.   Time spent on tool-crap gets in the way of time spent on game-crap, and is counterproductive for me.

Also, people get into these things often for their love of a particular system, not because of the available toolset.   Suggesting that they go elsewhere if they want C is a bit lame.

If all I cared about was the functionality of the tools, there wouldn't be 4 PCE games from Aetherbyte.   I'd have a bunch of Dreamcast games released or something.

Hopefully, some people with enough free time and not-enough-game-projects come along to fill in the C gaps with whatever you end up releasing.   When it's ready to be molested, I'll look into a Squirrelable fork of it for people. 

I think that (functional, high level libraries + music, which was the biggest void in PCE development for awhile), is what would really encourage more developers (I thought that was one of the big goals).

New blood coming from newer ways of writing games (read: us younger people), have often come to expect higher level libraries because of what has evolved over the years. 

The like, 4 of us involved already figured out how to work with the doofy setup we were provided.   There aren't really many people banging at the gates for alternatives, either.   

This is also possibly due to the PCE not being a Sega/Nintendo machine.

[TailChao]

Elmer,

Have you considered trying WLA-DX? It's not quite CC65, but if you're doing assembly-only stuff it has some very nice linker features, etc.
I've been using this for my own PCE development instead of HuC / PCEAS without much trouble.

[elmer]

Have you considered trying WLA-DX? It's not quite CC65, but if you're doing assembly-only stuff it has some very nice linker features, etc.

WLA-DX looks really, really nice ... very much like an upgraded RGBASM.

I suspect that a couple of my old games would build on it pretty easily.

CA65 is a nice macro assembler, and LD65 is a very powerful linker ... with full programmer control of grouping segments into banks, a complete separation of load address from run address, and complete control of the layout of the binary output. The controls over the real/virtual segments should make programming overlays an absolute doddle. It also seems to have source-level debugging information already available.

If it is less powerful than WLA-DX, then it's still powerful enough for me ... and a step up from PCEASM.

One of the specific reasons for choosing CA65/LD65, is that there is a CC65 ... and there's a mailing list where it's still being worked on.

I would like people to have the option of using a more-standard-than-HuC version of C on the PCE. The more standard it is, the easier it will be for novices to use it, rather than just bumping up against the limits and quirks of HuC and getting frustrated.

I am willing to help with the work needed to make that happen ... but I don't want to be the lead programmer on the library/compiler part, I'd rather be writing a game.

If nobody is interested in doing that ... well, c'est la vie. But I will hopefully have at least done something to help make it easier for anyone that does want to do it in the future.

[Arkhan Asylum]

I don't think you'll likely find anyone interested in spearheading that process.

Or if you do, it won't get done in any timely fashion due to working on actual games, or project ADD.

[TurboXray]

WLA-DX has its set of issues as well. I don't remember all of them, but one of them is that the assembler automatically defaults to certain addressing modes and there's no way around this except for using macros with .db statements. Nesdev forum had some discussions about this. A few PCE asm coders switched back over to PCEAS too, from WLA-DX (for which I don't remember). I'd say stick with CA65.

 Whatever assembler you decided to use, if you get symbolic debugging working in mendafen - anyone could write a conversion tool to take whatever other symbol file format and convert it to whatever mednafen needs (assuming this is what you're modifying). So I see no problem there, and even if I didn't switch over to ca65, I could still use this feature. Maybe, you could modify mednafen to use a specific format you come up with yourself, then just the assembler of choice would need the a specific conversion app to that format.

[elmer]

I'd say stick with CA65.

CA65 is going to need a little work, too.

(EDIT)
Whoops ... my bad ... CA65 is right, and I'm wrong! 

Whatever assembler you decided to use, if you get symbolic debugging working in mendafen - anyone could write a conversion tool to take whatever other symbol file format and convert it to whatever mednafen needs (assuming this is what you're modifying).

Mednafen is my target ... I like it, and I'm hoping that it should be relatively easy to add a new "source level" page to the multiple pages of debugging info that it already supports.

[touko]

Mednafen is (i think) the most accurate pce emulator (but it seems not in his latest version, sgx emul sux a max).
His debugger is sufficient, but debug infos are definitely too small for my eyes and not comfortable at all .

[elmer]

Mednafen is (i think) the most accurate pce emulator (but it seems not in his latest version, sgx emul sux a max).
His debugger is sufficient, but debug infos are definitely too small for my eyes and not comfortable at all .

Yep, the default font strains my eyesight, too. I just switched to a bigger font.

Edit mednafen-09x.cfg ...

Code Select Expand

;Disassembly font size.
pce.debugger.disfontsize medium
I got mednafen 0.9.38.2 compiling on windows with msys2 last night.

OK, it looks like there's a new version, 0.9.38.3 this morning!

If you're saying that 0.9.38 is a bit buggy, then I can try going back to 0.9.37.

[touko]

just switched to a bigger font

I know, and it works fine for tracing code, but all the regs (CPU,VDC,VCE,audio) stay with a small font, in fact i don't know how to enlarge,and i don't know if it even possible .
 

If you're saying that 0.9.38 is a bit buggy, then I can try going back to 0.9.37.

I tested the latest, and my sgx stuffs wich works fine with the old 0.8.D (and of course real thing),are buggy with 0.9.3x ones .

[elmer]

I know, and it works fine for tracing code, but all the regs (CPU,VDC,VCE,audio) stay with a small font, in fact i don't know how to enlarge,and i don't know if it even possible .

Ah, sorry, I misunderstood.

Yes, the registers are definitely a pain ... I just squint and try to bear it for short periods of time.

If I'm hacking around in there anyway, I might look to see if something can be done about that ... the debugger isn't full-window-size at the moment.
 

I tested the latest, and my sgx stuffs wich works fine with the old 0.8.D (and of course real thing),are buggy with 0.9.3x ones .

Wow ... I really don't want to go back to the 2010 source code!

Have you reported the problem to the Mednafen developers?

[touko]

If I'm hacking around in there anyway, I might look to see if something can be done about that ... the debugger isn't full-window-size at the moment.

This would be great if you can correct this, my eyes would thank you ;-)

Wow ... I really don't want to go back to the 2010 source code!

All seems to be fine with PCE, but if you want use mednafen for pcfx stuffs,you have the risk of having the same problem than SGX.

Have you reported the problem to the Mednafen developers?

No, because i think than mednafen's author is more concerned by commercial games emulation, not homebrew ..
Maybe i should contact him, i don't know ..

[elmer]

This would be great if you can correct this, my eyes would thank you ;-)

Mine,  too!

No, because i think than mednafen's author is more concerned by commercial games emulation, not homebrew ..
Maybe i should contact him, i don't know ..

Yes, the old commercial games are definitely their priority.

But if you can send then a HuCard or ISO with an easily reproducable example of the problem ... then I'd be sad if they refused to respond.

Since you're not talking about a commercially released game, it's going to be critical for you to make it as easy as possible for them to reproduce (and so find).

[TurboXray]

Touko, is this an edge case scenario issue?

Ryphecha's always strived for accuracy for her emulation, as far back as I can remember. She even added different audio implementation for emulation depending on chip revisions, etc (she's done a lot with accurately emulating the audio chip). And a bunch of other stuff too. I would at least ask. Also, I have an SGX so I might be able to confirm some test stuffs. It might be better to talk with her on the mednafen IRC channel.

 I wanted to see if she could implement that hacked mode for 8 pixel tall sprite cells, but since I haven't made anything with it.. I haven't asked. One of these days, though.

[touko]

Touko, is this an edge case scenario issue?

Yes all my SGX stuffs are broken, even a simple one like my flappy bird adaptation wich is not sgx intensive,and works fine on 0.8D and true hardware .
Seems that some VRAM writes are broken when you do it on active display .

I tested with my 0.9.28,and 0.9.38.3, and nothing works correctly for SGX,hucard and cdrom  ..

[touko]

i posted my problem on mednafen forum .

and the answer is :

Found the bug in Mednafen; VRAM DMA is failing to start if there isn't a SAT DMA for that VBlank period. Kind of surprised it didn't break more software... It'll be fixed in the next release.
[Updated on: Fri, 06 March 2015 07:37]

[elmer]

Excellent!    I'll grab the new version when it's posted.

Mednafen has turned out to be nice and easy to compile, so I'm digging into the guts of it now.

[spenoza]

Mednafen is what the folks at tasvideos.org used as the basis for PCE support in their Bizhawk emulator.

[elmer]

If I'm hacking around in there anyway, I might look to see if something can be done about that ... the debugger isn't full-window-size at the moment.

This would be great if you can correct this, my eyes would thank you ;-)

I've been digging around in the Mednafen source and ...

• Increased the debug window from 640x480 to 800x600
• Added a new 6x9 font
• Added the ability to "tab" out register printouts to form columns
• Added some extra labels on the registers

Touko (and anyone else that might care) ... does that look any easier to read?

Any suggestions for further changes?

[touko]

Greaaaat, i want to do it too ;-)

[elmer]

Greaaaat, i want to do it too ;-)

Excellent! ... Are you comfortable with building Mednafen from source?

I'm using msys2/mingw64 on Windows. I think that the official Mednafen builds are made with mingw64 on Linux. Either way ... it's a Linux-style build environment. You may already be using it.

At some point I'll wrap things so that it can all be built from Windows .cmd files ... but it will still require downloading nearly 1GB of msys2 ... and I'm not at that point anyway, yet.

If you're not comfortable with that, then I can upload a binary build somewhere. Just understand that this is still a work-in-progess!

[touko]

Excellent! ... Are you comfortable with building Mednafen from source?

No, but i am not affraid to do it ..

If you're not comfortable with that, then I can upload a binary build somewhere. Just understand that this is still a work-in-progess!

If you can upload (windows) binary, i'll pick that, it's more easy and faster for me, I'm a bit lazy sometimes 

[elmer]

If you can upload (windows) binary, i'll pick that, it's more easy and faster for me, I'm a bit lazy sometimes 

OK, to make things easy, I put a 32-bit Windows binary build up on my PogoPlug that anyone with an interest can grab.

It only supports the PCE & PC-FX ... nothing else.

The source patch is included (as per GPL), should anyone want to try compiling it themselves.

[EDIT] <2015-08-11 removed dead link>

I'm happy for feedback ... but please remember that this is a work-in-progress. It seems to work fine, but it hasn't had the kind of testing that an official build of Mednafen would get.

[touko]

Thanks ..

Downloaded and tested, and didn't work,zlib1.dll is missing ..

[elmer]

Thanks ..

Downloaded and tested, and didn't work,zlib1.dll is missing ..

Haha ... the joys of development! 

I have no idea why I have a copy of zlib1.dll in my path somewhere ... but now I'm going to have to look for it and find out how old it is.

Anyway, I've updated the archive to include the correct msys2 zlib1.dll, and updated the link in the previous post.

Thanks for letting me know.

[touko]

 

Ok man works fine now, thanks a lot