Jump to content
IGNORED

Foxit - in progress


GDMike

Recommended Posts

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. 

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

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