I think you should just drop your source into the PTI window and have at it.dysfunction wrote:Do you mean the ability to just hit "Build" then "Run" and it sends your file straight to PTI (with Ion or Mirage if they are dependencies) and executes it? Because that would be awesome. Perhaps such a thing could be integrated into Latenite?CoBB wrote:Has anyone thought of integrating an assembler into PTI? I've been playing with the thought myself. Just imagine, the whole building cycle would consist of nothing but sending your main source file to the emulator. No stupid dependencies and directory structures or whatever, just a single independent standalone taking care of everything. Mmmm...
[Featured][Dev] Zelda (Best Project 2005)
Moderator: MaxCoderz Staff
-
- Calc King
- Posts: 2195
- Joined: Sun 27 Mar, 2005 4:06 am
- Location: sleeping
- Contact:
- dysfunction
- Calc Master
- Posts: 1454
- Joined: Wed 22 Dec, 2004 3:07 am
- Location: Through the Aura
- benryves
- Maxcoderz Staff
- Posts: 3089
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: Croydon, England
- Contact:
It already does that. I haven't released it yet, though, as I was hoping to get breakpoints operating correctly (which I haven't managed). Maybe I'll package up a basic, incomplete non-debugging version in the meanwhile to show that I am actually working on it.dysfunction wrote:Do you mean the ability to just hit "Build" then "Run" and it sends your file straight to PTI (with Ion or Mirage if they are dependencies) and executes it? Because that would be awesome. Perhaps such a thing could be integrated into Latenite?
I've gotten to an assembler version that is pretty much complete. Decent errors, clearer list files than TASM, in my opinion, and pretty nice mnemonic sorting. Opcode searching is always a bit tedious -- take LD A,* for example. Here's an excerpt from the stat file generated from page one of Zelda:Even though the LDs with numeric args are much more common, all of the other symbolic LDs must be searched first, since they fulfill the requirements for the * wildcard, yet are distinct commands. This is the reason behind the longstanding bug in TASM where this occurs:TASM takes a little shortcut where it ignores internal parenthesis when searching. The search order, defined by the table file was a,(*) then a,*, so line one's result was a,(*). Had a,* been first, all a,(*) commands would be lumped into it -- complete chaos and loss of the use of a,(*). Though table order is still important for my assembler, the +0 at the end is no longer necessary since internal parenthesis are noted.Cool, huh?
Code: Select all
LD A,B 28
LD A,C 21
LD A,D 5
LD A,E 5
LD A,H 3
LD A,L 5
LD A,(*) 143
LD A,* 179
Code: Select all
0001 0000 3A 14 00 ld a,(10*2)+(1*2)
0002 0003 3E 16 ld a,(10*2)+(1*2)+0
Code: Select all
00001 0000: 3E 16 - - ld a,(10*2)+(1*2)
00002 0002: 3E 16 - - ld a,(10*2)+(1*2)+0
Now that Zelda assembles instantly, development's a lot easier. How long it'll take to finish depends on how long of game it needs to be! Right now there is certainly enough to release, more than any other Zelda attempt (granted, mine's the first APP version). But I'd like to make it a bit longer than forty minutes.
I'll release the assembler to whomever is tired of waiting for slow assemblies. (It should be entirely compatible with TASM, except for my interpretation of .org being very different -- imo you write null bytes to the IP with .fill or .block, not with .org). Recently I added support into the #include preprocess for binary and bitmap files. It'll figure out file type. This is beneficial since reading straight from a bitmap or binary is faster than parsing text data. However, I don't have any plans for supporting grayscale or compression, since that depends on the programmer's implementation.
I'll release the assembler to whomever is tired of waiting for slow assemblies. (It should be entirely compatible with TASM, except for my interpretation of .org being very different -- imo you write null bytes to the IP with .fill or .block, not with .org). Recently I added support into the #include preprocess for binary and bitmap files. It'll figure out file type. This is beneficial since reading straight from a bitmap or binary is faster than parsing text data. However, I don't have any plans for supporting grayscale or compression, since that depends on the programmer's implementation.
You could release a public beta, or a demo. We're all waiting eagerly to try it out.Spencer wrote:Now that Zelda assembles instantly, development's a lot easier. How long it'll take to finish depends on how long of game it needs to be! Right now there is certainly enough to release, more than any other Zelda attempt (granted, mine's the first APP version). But I'd like to make it a bit longer than forty minutes.
In Memory of the Maxcoderz Trophy