Jump to content
GDMike

Foxit - in progress

Recommended Posts

1 hour ago, GDMike said:

...

 BYTE >NNNN  or just for a BYTE >NN ?

Because I always define as BYTE >NNNN

 

As with the DATA directive, you can string several operands together by separating them with commas:

       DATA >1234,987,LABEL1,LABEL2,>45
       BYTE >12,3,>45,255
       EVEN

...lee

  • Like 1

Share this post


Link to post
Share on other sites
7 minutes ago, Lee Stewart said:

 

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

Ahhh. Good deal. 

Share this post


Link to post
Share on other sites

My use of byte is basically for key scan values, such as ENT BYTE >0C00 is my enter key comparitive. So I should not be doing this? But stick to ENT BYTE >0C instead?

Edited by GDMike

Share this post


Link to post
Share on other sites

I'll make the proper adjustments..thx for that tip ..I'm surprised I've gotten as far as I have, as SNP "works" and I have this"bad coding" strung all over but I'd never guess it had issues.

I'll stop the bad coding ethics.

Edited by GDMike

Share this post


Link to post
Share on other sites
38 minutes ago, GDMike said:

My use of byte is basically for key scan values, such as ENT BYTE >0C00 is my enter key comparative. So I should not be doing this? But stick to ENT BYTE >0C instead?

 

Yup. 

ENT    BYTE >0C00

will result in >00 being assembled at label ENT and should get you an error message for the truncation. If you want ENT to point to a value of ‘>0C’, then, indeed, you should be coding it as

ENT    BYTE >0C

...lee

  • Like 2

Share this post


Link to post
Share on other sites
2 hours ago, Lee Stewart said:

 

Yup. 

ENT    BYTE >0C00

will result in >00 being assembled at label ENT and should get you an error message for the truncation. If you want ENT to point to a value of ‘>0C’, then, indeed, you should be coding it as

ENT    BYTE >0C

...lee

If and when you get a free moment, can you point me to some basic tips on reading and using cl99 debugger? I don't know if there's a from the chair fireplace video of using it. I get some of it, but I'm missing quite a bit.. like setting break point, setting a range to watch or capture. I'm using it but not to a great advantage yet, and I'd like to.

Also, can it still be used to dial in on a word in forth that needs troubleshooting?

I've just gotten CL99 manual..I haven't looked further if there is good in depth debugger information. I'll try to get un-busy and do some lookup. But nothing beats a hands-on demonstration..

 

Looking now... maybe something will jump out..oooh. STEP(F3) is very useful for me. Nice touch.

BTW...I just reviewed my code and I'm not using the BYTE directive, all my key values are indeed set as DATA. Sorry for confusing.. 

IMG_20211220_160641042.jpg

Edited by GDMike

Share this post


Link to post
Share on other sites
43 minutes ago, GDMike said:

If and when you get a free moment, can you point me to some basic tips on reading and using cl99 debugger? I don't know if there's a from the chair fireplace video of using it. I get some of it, but I'm missing quite a bit.. like setting break point, setting a range to watch or capture. I'm using it but not to a great advantage yet, and I'd like to.

Also, can it still be used to dial in on a word in forth that needs troubleshooting?

 

When working with the debugger, you need to have your assembly listing handy to pick and choose addresses where you suspect hanky-panky.

 

When single-stepping, you want to avoid loops like writing the screen. Otherwise, your finger will get tired,

 

You also need to be aware that enabling interrupts can get you into code you didn’t write, like KSCAN. I say that because, especially for single-stepping, you can get stuck in unfamiliar territory for a while until it dawns on you what is going on.

 

As for Forth, that can be another can of worms because you are often at a higher level than is convenient for following in the debugger. You, at the very least, need to watch the Forth registers while working out your debugging strategy.

 

...lee

  • Like 3

Share this post


Link to post
Share on other sites

My big revelation was when I pressed the question mark button.  (after about a year of using Classic99)

 

:) 

 

image.png.c2c18175c19b35c8e4f8b1515ec6f5e7.png

  • Thanks 1

Share this post


Link to post
Share on other sites

I could probably do a short video on general debugging, but the absolute biggest tip Lee already provided - have your assembly listing so you know the addresses of interest.

 

When you get into a loop, you can set a breakpoint to the end of the loop to get out of it quicker. It's a bit tedious to do so at the moment (since it's all manual) but it works. You can avoid breakpoints in ROM code (mostly useful if you are checking for values) with the 'Ignore console hits' checkbox (will ignore breakpoint matches if the PC is >0000->1FFF). And if you end up stepping into an interrupt and don't want to, what I usually do to get out of it is set a breakpoint for the entire range of my program, then it will break when it returns. (So, for instance, (6000-7FFF) or (A000-FFFF)). Of course, all these temporary breakpoints usually need to be removed when you get back where you want to be.

 

Let me know if there are specific techniques I could demonstrate...?

 

  • Like 4
  • Thanks 1

Share this post


Link to post
Share on other sites
Quote

 

Thanks so much. Rt now I'm still familiarizing myself with it and memorizing certain keys. The basics.. don't need to waste your time..I see this in the manual, I'll dive in later this week, actually.lol..its already there and no diving is necessary. Nicely done.

