6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Thu May 09, 2024 3:00 am

All times are UTC




Post new topic Reply to topic  [ 20 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Mon Mar 07, 2016 10:47 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3354
Location: Ontario, Canada
VetteGuy777 wrote:
I believe the test number and enter are being strung together.
Hm. What you're saying here isn't wrong, but let's take it apart. What's meant is:

    - the first call to GetCharW returns the test number
    - the following call to GetCharW returns the Enter

or, more simply,

    - sometimes when you call GetCharW you get a test number. Other times when you call GetCharW you get something that isn't a test number.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html


Top
 Profile  
Reply with quote  
PostPosted: Tue Mar 08, 2016 6:42 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8177
Location: Midwestern USA
VetteGuy777 wrote:
When the automatic grader inputs the test numbers it not only enters the number but it enters the code for "enter" aka carriage return.
Dr Jefyll wrote:
Hm. What you're saying here isn't wrong, but let's take it apart. What's meant is:

- the first call to GetCharW returns the test number
- the following call to GetCharW returns the Enter

or, more simply,

- sometimes when you call GetCharW you get a test number. Other times when you call GetCharW you get something that isn't a test number.

I think what is being described suggests that the GetCharW sub is collecting a data stream in a FIFO somewhere (IRQ-driven source, perhaps?) and each call to GetCharW returns with the "oldest" byte in the FIFO. That's exactly how the GETCHx subs in my POC's firmware behave (where the x in GETCHx refers to one of the TIA-232 channels). GETCHx does no analysis of what it returns—the calling program has to look at the byte and decide what to do with it. I suspect GetCharW works in similar fashion.

It sounds to me as though your program need to buffer the bytes retrieved from GetCharW until the <CR> is received and then process the input. Think of <CR> in this case as meaning "end of data—it's time to process the input."

Here's an example of how I did it in Supermon 816:

Code:
;================================================================================
;
;input: INTERACTIVE INPUT FROM CONSOLE CHANNEL
;
;   ———————————————————————————————————————————————————————————
;   Preparatory Ops: Zero IBUFIDX or load IBUFFER with default
;                    input & set IBUFIDX to the number of chars
;                    loaded into the buffer.
;
;   Returned Values: .A: used
;                    .X: characters entered
;                    .Y: used
;
;   Example: STZ IBUFIDX
;            JSR INPUT
;
;   Notes: Input is collected in IBUFFER & is null-terminated.
;          IBUFIDX is reset to zero upon exit.
;   ———————————————————————————————————————————————————————————
;
input    ldx ibufidx           ;current buffer index
         stz ibuffer,x         ;be sure buffer is terminated
         jsr dpyibuf           ;print default input if any
         per dc_cn
         jsr sprint            ;enable cursor
         ldx ibufidx           ;starting buffer index
;
;
;   main input loop...
;
.0000010 jsr getcha            ;poll for input
         bcs .0000060          ;nothing
;
         cmp #a_del            ;above ASCII range?
         bcs .0000030          ;yes, not allowed
;
         cmp #a_ht             ;horizontal tab?
         bne .0000020          ;no
;
         lda #a_blank          ;replace <HT> w/blank
;
.0000020 cmp #a_blank          ;control char?
         bcc .0000040          ;yes
;
;
;   process QWERTY character...
;
         cpx #s_ibuf           ;room in buffer?
         bcs .0000030          ;no
;
         sta ibuffer,x         ;store char
         inx                   ;bump index
         .byte bitabs          ;echo char
;
.0000030 lda #a_bel            ;alert user
         jsr putcha
         bra .0000010          ;get some more
;
;
;   process carriage return...
;
.0000040 cmp #a_cr             ;carriage return?
         bne .0000050          ;no
;
         phx                   ;protect input count
         per dc_co
         jsr sprint            ;cursor off
         plx                   ;recover input count
         stz ibuffer,x         ;terminate input
         stz ibufidx           ;reset buffer index
         rts                   ;done, return to caller
;
;
;   process backspace...
;
.0000050 cmp #a_bs             ;backspace?
         bne .0000010          ;no
;
         txa
         beq .0000010          ;no input, ignore <BS>
;
         dex                   ;1 less char
         phx                   ;preserve count
         jsr gendbs            ;generate destructive backspace
         plx                   ;restore count
         bra .0000010          ;get more input
;
;
;   input waiting loop...
;
.0000060 wai                   ;wait for datum
         bra .0000010
;

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Tue Mar 08, 2016 9:17 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10800
Location: England
VetteGuy777 wrote:
I think I have found out why it is not working but how to fix it is still beyond me. When the automatic grader inputs the test numbers it not only enters the number but it enters the code for "enter" aka carriage return. My program automatically starts to do stuff with the input before an enter command can be given but since it is computerized I believe the test number and enter are being strung together. Thus it does not work. My professor, I think, told me to make it either use or ignore the enter. So does anybody have any ideas.

I'd like to compare two approaches to getting an assembly language program to behave in a desired way:
- write some code
- test it
- keep changing it
- until it passes
as compared to
- write some code
- test it
- understand exactly what happened to make it fail
- adjust the code according to your new understanding
- repeat until it passes

That is to say, your objective is either to pass the test, or to understand the subject matter well enough that you pass the test.

If your program isn't passing, then that's exactly the opportunity you need to study your program, work through its behaviour step by step, and see how it behaves.

My guess is that you're not yet looking carefully enough at each and every instruction - the nature of programming at this low level is that you often can't gloss over several instructions and assume that they do such-and-such, if there's any evidence that they don't.

So, my advice would be
- slow down
- step through your failing program one instruction at a time

It will be worth it!


Top
 Profile  
Reply with quote  
PostPosted: Tue Mar 08, 2016 4:03 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1928
Location: Sacramento, CA, USA
VetteGuy777,

Does the emulator you're using provide support for single-stepping, break-points and memory dumps? If so, that's a path I would try (especially the break-points). I would pay particular attention to the return values coming from the system subroutines ...

Mike B.


Top
 Profile  
Reply with quote  
PostPosted: Tue Mar 15, 2016 12:44 pm 
Offline

Joined: Sat Mar 05, 2016 4:27 pm
Posts: 7
I solved it apparently the grader was unhappy because the program was not in a continuous loop. Thank you all for your input.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 20 posts ]  Go to page Previous  1, 2

All times are UTC


Who is online

Users browsing this forum: No registered users and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: