News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: 65xx Assembler Alpha release: Schasm  (Read 12125 times)

Disch

  • Hero Member
  • *****
  • Posts: 2814
  • NES Junkie
    • View Profile
65xx Assembler Alpha release: Schasm
« on: July 13, 2015, 12:50:41 am »
I was torn as to whether or not to put this in the Romhacking forum or here in the programming forum.  Ultimately it seemed like programming made more sense.

Anywho.   For a... 'project'... I've been needing an assembler for SNES.  After toying around with xkas 0.06, xkas 0.12, wla-dx, and ca65... I had come to the realization that none of these assemblers do what I want on a level that I want them to.  There is like a handful of critical features that I need, and while some assemblers have some of them, none of them have all of them.

So what to do?  Create my own assembler, of course!


So here's Schasm.  An assembler for the 65xx series.
https://www.dropbox.com/s/wsivt454ucd884q/schasm_alpha002_2015_07_16.zip?dl=0

Note that this is an ALPHA release in that I have done practically ZERO testing on this, so it almost certainly has bugs.  I'm going to resume my ... 'project'.... using this assembler and try to uncover bugs in the process... but I figured I would post the assembler here if anyone else is interested in trying it out to help me find problems with it.

Since it's an alpha, I do not want it to be hosted on RHDN just yet, so I did not submit it.  I want to wait until I'm satisfied it's reasonably stable and reliable.



So why should anyone use this assembler over any of the others?  Well, that's a subjective question.  So here's a general feature list.  Again note that some assemblers have some of these, but no assembler I've tried has all of them:

- Inject assembly into an existing ROM without rewriting the entire file
- system agnostic approach to file offsets.  The #org address is independent of the ROM offset (why didn't any other assembler do this?  They all seem to try to compute the offset based on the org address which made it clunky)
- Intelligently keep track of DB and DP to choose appropriate addressing modes for instructions (xkas *almost* did this)
- Able to specify mirrored regions for further optimization.  Ex:  you can declare a variable in bank $7E, and tell the assembler than part of bank $00 mirrors bank $7E (which it does on SNES), allowing you to access those vars through DP or absolute mode even when DB is not $7E  (no other assembler does this!  Makes it unreasonable to use symbol names in your code!)
- Text output with support for table files.  DTE/MTE supported
- automatic construction of pointer tables
- sane namespace and symbol scope system  (severely lacking in other assemblers)
- local symbol definitions
- macros
- nameless labels
- complex expressions:   "lda (foo+5)*3,X"
- conditional assembly
- bounds checking
- ... and more!


So yeah if anyone else wants to check it out and let me know what they think and let me know if they hit any bugs with it, that'd be awesome.  I certainly welcome any and all feedback.
« Last Edit: November 14, 2015, 03:03:57 am by Disch »

dougeff

  • Sr. Member
  • ****
  • Posts: 358
    • View Profile
Re: 65xx Assembler Alpha release: Schasm
« Reply #1 on: July 16, 2015, 09:45:28 am »
Nice work as always Disch.

I don't know enough about SNES programming to do a full test of it, but I'll definitely check it out.
nesdoug.com -- blog/tutorial on programming for the NES

Disch

  • Hero Member
  • *****
  • Posts: 2814
  • NES Junkie
    • View Profile
Re: 65xx Assembler Alpha release: Schasm
« Reply #2 on: July 16, 2015, 10:10:26 am »
FWIW I found a handful of completely disasterous and obvious bugs shortly after uploading that.  Here's an updated one:

https://www.dropbox.com/s/wsivt454ucd884q/schasm_alpha002_2015_07_16.zip?dl=0

DaMarsMan

  • Hero Member
  • *****
  • Posts: 1288
  • Bring DQV
    • View Profile
    • DQ Translations!
Re: 65xx Assembler Alpha release: Schasm
« Reply #3 on: July 16, 2015, 12:20:40 pm »
Bass also did not have the features you needed? It sounds like you got a pretty badass feature-set started though!  :thumbsup:

Disch

  • Hero Member
  • *****
  • Posts: 2814
  • NES Junkie
    • View Profile
