Assembly on the 99/4A

[Opry99er]

Ha!!!!! Let me try!

[Opry99er]

Well, I HAD intended on posting this to my Beryl thread initially--- I accidentally posted it here, but it's not a bad thing. I'll repost it over there so we can continue discussion on it. =)

 

In the mean time, I am hoping Matthew will explain this KSCAN method in another post so I can figure out what I'm doing wrong. =) Even with the MOV instead of MOVB, it's whacked out...

[+adamantyr]

Your statement LI R12,MAPDAT can never be reached; when the pattern loop code finishes it jumps to the DRWMAP label, which is beyond it. Just move the label to that statement and that should help.

 

Adamantyr

[Opry99er]

Thanks Adam. Got it workin' now. =) I had to do something a LITTLE different than you suggested, but ultimately the same thing. Check the Beryl thread for explanation. Here's the little video of the scroll!!! =)

 

http://www.youtube.com/watch?v=7ivRjZnQIfU

[matthew180]

Nice job Owen! I knew if I left you along long enough you would work it out. Actually I was setting up the pool for the kids today, so I have not had any 99/4A time until now.

 

I'll get to the keyboard input stuff soon, but I won't be using KSCAN since (get ready) I don't like it... No surprise there. The clincher was the post that retroclouds (or was it sometimes? I can't remember now) made a bit ago that pointed out the ROM KSCAN routine uses a delay. So I fired up the TI Intern and did some code reading of the KSCAN routine and found the delay is used twice and each time causes a 25ms delay. That means it takes about 3 video frames just to call KSCAN, and that is counting just the delay loops. That is 50ms where the computer is just spinning its wheels, and when instructions are measured in microseconds, 50 milliseconds is a long time!

 

Matthew

[Opry99er]

Thanks man!! I look forward to it!!! In the meantime, I'm having a bit of an issue right now--- perhaps you could take a look over at the Beryl thread. Id love some advice

[Opry99er]

Here's the latest update. Still MUCH work to do...

 

1) Create the Beryl character graphics, forward facing, left-facing, right-facing, away-facing

2) Add an "ok" check for the bridge characters. Essentially, right now you can JUST walk on the path... need to figure out how to add more checks

3) Get it set up as a 2x2 player character instead of 1x1. This also means changing how I check for "in bounds" because I need to check 2 screen locations at once.

4) Get the rest of the screen drawn. (see the below video for what I'm wanting to accomplish on-screen)

 

if you all felt like looking at this source while I'm working my tail off the next week or two, I'd love some advice. =)

 

Unzip, drop in DSK1, Editor Assembler, Option 3 (LOAD AND RUN) program name "LAVAMOV" Enjoy

 

 

And this is the newest video of the Beryl Reichardt scroll routine. with subtitles. =)

http://www.youtube.com/watch?v=6JPNZVE9Gvw

LAVAMOV.zip

lavanb.txt

Edited May 30, 2010 by Opry99er

[matthew180]

Owen, you're doing great and from your posts in the Beryl thread it sounds like you're really getting into assembly. :-)

 

To answer #2 in your post above, I assumed you could walk on all the characters from 104 to 111? I would suggest you make all traverseable tiles consecutively, then you can easily check if the tile you want to move to is within that range.

 

Pseudo code would be something like:

TempX = X
TempY = Y

If move up then TempY=TempY-MapWidth
If move down then TempY=TempY+MapWidth
If move left then TempX=TempX-1
If move right then TempX=TempX+1

Tile=character value at TempX,TempY

If Tile >= 104 and Tile <= 111 then
 X=TempX
 Y=TempY
End If

 

Matthew

Edited May 31, 2010 by matthew180

[Opry99er]

Very good info, thank you!

[Opry99er]

How far away can a JNE be from its target label? I am getting a crash on something and I think I might be too far away in my JNE. 42 lines. That too much? If so, what's a quick way to get there?

