After reading some Atari documentation and also seeing some of the documentation for the 84+C, the way I saw what was considered "acceptable" assembly completely changed. For the past few years, I have procrastinated on this project of mine, but last night I started from scratch and it is almost finished.

I have basically created an emulator for a processor that doesn't exist. I created the instruction set to emulate and the ports. I originally modeled instructions and interactions based on how the z80 does it and so the process of completing the instruction set was tedious. I completely changed my approach and here are the stats:

The instruction set is 6-bits, so there is room for 64 instructions but not all are finished. You have 256 bytes of RAM, the first 42 bytes (it will probably be more before this is finished) is for interacting with ports and the last 128 bytes is for a stack. There are 512 bytes of code space and there are no registers. This was the main spark of insight I had last night. Instead, you work directly with the RAM. Here are the instructions currently emulated:

Note that all values are 1-byte.

ld (addr1),(addr2) loads a byte from one RAM address to another.
ld (addr),const loads a byte into the RAM address
add (addr1),(addr2) adds two bytes of RAM together, storing the result to the first byte. Modifies C and Z flags
add (addr),const adds the constant value to the byte. Modifies C and Z flags

You get the idea, I am sure, so here are others that follow the same structure:
adc
sub
sbc
xor
or
and
cp    (compare two values)

And these are some more:
inc (addr)
dec (addr)
push (addr)
push const
pop (addr)
ex (addr1),(addr2)   ;exchange two bytes
ret
ret z
ret c
ldir (addr),size,data   ;copies inline data of the given number of bytes to a ram location specified by (addr)
ldir const,size,data   ;copies inline data of the given number of bytes to a ram location specified by (addr)

It is important to note that the ldir commands are very useful for setting up the ports.

there are also the jrf, jrb, callf, and callb commands. Each of these can work on a condition of c or z (not nc or nz).

jrf jumps forward a given number of bytes.
jrb jumps backwards a given number of bytes.
callf calls a relative routine that is within 256 bytes ahead
callb calls a relative routine that is within 256 bytes behind

Anytime a relative jump or call is made, it will never execute code from RAM. If you go past the 0~511 byte code range, it will loop back around.

There are 8 sets of 4 ports for sprites. The ports are ordered:
LSB of sprite data
MSB of sprite data
X coordinate
Y coordinate

In all, these makeup the first 32 bytes of RAM
Port 20h is the Sprite Update Port. When a sprite is drawn, its corresponding but gets set here. You can reset all of the bits here, then read from it to figure out when all of the sprites have been drawn.
Port 29h is the Sprite Mask Port. Set the corresponding but here to have the sprite drawn. Compare this port to port 20h to see if all the sprites are drawn.
Ports 21h~27h hold values for keypresses
Port 28h is the Key Mask Port which determines which groups of keys get polled

2Ah holds the stack pointer.


Anyways, I would offer an upload or something, but I cannot get it off of my calc, once again. Also, it is currently written in Grammer code, but I plan to convert it to an assembly program. My first attempt is going to make a Pong game and all I currently have done codewise setting up the ports All of the mentioned instructions work by the way, all I need to do is emulate the ports

You can change the size of the of the squares, so it was just easier than scaling a sprite to fit the size of the path. I did have a version that used a built in sprite when the path size was 5 pixels wide, but I got rid of it

Hehe, I am getting anxious! I have a vacation from the 9th to the 17th, so hopefully I can get much done for TI-BASIC (68K and z80).

yes, I am sure it will and that is what the extended commands are (multi-byte tokens, basically). So for example:
F800     ;Command 0 of one of the extended token sets
I was also trying to figure out a good way of allowing the extended sets to have extended tokens just in case, but I don't think I will need to do that (will we really need 3-byte tokens? )

Oh, yes, that might be useful (the header thing). As well, floating point numbers are a different type from integers. Integers also have signed/unsigned, and 8,16,32, and arbitrary sizes.

This is actually a type of algorithm that would be much better in Axe or Assembly, so I was thining of porting it later today. Luckily all three languages are similar enough that porting won't b too difficult.

I started working on a maze generating thingy after seeing KermM's BASIC algorithm (using the DCS7 AnsStack command). I have coded this in Grammer and I am still working on optimising it more. If you want to edit the size of the path (2 pixels wide, 3 pixels wide, et cetera), open the source and change the value for →S. 2 makes a 1-pixel wide path, 6 makes a 5 pixel wide path, for example. On my actual calc, I have an actual game started, but I haven't been able to transfer my programs.

Here is the code:
:.0:Return
:Full
:3→S
:Fix 16
:96/S
:*64/S→A
:Send(+A,"VYπ→θ+A→Z
:π86EC→W
:π9340→V
:Lbl "BTR→T
:Lbl "pxl-Test(NEIGHBORS→U
:Fill(0→N→X→Y
:ClrDrawZ
:Disp W
:ClrDraw
:64/S→A
:96/S→B
:Horizontal A
:Vertical B
:Line(S*B-1,S*A-1,S,,0,V
:Pxl-On(A-1,B-1
:!Repeat N
:int(Z+N,X
:int(θ+N,Y
:Pxl-On(Y,X
:Line(1+S*X,1+S*Y,S-1,,0,V
:If 15=prgmU
:prgmT
:!Repeat and A
:e^(randInt(0,4
:End
:→A=2
:+X-A=1→X*S
:+1+A=1
:-A=2→B
:Y+A=4
:-A=8→Y*S
:+1+A=8
:-A=4→A
:Line(B,A,S-1,,0,V
:IS>(N
:Disp V:DispGraph:Disp W
:End
:Stop
:.BTR
:Repeat 15≠prgmU
:N-1→N
:If θ'
:Stop
:(+Z→X
:(θ+N→Y
:End
:End
:.pxl-Test(NEIGHBORS
:pxl-Test(Y-1,X
:+Ans+pxl-Test(Y+1,X
:+Ans+pxl-Test(Y,X+1
:+Ans+pxl-Test(Y,X-1→A
:End

That creates a maze that is guaranteed to have a path from the upper left corner to the lower right of the screen.