Re: 65xx Assembler Alpha release: Schasm
« Reply #4 on: July 16, 2015, 12:48:30 pm »
Bass also did not have the features you needed?

I looked at a number of different assemblers.  Off the top of my head:  Bass, xkas (.06 and ?.12?), x816, wla-dx, and ca65.  And apart from x816 which wouldn't run on my box because it was too old -- Bass was at the bottom of my list.

Either the documentation is incomplete to the point of being unusable... or it's just a mini version of xkas that has more awkward syntax and less features.  I get the feeling it was byuu's attempt to reboot xkas -- which would have been great -- except he just never finished it.   I don't mean to sound like I'm knocking byuu or anything.  I mean I have nothing but respect for the guy -- but Bass is pretty much unusably incomplete.  At least it was for the demands that my project has.

Nightcrawler

  • Hero Member
  • *****
  • Posts: 5787
    • View Profile
    • Nightcrawler's Translation Corporation
Re: 65xx Assembler Alpha release: Schasm
« Reply #5 on: July 16, 2015, 05:58:36 pm »
I suggest you also take a look at Asar. It's a fixed and extended version of the old xkas lineage. It's not well known in these circles, so I thought I'd throw it out there.

http://www.romhacking.net/utilities/964/
TransCorp - Over 20 years of community dedication.
Dual Orb 2, Wozz, Emerald Dragon, Tenshi No Uta, Glory of Heracles IV SFC/SNES Translations

Lilinda

  • Hero Member
  • *****
  • Posts: 4538
    • View Profile
Re: 65xx Assembler Alpha release: Schasm
« Reply #6 on: July 16, 2015, 07:39:31 pm »
Silly question: What made you choose that name?
Retired moderator/staff member as of July 14th 2016

Disch

  • Hero Member
  • *****
  • Posts: 2814
  • NES Junkie
    • View Profile
Re: 65xx Assembler Alpha release: Schasm
« Reply #7 on: July 16, 2015, 09:51:13 pm »
I suggest you also take a look at Asar. It's a fixed and extended version of the old xkas lineage. It's not well known in these circles, so I thought I'd throw it out there.

Asar is interesting, but it still doesn't have the mirroring acknowledgement or the awareness to shrink to directpage when appropriate which are two things I REALLY wanted.  It does have some other interesting ideas that I might steal, though  ;D

Silly question: What made you choose that name?

Someone on IRC suggested it.  I like names that are google-able and I sort of have a "sch" motif going.

Nightcrawler

  • Hero Member
  • *****
  • Posts: 5787
    • View Profile
    • Nightcrawler's Translation Corporation
Re: 65xx Assembler Alpha release: Schasm
« Reply #8 on: July 18, 2015, 09:35:45 am »
Asar is interesting, but it still doesn't have the mirroring acknowledgement or the awareness to shrink to directpage when appropriate which are two things I REALLY wanted.  It does have some other interesting ideas that I might steal, though  ;D

How do you intend to do any better than the aforementioned assemblers on direct page awareness? You will always have the inherent problems that you don't know the starting values (unless explicitly given by the user), it can be changed in code outside the assembler between functions, and you can't handle it being changed by stack pulls, or if the value is a result of a calculation, table grab, etc.

For mirroring, have you accounted for the fact that WRAM is not mirrored in all banks?
TransCorp - Over 20 years of community dedication.
Dual Orb 2, Wozz, Emerald Dragon, Tenshi No Uta, Glory of Heracles IV SFC/SNES Translations

Disch

  • Hero Member
  • *****
  • Posts: 2814
  • NES Junkie
    • View Profile
Re: 65xx Assembler Alpha release: Schasm
« Reply #9 on: July 18, 2015, 09:46:00 am »
How do you intend to do any better than the aforementioned assemblers on direct page awareness? You will always have the inherent problems that you don't know the starting values (unless explicitly given by the user),

It's explicitly given by the user.

I don't need much for DP awareness.  Just a way to specifiy what direct page is and have the assembler take advantage of it.  Many assemblers don't even do that much -- if you want to use DP you have to actually specify the size of each individual instruction.  Like in xkas, you have to use the '.b' mnemonic suffix (lda.b) or it will always use absolute mode.  I didn't see anything in Asar's notes which changed that -- though maybe I missed it.