[+adamantyr]

How far away can a JNE be from its target label? I am getting a crash on something and I think I might be too far away in my JNE. 42 lines. That too much? If so, what's a quick way to get there?

 

Jumps use a single byte to indicate the number of words to skip, -128 to 127. Your average assembly instruction is two words, or 4 bytes. So 42 lines is probably out of range... which is the error you would get when you try and compile, and OUT OF RANGE in this line.

 

There's multiple ways to deal with this. Easiest is to have it jump to a branch instruction, which can get anywhere in memory as it uses a whole word for the address. You can also refactor your code so things are closer together; use branch-and-link to break down your routines between jumps into smaller pieces.

 

Adamantyr

[sometimes99er]

How far away can a JNE be from its target label? I am getting a crash on something and I think I might be too far away in my JNE. 42 lines. That too much? If so, what's a quick way to get there?

You didn't say compile error, but crash, so I assume it's the compiled program crashing. JNE is then working alright, but there might be something wrong logically, wrong label or label at wrong place. The problem may very well be somewhere else. If it starts crashing after just one change, then set a breakpoint in advance in the Debugger and single step to see the values and what happens.

 

Edited June 1, 2010 by sometimes99er

[Opry99er]

Thanks. I fixed it. It was something screwy like a skipped line or something. =) Amazing how simple it seems once you get it figured out. Now I'm trying to get my SPRITEs onscreen and I can't seem to make it work. I've attached my source code as it currently sits. it WILL assemble and run nicely, but the SPRITEs aren't visible. I'm using the Lottrup book and it's a bit confusing here. PLease take a look and give me a hand. The SPRITEs are probably not in the correct places, but they need to be at the exact same screen locations. And I still need to center my screen and whatnot, but take a look, assemble it, run it, let me know what ya think. =)

lavanbn.txt

[sometimes99er]

I would recommend setting all 8 VDP registers as one of the first things. You can't always assume. There are differences between EA, MiniMem and XB, and I believe there's even some difference between emulators. Other than that you're setting some sprite patterns ...

 

LI R0,>0420

LI R1,SP0

LI R2,32

BLWP @VMBW

 

>0420 with EA should be sprite pattern no. >84

 

One character is 8 bytes hence: >0420 / >8 = >84

 

When setting the sprite attribute you're however using >88

 

SDT0 DATA >5050,>880E

 

?

 

This is just a first glance ...

Edited June 1, 2010 by sometimes99er

[matthew180]

Wow. It is amazing how a seemingly simple thing turns into a really big deal! I was working on a viewport based map scroller to provide as an example for Owen and the thing kept getting really crazy! The biggest problem is the constant translation between coordinate spaces, i.e. real screen X,Y vs. the player's X,Y location in the map, and converting between an X,Y location and an offset into the data (which is needed for drawing, path checking, etc.)

 

But probably the biggest problem turned out to be the map itself and what to do once you hit the edge. Initially I thought keeping the player at a fixed screen location (the center of the viewport) and scrolling the map would be the easiest. However, you need a border around your map that is half the width of the viewport, which is a huge waste on a limited system. Of course that border can be dynamically figured and drawn, but it takes a lot of assembly code to do that (tons of checks inside the drawing loop) and was killing the performance.

 

What I settled on was a hybrid really. The player stays in the middle of the viewport and the map scrolls as long as there is enough map to fill the viewport. As soon as the player gets close to an edge, the map clamps and no longer scrolls, and the player moves from the center location and can travel to the edges.

 

It seemed to work out nicely and keeps all the calculations out of the drawing loops. It is still a lot to track though, and the code I'm attaching here certainly needs refinement. You can mess with the viewport size in the MAPLOD subroutine, just make sure the start location is at least 1, and the width and height are odd and provide room for the border. The code should support even width and height values, but I did not test it.

 

I have tested this code with the E/A on Classic99. Assemble with the R option, run via EA3, the program name is "MAIN".

 

