Jump to content
IGNORED

Foxit - in progress


GDMike

Recommended Posts

does it move around with arrow keys -

oops....i see the astersik..that means im at a stop.. which I placed on purpose. That's great!

 

.ok. thank you!!

I cannot get this far? Im not sure why...its working for you though because of the "*" mark...

which my screen locks up and goes funky before getting to display the field name.

Edited by GDMike
Link to comment
Share on other sites

It only allows 1 Field that move in the modi screen routine as of right now because that's where I left off last weekend..

But if it works for someone and not me..then I'm wondering why....

It's not working for me any more..I'll be back in half n hr

Edited by GDMike
Link to comment
Share on other sites

Yes. It's not crashed. The program is still running like normal waiting on a key. But the video is scrambled. @BF can run the program with no scrambled video. I then upgraded classic 99 thinking maybe?? But I've not seen this before, and everything was good when I put the laptop away last weekend and the program ran perfect then. But I left the machine on overnight day before yesterday and some updates went through. I also put chrome on it. So thinking that may have caused issues I removed chrome. But naa.. that didn't fix it and reboots have been plenty.

I'll throw win 7 on it as soon as I get a break. Well, I can't stand win 10. I mean it was ok for the past hmmm couple months but all of a sudden...so I'm blaming it on win 10 updates.

The machine is a Dell 17" Inspiron i5. SSD 8 GB ram. And only office and Adobe but I've since removed adobe as to troubleshoot...

Firefox still installed, chrome removed. No network during my time here tonight.

Thank you for inquiring

 

Edited by GDMike
Link to comment
Share on other sites

23 hours ago, TheBF said:

image.png.0c06fd5bc2ddb8347f8540d0ead50589.png

Doesn't move here.

?

Gotta go for awhile.

 

Fixed my issue. I don't understand why it ran on your CL99 and not mine any longer, but I found a data statement that represents the length of the field value, and if I just force to a 5, for example, it worked...

Anyway, I changed my DATA 0 for my Field values length to that of DATA 1 and I'm back in action..

I've always stored values using DATA 0 followed with EVEN in my source and this is the first time it threw my graphics all over the place, well understand that since it was a VMBW and who knows what high value garbage was stuck in the value..

Mystery why it ran on @BF test program..

but it is what it is.

Edited by GDMike
  • Like 1
Link to comment
Share on other sites

Well even after losing a day of coding, I was still able to make progress this weekend.

 

The error that ran it's course in a data statement allowed me to review how I was handling the placing of fields on the screen.

I was able to rebuild that routine and I've used less code doing it and it is tighter than ever.

So I'm pleased about that.

I'll be coding late next week as I work Friday, Saturday and Sunday coming up, so I wonder how much can get done!

 

 

 

  • Like 1
Link to comment
Share on other sites

16 hours ago, GDMike said:

I've always stored values using DATA 0 followed with EVEN in my source...

 

EVEN is unnecessary after a DATA directive because a DATA directive always starts and ends on an even address boundary. The same is true for any machine instruction.

 

EVEN is useful after BYTE and TEXT directives because they can, in fact, leave the code on an odd address boundary.

 

...lee

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

35 minutes ago, Lee Stewart said:

 

EVEN is unnecessary after a DATA directive because a DATA directive always starts and ends on an even address boundary. The same is true for any machine instruction.

 

EVEN is useful after BYTE and TEXT directives because they can, in fact, leave the code on an odd address boundary.

 

...lee

Ahh ... great to know about Data statement. Does that still remain true if I define my BYTE statement as:

 BYTE >NNNN  or just for a BYTE >NN ?

Because I always define as BYTE >NNNN

Edited by GDMike
Link to comment
Share on other sites

1 hour ago, GDMike said:

Ahh ... great to know about Data statement. Does that still remain true if I define my BYTE statement as:

 BYTE >NNNN  or just for a BYTE >NN ?

Because I always define as BYTE >NNNN

BYTE >NNNN   is going to  take 1/2 of that number and put it in memory as a byte.  

It can't swallow an integer.

 

And so the program counter could end up on an ODD address which 9900 does not like. 

Therefore as Lee says, use EVEN after BYTE or TEXT and you don't have to worry about it.

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, GDMike said:

Ahh ... great to know about Data statement. Does that still remain true if I define my BYTE statement as:

 BYTE >NNNN  or just for a BYTE >NN ?

Because I always define as BYTE >NNNN

 

If by >NNNN you mean 4 hex digits, that is not a byte! You should get an assembler warning or error for that. BYTE is not treated as DATA. It is not guaranteed to start on an even boundary as is the case with DATA. It is always a good idea to end a BYTE directive or a TEXT directive with EVEN

 

...lee

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...