Quote
you can't handle it being changed by stack pulls, or if the value is a result of a calculation, table grab, etc.

This is not a typical usage of DP.  Usually when you set it, you set it explicitly.  A calculated DP value would be very rare.

Unless the address you're reading from would be relative, and DP acts as a sort of pointer.  In which case I guess you could tell the assembler that DP is $0000 so you can use relative addresses instead of shrinking absolute addresses.  But I guess that would screw up if you tried to access anything on page $00xx.  But again this is extremely atypical.

Quote
For mirroring, have you accounted for the fact that WRAM is not mirrored in all banks?

Yes.  You specify a range of banks for data to be mirrored across.

Nightcrawler

  • Hero Member
  • *****
  • Posts: 5787
    • View Profile
    • Nightcrawler's Translation Corporation
Re: 65xx Assembler Alpha release: Schasm
« Reply #10 on: July 19, 2015, 01:00:22 pm »
It's explicitly given by the user.

I don't need much for DP awareness.  Just a way to specifiy what direct page is and have the assembler take advantage of it.  Many assemblers don't even do that much -- if you want to use DP you have to actually specify the size of each individual instruction.  Like in xkas, you have to use the '.b' mnemonic suffix (lda.b) or it will always use absolute mode.  I didn't see anything in Asar's notes which changed that -- though maybe I missed it.

Oh, right. I forgot xkas didn't actually support direct page in the assume command. Then, I think asar removed it entirely in favor of auto 24-bit to 16-bit optimizations, but apparently leaving direct page optimization out in the cold. So, supporting it at all would indeed be an improvement! ;D

Quote
Yes.  You specify a range of banks for data to be mirrored across.

I was going to respond by mentioning that the WRAM mirroring is a fixed scheme on the SNES, but I see in your documentation that you you already map it by default and allow additional mirroring via that directive. Nice! :)

It looks like you're off to a great start so far. I will read through what you have a little more closely when I have some more time and see if I have any other useful comments to muster. I know it's early in the game, but it would be great to support SPC700, and a few other SNES co-processers in the future. asar does SPC700 and includes SuperFX for example.
TransCorp - Over 20 years of community dedication.
Dual Orb 2, Wozz, Emerald Dragon, Tenshi No Uta, Glory of Heracles IV SFC/SNES Translations

Nightcrawler

  • Hero Member
  • *****
  • Posts: 5787
    • View Profile
    • Nightcrawler's Translation Corporation
Re: 65xx Assembler Alpha release: Schasm
« Reply #11 on: July 20, 2015, 08:09:11 pm »
I have reviewed the documentation in detail and... I like it! It seems like a very capable assembler with some reasonable and consistent syntax. You get bonus points for good documentation too! It seems you have most things covered.

Questions:
1. Does #IncBin and #IncSrc handle relative paths?
2. When declaring variables like 'SomeVar = $001800', are you required to always use long addresses?
3. Is there a way to output the pc or embed it into debug message like #Warn/#Error? I have to do this often to get the breakpoint I need to use to debug various specific areas and lines of code. I didn't see a way to do this.
4. Can expressions be used in variable declarations? Something like 'Foo = (5+2) - 1 * 7 ;my secret constant for sprite animation.'? What about a variable within a variable declaration? I'm getting at equivalent functionality for defines in xkas/bass. You can do some interesting things with them being able to define almost anything. Not all of that power is needed, but it is a frame of reference when evaluating abilities of schasm.

Suggestions:
I know you probably choose #Byte,#Word,#Long,#Dword for consistency with all directives and ease of parsing, but what do think about also supporting traditional db (define byte), dw (define word), etc. type syntax many assemblers do?

Comments:
1. #Var is a nice addition. It is annoying to add variables in the middle of your list, change your mind about a variable length throwing addresses of everything else off, and what not.