Oh, and you are looking DOWN on the player, which is supposed to be a sword, shield, and a blob that is the head / body / player.

 

Matthew

viewport.zip

[Opry99er]

Holy crap!! I need to DL this as soon as I get back to the room!!! Looks amazing!

[Opry99er]

Man, I am amazed!!! That is so nice!!!!! I love the new viewport window as well! =) i had a very VERY long day, and this just made it all worthwhile. =) I will probably go with my initial concept for the character thougth... forward facing, away facing, left facing, and right facing. But this looks great Matthew! I can't thank you enough for creating this. I love how he can move out of the center when you come up on edges of the map. I thought about doing something like that before, but I had no idea how to implement it. =) This source is awesome. I have added some very cool updated graphics to go with this map... so I'll just make sure I keep the map the same size it is now. =) Gosh man... So much to do now!!! Also... just wanted to mention, the mountains and the graves and such should not be navigable. I'll look to see if I can find where that is in the source and change that. In this map (as of right now) there are only 3 navigable tiles... the path and the bridge tiles. Everything else is off limits. I will be creating more interesting parts of the path which will make it look more like a scroller--- update the landscape and make it more richly detailed. It is only a skeleton as it sits, but I'm working slowly on some very cool updates for the map graphics. Did you use Magellan for this project? If so, I'd like to see your .mag file if you don't mind. =) I might be able to work right off that one rather than mine. Mine's got all that extra stuff in it now, and I probably need to see what you did to alter the original map. Again, thank you a million. My own attempt at this was a success, so I don't feel like a bum--- waiting for people to do stuff for me. =) I wanted to do it myself, even though I knew yours would be better and far more advanced. So now, I will be using your source here as the basis for the remainder of the development. There's nothing in mine that isn't now in yours, so I can just set it aside, I think. The only thing that I have that is new is a few little graphics. Here's one of the entry door to the world. =) Pretty lame, but something new, nonetheless. I've been adding new graphic tiles to my .mag file as I go along... but I haven't spent much time on the graphics yet. Suppose I need to do that sometime. =) As long as the map size doesn't change, I can pretty much do whatever I need to do with it. anyway, sorry for my rambling. Thanks again!

 

 

 

 

 

[matthew180]

I will probably go with my initial concept for the character thougth... forward facing, away facing, left facing, and right facing.

 

Use whatever graphics you want, you're not going to hurt my feelings any. I just needed a layered sprite to test with and since the map is not isometric, a top down seemed logical. Plus I didn't want to get caught up messing with graphics for a day.

 

Also... just wanted to mention, the mountains and the graves and such should not be navigable. I'll look to see if I can find where that is in the source and change that.

 

This is where the path range is set:

PATHLO BYTE 104               * Range of path tile name
PATHHI BYTE 111
      EVEN

As I mentioned before, life is a lot easier if you define the path tiles consecutively so it is easy to have multiple tiles that you can walk on, but still check for a valid path easily. So, make sure the path is tile 104, and the two bridge tiles 105 and 106, then change the 111 to 106. Now you can only walk on the path and bridges.

 

I also suggest you do this same technique for object tiles, i.e. things you can pick up or interact with. That will make the collision detection just as simple as path detection.

 

Did you use Magellan for this project? If so, I'd like to see your .mag file if you don't mind. =) I might be able to work right off that one rather than mine.

 

My .mag file? Okay, head over to the Berly thread, about page 15 or so and download the map *you* posted. It is your map. I used Magellan to check a few things like tile pattern assignments and actual size of the map, and the data export to assembly code, but that's it. The map data is unmodified since the idea was to use Magellan generated data and load it from disk. Right?

 

I wanted to do it myself, even though I knew yours would be better and far more advanced.

 

