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

Is it meant to be a safer and more compatible version of asm? Or is it just something random you liked to try out? Anyway, it sounds cool.

Sounds interesting, another random idea of xeda, lol, but awesome

This is a pretty neat idea. I've put some thought into doing something similar myself, but on a computer. What made you decide to leave out registers?

I have begun the process of converting this to assembly now, so once it is complete, I will be able to have a copy of it on my computer (and so I can upload it here). I currently have all of the jumps and calls emulated and now I just have the math operations to finish and the others random things. For an example of the code that I wrote (in hex on my calc) that was emulated:
3020        ;jrf 32             ;jumps over the next 32 bytes
<32 bytes of masked sprite data>
1F2802      ;ldir keymask,2     ;copies two bytes to the RAM location at keyMask (these are ports keymask and sMask)
0303        ;.db 3,3
1F0008      ;ldir sLSB0,8       ;copies 8 bytes to the first two sets of sprite data ports
  02000303  ;.dw 2 \ .db 3,3    ;location of the sprite, coordinates
  12005535  ;.dw 18 \ .db 85,53 ;location of the second sprite, coordinates
3302        ;jrb $              ;jumps back two bytes to the start of this instruction. Causes an infinite loop.


ooh, this sounds really fun =)
and yeah, it could be a very helpful way to introduce people to asm as well.

What made you decide to leave out registers?

the only reason to have registers in a processor is to make things faster, so you don't have to be accessing ram constantly.

It's pretty nice indeed ! I'm not sure I'm capable of such things, though... Well, I'll maybe learn someday.

Xeda, i would love to play around with this if you ever get around to releasing something! I like the idea of trying to make games fit in small places and working with memory directly sounds interesting. Is the code then stored in your hex format and parsed?