2. Interesting approach to #Org with the independence between platform address and file offset. That's great for more difficult mappings as long as it is not a burden for simple mappings. I see it is optional, but I'm not sure I understand how optional with the explanation given. If you have a no header, traditional hirom mapped ROM, and all your code is in the linearly mapped region for example, you wouldn't really have much need to declare file offsets more than once at the beginning. All other instances of #Org in the project probably wouldn't need it (nor would I want to have to declare it all the time). Is that allowed here? When can you omit the file offset on #Org exactly?

3. It's dangerous to make assumptions that some things will never be used. Either I saw, or I read about (damn old age, I can't remember!) a game that used brk to call a decompression subroutine, for example! Few would expect that usage, but yet it was done. Perhaps that was not the smartest thing to do, but I'm sure there are other cases where something was used unconventionally and it was actually very clever. I guess my point never assume something would never be used and use as an excuse not to put it in! You'll need another excuse! :laugh:

Small mistakes observed:
1. In both readme.txt and directives.txt your passage says 'changes how the compiler assembles its code.' Technically it's an assembler rather than a compiler.
2. typo in readme.txt -  'jmp Label       ; legal, Label is vidible here'
TransCorp - Over 20 years of community dedication.
Dual Orb 2, Wozz, Emerald Dragon, Tenshi No Uta, Glory of Heracles IV SFC/SNES Translations

Disch

  • Hero Member
  • *****
  • Posts: 2814
  • NES Junkie
    • View Profile
Re: 65xx Assembler Alpha release: Schasm
« Reply #12 on: July 20, 2015, 08:43:44 pm »
Thanks for the feedback Nightcrawler!  ^^

1. Does #IncBin and #IncSrc handle relative paths?

Yes.  The target file is relative to file that included it.  "dot" directories like ".." to move up a dir are also accepted.

Quote
2. When declaring variables like 'SomeVar = $001800', are you required to always use long addresses?

No.  0, $0, $00, $000000 are all exactly the same in the eyes of the assembler.  The symbol itself ultimately just represents a number (or string).

Quote
3. Is there a way to output the pc or embed it into debug message like #Warn/#Error? I have to do this often to get the breakpoint I need to use to debug various specific areas and lines of code. I didn't see a way to do this.

There isn't.  Right now it just allows you to specify a fixed string.  That'd be something to add for sure.

Quote
4. Can expressions be used in variable declarations? Something like...

Yes you can do all of that.  I think I put a restriction on 20 or so levels of nesting for variable names (to stop infinite recursion)... which seemed like plenty.  I kind of picked that number at random -- it's easy to increase if need be.

Quote
Suggestions:
I know you probably choose #Byte,#Word,#Long,#Dword for consistency with all directives and ease of parsing, but what do think about also supporting traditional db (define byte), dw (define word), etc. type syntax many assemblers do?

I specifically avoided using db since that conflicts with a common abbreviation for "data bank" on the 65816.  I even wanted to use #db for the #databank directive  -- but quickly realized "wait, I can't do that because that's for byte output in other assemblers".

I figured it's best to simply not use #db at all to avoid the confusion.

Quote
Comments:
1. #Var is a nice addition.
Thanks.  Yeah this is something I've found disturbingly lacking in other assemblers.  IIRC ca65 and wla-dx were the only ones I saw that did something like it.

Quote
2. Interesting approach to #Org with the independence between platform address and file offset. That's great for more difficult mappings as long as it is not a burden for simple mappings.

Yeah this was kind of weird to plan out.  I wanted you to explicitly specify what offset you want to be at -- the lack of which is something that really bugged me with other assemblers.  Originally I was going to have a separate #offset directive... but I couldn't think of a situation where you would have wanted to use that and but not to use #org, so I kind of just combined them.

The offset parameter of org is pretty much only optional for doing this like #var definitions which need a PC but don't actually produce any output.  For anything that does produce output, you have to give it an offset.

I thought this might be a little clunky -- but figured you could always macro it away:

Code: [Select]
fileHeaderSize = 0  ; or $200

; hirom org
#macro org, pc
    #org pc, (pc & 0x3FFFFF) + fileHeaderSize
#endmacro

!org $C00000
    ; blah

Quote
3. It's dangerous to make assumptions that some things will never be used.