That's how you learn. If you don't struggle through something, you won't understand it or get better. Your knowledge comes from your failures as much as your success. I learned something over the last 5 days: generating a border takes way too much processing. I originally thought it would be easier than clamping and letting the player move at the edges. I was wrong. I rewrote the mapping code about 5 times to get it where it is today, with plenty of Classic99 debug sessions.

 

So now, I will be using your source here as the basis for the remainder of the development. There's nothing in mine that isn't now in yours, so I can just set it aside, I think.

 

My code was designed to be a viewport scroller. Although you can use it as a basis for further development, there is a *lot* more that needs to go into it to facilitate a game. It needs some clean up and tweaking for sure, some variable management and reduction, restructuring, some subroutine separation to make life easier, etc.

 

There is a lot of code in there to deal with variable viewport placement and size, which could be greatly simplified if the viewport was at a known location and a fixed size. There is always a trade off between speed, code size, and flexibility. At this point it would be a good idea to determine as many parts of the code as possible and finalize on some key elements of the game, specifically:

 

* Will you require the 32K and disk (I'm pretty sure this is a "yes")?

* Is this going to run from EA3 or cartridge?

* Will the NPCs (non player characters) and mobs (monsters or anything you fight) be related to, or change with the current map? Or will they be the same no matter the map?

* What are the gameplay mechanics and goals?

* Is combat going to be real time or turn based?

* What happens when items are dropped?

* Are the maps going to be more like "areas", or progress from one to another such that they define a complete "world", just cut up into pieces?

* Are there going to be interior areas?

* What are the sound and music requirements?

 

All these will affect code organization and you need to have some idea up front. Like Adam said, assembly language is not really a prototyping language. It takes a lot of code to get things going which means changing your mind or trying new things takes a lot of rework.

 

Small "proof of concept" programs are the best way to go, and that is how I look at this viewport scroller. It is a program where you can mess with the viewport, try out a map, tweak things, etc.

 

As long as the map size doesn't change, I can pretty much do whatever I need to do with it.

 

Huh? The map size can be anything you want. The only restriction is that it has to be at least as big as the viewport. The LODMAP subroutine is where the map data would be loaded from disk and that's why the code has a ton of variables for dealing with the map instead of fixed values throughout the code.

 

You should spend some time understand the code and where/how things work. Try changing something and see what happens. Look at the sprite code, look at the coordinate to offset translations, etc. I try to comment enough to explain what is going on, but I would be very surprised if you didn't have any questions.

 

Matthew

[Opry99er]

Hey man. Yea, there's alot

to accomplish and it's certainly not a game yet---nor anywhere close. But I think I can answer all your questions--

 

* Will you require the 32K and disk (I'm pretty sure this is a "yes")?

 

-yes.

 

* Is this going to run from EA3 or cartridge?

 

Actually, I had been thinking "cart". Put it out as a cart+diskette combo. I'd like to have the game engines on cart and the large chunks of data on diskette.

 

* Will the NPCs (non player characters) and mobs (monsters or anything you fight) be related to, or change with the current map? Or will they be the same no matter the map?

 

-They will be mostly unique to the worlds, but there are a few that exist in many worlds too. (I have a list somewhere with all the monster data)

 

* What are the gameplay mechanics and goals?

 

-Get through each world by collecting the necessary items and defeating the boss--/make sure to complete your world quest for each world.

 

* Is combat going to be real time or turn based?

 

-Yea man--- most of this stuff is already covered in the Beryl thread, but on this one--- fully turn-based with chance for enemy interrupts (this ability of the enemy to interrupt the natural flow of turns is a real bitch when you're trying to set up combos.

 

* What happens when items are dropped?

 

-I don't think I follow. I won't need to drop items I don't think, and if I do--- they will surely just disappear.

* Are the maps going to be more like "areas", or progress from one to another such that they define a complete "world", just cut up into pieces?

 

-The Forest World is one large map, roughly the same size as the lava world you already know. The Forest world has unique graphics, unique challenges, and unique storyline and enemies. It is completely it's own little world. If you read the very first entry of my Beryl thread, you'll get a better understanding of the game goals. As you defeat the forest world, you move on to the desert world, then will be the mountainous region(world), the cavernous region(world), the lava world, the dungeon world, and finally "The Underworld"

* Are there going to be interior areas?

 

-Just a few, but they really are just mainly going to be short little walks from the door to the boss. . There is one like this in both the Forest and Lava worlds.

* What are the sound and music requirements?

 

-3 main game themes--- the Overworld exploration theme (forest/desert/mountainous worlds)------ the subterranian exploration theme (cavernous, lava, dungeon worlds) and--thirdly--- the Underworld theme. There will also be two smaller pieces of music for 1) battling enemies, 2) battling bosses. Then lastly, a simple

16 note "victory" tune when a level

is beaten.

 

Most of this stuff is already discussed in the Beryl thread, but it's good to post it here as well.

[Opry99er]

I also suggest you do this same technique for object tiles, i.e. things you can pick up or interact with. That will make the collision detection just as simple as path detection.

 

that's great advice--- I will do so from this point forward.

[matthew180]

Most of this stuff is already discussed in the Beryl thread, but it's good to post it here as well.

 

Yes it is, but the Beryl thread is 18 pages and it can be hard to dig the details out of a thread like that. Anyway, I really didn't mean for you to post answers, I was mostly proposing questions that you need to have thought about and worked out before you can write code to execute the ideas. Sorry, I'll try to be less vague in the future.

 

The 32K and disk requirement affect how your structure your code, as does a cart vs. EA3 style program. The code I wrote is EA3 and will need to be modified to run from a cart. Also, with a cart you can use 100% of the low 8K, which would make a good place to store map data, and possibly sound. However, sound data only needs to be read a few bytes at a time in sequential order, unlike the map, so the VDP RAM is also a good place for sound data. An EA3 program has to tread lightly in the low 8K, at least until it is loaded and running, since the REF/DEF table and utilities are in the low 8K. Once you are running, that RAM can be used 100% if you do not intend to return to the E/A cart (which I don't think you do.)

 

Either way, it makes a difference in how things are coded and set up. Also, if you are going to have a bank-switched cart, that also affects program organization.

 

I think I'm going to post a few skeleton programs for people to use as a general reference:

 

1. EA3, bare bones

2. EA3, VSYNC based FSM

3. Cart, bare bones

4. Cart, VSYNC based FSM

 

Of course none of these will have REF dependencies (which you can't use in a cart anyway.)

 

Matthew

[matthew180]

I also suggest you do this same technique for object tiles, i.e. things you can pick up or interact with. That will make the collision detection just as simple as path detection.

 

that's great advice--- I will do so from this point forward.

 

Yes and no. There are alternatives to object, NPC, and mob detection. Using an array to maintain the location of each "object" (referring to anything the player can interact with) might be faster, use less memory, and be more flexible. Just having the object location is usually not enough and you have an array of some sort anyway. Again, it all depends.

 

For path tracking that method works pretty good since the path data is already part of the map and the terrain tends not to change. NPCs and mobs may move around though, and are usually tracked in a separate array from the map.

 

Matthew

[Willsy]

Nice job Owen! I knew if I left you along long enough you would work it out. Actually I was setting up the pool for the kids today, so I have not had any 99/4A time until now.

 

I'll get to the keyboard input stuff soon, but I won't be using KSCAN since (get ready) I don't like it... No surprise there. The clincher was the post that retroclouds (or was it sometimes? I can't remember now) made a bit ago that pointed out the ROM KSCAN routine uses a delay. So I fired up the TI Intern and did some code reading of the KSCAN routine and found the delay is used twice and each time causes a 25ms delay. That means it takes about 3 video frames just to call KSCAN, and that is counting just the delay loops. That is 50ms where the computer is just spinning its wheels, and when instructions are measured in microseconds, 50 milliseconds is a long time!

 

Matthew

 

Agreed. KSCAN sucks the root. Here is a replacement KSCAN routine that I have on my hard disk from somewhere. I'm sorry, I have no idea who the author is so I can't give credit. If you are, or know the author, please shout out so that you can be credited (and questioned ). Nor have I checked that it works . I should invest some time in checking it out, because TurboForth could benefit from an independent (from the ROM) KSCAN. Unfortunately, what I know about CRU could be written on the back of a postage stamp with one of Demis Roussos' stubby fingers.

 

Mark.

 

*==
* Exported function list:
*   - KBSCAN -- Scans keyboard & returns qualified key code (BL @)
*               -- don't use if keyboard interrupt is active
*                 R0 msb = qualifier
*                    lsb = key code
*                 R1     = trash
*                 R2     = trash
*                 R12    = trash
*
*   - KBCONV -- Converts qualified key code to ASCII (BL @)
*                 R0 msb = qualifier
*                    lsb = key code
*                 R0 msb = ASCII key, >FF if none
*                    lsb = trash
*                 R1     = trash
*                 R2     = trash
*==

* Note: Hardware conflicts prevent some key codes from being correctly
*       detected if multiple qualifiers are held simultaneously. This
*       is due to the keyboard shorting across multiple key columns.
*       For the moment, I have removed support for such cases since it
*       lends itself better to specialized environments where overhead
*       is less of an issue.

* Export functions here
      DEF  KBSCAN,KBCONV

*==
* Scan keyboard (call with BL)
*
*  R0 msb = qualifier
*     lsb = key code
*
*  R0 is negative if a key is pressed... >80 will be set, if not,
*     qualifiers are still valid!
*
*  R1-R2, R12 trashed
*
* SIZEOF: 138 + 16 = 154 bytes
*==

* Init and scan alpha lock
KBSCAN LI   R12,36      * CRU base for keyboard scans
      CLR  R0          * Set to keyboard row 0, alphalock on
      LDCR R0,4
      TB   7-18        * Test alpha lock
      JEQ  KS1         * Not active?
      LI   R0,>80      * Add qualifier
KS1    SBO  21-18       * Alphalock off
* Scan qualifiers
      LI   R12,14      * Base for reading Ctrl,Shift,Fctn
      STCR R0,3        * Read qualifiers
      XOR  @B07,R0     * Invert qualifier bits
* Scan keyboard row 0
      LI   R12,6       * Base for reading
      CLR  R1          * Clear R1's lower bits...
      STCR R1,3        * Read to high R1
      XOR  @B07,R1     * Invert key bits
      JNE  KS2         * Key detected?
* Scan keyboard row 1
      SRL  R0,2        * Shift qualifier for SRC R0,5 later on
      INC  R0
      SBO  18-3        * Only bit to change
      STCR R1,8        * Read to R1
      JOP  KS3
* Scan keyboard row 3
      INCT R0
      SBO  19-3        * Only bit to change
      STCR R1,8        * Read to R1
      JOP  KS3
* Scan keyboard row 2
      DEC  R0
      SBZ  18-3        * Only bit to change
      STCR R1,8        * Read to R1
      JOP  KS3
* Scan keyboard row 4
      INCT R0
      SBZ  19-3        * 2 bits to change
      SBO  20-3
      STCR R1,8        * Read to R1
      JOP  KS3
* Scan keyboard row 5
      INC  R0
      SBO  18-3        * Only bit to change
      STCR R1,8        * Read to R1
      JOP  KS3
* No key detected
      SLA  R0,3        * Shift qualifier back
      RT               * Exit!

* One of =, <space>, or <enter> pressed
KS2    SWPB R1           * Word extend (fast)
      SRL  R0,7         * Setup qualifier
      MOVB @KSD3(R1),R0 * Isolate code
KS6    ORI  R0,>80       * Mark keypress
      SWPB R0           * Swap
      RT

* Prioritize code read from 8 bits... splits into 2 4bit chunks
KS3    XOR  @BFF,R1      * Invert bits
      SWPB R1           * Swap to low (fast)
      MOV  R1,R2        * Store for later
      SRL  R1,4         * Check high bits first
      JEQ  KS4          * Nothing in high nybble?
      AI   R0,>8000     * Add high code offset
KS5    SRC  R0,5         * Shift key row and qualifier
      AB   @KSD4(R1),R0 * Add code
      JMP  KS6          * Done
KS4    SLA  R1,4         * Shift back
      XOR  R2,R1        * Insert low nybble
      JMP  KS5

* 3 bit and nybble scan
KSD4
KSD3   BYTE 0,0,1,1,2,2,2,2
      BYTE 3,3,3,3,3,3,3,3

*==
* Translate rawkey code
*
*  R0 msb - qualifier
*     lsb - key code
*
*  R0 msb = ASCII code, >FF is none
*
*  R1-R2 trashed
*
*  CTRL keys: ','       = 00
*             'A' - 'Z' = 01 - 26
*             '.'       = 27
*             '/'       = 27
*             ';'       = 28
*             '='       = 29
*             '0' - '9' = 22 - 31
*
*  FCTN keys: '0' - '9' = >F0 - >F9
*             'S'       = >FA
*             'D'       = >FB
*             'E'       = >FC
*             'X'       = >FD
*             '='       = >FE
*             undefined are unmapped
*
* SIZEOF: 44 + 16 = 60 bytes
*==

KBCONV MOVB R0,R1        * Copy qualifier
      JLT  KCONV1       * No key pressed
      SETO R0           * Return >FF -- no key pressed
      RT
KCONV1 SLA  R1,1         * Kill >8000 flag
      SRL  R1,9         * Word extend
      MOV  @KCD1(R1),R2 * Get table base
      A    R0,R2        * Add code
      SB   R0,R2        * Fix high byte
      MOVB *R2,R0       * Get ASCII key code
      SRL  R1,1         * Test alpha lock bit
      JNC  KCONV2       * Not set
      CI   R0,'a'*256   * Lowercase 'a'
      JL   KCONV2       * Below range
      CI   R0,'z'*256+255 * Lowercase 'z'
      JH   KCONV2       * Above range
      AI   R0,->2000    * Make uppercase
KCONV2 RT

* Index table (future extension)
KCD1   DATA KBNORM,KBFCTN,KBSHFT,KBFCTN
      DATA KBCTRL,KBCTRL,KBCTRL,KBCTRL

*==
* Keyboard data, only 4 of the 8 possibilities mapped (simple codes)
*
* SIZEOF: 192 bytes
*==

* Keyboard data -- normal
KBNORM BYTE '=',' ',013,>FF
BFF    DATA >FF00
B07    DATA >0700
      BYTE '.','l','o','9','2','s','w','x'
      BYTE ',','k','i','8','3','d','e','c'
      BYTE 'm','j','u','7','4','f','r','v'
      BYTE 'n','h','y','6','5','g','t','b'
      BYTE '/',';','p','0','1','a','q','z'
* Keyboard data -- shift
KBSHFT BYTE '+',' ',013,>FF,>FF,>FF,>FF,>FF
      BYTE '>','L','O','(','@','S','W','X'
      BYTE '<','K','I','*','#','D','E','C'
      BYTE 'M','J','U','&','$','F','R','V'
      BYTE 'N','H','Y','^','%','G','T','B'
      BYTE '-',':','P',')','!','A','Q','Z'
* Keyboard data -- fctn
KBFCTN BYTE >FE,' ',013,>FF,>FF,>FF,>FF,>FF
      BYTE >FF,>FF,>27,>F9,>F2,>FA,'~',>FD
      BYTE >FF,>FF,'?',>F8,>F3,>FB,>FC,'`'
      BYTE >FF,>FF,'_',>F7,>F4,'{','[',>FF
      BYTE >FF,>FF,>FF,>F6,>F5,'}',']',>FF
      BYTE >FF,>FF,'"',>F0,>F1,'|',>FF,'\'
* Keyboard data -- ctrl
KBCTRL BYTE 029,' ',013,>FF,>FF,>FF,>FF,>FF
      BYTE 027,012,015,031,024,019,023,024
      BYTE 000,011,009,030,025,004,005,003
      BYTE 013,010,021,029,026,006,018,022
      BYTE 014,008,025,028,027,007,020,002
      BYTE 027,028,016,022,023,001,017,026


* Key qualifiers
KQ$ALP EQU  1                 * Alpha lock
KQ$FCT EQU  2                 * Function
KQ$SHF EQU  4                 * Shift
KQ$CTR EQU  8                 * Control
KQ$NON EQU  >80               * No key pressed

* Key codes
KC$ENT EQU  2  * <enter>
KC$SPC EQU  1  * <space>
KC$PER EQU  8  * .
KC$COM EQU  16 * ,
KC$EQ  EQU  0  * =
KC$SEM EQU  41 * ;
KC$SLA EQU  40 * /
KC$1   EQU  44 * 1
KC$2   EQU  12 * 2
KC$3   EQU  20 * 3
KC$4   EQU  28 * 4
KC$5   EQU  36 * 5
KC$6   EQU  35 * 6
KC$7   EQU  27 * 7
KC$8   EQU  19 * 8
KC$9   EQU  11 * 9
KC$0   EQU  43 * 0
KC$A   EQU  45 * A
KC$B   EQU  39 * B
KC$C   EQU  23 * C
KC$D   EQU  21 * D
KC$E   EQU  22 * E
KC$F   EQU  29 * F
KC$G   EQU  37 * G
KC$H   EQU  33 * H
KC$I   EQU  18 * I
KC$J   EQU  25 * J
KC$K   EQU  17 * K
KC$L   EQU  9  * L
KC$M   EQU  24 * M
KC$N   EQU  32 * N
KC$O   EQU  10 * O
KC$P   EQU  42 * P
KC$Q   EQU  46 * Q
KC$R   EQU  30 * R
KC$S   EQU  13 * S
KC$T   EQU  38 * T
KC$U   EQU  26 * U
KC$V   EQU  31 * V
KC$W   EQU  14 * W
KC$X   EQU  15 * X
KC$Y   EQU  34 * Y
KC$Z   EQU  47 * Z

[Opry99er]

You know--- I've been trying to make some analogies in the basics of assembly.. I am thinking about several simple ones, the first of which dealing with Registers. If you understand registers you're pretty much on your way. I think of registers like "buckets". What can you do with a bucket? You can put stuff into it, you can take stuff out. You can re-arrange the contents of the bucket, you can physically LOOK into a bucket. And once stuff is in there, it stays until dumped out.

 

Put stuff in: LI

Take stuff out: CLR

Rearrange stuff: SWPB

Look at stuff: CI

 

this is way over-simplified, but it helped me to conceptualize during my early learning processes. Something as simple as that analogy can be useful for someone who wants to get a bit of a grasp of the basics. Just a thought---

[matthew180]

Maybe try these analogies:

 

XB: A=0

AL: CLR R0

 

XB: A=5

AL: LI R0,5

 

XB: A=B

AL: MOV R1,R0

 

XB: IF A=6 THEN

AL: CI R0,6

 

XB: IF A=B THEN

AL: C R0,R1

 

If A and B are between 0 and 255

XB: C=A :: A=B :: B=C

AL: SWPB R0

 

XB: C=A :: A=B :: B=C

AL: MOV R0,R2

AL: MOV R1,R0

AL: MOV R2,R1

 

Matthew