sorry to hound, im using $C5 and if it equals #88 nothing was pressed.. i tied this routine into the IRQ
im trying to scan for left arrow, right arrow and up arrow, as these keys will be key to this IRQ routine. I dont know what im having such a difficult time adapting to the 128, but i guess im a slow learner..


lbstart  lda $c5
         cmp #88
         beq getout
;
         cmp lastkey
         beq getout
;
         sta lastkey
         cmp #85             ;F3
         bne lbarf5
;
         jmp mleft
;
lbarf5   cmp #86             ;F5
         bne lbarf7
;
         jmp mright

lbarf7   cmp #83             ;F7
         bne getout
;
         jmp select
;
getout   sta lastkey
         jmp lbexit
;
lbexit   rts

Location $C5 on the 128 is used by the kernel's tape handler functions and has nothing to do with the keyboard.  So I'm not at all surprised that it doesn't work as expected.  Relevant values to the keyboard scan are:

nokey    =$58                  ;idle QWERTY keycode
shflag   =$d3                  ;Shift/C=/Ctrl/Alt status...
;
;    000xxxxx
;       |||||
;       ||||+---> 1: Shift pressed
;       |||+----> 1: C= pressed
;       ||+-----> 1: Control pressed
;       |+------> 1: ALT pressed
;       +-------> 1: Caps Lock pressed
;
sfdx     =$d4                  ;QWERTY keypress status

The NOKEY value is what you would see at SFDXwhen no key is being pressed.  Note that for scanning purposes, keys such as F1, F2, ESC, etc., are QWERTY keys.  So, using some of the above labels, the beginning of your code would look something like this:

lbstart  lda sfdx              ;check QWERTY keycode
         cmp #nokey            ;anything pressed?
         beq getout            ;no, just exit
;

All of this information is in Mapping the Commodore 128, which it seems you haven't taken the time to read.

It would greatly help when you are asking for assistance for you to format your code fragments so they are easily read.  Also, try commenting so we know what your thinking was.  Routines with names likeMRIGHT and SELECT don't tell much without comments.

stiggity, you are exhibiting some bad coding habits by burying magic numbers like $C5 and 88within your program.  The casual reader will have absolutely no idea what those numbers mean.  Even I had to look them up, and I have more than a little assembly language programming experience with the 128.

There's a reason why assemblers allow you to assign values to labels!  Just about every location in the 128 that is affected by BASIC or the kernel has an official definition, such as SHFLG or SFDX. Use those definitions to make your code more readable and less buggy. If you define a location with a label and consistently use the label definition throughout your program, you will greatly reduce the likelihood of introducing a bug due to a typo.  Hard coding addresses and keypress values within the program opens the door to errors that the assembler will not catch for you.

Dino:
Yeah, i dont comment my source code. Everyone tells me i should, but since this is only my 2nd asembly project, ill try harder in the future. And yes, i have been using the crud out of mapping the 128, and using my 128 PRM. Very good reading, its just when i run into a problem, and have access to both books, where do i look? The appendix only helps so much, and with 500+ pages... ehehhe but.. i appreciate the help..

-Steve

Quote from: stiggity on July 24, 2010, 11:46 PMYeah, i dont comment my source code. Everyone tells me i should, but since this is only my 2nd asembly project, ill try harder in the future.

Why not "try harder" now?  Inadequate program documentation is the mark of an amateur.  I've been writing 65xx assembly language programs for some 30 years and to this day, I comment everything.  No one's memory is infallible and that's why all programming languages include the means to comment code.  If you keep putting up code fragments with hard-coded addresses and values, and no comments, and expect help, you won't get it from me.  I've fired people in years past for sloppy programming habits.

Commented source code allows you to go back to something you wrote long ago and be able to understand your thought processes.  Several years ago, I resurrected code that I developed when the C-128D was fresh off the assembly line (no pun intended) and with a little time spent reading the comments that I had placed into the original source code, I was able to expand on that ancient stuff, resulting in the 80 Column Display Manager.   Without adequate documentation, I would have been faced with puzzling through the program, line-by-line, trying to figure out what I was thinking back then.