Are you referring to BRK/COP?  I think that's the only thing where I mentioned nobody ever uses them in documentation.  :P
But yeah I have seriously never seen BRK/COP used in actual production code.  They seem kind of worthless.

Regardless, the assembler supports them, so it's not like my assumption is changing anything.


Quote
Small mistakes observed:

Woop!  Thanks.  I'll fix those.

oziphantom

  • Jr. Member
  • **
  • Posts: 32
    • View Profile
Re: 65xx Assembler Alpha release: Schasm
« Reply #13 on: July 21, 2015, 12:32:44 pm »
Oh thank Odin! I was thinking I was the only one/there was some secret source I was missing.

warning I'm from C64 land and thus use to all the mod cons

Does it handle Binary input. %11011010 for example or better yet allow for _ to split them so you can do %11_011_010 ?
Fixed point numbers? #p4 = 4:4 #p8 = 8.8 or since we are in 16bts you can also have a #p12 for 4:12, does the normal system handle fixed point so to make a 12:4 number can you do (3.14 << 4) & $FFFF ?

I know that you have namespaces but could it also have Structs, which is like a namespace but you can instigate one. Like so
Code: [Select]
sGameData .struct
    lives .byte ?
    flowers .byte ?
    score .byte ?,?,?,?,?,?
    high .byte ?,?,?,?,?,?
    currLevel .byte ?
    exitOpen .byte ?
.ends

Where ? tells the compiler anything, don't force the memory to be a value if you don't need to. Then later we can instigate one of them like so
Code: [Select]
*=7e2000
GameData .dstruct sGameData
or
GameData .dstruct sGameData = 0x7e2000

then we can do sta sGameData.currLevel etc Since the strut is defined as ? it knows not to try and put data in the output at 7e2000 ;)

I can see the current system lets you do :: in place of . but I doesn't look like you can instance a namespace, or am I wrong?

Equ, constants etc like
Code: [Select]
kVectors .block
charBase = $4000
spr0ID = charBase+1016
spr1ID = charBase+1017
spr2ID = charBase+1018
spr3ID = charBase+1019
spr4ID = charBase+1020
spr5ID = charBase+1021
spr6ID = charBase+1022
spr7ID = charBase+1023
.bend

Repeats and For Loops
Code: [Select]
.for ue = kVectors.charBase, ue < kVectors.charBase + $400, ue = ue + 40
.byte >ue
.next
this outputs $00,$28,$50,$78,$A0,$C8,$F0,$18,$40,$68,$90,$B8,$E0,$08,$30,$58,$80,$A8,$D0,$F8,$20,$48,$70,$98 when KVectors.charBase is as above. But can also be used for loop unrolling, lots rolling thorough a bunch of macors etc

Are there any IDEs for SNES that you use/the asm format supports? Something with auto complete, file/function browsing, emulator launch scripts etc?

Re BRK/COP
COP is pretty useless on the SNES, even though it does actually have coprocessors it doesn't seem to use COP..
BRK on the other hand is handy when writing code, especially when you only have 4 break points. and no conditional breakpoints... You can use it as a general something went wrong and it got to this code point where it shouldn't, or put it in various part of your code and then track how it all goes wrong. Make you own Crash/blue screen handler for your beta testers etc.

Disch

  • Hero Member
  • *****
  • Posts: 2814
  • NES Junkie
    • View Profile
Re: 65xx Assembler Alpha release: Schasm
« Reply #14 on: July 21, 2015, 01:09:44 pm »
Binary input:  Yes

Split binary input:  No.  I have never seen or considered anything like that before.  It's definitely interesting and wouldn't be that hard to implement.

Fixed point:  No.  This is an interesting idea but would add a lot of complication to the assembler for something that isn't all that important.  Fixed point can usually be faked easily enough:  ((314 << 4)/100) & $FFFF.

The real problem with adding fixed point into the assembler is that it complicates expression rules.  Assuming 3.14 is stored as fixed point 4:4... it would be $32.  But would that +5 result in $82 (8.14) or $37 ?  And what if you are trying to do computations on fixed point values of different sizes?  This turns into a huge nightmare very quickly -- and IMO it isn't worth it.


