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?
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.
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.
More capable how?
Quote from: guest on 02/28/2015, 01:07 AMMore 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/ (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/ (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.
Quote from: elmer on 02/28/2015, 11:48 AMThe 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/ (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.
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).
I feel so dumb after reading this...so damn dumb...
Quote from: Bernie on 02/28/2015, 05:37 PMI 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.
Quote from: Bernie on 02/28/2015, 05:37 PMI 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.
Quote from: dshadoff on 02/28/2015, 02:57 PMFeel 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.
Quote from: dshadoff on 02/28/2015, 02:57 PMHuC/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.
Quote from: dshadoff on 02/28/2015, 02:57 PMFeel 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).
Quote from: TurboXray on 02/28/2015, 03:46 PMYeah, the full control over where subroutines are placed in banks/addresses is incredibly powerful.
Definitely agree! :wink:
Quote from: TurboXray on 02/28/2015, 03:46 PMIIRC, 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.
Quote from: TurboXray on 02/28/2015, 03:46 PMI 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.
Quote from: TurboXray on 02/28/2015, 03:46 PMWhich 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. :(
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...
Quote from: Aladar on 03/01/2015, 03:35 AMFrom 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.
QuoteA 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.
QuoteWhat 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.
Quote from: dshadoff on 02/28/2015, 02:57 PMFeel 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!!! :shock:
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.
Quote from: elmer on 03/01/2015, 02:43 PMAaaarrgggghh!!! :shock:
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
*/
HuCDavid 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 (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 (http://gaby.de/ftp/pub/cpm/znode51/pcwworld/l101/user_0/zsc_1.c)
Attribution:
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.
LibrariesWritten 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.
QuoteDavid ... 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.
QuoteThe 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.
QuoteIf not, then it's back to typing in the includes from the Develo docs.
Don't do that... it hurts.
Quote from: dshadoff on 03/01/2015, 03:26 PMAttribution:
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!
Quote from: dshadoff on 03/01/2015, 03:26 PMI 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 ...
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.
Quote from: dshadoff on 03/01/2015, 03:26 PMQuoteIf 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. :wink:
I was asking about PCEAS vs. CC65's assembler. Not HuC.
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.
Quote from: dshadoff on 03/01/2015, 06:04 PMOK, 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.
QuoteThere 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.
QuoteAs 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.
Quote from: dshadoff on 03/01/2015, 06:04 PMipl.bin is a 4,096-byte extract from the boot sector of a CDROM.
Sega v. Accolade?
Quote from: dshadoff on 03/01/2015, 08:58 PMQuote from: guest on 03/01/2015, 07:38 PMSega 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! :wink:
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!
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.
Quote from: guest on 03/03/2015, 01:34 PMSo 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.
QuoteBeing 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.
http://youtu.be/Xe1a1wHxTyo
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.
QuoteSo, 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/ (http://www.dwheeler.com/6502/)
QuoteI 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.
QuoteDo 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.
QuoteHow 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.
QuoteI 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.
Quote from: elmer on 03/03/2015, 10:50 PMWe 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.
QuoteYes, 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.
QuoteIf 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.
QuoteI'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.
QuoteBut 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.
QuoteIf 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.
QuoteNo 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.
QuoteConstant 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.
QuoteI 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.
QuoteBTW ... 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.
Quote from: guest on 03/04/2015, 02:04 AMI 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.
QuoteSo, 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.
QuoteThis 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.
QuoteBut, 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.
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.
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.
Quote from: TailChao on 03/04/2015, 12:12 PMHave 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.
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.
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.
Quote from: TurboXray on 03/04/2015, 06:01 PMI'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! :oops:
QuoteWhatever 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.
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 .
Quote from: touko on 03/05/2015, 04:49 AMMednafen 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 ...
;Disassembly font size.
pce.debugger.disfontsize mediumI 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.
Quotejust 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 .
QuoteIf 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 .
Quote from: touko on 03/05/2015, 01:32 PMI 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.
QuoteI 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?
QuoteIf 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 ;-)
QuoteWow ... 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.
QuoteHave 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 ..
Quote from: touko on 03/05/2015, 03:26 PMThis would be great if you can correct this, my eyes would thank you ;-)
Mine, too!
QuoteNo, 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).
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.
QuoteTouko, 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 :(..
i posted my problem on mednafen forum .
and the answer is :
QuoteFound 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]
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.
Mednafen is what the folks at tasvideos.org used as the basis for PCE support in their Bizhawk emulator.
Quote from: touko on 03/05/2015, 03:26 PMQuoteIf 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?
(?action=dlattach&topic=18654&attach=2465&image)
Greaaaat, i want to do it too ;-)
Quote from: touko on 03/13/2015, 04:12 AMGreaaaat, 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!
QuoteExcellent! ... Are you comfortable with building Mednafen from source?
No, but i am not affraid to do it ..
QuoteIf 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 :P
Quote from: touko on 03/13/2015, 01:11 PMIf you can upload (windows) binary, i'll pick that, it's more easy and faster for me, I'm a bit lazy sometimes :P
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.
Thanks ..
Downloaded and tested, and didn't work,zlib1.dll is missing ..
Quote from: touko on 03/14/2015, 11:19 AMThanks ..
Downloaded and tested, and didn't work,zlib1.dll is missing ..
Haha ... the joys of development! :wink:
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.
:mrgreen:
Ok man works fine now, thanks a lot :wink:
I've put a new Windows build of Mednafen up on my PogoPlug for anyone that wants it ...
[EDIT] <2015-08-11 removed dead link>
This is still a 32-bit version that only supports the PCE and PC-FX.
New features are ...
- The memory debugger has now been expanded to 800x600 and made more readable.
- You can use either "G" or "ENTER" to set the address on both the main view and the memory view ... rather than having the same function on different buttons on different views.
- Built with it's own 64-bit version of zlib to make Mednafen happy.
Patch files and a build script are included for the adventurous.
Here are "before" and "after" screenshots of the memory view ...
Downloaded, thanks ;-)
I've put up another new Windows build of Mednafen up on my PogoPlug for anyone that wants it ...
[EDIT] <2015-08-11 removed dead link>
This is still a 32-bit version that only supports the PCE and PC-FX.
New features are ...
- Built with today's new Mednafen 0.9.38.4 release (which fixes touko's SuperGrafx bug).
- Added a bit more white-space between lines on the PCE & PC-FX debugger screens to make them easier to read.
- Reorganized PC-FX register display a bit because of the previous change.
Patch files and a build script are included for the adventurous.
oh cool,2 gifts in one ;-)
Quote from: touko on 04/15/2015, 12:27 PMoh cool,2 gifts in one ;-)
You're welcome! :wink:
I'm glad that someone else is finding the changes useful.
Tested, and it still doesn't work with my sgx stuffs :?
Even with the last mednafen release .
Uh-oh ... can you please test with the official new 0.9.38.4 Mednafen binary release to make sure that I've not screwed something up?
[EDIT]
I've diff'd 0.9.38.3 vs 0.9.38.4 and I can see that Ryphecha made some changes in src/hw_video/huc6270/vdc.c (and .h) that I can only assume are there to fix the bug that you reported.
QuoteUh-oh ... can you please test with the official new 0.9.38.4 Mednafen binary release to make sure that I've not screwed something up?
Already tested, it works with an old release of flappy bird, but not with the last .
Quote from: touko on 04/20/2015, 03:41 AMAlready tested, it works with an old release of flappy bird, but not with the last .
Sorry ... I can't tell what you mean from that, which "it" (official Mednafen or my Mednafen) and which "last" (Mednafen or Flappy Bird")?
Does the latest official Mednafen fix the version of Flappy Bird that you sent to Ryphecha when you reported the problem?
If it does, then does my build also work with that same version of Flappy Bird?
Since you've kept on developing ... perhaps you've found another problem with Mednafen, or perhaps Ryphecha's fix didn't fully work in all cases.
I'm just trying to figure out if your current problem is in the current official Mednafen, or if it is something that only breaks with my msys2 build.
QuoteSorry ... I can't tell what you mean from that, which "it" (official Mednafen or my Mednafen) and which "last" (Mednafen or Flappy Bird")?
Oups sorry, i sent a version of my flappy bird clone to mednafen author ,the last build of mednafen (0.9.38.4) works fine with it .
i tested a new version of flappy with some optimised code in graphic libraries, and it didn't works, i have a black screen, but it works fine on the old mednafen 0.8 and true hardware .
QuoteDoes the latest official Mednafen fix the version of Flappy Bird that you sent to Ryphecha when you reported the problem?
Yes it works :wink:
QuoteI'm just trying to figure out if your current problem is in the current official Mednafen, or it it is something that only breaks with my msys2 build.
i thought too, but no, the two versions have the same issue, a black screen .
EDIT: Ok set and sbc was the problem, for sure this doesn't work on real hardware ;-)
Quote from: touko on 04/20/2015, 12:22 PMQuoteI'm just trying to figure out if your current problem is in the current official Mednafen, or it it is something that only breaks with my msys2 build.
i thought too, but no, the two versions have the same issue, a black screen.
It's good to know that all my patches haven't broken anything!
Quotei tested a new version of flappy with some optimised code in graphic libraries, and it didn't works, i have a black screen, but it works fine on the old mednafen 0.8 and true hardware .
I can see that you've reported the issue on the official Mednafen board, so I'll keep a watch on it there and see if I need to make a new build.
[EDIT]
Looks like you're doing a naughty thing with the SET instruction that's definitely not documented in the official Hudson manual, or Charles MacDonald's hardware notes.
If you confirm that it actually does work on real SGX hardware, can you please test to see if CMP and LDA also work with SET (just like the Mitsubishi 740 series)?
QuoteIf you confirm that it actually does work on real SGX hardware, can you please test to see if CMP and LDA also work with SET (just like the Mitsubishi 740 series)?
For now i cannot, bacause i have a real sgx but no flash card (my sgx stuffs was tested by a friend) .
Set is the instruction that i want to test absolutely on real hardware .
But it seems that SBC works too .
QuoteLooks like you're doing a naughty thing with the SET instruction that's definitely not documented in the official Hudson manual, or Charles MacDonald's hardware notes.
i don't really think that SET is the problem, because it works with the old mednafen version .
And works too with PCE stuffs only, even those that contain the same libraries (with the use of SET) .
Just tested to reconfirm it, SET does not appear to have any effect on SBC when paired with it, on a HuC6280(in my PC Engine Duo). So at the very least, if you're making programs targeting the PC Engine, it's erroneous to use SET with SBC and expect it to work as it would with ADC.
Quick and dirty test program: http://sarsie.fobby.net/junk/set-test-apr20-2015.zip (http://sarsie.fobby.net/junk/set-test-apr20-2015.zip)
Quote from: Mednafen on 04/20/2015, 06:05 PMQuick and dirty test program: http://sarsie.fobby.net/junk/set-test-apr20-2015.zip (http://sarsie.fobby.net/junk/set-test-apr20-2015.zip)
Thanks for knocking this test program up so quickly!
I've tried it on my Core Grafx II and my 3 Super Grafx consoles (OK, so I'm a bit of a fan) ... and the test fails on all 4 with the same screen as on your Duo.
So unless the test itself is flawed (and it seems good to me from a quick look at the assembly source) then Touko ... I'm afraid that I've got to paraphrase the immortal Inigo Montoya and say ....
"I do not think that instruction does what you think it does." :wink:
Tested years ago with every single opcode: SET affects only ADC, AND, EOR and ORA.
Quote from: Aladar on 04/21/2015, 03:23 AMTested years ago with every single opcode: SET affects only ADC, AND, EOR and ORA.
Yes i saw that on develo book,SET is mentioned only for these opcodes .
I confirm that removing set with sbc made it to work fine .. :wink:
luckily it was used only in load_vram function :P
Quotethen Touko ... I'm afraid that I've got to paraphrase the immortal Inigo Montoya and say ....
"I do not think that instruction does what you think it does." :wink:
:lol:
it worked very well on mednafen 0.8,if it was fine for him then it was fine for me :mrgreen:
And like the great mulder said " I want to believe" . :wink:
Seriously,now i'll test my picky code directly on real thing to be sure .
Hey elmer, thank you very much for this version of mednafen :-) It's very much appreciated.
I don't know how many people would be interested, but you can bet I would use CA65 and LD65 :-)
I've put up another new Windows build of Mednafen (with my changes) for anyone that wants it ...
https://www.dropbox.com/s/o967dmh3v5kq4hg/mednafen-0.9.38.5-x86-elmer.zip?dl=0 (https://www.dropbox.com/s/o967dmh3v5kq4hg/mednafen-0.9.38.5-x86-elmer.zip?dl=0)
Just to remind any newcomers to this thread, the modifications are in Mednafen's PCE and PC-FX debugger displays in order to make them a bit more pleasant to look at, and readable.
This is still a 32-bit version that only supports the PCE and PC-FX.
New features are ...
- Built with the recent Mednafen 0.9.38.5 release (which fixes a PC-FX bug).
- Built with latest msys2 GCC compiler in the hope that this might run on Windows 10.
The patch files and a build script are available at ...
https://www.dropbox.com/s/nuqejdtmxpgur4d/build-msys2-mednafen-0.9.38.5-x86-elmer.zip?dl=0 (https://www.dropbox.com/s/nuqejdtmxpgur4d/build-msys2-mednafen-0.9.38.5-x86-elmer.zip?dl=0)
Quote from: touko on 04/21/2015, 04:31 AMQuote from: elmerthen Touko ... I'm afraid that I've got to paraphrase the immortal Inigo Montoya and say ....
"I do not think that instruction does what you think it does." :wink:
:lol: it worked very well on mednafen 0.8,if it was fine for him then it was fine for me :mrgreen:
And like the great mulder said " I want to believe" . :wink:
An Inigo Montoya reference followed by one from X-Files in the same thread, great stuff! :)
Interesting read in this thread BTW, tried to catch up and read most of it!
Bonknuts posted that CC65 has recently got support for the PCE, so I thought that I'd give it a try.
It's only got console-io at the moment, but it certainly works in Mednafen.
Looks like it's time to start figuring out what library functions could be ported over from HuC! :wink:
#include <conio.h>
void main (void)
{
unsigned uLine;
for (uLine = 2; uLine < 30; uLine += 2)
{
cputs( "Hello, World!\n\r" );
cprintf( "CC65 console line %d\n\r", uLine );
};
while (1);
}
(https://farm1.staticflickr.com/660/22940243232_49b5c5f81f_o.png) (https://flic.kr/p/AX9K63)
Since the HuC code for reading/writing a Turbo Everdrive's SD card seems to have been stuck for quite a while now, I thought that I'd see if CC65 could compile one of the more popular open-source FAT32 libraries.
It compiles with no problem at all. :)
Here's the size of the compiled code with various different options enabled.
FatFs - Generic FAT File System Module
http://elm-chan.org/fsw/ff/00index_e.html (http://elm-chan.org/fsw/ff/00index_e.html)
Size Writable Long Filename Limitations
-------------------------------------------------------------
$725B : FATFS : read-write : UNICODE LFN :
$3E3F : FATFS : read-only : UNICODE LFN :
$34F9 : FATFS : read-only : UNICODE LFN : no directories
$239F : FATFS : read-only : no LFN, CP437 : no directories
Petit FAT File System Module
http://elm-chan.org/fsw/ff/00index_p.html (http://elm-chan.org/fsw/ff/00index_p.html)
Size Writable Long Filename Limitations
-------------------------------------------------------------
$1A42 : PFF3, : read-write : no LFN, CP437 : no lseek, fat16 & fat32
$1907 : PFF3, : read-write : no LFN, CP437 : no lseek, fat32 only
$16fa : PFF3, : read-only : no LFN, CP437 : no lseek, fat16 & fat32
$15BF : PFF3, : read-only : no LFN, CP437 : no lseek, fat32 only
Now, if I could get the TED2 low-level assembly code to actually read blocks of data from the SD card instead of crashing, then we might have something useful. :-k
Can these actually be made into libraries accessible from ROMs, eg PCEmon, a hacked TenNoKoe Bank ROM, etc?
Quote from: ccovell on 11/28/2015, 07:30 PMCan these actually be made into libraries accessible from ROMs, eg PCEmon, a hacked TenNoKoe Bank ROM, etc?
I don't think that I quite understand the question?
These
are libraries, distributed as "C" source.
You just include them in your CC65 project, decide what code/data segments/banks you want to put them in ... and use them.
CC65 doesn't really impose any limitations on where you choose to place stuff ... it is entirely flexible.
With CC65/CA65, it's easy to mix "C" and assembly code ... so you just write your ROM in whichever language makes you happy.
I still need to finish-off low-level SD-card access functions ... the one's that Mooz did for the TED1 have needed a fair bit of fiddling about to get them even partially-working on the TED2.
I can't see them being much use for hacking into the TenNoKoe Bank ROM. Instead, I'd rather assume that anyone wanting to copy data from Backup Memory to SD card would just write a completely new ROM.
If you're thinking about an expanded Super System Card with something like PCEMon and copying Backup Memory to/from SD card, saving screen grabs on SD card, etc ... then "yes", I'd say that it is certainly possible.
Something along those lines is one of my goals, with the TED2 System Card patch as a 1st-step.
The TED2's built-in USB connection to a PC makes things even easier and more convenient for people.
I think the topic of CC65 came up awhilllllle ago one time, and it never went anywhere only because there were (are) like 3 active developers.
at the time I think it was something like, Bonknuts wasn't using C, we were already successfully bitch slapping HuC into producing games that move faster than -12 FPS, Rover was around there too, and Cabbage was using ASM too?
so nobody wanted to make libraries or spend time on it.
Squirrel would have to be re-diddled for CC65 at some point, assuming it's usage takes off. Without Squirrel, basically any compiler is useless to me.
I don't think it would be too hard. Famous last words.
Quote from: Psycho Arkhan on 12/01/2015, 01:55 AMSquirrel would have to be re-diddled for CC65 at some point, assuming it's usage takes off. Without Squirrel, basically any compiler is useless to me.
I know Squirrel is your baby and caters to your musical strengths, but with all the potential audio engine options on the horizon, it might be worth seeing if you can adapt the MML format to other engines to share some of the MML love.
Quote from: guest on 12/01/2015, 06:48 PMQuote from: Psycho Arkhan on 12/01/2015, 01:55 AMSquirrel would have to be re-diddled for CC65 at some point, assuming it's usage takes off. Without Squirrel, basically any compiler is useless to me.
I know Squirrel is your baby and caters to your musical strengths, but with all the potential audio engine options on the horizon, it might be worth seeing if you can adapt the MML format to other engines to share some of the MML love.
There aren't many potential options on the horizon. Isn't there just HuSound? The way it expects things does not lend itself well to MML. Writing an MML compiler that produces output for HuSound is a bit of a waste of time.
Especially because HuSound doesn't have a CC65 thing yet either, does it?
So really, any sound library needs CC65'd.
Squirrel was designed to adhere to MML standards and be inline with how commercial software at the time (and now, on MSX) is done. I don't see a reason to forego that.
The people that are using other engines are probably using it because they don't like MML. Providing them MML options don't help them.
Quote from: Psycho Arkhan on 12/01/2015, 08:39 PMThere aren't many potential options on the horizon. Isn't there just HuSound?
...
The people that are using other engines are probably using it because they don't like MML. Providing them MML options don't help them.
Sounds like Bonknuts is cooking something up to pair with his 4-channel MOD engine, so that's 2 options (or one compound option) right there. But yeah, your point is taken. You're probably right.
There are many reasons people make their own sound engines, regardless of the higher level format that gets compiled down (MML or not). Usually academic or research/experience, but sometimes other specific reasons (capabilities that doesn't exist in other engines, or resource issues, etc).
QuoteSounds like Bonknuts is cooking something up to pair with his 4-channel MOD engine
My sound engines are just a proof of concept thing, because in all reality no one will probably use it.
Most people don't use other people stuffs in this scene (or even in other console homebrew scenes). And my sound engines also alienates the PCE style of sound by doing something completely different with it, which isn't always popular with chiptunists (it doesn't follow that
true PCE sound). I currently don't have an MCU or arduino setup at the moment to play with, so the PCE tends to get some of that stuff that I would probably/normally do for that. But I'm fine with that.
Tailchao is probably doing his own engine so he has complete control over all variables that go into resource management of it, as well as any distinct features he wants to use. Writing a script compiler is less work than writing a music engine from scratch (although you'll still hear me complain about the script compiler thing). I'm sure he's capable of writing one. As for me, I already have a simple script compiler that I can rework.
QuoteThere aren't many potential options on the horizon.
There isn't. Everyone is just doing their own thing. Mooz has a sound engine (based on deflemask format, IIRC). I have two that are fully completed (a tracker/hybrid one, and the full working AirZonk one), and a third one that works/near complete (90% mod FX compatibility and full tracker format). Tailchao has one. DamageX guy with the Phantasy Star PCE demo has sound engine. I'm sure there are others. I tried to pimp out one of mine to chip tuners and what I got back was; no tracker interface, then not really interested. So I started working on an XM to PCE converter, so people could prototype and build the song in milkytracker, and have it play near identical on the PCE. But then I was like.. eh, fuck it - it's a lot of work and people probably still won't use it. I watched
thefox make an awesome tracker for the NES, with some great example songs, and then no one used it. Actually, there are a lot of custom made sound engines in the NESdev scene - made just for the devs themselves because no one bothers sharing stuff that they know no one will bother to use. Everyone would rather just re-invent the wheel (which I can relate to), rather than take the time to alter someone else's design. Famitracker supposedly offers quite a bit, but devs still complain about it and end up writing their own.
That said, I'd like to see squirrel with ADPCM and/or Timer interrupt sample support - if you guys ever get around to it.
Quote from: TurboXray on 12/01/2015, 10:18 PMThere isn't. Everyone is just doing their own thing. Mooz has a sound engine (based on deflemask format, IIRC). I have two that are fully completed (a tracker/hybrid one, and the full working AirZonk one), and a third one that works/near complete (90% mod FX compatibility and full tracker format). Tailchao has one. DamageX guy with the Phantasy Star PCE demo has sound engine. I'm sure there are others. I tried to pimp out one of mine to chip tuners and what I got back was; no tracker interface, then not really interested. So I started working on an XM to PCE converter, so people could prototype and build the song in milkytracker, and have it play near identical on the PCE. But then I was like.. eh, fuck it - it's a lot of work and people probably still won't use it. I watched thefox make an awesome tracker for the NES, with some great example songs, and then no one used it. Actually, there are a lot of custom made sound engines in the NESdev scene - made just for the devs themselves because no one bothers sharing stuff that they know no one will bother to use.
IMHO, it's not
that difficult to write a basic sound engine and, as you point out, everyone-and-his-dog has done so.
It's one of those fun projects for a programmer to do, with quick feedback (i.e. it makes noises), and it's also easy to convert a simple MIDI tune into something that you can experiment with.
What you've been doing with your custom sample-playback engines is very unusual for the platform, and a giant leap beyond most people's experiments, but, as you say, the real trick is in getting a musician to want to use it.
Back-in-the-day a lot of the early musicians wrote their own sound drivers, because that was easier than explaining it all to someone else, and it gave them perfect control of how to make their own music.
But almost nobody wants to do that anymore, with TailChao being one of the very-few exceptions.
It'll be interesting to see if any of the other musicians here downloads HuSound and tries to use it to make a tune.
Even though I don't personally love MML as a concept, what Arkhan has done really well with Squirrel is to make it easy-ish for musicians to get good sound out of a PCE, without needing to deal with a programmer. That's great!
Deflemask seems to be the current-standard of the Tracker-interface version of the same idea.
With Mooz's player ...
https://github.com/BlockoS/dmf-player (https://github.com/BlockoS/dmf-player)
And at-least-some interested PC Engine Deflemask users ...
http://www.delek.com.ar/forum/deflemask/pc-engine-instruments-and-wavetables-pack (http://www.delek.com.ar/forum/deflemask/pc-engine-instruments-and-wavetables-pack)!!/
Then perhaps that will be another alternative for people.
Quote from: TurboXray on 12/01/2015, 10:18 PMEveryone would rather just re-invent the wheel (which I can relate to), rather than take the time to alter someone else's design. Famitracker supposedly offers quite a bit, but devs still complain about it and end up writing their own.
I'm waaaayyy passed that stage myself. I've written sound engines in the past, but I've been using other-people's engines for years.
That's precisely because I've found it to be the best way to actually get a musician to write good music. Folks want things to be "musician-friendly", and most programmer-designed sound engines just don't pass that test.
QuoteThat said, I'd like to see squirrel with ADPCM and/or Timer interrupt sample support - if you guys ever get around to it.
Me, too. IMHO, any PCE sound engine needs to support at-least-one sample-playback channel.
I'd also like to see Arkhan being a little less "precious" with the licensing terms ... but that's already been mentioned. At the end of the day, it's his toy, and he gets to decide how other people can play with it.
QuoteQuoteThat said, I'd like to see squirrel with ADPCM and/or Timer interrupt sample support - if you guys ever get around to it.
Me, too. IMHO, any PCE sound engine needs to support at-least-one sample-playback channel.
Why? I don't understand......?
You can use the 5-bit stuff (re-loading the waveforms) to do some neat things. If you play with it a bit...
I just don't understand how changing the sound engine helps anything. The point behind squirrel (which, once again, is the MML compiler and *not* the assembler playback engine) was to make it possible to create sound that was system card compatible. You can swap your program to cd, and have it play the same. So you can develop your music (or whatever) on a card image (in an emulator) and drop it into a cd-image.
If I have to use system card memory to hold a player -that's already in the bios-, I'd use a custom engine, too.
So when will it be available for general use, bonknuts? And what kind of resources does it us? (we already know about the cpu time.) How is it on memory? especially the zp space?
[ Don't take that the wrong way. It's -not- a dig; it's a serious question. I'd like to see what it can do, especially the adpcm stuff....]
Quote from: TurboXray on 12/01/2015, 10:18 PMTailchao is probably doing his own engine so he has complete control over all variables that go into resource management of it, as well as any distinct features he wants to use.
Actually, the whole reason I wrote HuSound was to force myself to start writing (NULL == pValue) instead of (pValue == NULL) before starting a new job.
Although yes, it is partially a resource management thing. The driver and toolset are a complete overkill for what most games need. But I think it's easier to take extra features out later on rather than have to jam them in near ship time. The composer can do whatever they want and we put off optimization until later.
Quote from: elmer on 12/02/2015, 08:09 PMIt's one of those fun projects for a programmer to do, with quick feedback (i.e. it makes noises), and it's also easy to convert a simple MIDI tune into something that you can experiment with.
Absolutely. It's also a great way to learn about music if you're not a composer. I usually just make the characters move.
Quote... to force myself to start writing (NULL == pValue) instead of (pValue == NULL)
Won't they let you do just (pvalue) for checks?????
wow....
Quote from: TheOldMan on 12/02/2015, 08:54 PMQuoteQuoteThat said, I'd like to see squirrel with ADPCM and/or Timer interrupt sample support - if you guys ever get around to it.
Me, too. IMHO, any PCE sound engine needs to support at-least-one sample-playback channel.
Why? I don't understand......?
You can use the 5-bit stuff (re-loading the waveforms) to do some neat things. If you play with it a bit...
I just don't understand how changing the sound engine helps anything. The point behind squirrel (which, once again, is the MML compiler and *not* the assembler playback engine) was to make it possible to create sound that was system card compatible. You can swap your program to cd, and have it play the same. So you can develop your music (or whatever) on a card image (in an emulator) and drop it into a cd-image.
If I have to use system card memory to hold a player -that's already in the bios-, I'd use a custom engine, too.
For me, it's because samples have always been part of that staple PCE sound. They were used in a
lot of games. Devil's Crush uses up to three sample streams at a time for some parts. Batman on the PCE has a really nice punch to the bass guitar because of samples (as well as the orchestra hit). Bonk's drumskit, Blazing Lazers drumkits, etc.
You guys obviously know a lot more about the BIOS player than I do. But I do remember looking at games that did ADPCM drumkits/etc and IIRC they used kind of a hacked way going about it. As in another engine running at the same time (in sync), just for the sample side of things. Does this sound familiar? It's possible other ADPCM+PSG usage in CD games made their sound engine, bypassing the BIOS player. Either way, sounds like a pain - running a hack/hook mini engine to run along side of it, or making a new but compatible sound engine with TIMER and/or ADPCM support.
QuoteSo when will it be available for general use, bonknuts?
I'm working on a few different audio projects, so I'm going to assume you mean the MOD-ish type player. And the first engine at that (not the 8 channel PCM player with higher bit depth).
Just to be clear, it's sound driver
not a music engine. The driver is finished, and that includes the interfacing support for it as well; all the calls needed to load, stop, start, resume, set frequency, etc. The driver package itself will be public this month (I need to comb over the source remove any unnecessary stuff). I plan to write a
tiny music engine to show it off (how to use it, etc). And that's planned for this month. But the simple example music engine is not the point and not really for distribution (though I don't care what people do with it).
QuoteAnd what kind of resources does it us? (we already know about the cpu time.) How is it on memory? especially the zp space?
It uses 3 bytes of ZP space. I guess I should reduce that to 1 byte, and just push $00/$01 on the stack for the interface calls. So.. 1 byte of ZP space. CPU resource is light for the interfacing code. All changes are buffered and applied during a vblank call (the user calls this, not an automatic thing unless the user puts the call inside the vblank routine). This is needed because the TIMER routine is constantly using the PSG regs and you would have a conflict if code outside of the interrupt routine tried to update other PSG regs. Thus the need for buffering. Though that's the issue with any music engine and using the TIMER interrupt for DDA playback.
As far as cpu resource, disabling a channel for PCM output (making it free for normal use) reduces the cpu resource from 5.7% down to 0.4%. The last two channels, of the 6 total PCM streaming, take up 3.4% for PCM streaming per channel because they are fixed frequency, and they're also at a state of 0.4% cpu resource when not used. The TIMER interrupt overhead itself takes up 6.8% cpu resource regardless if any channels are playing or not. The TIMER interrupt routine
immediately enables interrupts so as not to stall the VDC interrupt service. Depending on the length of the VDC interrupt routine, as well as the number of instances, will result in jitter in PCM playback. A tight VDC routine is preferred, but not required. The PCM driver sets a flag during its call to prevent multiple instances from happening if for some reason it didn't finish the routine in time. Also, no banks needs to be permanently mapped for this routine to run. I figured flexibility was worth more than saving a handful few cycles per call.
It uses ~660bytes of system/ram memory and that includes the driver that needs to sit in ram. It needs 768bytes for the frequency look up table (sits in rom). And about 2k for the interfacing library (rom).
It's not extreme or drastic, or convoluted/complex in its interface into an another design/layout (game/etc). It's flexible in the number of channels a user can allocate/configure for PCM streaming, gaining back cpu resource for less channel usage. It's simple and realistic. It's not going to break down doors or win sound innovation of the year for retro systems, and it
does have some limitations in relation to quality (low bitrate, low frequency output), but it does allow some expansion on the PCE's sound capabilities. For me, that's exciting.
Quote[ Don't take that the wrong way. It's -not- a dig; it's a serious question. I'd like to see what it can do, especially the adpcm stuff....]
No worries :) I already have the ADPCM routine adapted to the VDC interrupt call (it runs out of there), and I think it was something like 50% cpu resource for decompressing to 10bit output (clipped from 13bit) @ 15.3khz (bound at 256 samples per 1/60 frame to keep things fast ;) ). The interesting part will be preping the audio stream, before compression, to see what kind of quality can be achieved. Anything above 7khz with PCE audio circuit, and filter effects starts to kick in. So it should sound a little smoother than the hardware ADPCM in the CD unit (which is pretty
sharp sounding), even though they both output to a 10bit DAC. I've already have a clear idea of how to show it off. It'll be interesting to see how it works out.
Quote from: TailChao on 12/03/2015, 01:06 AMActually, the whole reason I wrote HuSound was to force myself to start writing (NULL == pValue) instead of (pValue == NULL) before starting a new job.
Hahaha ... the joys of "other people's" coding standards. :wink:
I know that "(NULL == pValue)" is supposed to be "good" practice, but I just don't like the look.
I get bitten by the "(pValue = NULL)" bug once or twice a year, but it doesn't take long to find, and is a price that I'm personally willing to pay to not have to mentally deal with reading "reverse-polish" in my C source.
I don't like the old-school "(pvalue)" much, mostly because it gets really ugly (to me) once you start doing things like "(!pStruct || pStruct->mFlag)" ... which is the kind of test I'd rather see written out in long form to make it easier to read.
IMHO ... the "bug-fixing", "maintenance" and "reusability" phases of the life of a piece of source code all take a lot more time than what is saved by skipping a few keystrokes during the "initial coding" phase ... so "readability" is very high on my list of virtues in a programmer.
Of course, that comes from working on multi-programmer codebases that evolve over years of different projects. Like most people, I'm often a bit sloppier when it comes to my own quick-hack utilites.
Quote from: TheOldMan on 12/02/2015, 08:54 PMI just don't understand how changing the sound engine helps anything. The point behind squirrel (which, once again, is the MML compiler and *not* the assembler playback engine) was to make it possible to create sound that was system card compatible.
Thanks for clearing up the distinction between the compiler and the driver ... I keep on mixing them up. #-o
It's a great thing to have that System Card compatibility, but IMHO the real question is where you go
next.
When the first PCE CD unit came out with only 64KB RAM, it made some sense to have a sound driver in the System Card ROM (although a complete generation of 64KB-or-less 8-bit home computers managed without one).
Once you've got the 256KB of a Super System Card, it makes a lot less sense to be limited by the capabilities of the old driver, just "because-it's-there".
Instead, developers start to want to enhance their games with at-least-some sample-playback, either for instruments, or sound-effects, or speech.
As Bonknuts said, a number of games seem to have done that by using some really ugly hacks while still running original System Card driver. That complicates both the code and the creation of the original music, just to save the few KB needed to put in a new driver.
IMHO, that's not a great choice ... but then Japanese culture is very different to Western culture.
These days, since you guys at AetherByte now have your own source for both the "compiler" and the "playback" side of things, I hope that you guys would want to push things forwards a bit and make some improvements.
Perhaps Bonknuts' core sound driver matched with your higher-level compiled-MML will be a way to do that. :-k
QuoteI know that "(NULL == pValue)" is supposed to be "good" practice, but I just don't like the look.
I get bitten by the "(pValue = NULL)" bug once or twice a year, but it doesn't take long to find, and is a price that I'm personally willing to pay to not have to mentally deal with reading "reverse-polish" in my C source.
Yeah, I don't like the 'reverse polish' notation either. To my mind, I'm comparing a variable to a value - not the other way around.
And just by habit from long ago, my code is littered with if( cptr == (char *) NULL)... I know it's not needed (but I have a few funny stories about people who thought that and took it out, only to find out it really was needed sometimes), but it helps get around some type-checking warnings.
QuoteThese days, since you guys at AetherByte now have your own source for both the "compiler" and the "playback" side of things, I hope that you guys would want to push things forwards a bit and make some improvements.
The compiler code, yes.
AFAIK, the player code is still copyright NEC. That's why we aren't changing it, and why we can't license it like people keep asking. As for the licensing terms, that all because Arkhan wants to know who's actually using it - I don't think he's ever told anyone they can't, or had to pay royalties.
QuotePerhaps Bonknuts' core sound driver matched with your higher-level compiled-MML will be a way to do that.
I would love that. But I'm not sure a compiler-type program would do it. I'd have to see what the driver supports/does. It is a good idea, if it will work...
(I'd like to have a choice of drivers built into a bios image even better. :) )
Just a side note : the PC Engine Deflemask player thingie is far from being usable :(
You can fake samples with Squirrel if you convert them to 32 byte waves and cycle them quickly. I had it doing something at one point. There's enough space in the "custom waves" area above the presets that you can fit a few samples in.
But again, the real purpose of Squirrel (the MML compiler), was the following:
- To properly make use of the already existing sound engine built into the CD hardware since they were nice enough to put the damn thing there for us.
- To be damn near identical to how things are being done commercially still on the MSX, which is currently the most active old-hardware-game-producing-scene in existence. I worked closely with some MSX friends on some of the MML ideas that made it into Squirrel. They approved.
On that note, the Develo stuff basically mentions and includes MML stuff too. It's clear that is what was meant to be done with it. - To provide a fast, easy, headacheless way to produce sound effects and music in a game. See: Atlantean
I am more about functionality than anything.
The player was already sitting there. IIRC, there is sample support that could be hooked in. The one doc mentions it.
I could look into it more at some point. But, I am pretty comfortable with my thumpy kick drum I made without samples, and the snare is pretty cool too, so I was never really itching to use samples. Lots of high end commercial games don't use samples either. Some do, some don't. It's a style thing.
We also just recreated the sound engine for HuCards and removed the necessity of the PSG-BIOS stuff.
But, the ultimately useful thing that Squirrel allows for is flexibility
and portability.
Flexibility:Insanity's soundtrack features CD and chiptunes. They are generated from the same thing. I wrote the songs once. I used a professional music editing program, spit out midis, used 3MLE, and hand tweaked the MML. There's a video on YouTube demonstrating it. This workflow is arguably better. You get to use a modern DAW and all of it's nice features (that people would've killed for back then), and can then produce a file that plays on the PCE with minimal effort. Slap your VSTs ontop, and now your CD soundtrack is done too. Just export some .wav files...
Portability:Songs for Inferno (MSX game I am making) were originally PCE tunes. I copy pasted the MML into an MSX file and pressed about 4 buttons on my keyboard, and now they're MSX tunes instead.
I like this.
I also like using 3MLE to edit MML and have a visual (piano roll) representation. There are already existing editors out there for music. No point reinventing things. I prefer leveraging stuff that already works, so I can get to the whole "making a game" thing faster.
As for licensing, it's more a matter of "credit us for making your life easier" and "toss us a freebie of a game if you start selling them."
That's about it.
Well, that, and "don't modify the flying piss out of everything", because then it probably won't actually work like it's supposed to, and because we technically jacked things from NEC as OldMan mentioned.
Quote from: guest on 12/04/2015, 12:39 PM- To properly make use of the already existing sound engine built into the CD hardware since they were nice enough to put the damn thing there for us.
I've been wondering about this. Is it a sound engine from the CD cards that can be used by CD games, and stripped down so that HuCard games can use it too? Or is it from some kind of devkit library?
The Squirrel readme mentions Hu7/Develo.
Quote from: Pokun on 12/04/2015, 08:30 PMI've been wondering about this. Is it a sound engine from the CD cards that can be used by CD games, and stripped down so that HuCard games can use it too?
The System Card (version 1, 2 and 3) contains what the official documentation calls a "PSG Driver". That's also commonly known as a "Sound Driver" or "Music Engine" or various other synonyms.
My understanding is that "Squirrel" is Aetherbutt's compiler that turns MML into bytecode in the same format that the System Card's "PSG Driver" expects.
The data format that the "PSG Driver" expects is documented in the official Hu7 CD System documents.
From what TheOldMan has said, the actual "PSG Driver" that they're using for HuCards is actually just the same one that's on the System Card, that they've ripped out and disassembled (converted it back into source code), so that it can be re-assembled and used on a HuCard (i.e. it's not legally their code).
Arkhan's explanations of the benefits of multi-platform compatibility are absolutely true, at least for someone that wants to create music for a multi-platform game.
A significant chunk of the videogame industry has been using FMOD (http://www.fmod.org/ (http://www.fmod.org/)) for many years, precisely for that reason.
Quote from: Pokun on 12/04/2015, 08:30 PMQuote from: Psycho Arkhan on 12/04/2015, 12:39 PM- To properly make use of the already existing sound engine built into the CD hardware since they were nice enough to put the damn thing there for us.
I've been wondering about this. Is it a sound engine from the CD cards that can be used by CD games, and stripped down so that HuCard games can use it too? Or is it from some kind of devkit library?
The Squirrel readme mentions Hu7/Develo.
Yeah. The PSG thing is already present if you have the CD hardware (System Card). When we originally did this, we were making Insanity for PCE CD. So, it made alot of sense to just use what was there instead of wasting time trying to make our own stuff.
Initially, we had this sort of "on the fly" parse/play thing for MML that at least demonstrated that the idea worked. It wasn't perfect. I remember spending alot of time trying to get intervals to work right.
and yeah, Squirrel simply turns an MML file into the bytecode expected by the PSG driver.
I see, thanks!
I've put up another new Windows build of Mednafen (with my changes) for anyone that wants it ...
https://www.dropbox.com/s/9kmh6wiscv411ni/mednafen-0.9.38.7-x86-elmer.zip?dl=0 (https://www.dropbox.com/s/9kmh6wiscv411ni/mednafen-0.9.38.7-x86-elmer.zip?dl=0)
Just to remind any newcomers to this thread, the modifications are in Mednafen's PCE and PC-FX debugger displays in order to make them a bit more pleasant to look at, and more readable.
This is still a 32-bit version that only supports the PCE and PC-FX.
New features are ...
Built with the recent Mednafen 0.9.38.7 release.
Built with latest msys2 GCC compiler in the hope that this might run on Windows 10.
The patch files and a build script are available at ...
https://www.dropbox.com/s/2g6xwo4w4owwkuc/build-msys2-mednafen-0.9.38.7-x86-elmer.zip?dl=0 (https://www.dropbox.com/s/2g6xwo4w4owwkuc/build-msys2-mednafen-0.9.38.7-x86-elmer.zip?dl=0)
Downloaded, thanks .
Downloaded too. Thanks, I'll try it soon.
I've put up yet-another new Windows build of Mednafen (with my changes) for anyone that wants it ...
https://www.dropbox.com/s/6rpkviyhgihw4gt/mednafen-0.9.38.7-x86-elmer-2.zip?dl=0 (https://www.dropbox.com/s/6rpkviyhgihw4gt/mednafen-0.9.38.7-x86-elmer-2.zip?dl=0)
Just to remind any newcomers to this thread, the modifications are in Mednafen's PCE and PC-FX debugger displays in order to make them a bit more pleasant to look at, and more readable.
This is still a 32-bit version that only supports the PCE and PC-FX.
New features are ...
PCE now has 480KB of SCD RAM (banks $44-$7F), plus the 2MB ACD RAM (banks $40-$43).
PC-FX now has 8MB RAM.
The extra RAM can be useful during homebrew development as a place to store debugging-info.
It might also be useful for someone that needs the extra memory for a translation.
N.B. This is a 32-bit build, but 64-bit Windows builds are now working if someone wants to build it from source.
The patch files and a build script are available at ...
https://www.dropbox.com/s/i3mor256dhrddef/build-msys2-mednafen-0.9.38.7-x86-elmer-2.zip?dl=0 (https://www.dropbox.com/s/i3mor256dhrddef/build-msys2-mednafen-0.9.38.7-x86-elmer-2.zip?dl=0)
Rather than sift through this and try to figure out what the hell was going on:
Where's CC65 at with regards to using it instead of HuC for making games?
Quote from: guest on 02/22/2016, 04:26 AMWhere's CC65 at with regards to using it instead of HuC for making games?
Short Answer:
It just requires the desire to use it, and the willingness to copy over any HuC library routines that you want to use.
From my POV, that makes it perfectly usable, but I suspect that you've got a different POV. :wink:
------------------------
Long Answer:
The workflow is definitely going to be different to HuC, because of it is the more-traditional compile/assemble/link style, and because it doesn't have HuC's PCE-specific #incpal/#inctile/#incspr functions.
CC65/CA65 are working perfectly fine as a compiler/assembler.
I've built a test-rom with it to confirm that it compiles standard C code (a FAT32 library for reading the Everdrive's SD card).
It was easy to use and incredibly flexible once you've got your head around the power of its code-layout and startup options.
The point is that it's
all configurable and
you get to decide where the linker puts the startup-code/library-code/game-code/data.
The guy that was working on the PCE-port hasn't committed anything new in about 4 months. But that's not really a problem since he was definitely a novice on the PCE and was doing some things in a very strange (and wrong) way.
Because it's all "linked", we can just use the bits of his CC65-specific code that we like, and override anything else with new code.
Then, if you want to make a CD, you have to piece-together the .iso binary with something like 'bincat' and then modify the 2nd-sector with your particular
------------------------
Here's my batch file for compiling the test code ...
# C files.
cc65 -O -t pce hello.c
cc65 -O -t pce fatfs/ff.c
cc65 -O -t pce fatfs/diskio.c
cc65 -O -t pce fatfs/option/unicode.c
ca65 -t pce -v hello.s
ca65 -t pce -v fatfs/ff.s
ca65 -t pce -v fatfs/diskio.s
ca65 -t pce -v fatfs/option/unicode.s
# ASM files.
ca65 -t pce -v crt0.s
ca65 -t pce -v text.s
ca65 -t pce -v sd.s
# Link
ld65 -o hello.pce -m hello.map -C pce.cfg hello.o text.o sd.o fatfs/ff.o fatfs/diskio.o fatfs/option/unicode.o crt0.o pce.lib
------------------------
I decided to use the following layout for the HuCard ...
The STARTUP & library CODE go in bank $00 that lives at $E000-$FFFF.
The INIT code and the 'initialized' DATA (that get copied to RAM) goes in bank $01 that lives (temporarily) at $C000-$DFFF.
Once the HuCard starts up and my customized crt0.s runs the INIT code, and copies the 'initialized' DATA to RAM, then I map banks $02-$05 into $4000-$DFFF for my main code, and leave $C000-$DFFF for paging code/data as I need to.
Now I'm not saying that this is a particularly great way to lay out a HuCard, but I needed an uninterrupted 32KB for the FAT32 code, and the big point is that I was easily able to do that with CC65.
And here's my customized CC65 configuration file for that layout ...
SYMBOLS {
__STACKSIZE__: type = weak, value = $0300; # 3 pages stack
}
MEMORY {
# Preserve System Card standard ZP locations.
ZP: start = $00, size = $ec, type = rw, define = yes;
# reset-bank and hardware vectors
ROM0: start = $E000, size = $1FF6, file = %O, fill = yes, define = yes;
ROMV: start = $FFF6, size = $000A, file = %O, fill = yes;
ROM1: start = $C000, size = $2000, file = %O, fill = yes, define = yes;
ROM2: start = $4000, size = $8000, file = %O, fill = yes, define = yes;
ROM6: start = $C000, size = $2000, file = %O, fill = yes, define = yes;
ROM7: start = $C000, size = $2000, file = %O, fill = yes, define = yes;
# First RAM page (also contains stack and zeropage)
RAM: start = $2200, size = $1E00, define = yes;
}
SEGMENTS {
STARTUP: load = ROM0, type = ro, define = yes;
INIT: load = ROM1, type = ro, define = yes, optional = yes;
CODE: load = ROM0, type = ro, define = yes;
RODATA: load = ROM0, type = ro, define = yes;
DATA: load = ROM1, type = rw, define = yes, run = RAM;
SDCODE: load = ROM2, type = ro, define = yes;
SDDATA: load = ROM2, type = ro, define = yes;
BSS: load = RAM, type = bss, define = yes;
VECTORS: load = ROMV, type = rw, define = yes;
ZEROPAGE: load = ZP, type = zp, define = yes;
EXTZP: load = ZP, type = zp, define = yes, optional = yes;
APPZP: load = ZP, type = zp, define = yes, optional = yes;
}
FEATURES {
CONDES: type = constructor,
label = __CONSTRUCTOR_TABLE__,
count = __CONSTRUCTOR_COUNT__,
segment = INIT;
CONDES: type = destructor,
label = __DESTRUCTOR_TABLE__,
count = __DESTRUCTOR_COUNT__,
segment = RODATA;
CONDES: type = interruptor,
label = __INTERRUPTOR_TABLE__,
count = __INTERRUPTOR_COUNT__,
segment = RODATA,
import = __CALLIRQ__;
}
EDIT:
I guess that it would help to explain a couple of things in the configuration file (it's for the "LD65" linker).
The "MEMORY" section is basically just a list of areas (and their sizes) that get written to the output file ... in this case I'm having it create an 8 bank HuCard ROM image.
The actual names of the different sections in "MEMORY" can be anything ... I'm just using the name "ROM" + bank-offset for my own convenience.
The "SEGMENTS" section defines the names of the different segments in the C and ASM code (user-defined, but with a few defaults like CODE/DATA/RODATA/RAM), and it shows where in the output file those segments should be put.
That's it ... you have total flexibility to map your code/data into the output HuCard/ISO image in any way that you like.
------------------------
Ah. Well, that's straightforwardish.
And I guess really, the real dilemma for me is the whole Squirrel thing. lack of chiptunes = how do I games.
Though, I don't think dealing with the CD BIOS to feed Squirrel in would be too hard.
Mapping in all the HuCard version crap might not really be that hard either.
I'd look, but I don't want to distract myself from finishing this MSX game.
I tend to work serially on things.
QuoteAnd I guess really, the real dilemma for me is the whole Squirrel thing.
Don't worry about it. From what I've seen, we can put the player in whatever page we want, and fix the startup/irq code to handle it. It shouldn't be any worse than the Huc modifications.
My worry is getting the Huc functions to work. Guess I'll install this, and see what I can do..
Quote from: TheOldMan on 02/23/2016, 03:28 AMQuoteAnd I guess really, the real dilemma for me is the whole Squirrel thing.
Don't worry about it. From what I've seen, we can put the player in whatever page we want, and fix the startup/irq code to handle it. It shouldn't be any worse than the Huc modifications.
My worry is getting the Huc functions to work. Guess I'll install this, and see what I can do..
It really shouldn't be too hard to get any ASM source transferred over.
It's the subtle changes in syntax that'll annoy you.
Like "TAM #$40" instead of "TAM #6", or the horrible old original "LDA (<$F8),Y" instead of "LDA [$F8],Y".
I might see if I can hack it to accept the square bracket syntax (the TAM syntax doesn't bother me, since that's what Mednafen displays ... although I could always hack that, too).
EDIT:
They do allow "TAM6" instead of "TAM #6".
Looks like it should be easy to change the '(' to a '[', but that will probably kill the assembler's ability to properly deal with the SNES's 65816 24-bit "far" addresses.
I suspect that we don't really care too deeply about that! :wink:
Oh ... one last thing, the MACRO syntax is
totally different.
Let me just say thank you guys for furthering the tool progression, for non-programmer types like myself it's endlessly helpful to read through your opinions and documentation! Bravo, I owe you guys some beers or sodas!
I started working on a pceas/ca65 stuffs.
The macro syntax is different but you can get something close but not enough to avoid doing the job twice.
Example :
https://github.com/BlockoS/HuDK/blob/master/include/pceas/word.inc
vs
https://github.com/BlockoS/HuDK/blob/master/include/ca65/word.inc
Quote from: elmer on 02/23/2016, 11:39 AMIt's the subtle changes in syntax that'll annoy you.
Like "TAM #$40" instead of "TAM #6", or the horrible old original "LDA (<$F8),Y" instead of "LDA [$F8],Y".
I might see if I can hack it to accept the square bracket syntax (the TAM syntax doesn't bother me, since that's what Mednafen displays ... although I could always hack that, too).
...
They do allow "TAM6" instead of "TAM #6".
Looks like it should be easy to change the '(' to a '[', but that will probably kill the assembler's ability to properly deal with the SNES's 65816 24-bit "far" addresses.
I guess that I should really ask the programmers here ... do you care about this stuff?
In some ways, I don't like the idea of changing CC65 "just-for-the-sake-of-it".
As it is now, it's using the offical syntax for both the HuC6280 and the 65816.
It's pceas that's got the "TAM" wrong, and while I personally find the '[' indirection easier to read than the '(' version, and while there are lots of 6502 assemblers use it ... it's not the "official" syntax.
I think that I can make CA65 accept either syntax (on everything except the 65816) ... but is that an "ugly" hack that just shouldn't be done?
How do you guys feel about it?
I would fix the non standard compiler instead.
QuoteHow do you guys feel about it?
Personally....I'll adapt. Either '[' or '(' is fine
Can I macro (something like) MPR6 = $40?
Quote from: TheOldMan on 02/24/2016, 02:04 AMQuoteHow do you guys feel about it?
Personally....I'll adapt. Either '[' or '(' is fine
Can I macro (something like) MPR6 = $40?
Do you mean just a regular constant, i.e. "TAM #MPR6"? Sure, that would work.
If you use the "TAM6" syntax, then you could just write a macro for that on pceas.
Quote from: MooZ on 02/24/2016, 01:41 AMI would fix the non standard compiler instead.
??? CC65 ???
CC65 has properly compiled the standard C89-compliant code that I've thrown at it ... which HuC's small-C-based compiler doesn't.
I'm not sure what you mean.
You got me wrong :)
I was meaning pceas.
Quote from: MooZ on 02/24/2016, 12:42 PMYou got me wrong :)
I was meaning pceas.
Ahhh ... I thought that was probably what you meant, thanks for the clarification.
--------------
I've asked the CC65 developers what their opinion is on putting in an option for using square-brackets instead of braces.
As a "programmer", I personally prefer the square-bracket, because it makes things easier to read (to me), and because I like to put expressions in braces, particularly when they are complex expressions, so I prefer
lda (structure+member_offset),y rather than
lda structure+member_offset,y It's just not possible to use a complex expression in some 6502 instructions if the opening brace of that expression changes the meaning of the instruction.
But, like TheOldMan, I can adapt if necessary.
I agree. The code is more readable with square-brackets.
Quote from: elmer on 02/24/2016, 12:57 PMI've asked the CC65 developers what their opinion is on putting in an option for using square-brackets instead of braces.
They're OK with the idea in principle ... so now it's all up to the details. :)
I've submitted a patch to them that will allow us to use the square-bracket syntax in any assembly source file, controlled by a ".feature" setting.
I look forward to hearing what changes they ask for.
Quote from: Gredler on 02/23/2016, 01:33 PMLet me just say thank you guys for furthering the tool progression, for non-programmer types like myself it's endlessly helpful to read through your opinions and documentation! Bravo, I owe you guys some beers or sodas!
Definitely beer ... I've heard that soda is bad for you! :wink:
As I said a year ago in this very thread ...
Quote from: elmer on 02/28/2015, 08:28 PMI'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.
Quote from: TheOldMan on 02/23/2016, 03:28 AMQuoteAnd I guess really, the real dilemma for me is the whole Squirrel thing.
Don't worry about it. From what I've seen, we can put the player in whatever page we want, and fix the startup/irq code to handle it. It shouldn't be any worse than the Huc modifications.
My worry is getting the Huc functions to work. Guess I'll install this, and see what I can do..
Yeah, I'd figure the HuCard stuff is the trickier part since the CD one just calls into existing stuff. Since potentially using CC65 lets us literally pick everything, we can stop things from getting shoved around how we don't want.
I haven't had time to look at PCE code due to MSXing.
I'd also be more worried about the screen/vram related library functions, because they are more involved/goony.
As for the ( vs [.
Use both.
tniasm for MSX supports () and [] for indirection. It's nice to have that kind of support.
I've got no idea how long it's going to take to get the CC65 patch approved and put into the main line.
If anyone wants/needs a custom-build of CC65 with the new "square-bracket" option, then I can upload one to my dropbox.
As long as by making things standard you don't introduce a whole shitload of additional bloat, I'm all for that. :lol:
Quote from: OldRover on 02/28/2016, 07:57 PMAs long as by making things standard you don't introduce a whole shitload of additional bloat, I'm all for that. :lol:
It's a
tiny patch. The "documentation" and the stuff for enabling the patch by using the ".feature" command together dwarf the actual patch itself.
Here you go, it's in the "queue" ...
https://github.com/cc65/cc65/pull/269
FWIW, the option for using "[]" for indirection is now in the mainline CC65 repository. :)
https://github.com/cc65/cc65
Cool!
alright, I've been trying to get the hang of doing PCE development with ca65 and ld65...
Managed to load a font and write to BAT, though I've been having some trouble dealing with VRAM locations...
(https://www.ajworld.net/pcedev/example01_screen.png)
rom and source code is available here (http://www.ajworld.net/pcedev/pce-example01_ca65.zip); requires gnu make and a recent ca65/ld65 set.
With relation to VRAM troubles, I have to offset the location the file gets loaded by 4 (it was previously 3 before I changed how I was calculating the VRAM address)... not sure how to go about fixing this, so I'm hoping one of the PCE gurus will check it out and lend me a hand :p
Hi, first you set your VRAM position badly
you did it like that:
st0 #VDCREG_MAWR
st1 #<$0804
st2 #>$0804
It must be:
st0 #VDCREG_MAWR
st1 #<($0800 >> 4)
st2 #>($0800 >> 4)
All VRAM read/write addresses must be (my_address >> 4), and for sprite patterns (my_address >> 5)
PS:Your source code is very clean :wink:
Quote from: touko on 03/11/2016, 04:31 AMPS:Your source code is very clean :wink:
thanks, that was one of my goals :)
Quote from: touko on 03/11/2016, 04:31 AMyou set your VRAM position badly
you did it like that:
st0 #VDCREG_MAWR
st1 #<$0804
st2 #>$0804
It must be:
st0 #VDCREG_MAWR
st1 #<($0800 >> 4)
st2 #>($0800 >> 4)
I just tried this out in mednafen, and this seems wrong... the VRAM looks like this:
dropboxusercontent.com/u/6447287/pcedev/800_lsr4-vram.png
Quote from: touko on 03/11/2016, 04:31 AMAll VRAM read/write addresses must be (my_address >> 4), and for sprite patterns (my_address >> 5)
That sounds right for the BAT and SATB areas, but I'm having trouble with just getting the tiles into VRAM properly...
if I just use $0800 as the VRAM source address, a la
st0 #VDCREG_MAWR
st1 #<$0800
st2 #>$0800
this is what I get in the VRAM viewer:
dropboxusercontent.com/u/6447287/pcedev/800_regular-vram.png
(edit)
and for reference, here's what the VRAM looks like when I load into $0804:
dropboxusercontent.com/u/6447287/pcedev/804_dumbluck-vram.png
EDIT: Sorry i was wrong, VRAM read/write addresses are good :P
You only shift tile/sprite addresses, not VRAM ones .
I tried to load your font with pceas and it works fine .
Try this for loading your font:
lda #.bank( gfx4BPP_font )
tam #2
inc A
tam #3
st0 #0
st1 #<( $800 )
st2 #>( $800 )
st0 #2
tia gfx4BPP_font , $0002 , $800
Your vram_clearBAT code isn't correct ... you're using Y without initializing it.
Your loop should look more like ...
lda #$80
ldx #32
@rowLoop: ldy #32
@colLoop: sta a:VDC_DATA_LO
stz a:VDC_DATA_HI
dey
bne @colLoop
dex
bne @rowLoop
Your font loading code isn't correct ... you're using Y without initializing it (because font_loadSize is $0800).
; load loop goes here
ldx font_loadSize
beq @checkOuter
cly
@fontLoadLoop: lda (fontDataAddr),y
Fix those bugs, and you'll find that you can write to VRAM $0800 as your expect.
Quote from: touko on 03/11/2016, 05:47 AMI tried to load your font with pceas and it works fine .
Try this for loading your font:
...
tia gfx4BPP_font , $0002 , $800
I keep forgetting I'm not coding straight 6502 and have access to things like this; thanks :)
Though I did have to change $800 to $800*2 since the VRAM expects word values.
Quote from: elmer on 03/11/2016, 12:13 PMYour vram_clearBAT code isn't correct ... you're using Y without initializing it.
aha, so I was getting by on pure luck. ;) I figured that routine was broken somehow, due to being a late night coding exercise.
Quote from: elmer on 03/11/2016, 12:13 PMYour font loading code isn't correct ... you're using Y without initializing it (because font_loadSize is $0800).
ah, there we go, that would be it. guess I wasn't running the branch code properly in my head :)
Thanks for your help, elmer and touko; this weekend is going to be a lot of fun.
here's the fixed example, in case anyone wants it:
http://www.ajworld.net/pcedev/pce-example01_ca65-fixed.zip (http://www.ajworld.net/pcedev/pce-example01_ca65-fixed.zip)
other comments/critique are welcome :)
QuoteI keep forgetting I'm not coding straight 6502 and have access to things like this; thanks :)
Though I did have to change $800 to $800*2 since the VRAM expects word values.
Of course, $800 was just a value to see if your font start to load correctly at $800 in VRAM ..
Quoteother comments/critique are welcome :)
A little tips,no need to write the LOW value in VRAM if it's the same all the time in your loop,because it's buffered .
Write it before the loop, and write only the HIGH byte in your loop, it's 2x time faster :wink:
For exemple, writing 32 words in VRAM
ldx #32
lda #low_byte
sta $0002
loop:
stz $0003
dex
bne loop
Quote from: touko on 03/11/2016, 02:22 PMA little tips,no need to write the LOW value in VRAM if it's the same all the time in your loop,because it's buffered .
Write it before the loop, and write only the HIGH byte in your loop, it's 2x time faster :wink:
For exemple, writing 32 words in VRAM
ldx #32
lda #low_byte
sta $0002
loop:
stz $0003
dex
bne loop
Hmmm ... I'm not sure if that counts as "very-clever", or "fugly". Either way ... for-gawd's-sake, please put some comments in the code when you do that, or it'll bite you in the ass when you least expect it.
BTW ... has it been confirmed that you get the full-benefit of the trick on real hardware?
I'm curious if the loop is still slow enough to avoid overrunning the CPU-to-VRAM bandwidth and causing cycle stalls from that (the way that we've only just found out about the unexpected TSB/TRB delay).
QuoteBTW ... has it been confirmed that you get the full-benefit of the trick on real hardware?
Yes tested on my SGX,the 2 bytes are buffered, and writed to VRAM only when you write to $0003 .
You canot update only the low byte in VRAM .
It's very well explained in charles's doc .
Quote from: touko on 03/12/2016, 01:41 PMQuoteBTW ... has it been confirmed that you get the full-benefit of the trick on real hardware?
Yes tested on my SGX,the 2 bytes are buffered, and writed to VRAM only when you write to $0003 .
You canot update only the low byte in VRAM .
It's very well explained in charles's doc .
I not arguing about how the buffering works ... just questioning the actual speed improvement.
For instance ...
st1 #$00 ; 4+1 cycles
.loop: st2 #$00 ; 4+1 cycles
st2 #$00 ; 4+1 cycles
st2 #$00 ; 4+1 cycles
st2 #$00 ; 4+1 cycles
st2 #$00 ; 4+1 cycles
st2 #$00 ; 4+1 cycles
st2 #$00 ; 4+1 cycles
st2 #$00 ; 4+1 cycles
dex
bne .loop
Will this really clear VRAM 8-words-at-a-time, at 40 cycles per 16 bytes, i.e. 2.5 cycles per byte?
As Bonknuts found out with the TSB/TRB test ... there was an unexpected delay in the turn-around between the read and the write, presumably caused by the VDC having to wait for a CPU read/write slot in the VRAM cycle timings.
Ah ,ok, i understand, of course it's faster in a dev point of view(and I do not take in any count some latency here), but i don't know if it's really faster due to some latency between each write,and i don't know if they are those latencies for stx, i think they are also present for lda/sta .
The tsb/trb case is apart because it read/write the same VRAM region (it needs 2 CPU slots),and bonk's tests was in low resolution mode.
I'll do some tests with the 2 methods to see if there is a difference.
Quotepresumably caused by the VDC having to wait for a CPU read/write slot in the VRAM cycle timings.
I think so, and if it's the case, latency should be done in MED/HIGH res mode.
The speed penalty from my TRB/TSB, comes from the VDC doing something internal from vram read to vram wright - hence the delay.
I didn't encounter any additional stuff for just sequential back-to-back writes (on screen or otherwise). Though technically you could hit an unavailable slot during active display, but that's going to be in partial master clock cycles (/RDY) and not whole instruction cycles. But I never noticed it in the timings of my sequential write tests (the error is probably spread over too many writes to be noticeable).
QuoteThe speed penalty from my TRB/TSB, comes from the VDC doing something internal from vram read to vram wright - hence the delay.
Yes TRB/TSB assume that there is no delay, because it suppose you use them on RAM,it's not the case with VDC, you only can write/read when a CPU slot is available, and this can cause delay,the more is for 256 px res ..
Quote from: touko on 04/08/2016, 04:22 AMQuoteThe speed penalty from my TRB/TSB, comes from the VDC doing something internal from vram read to vram wright - hence the delay.
Yes TRB/TSB assume that there is no delay, because it suppose you use them on RAM,it's not the case with VDC, you only can write/read when a CPU slot is available, and this can cause delay,the more is for 256 px res ..
But that's the point; I don't think it's a cpu slot availability thing with TRB/TSB. I think it's something more. Because I can do a series of st2 or sta on the msb, or straight read lda on the msb, and never really see much of that slot offset phase in negative performance. With TRB/TSB, on the MSB, it's has something to do with the VDC switching from a vram read operation to a vram write operation - and not the cpu access slot availability.