Getting started programming?

[Arkhan Asylum]

I've actually had PSP since 7.    I upgraded mine for 45$ or whatever.


The other reason I think Adobe sucks is basically what they've done to themselves.

Adobe fucked up CoolEdit, and turned their software into this juggernaut of nonsense.

Don't you have to login to use the subscription based one?

[Gredler]

You don't have to be online, and it's a one time login. You have to be online for updates obviously and that probably checks your credentials but it's never asked me to logon after the initial installation.

I can see your trpedation about Adobe because of audition/cooledit. I kinda feel the same way about Autodesk and Maya, but after acclimating to max by need of a job I had, I found that Maya (and max) getting shared features between the two makes them both better. These megacorps be shitting on our habits, it's rough dude I feel ya


I used PSP either 1 or 2, can't remember very well. I used it to draw Mario

[ccovell]

Two new videos, one on CPU instructions, and the other, we get started writing some code:

[Pokun]

A beginner tutorial for assembly, that's just what PC Engine needs!

Just finished watching them all and they are great tutorials! A bit slow at first but you show a lot of things that's not so easy to show in a written document so that's cool, and when you finally get to coding it's just great.

I'm looking forward to see more.

I don't know if anyone besides myself has written code and demos for the SF2 mapper, but PCEAS inability to handle anything beyond 1megabit and since there's no linker system - it makes handling organization of data painful or wasteful. Injecting the data into rom and expanding it with external tools is not a problem, but putting those labels and attributes into the main source file remains a by hand process. Normally I don't complain about PCEAS not having a linker, but this is probably one case that I would argue otherwise. From my perspective, if you're going to develop a hucard game without the intent to sell in physical form, the SF2 mapper is a great choice. It just needs additional tools; both for HuC and for PCEAS.

Hmm why can't it handle bigger than 2 Mbit if I may ask?
Now when cc65 handles Hu6280, what about using ca65 and the linker ld65 from the cc65 suit? That's what I'm doing for Snes and it's one of the most popular assemblers for Nes (although I'm using asm6 for Nes because it's simple like PCEAS). For newbie tutorials, PCEAS2 is probably the better choice though.

[elmer]

Hmm why can't it handle bigger than 2 Mbit if I may ask?

I suspect that Bonknuts means 8Mbit (1MByte), which is the largest cartridge size.

I know that the Catastrophy guys are using well over 1Mbit (128KByte).

It can probably be extended to handle larger cart sizes, but nobody has done so, probably because nobody  has needed the extra space.

Now when cc65 handles Hu6280, what about using ca65 and the linker ld65 from the cc65 suit? That's what I'm doing for Snes and it's one of the most popular assemblers for Nes (although I'm using asm6 for Nes because it's simple like PCEAS). For newbie tutorials, PCEAS2 is probably the better choice though.

CC65 is already usable on the PCE, I've used it.

It's just missing a lot of usability stuff like libraries, and it doesn't take any advantage of the Hu6280 or the memory segmentation/paging.

CA65 already understands Hu6280, but it has a problem with our zero-page being at $2000 instead of $0000.

You can see a long discussion of my attempts to talk to the guys about that on their github bug-tracker.

The discussion stopped a while back, and I don't know if there's ever going to be an official fix ... there are some deep-seated problems in Ulrich's original CA65 code-design that will take some fixing.

So, for the moment, PCEAS really is the best choice available (IMHO).

And while HuC lacks a lot of the code-optimizations in CC65, it does a number of things better (for the PCE), and its library is helping folks make games today.

[Pokun]

It can probably be extended to handle larger cart sizes, but nobody has done so, probably because nobody  has needed the extra space.

So PCEAS simply rejects assembling larger HuCard ROMs than 1 MB? Sounds like another mostly pointless restriction like the forced 8 kB banks thing that was fixed in PCEAS2.

CC65 is already usable on the PCE, I've used it.

Yes, I was mainly discussing the assembler CA65.

CA65 already understands Hu6280, but it has a problem with our zero-page being at $2000 instead of $0000.

You can see a long discussion of my attempts to talk to the guys about that on their github bug-tracker.

The discussion stopped a while back, and I don't know if there's ever going to be an official fix ... there are some deep-seated problems in Ulrich's original CA65 code-design that will take some fixing.

So, for the moment, PCEAS really is the best choice available (IMHO).

I see, it would be useful if it simply had an assembly directive to relocate the Zero Page to wherever the user want:

.zploc $2000  ;tell assembler where the Zero Page is

And then you are done with it for PC Engine. Would be useful for 65816's relocatable Direct Page as well.

Thanks for the explanation though. It sounds like CA65 isn't really ready for the Hu6280 yet, I guess I'll stick to PCEAS2. The main problem I have with it so far is that it doesn't have a complete readme file. The documentation that comes with Magicengine and HuC doesn't seem to be complete for PCEAS.

[elmer]

So PCEAS simply rejects assembling larger HuCard ROMs than 1 MB?

Errrr ... What would you like it to do? 

This is no standardized mapping scheme for > 1MB HuCard ROMs.

There was only one > 1MB HuCard ROM ever released, and nobody has implemented its mapping scheme in a homebrew HuCard release (that I know of).

Sounds like another mostly pointless restriction like the forced 8 kB banks thing that was fixed in PCEAS2.

I'm sure that the original PCEAS devs thought that it made sense.

It didn't really ... because they already handled an incbin that crossed bank boundaries, but ... oh, well.

BTW, PCEAS2 does NOT properly fix the problem. 

http://pcedev.wordpress.com/2012/02/06/new-tg16pce-assembler/

Opcodes that cross 8k bank boundaries no longer create an error and stop assembling. That is to say, if one or more opcode's byte cross that boundary. Now it will generate a warning instead, but assemble correctly.