I've already seen how it loads up my program, shows F18A initialize up in my routine and continue on.. but I need to step through things as I'd like confirmation on my code and what's going on. Seems to be very powerful with lots of other options that I find intriguing, saving code out as program image is one. How cool. Thx everyone. 

Share this post


Link to post
Share on other sites
2 hours ago, TheBF said:

My big revelation was when I pressed the question mark button.  (after about a year of using Classic99)

 

:)

 

image.png.c2c18175c19b35c8e4f8b1515ec6f5e7.png

I'll find that Handy. Very good. Thx

Share this post


Link to post
Share on other sites

Ok.. I've finished adding the F9, (exit) allowance while in  the MODIFY SCREEN routine. 

And I've almost gotten the modi screen routine done. I've run into a couple bugs that I'm working out. But it'll have to wait until tomorrow. My time is up today.

 

Edited by GDMike
  • Like 2

Share this post


Link to post
Share on other sites
On 12/20/2021 at 6:07 PM, TheBF said:

My big revelation was when I pressed the question mark button.  (after about a year of using Classic99)

 

:)

 

image.png.c2c18175c19b35c8e4f8b1515ec6f5e7.png

BTW, I think the E/A assembler, and probably other assemblers do this too, but my question is, during assembly if I select"L", list option, world that also create a listing by address of my program? Because rt now I can't load an assembled DF 80 because the code doesn't fit the editor for viewing, I get memory full error. So I've been reading the assembly through a XB reader program that spits out what I'm looking for at the moment, depending, as if I'm just needing memory used, or just wanting to see a particular address etc... but I'm needing a quick and dirty listing, I haven't tried the"L" option yet, well I was busy again today... but I'll definitely do it tomorrow.

And I've also got to figure out how to set the PC in the debugger. I'll be trying to solve those issues of mine tomorrow. Can't wait!!! I really need that debugger kicking it!!

Edited by GDMike

Share this post


Link to post
Share on other sites

The E/A, LISTING, will show specific addresses for ABSOLUTE coded lines, RELOCATABLE coded lines will show the LOCATION COUNTER instead.

 

You really need to read the funktastic manual more!

 

Try this...

 

DISASM=0000,2000


disasm.thumb.png.789d3774bb26286b2c3e973202302826.png

:ahoy:

Edited by HOME AUTOMATION
RELOCATABLE Vs. RELATIVE
  • Like 2

Share this post


Link to post
Share on other sites
4 hours ago, GDMike said:

but I'm needing a quick and dirty listing, I haven't tried the"L" option yet, well I was busy again today... but I'll definitely do it tomorrow.

And I've also got to figure out how to set the PC in the debugger. I'll be trying to solve those issues of mine tomorrow. Can't wait!!! I really need that debugger kicking it!!

You want L, yes. ;) If you build in Classic99 instead of on hardware, you can make the listing go to a Windows text file on a FIAD folder by naming it like "DSK2.?W.LISTING.TXT" (the ?W makes it a Windows text file)

Set the PC in the little edit box at the bottom of the screen, and any other memory changes too. PC is "PC=1234". Type "HELP" and look at the debug view for a summary of what that little box can do, cause it got a bit away from me. ;)

 

image.thumb.png.914cae5dffbfe28e05931660777bf841.png

  • Like 3

Share this post


Link to post
Share on other sites

Got the bugs removed from Foxit just now. 

Statement with a data 1 needed to be a data 0,

I needed an extra 120 bytes of SAMs for my screen routine.. and I had  a BL routine not passing R2 back to the calling program, which was related to the routine being short of SAMs ram from what I remember.

I'll finish the night by testing the rest of the screen layout routine and hopefully it'll be fine.

Actually think I've already knocked out the bugs in it. 

It's still progress.. Even though it took quite a bit of time.

I'll now start playing with the debugger a bit..

 

 

 

Edited by GDMike
  • Like 1

Share this post


Link to post
Share on other sites

Ok. With what I know now, im going to pull back a bit.

I'm gonna have to write a routine that runs at boot up and sets up 16 SAMs banks for me and lll have to push my routines into those banks and execute them as needed..

Meaning, I'll have to write my filing system that pulls in however many compiled object code routines that I have and place into SAMS. As I previously only using 1 bank and I was hoping to squeeze everything in, but I'm still short.

Not a setback, just more coding.

I wasn't to sure on how to do this but as Lee pointed out that it's similar on how I'm pulling in SNP pages in SNP, except that the data has to be compiled code. So I'll just make sure each routine starts out as an AORG >3000 and isn't more than 4K in size.

This way  I'll know where the routine is at all times.

 

Sounds like fun

 

 

Edited by GDMike
  • Like 3

Share this post


Link to post
Share on other sites

Happy new year '22 are you ready? It's happening.  

 

Headed out this morning to start my 3 day work week. Foxit will be getting a SAMs update. Whohoo

 

Edited by GDMike
  • Like 1

Share this post


Link to post
Share on other sites

Happy 2022 right back.

If there is anything you need to get done this year... get on it. :)

 

 

  • Thanks 1

Share this post


Link to post
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...