Structs:  I thought about structs and sort of dismissed them as "ehh, maybe I'll do that later."  Currently they are not supported.


Quote
I can see the current system lets you do :: in place of . but I doesn't look like you can instance a namespace, or am I wrong?

You are correct on both points.  Instancing a namespace doesn't make sense so you can't do it -- and I decided to use :: for namespace qualifiers because . is used for local qualifiers.  If they both used . it creates ambiguity (which is the whole thing namespaces are supposed to solve)

Example:   foo.bar  could be 'foo' is a top label and 'bar' is a local variable.  Or it could be that 'foo' is a namespace and 'bar' is a top label.  It's impossible for the assembler to know without doing a name lookup -- which might result in a conflict if both exist.

So instead:
foo::bar  <- foo is a namespace, bar is a top var
foo.bar <- foo is a top label, bar is a local var

No ambiguity.




Equ, constants:   Yes, these are supported.

Repeats and For Loops:  No.  When would this be useful?  I can't see a practical purpose for it.


Are there any IDEs for SNES:  I'm not aware of any.

oziphantom

  • Jr. Member
  • **
  • Posts: 32
    • View Profile
Re: 65xx Assembler Alpha release: Schasm
« Reply #15 on: July 22, 2015, 04:24:19 am »
Fixed Point : nah, you treat it all as floating point internally in the assembler and then drop to fixed at the end. Thus 3.14 + 5 = 8.14, ints are just fixed point 8:0 or 16:0 or 24:0 ;) The assembler is only ever working on constant expressions, not doing the actual maths the 65816 will be doing.

Rept, For..Next : useful for making tables, ye old Sin table is the classic example
Code: [Select]
.for range = 0, range < 256, range = range + 1
.byte 128.5 + 127 * sin(range * rad(360.0/256))
.next

or other index based tables that are long enough.

SNES Init
Code: [Select]
.for range = 0, range < $27, range = range + 1
stz 2100+range
.next
..handle unique cases here

Killing some clocks
Code: [Select]
nop .rept 3 ; wait for mul result

Say you have 1K VRAM buffers set up at 7F0000, and you have 16 of them, you want to make code to do a DMA from each bank to a slot in VRAM
Code: [Select]
numBanks = 16 ; must be POW2
bankShift = 4
bankSize = $400
RAMCache = $7F0000
; a = slot , x = channel
dmaSlotOnChannel
asl a .rept bankShift  ; shift bits up ready for channel mask
phx
ora 1,s
plx
asl a ; convert to words
tax
jmp (_DMALUT),x
_DMALUT
.for pointer = DMAstart, pointer < DMAend, pointer = pointer + DMASize
.word pointer
.next
DMAstart = *
.for src = RAMCache , src < RAMCache  + ( numBanks * bankSize), src += bankSize
.for dmaC = 4, dmaC < 8, dmaC = dmaC + 1
init DMA channel dmaC
set DMA src dmaC= src
set VRAM dest dmaC = src - $7F0000
fire DMAC
lda #$80
sta $2115
php
rep #$20
lda #<>src
sta $2116
sta $4302+(dmaC*$10)
lda #bankSize
sta $4305+(dmaC*$10)
sep #$20
lda #`src
sta $4304+(dmaC*$10)
lda $420B
ora #1 << (src - RAMCache ) / bankSize
sta $420B
plp
rtl
.next
DMAend = *
DMASize = (* - start) / numBanks


What do you edit your code in, does something like sublime text give you auto complete?
If the syntax is close enough to one of these 64tass, ACME, ca65, DASM, DreamAss, Kick Assembler and TMPx. , then http://www.popelganda.de/relaunch64.html could be used

Disch

  • Hero Member
  • *****
  • Posts: 2814
  • NES Junkie
    • View Profile
Re: 65xx Assembler Alpha release: Schasm
« Reply #16 on: July 22, 2015, 12:22:12 pm »
Fixed Point : nah, you treat it all as floating point internally in the assembler and then drop to fixed at the end. Thus 3.14 + 5 = 8.14, ints are just fixed point 8:0 or 16:0 or 24:0 ;) The assembler is only ever working on constant expressions, not doing the actual maths the 65816 will be doing.