Well, PCEAS2 doesn't fail when a bank is crossed, that part was definitely fixed.

But it doesn't actually assemble correctly.

None of the bytes that cross the boundary are written to the new bank, and they just stay at the default $FF.

You can see that if you edit his test2.asm, line 102 and change "lda #$FF" to "lda #$23" and run go.bat.

   99           5FFF        .org $5fff
  100  01:5FFF            cross_bank:
  101  01:5FFF            .loop
  102  01:5FFF  A9 FF       lda #$23
  103  02:6001  80 FC       bra .loop


I'll be fixing this in the next build of Uli's HuC, because it's messing up Huzak when there's tune data larger than 8KB.

I see, it would be useful if it simply had an assembly directive to relocate the Zero Page to wherever the user want:

.zploc $2000  ;tell assembler where the Zero Page is

And then you are done with it for PC Engine. Would be useful for 65816's relocatable Direct Page as well.

That's what they've been trying to implement.

But there are some deep-seated design choices (I'd call them "mistakes") that get a bit confused when $00xx is not a zero-page location.

[Pokun]

Heh well it kind of makes sense to assume that the Zero Page is always page 0. I guess Hudson should have called it the $20-page or something. I guess that's why they renamed it the Direct Page for 65816 in the first place, since it's relocatable to other pages.

So PCEAS simply rejects assembling larger HuCard ROMs than 1 MB?

Errrr ... What would you like it to do? 

This is no standardized mapping scheme for > 1MB HuCard ROMs.

There was only one > 1MB HuCard ROM ever released, and nobody has implemented its mapping scheme in a homebrew HuCard release (that I know of).

I see, so then it's not an artificial rejection but rather a matter of running out of addressing space.
Ideally it still should be possible to make games using the Street Fighter II' mapper somehow though.

Sounds like another mostly pointless restriction like the forced 8 kB banks thing that was fixed in PCEAS2.

I'm sure that the original PCEAS devs thought that it made sense.

Yeah well it's not as much a matter of making sense as a matter of putting unecessary restrictions on the assembler. There's no telling when you need to do something different than the usual way, and then these kinds of restrictions get in the way. That's why I think giving warnings and making things optional is the way to go.
For NESASM (the Famicom version of PCEAS if I understand things correctly) the forced 8 kB banks makes zero sense though (unless you are using certain mappers) which is why people dislike it over at Nesdev.net.

Well, PCEAS2 doesn't fail when a bank is crossed, that part was definitely fixed.

But it doesn't actually assemble correctly.

None of the bytes that cross the boundary are written to the new bank, and they just stay at the default $FF.

Oh I had no idea it wasn't really fixed. I've yet to make a program that is big enough to need more than one ROM bank of code.

So which version of PCEAS is the one to go with? I'd prefer an assembler that doesn't create extra banks and stuff that you don't tell it to. I'll create my own libraries.

[elmer]

Oh I had no idea it wasn't really fixed. I've yet to make a program that is big enough to need more than one ROM bank of code.

So which version of PCEAS is the one to go with? I'd prefer an assembler that doesn't create extra banks and stuff that you don't tell it to. I'll create my own libraries.

AFAIK, no version of PCEAS automatically creates or uses extra banks ... by itself.

If you *choose* to use the "proc" functionality in PCEAS, that was designed for HuC, to allow for the automatic relocation of functions into different banks ... then "yes", you'll end up with extra junk, and you'll be locked into HuC's uncommon memory-map.

If you avoid "proc" functions, and just code as normal in regular assembly-language, then PCEAS has no overhead.

I use the latest version of PCEAS, from the latest version of HuC that I've posted, and I just code in pure assembly language without using any of the HuC or MagicKit libraries, or functions. or memory map.

So, although I'm obviously biased, I'd recommend that you use the PCEAS and selected equates from the latest HuC, and just ignore (or delete) all of the other files in the download.

If you're programming in assembly-language, then just avoid huc.inc and startup.asm, they're a mess! 

At least then, you'd know who to come to with any complaints. 

Uli added various enhancements to bonknuts' changes in PCEAS 3.22, and I've added more of my own since.

Or you can just look at the most recent patches in github, and apply those to bonknuts' 3.22 source files, if you'd like to go that route.

[Pokun]

Ah so Bonknut's improvements are already in these HuC forks. Good, I'll just grab the assembler. Thanks!

Edit: OK I'm using this one.

[elmer]

Ah so Bonknut's improvements are already in these HuC forks. Good, I'll just grab the assembler. Thanks!

Edit: OK I'm using this one.

Yep, that's the latest build, with the bank-crossing fix.

http://pcedev.wordpress.com/2012/02/06/new-tg16pce-assembler/

Though what I would like to add in the future is <# and >#for shorthand #low() and #high() directives, which have nothing to do with ZP addressing.

I don't remember if I documented it anywhere, but the version of PCEAS in the new HuC already contains a change so that "<" and ">" are unary-operators and synonyms for low() and high().

i.e.

lda #<label
lda #>label

Gives you the low byte and high byte of the label, just like in almost-every-other 6502 assembler that I've ever seen.

[Pokun]

Yup those are great additions. I saw those in the thread. The #^(label) shorthand for #BANK(label) was also added.
But no I don't think you documented it at all. PCEAS has always been plagued by a lack of documentation. lol

(The original "usage.txt" file doesn't even mention how zero page addressing is done!)

[ccovell]

A little bump since I've added episode 5 to my tutorial videos:

https://www.chrismcovell.com/PCEdev/

[Pokun]

Great! Episode 6 is now also up! Finally some BG characters and sprites! Gotta catch up on these later when I feel like learning more PC-Engine development.

Thanks for your hard work!