News:

Upgrading to the new 2022 2.1 SMF core (years in WIP)! Mobile/Phone support by default, finally! I must port all my custom features and redo the theme however, but worth the trouble! I may still look at XenForo too.

Main Menu

Getting started programming?

Started by MNKyDeth, October 29, 2016, 12:21:52 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

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.

Quote from: elmer on February 20, 2017, 05:58:42 PM
Quote from: Pokun on February 10, 2017, 09:22:13 AMSo PCEAS simply rejects assembling larger HuCard ROMs than 1 MB?
Errrr ... What would you like it to do?  :-k

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.

Quote from: elmer on February 20, 2017, 05:58:42 PM
Quote from: Pokun on February 10, 2017, 09:22:13 AMSounds 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.

QuoteWell, 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

Quote from: Pokun on February 21, 2017, 04:57:59 AMOh 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!  #-o

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

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

#52
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

Quote from: Pokun on February 22, 2017, 05:37:11 AMAh 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.


Quote from: bonknutshttp://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! :D