Floating point doesn't work with bitshifting or other binary ops.  How do you resolve something like "(foo & $00FF) | ((bar<<8) & $FF00)" if foo/bar are floating point?  I assume you must convert them to integers, but with what fixed-point base?  Does the decimal portion simply get dropped?  Is the resulting value an integer?

Binary ops make up the vast majority of expressions in my experience, and having to do compile-time math with fixed point values is very rare.  And while I could certainly make the above expression value work, it would complicate the rules for expressions.

If given the choice, I would prefer intuitive over feature-filled.  If the answers to the above expression questions aren't obvious to me, they wouldn't be obvious for users.  That's a big turn-off.

I'm not completely dismissing this yet.  I can see the value in it.  It's just... I'm not entirely sold.  I'd have to sit down and really think about how I want this to work.

Quote
Rept, For..Next :

Yeah I can see the usefulness here for generating tables --- but for code portions would it just be unrolled loops?  Blech.

Nonetheless you've sold me on this one.  I should be able to add this.   ;D


Quote
What do you edit your code in, does something like sublime text give you auto complete?

I use Notepad++ which allows you to set up syntax highlighting -- but it doesn't have auto complete.

Nightcrawler

  • Hero Member
  • *****
  • Posts: 5787
    • View Profile
    • Nightcrawler's Translation Corporation
Re: 65xx Assembler Alpha release: Schasm
« Reply #17 on: July 22, 2015, 06:41:09 pm »
I use Notepad++ which allows you to set up syntax highlighting -- but it doesn't have auto complete.

Yes it does. Settings -> Preferences -> Auto-Completion


Also related to Notepad++ and SNES IDEs, I have used this setup a few times before. It's not your ideal SNES IDE, but pretty cool nonetheless.
http://www.romhacking.net/utilities/749/
TransCorp - Over 20 years of community dedication.
Dual Orb 2, Wozz, Emerald Dragon, Tenshi No Uta, Glory of Heracles IV SFC/SNES Translations

oziphantom

  • Jr. Member
  • **
  • Posts: 32
    • View Profile
Re: 65xx Assembler Alpha release: Schasm
« Reply #18 on: July 23, 2015, 03:05:26 am »
Ahh yes, bit shifts. That is going to force the need to determine if the whole expression is int or float and change accordingly.
There is no real reason to reinvent the wheel on it though, see the documentation here http://tass64.sourceforge.net/ which shows all the ops that can be done per type. The source code is available here
http://sourceforge.net/projects/tass64/?source=navbar - well once source forge get themselves working again...


Not unrolled loops, the DMA example is not a loop unroll, in that it makes each DMA XXXX to VRAM XXXX function, and then it is used to make the pointer table to said functions. The idea is that it doesn't call each one in order like a loop. Vs making a Macro then copy pasting the macro NxM times and them making a table by hand from the macro instances etc. Also very handy for helping with making multiplexors but that is not something you need to do on a SNES. Also Vector handlers. Make a list of pointers then get the for,next to make you N
Code: [Select]
pha
phx
phy
jsr <pointer from table>
ply
plx
pla
rti
But then seeing as the interrupt vectors are in ROM ( that must be a total pain ) maybe not the most useful case. I guess you make the ROM routine do a JMP [RAM_ADDR] :D

Disch

  • Hero Member
  • *****
  • Posts: 2814
  • NES Junkie
    • View Profile
Re: 65xx Assembler Alpha release: Schasm
« Reply #19 on: July 23, 2015, 05:05:11 pm »
Ahh yes, bit shifts. That is going to force the need to determine if the whole expression is int or float and change accordingly.

I've figured out how I'm going to do this.  The question now is how to do the syntax.

I'm thinking of "m:q" where m is the desired fixed point bitwidth and q is the value.

So "4 : 3.14" would be $32.  Where m and q could both be expressions.

Quote
Not unrolled loops, the DMA example is not a loop unroll,

Well.. the body of the for loop is unrolled.  That's what I meant.  It's basically "repeat the below code X times".