QuoteAnd yes, i have been using the crud out of mapping the 128, and using my 128 PRM.

If that's the case, why are you asking questions about what's going on in the 128? 

Quote...its just when i run into a problem, and have access to both books, where do i look?

Your best choice is Mapping the Commodore 128, mainly because of its blow-by-blow dissection of the machine.  If you can't figure out what is going on in the C-128(d) from Mapping the Commodore 128, you should consider sticking to BASIC. 

It may sound like BDD is jumping on your case there, but it's for your own good. People who don't learn to do these things the right way never accomplish anything worth doing. They remain amateurs, like those weekend woodworkers who spend four weekends trying to make a picture frame, and when they finally call it quits they have a picture frame that looks like it was made by an amateur. But beginning woodworkers who listen to the old experts (and NO ONE is older or more of an expert than BDD) will be cranking out heirloom china cabinets after just a couple of years.

BDD
I'll make it a point to REM my assem, and i have zero questions about basic 2. You have to understand, im writing a 128 80column BBS, and it took me 15mins to figure out how to get VICE into 80column mode.
In all of my years of using/programming/enjoying the hobby, ive never laid down 1 line of VDC code. And if someone asks me a question about the BBS program i wrote for the 64, i dont hesitate to send code examples, answer questions, etc... i will try to document my source, and due to its size, this 128 BBS venture, would take an eternity to add the address's, etc. I have my IRQ working, and I appreciate the help. Especially the help from Lokalhorst. I learned enuff to be sloppy from looking at topic-related source code. Not code that has no real purpose... but hey, what good is _another_ BBS program for the commodore. Basically, it's something i Enjoy, and I'll never "stick-to-basic" no real fun there, more of a chore, than enjoyment.. but hey, even tho i have both books, doesnt meen im a Genetically Engineered Uber programmer... u know??

-Steve

DINO!!!!
Your probably reading this, and if so.. could u include a routine to print reverse white to VDC screen memory. I didnt see anything in your program that has anything to do with colors...

Quote from: stiggity on July 26, 2010, 04:44 AMYour probably reading this, and if so.. could u include a routine to print reverse white to VDC screen memory. I didnt see anything in your program that has anything to do with colors...

Again, you're not making the effort to read.  If you very carefully read the stuff about the 80 Column Display Manager, you should see the part that tells you that it provides some features that are not available in the standard C-128 screen kernel.  80CDM doesn't provide features that already exist, such as routine scribbling on the 80 column display.  You can use routines in the screen kernel (look at the jump table starting at $C000) to print anything you want.  As I said in an earlier post, it appears you are trying to reinvent the VDC wheel.

I will again remind you to read about the VDC in Mapping the Commodore 128.  Be sure to study the part about attributes and attribute RAM, the latter which normally starts at $0800 in the VDC's memory mapâ€"see page 429.  If you do so, you will see that an attribute is defined as follows:

    xxxxxxxx
    ||||||||
    |||||||+â€"â€"> intensity: 1 = high
    ||||+++â€"â€"â€"> color (R-G-B, bit 3 = R)
    |||+â€"â€"â€"â€"â€"â€"> flash: 1 = on
    ||+â€"â€"â€"â€"â€"â€"â€"> underline: 1 = on
    |+â€"â€"â€"â€"â€"â€"â€"â€"> reverse: 1 = on
    +â€"â€"â€"â€"â€"â€"â€"â€"â€"> char set: 1 = mixed case

This is nothing more than simple bit-twiddling.  None of this is all that complicated and, no, I'm not going to write your code for youâ€"you won't learn if someone else does the work for you.  You do want to learn, no?  So suck it up, start reading the documentation that is available to you (that's how I learned my way around the 128's hardware) and don't be afraid to crash the machine now and then.

Quote from: stiggity on July 26, 2010, 04:44 AM...it took me 15mins to figure out how to get VICE into 80column mode.

Be aware that VICE's VDC emulation is not exact.  In particular, response to some register settings deviates from the official CSG documentation for the 8563/8568.