serial monitor

[Gurce Isikyildiz]

Thought I'd better break off this topic into a new thread.

I got the tab-completion working via the readline library too now.

Here's a walkthrough example. I'll notate every time I press tab with "\t":

<dbg>ps dos_\t
Display all 105 possibilities? (y or n) n

<dbg>ps dos_file_\t\t
dos_file_advance_to_next_cluster  dos_file_loadaddress
dos_file_advance_to_next_sector   dos_file_read_current_sector
dos_file_descriptors

<dbg>ps dos_req\tuested_filename
 dos_requested_filename: BOOTLOGO.M65

Hopefully that'll make typing in those length symbol names a lot easier :)

Gurce

[Gurce Isikyildiz]

I've added a "break <addr>" command. The advantage it has over the raw "b<addr>" command is that you can break on a symbol name.

As an initial example, I tried "break dos_readfileintomemory", but this didn't seem to trigger due to a break-bug that Paul mentioned.

 

No worries, I'll break an instruction deeper into it, at "break 8F9A" and that does the trick...

Another thought came to mind. Is there any way that I could trigger a reset similar to that done by the RESTORE key, but via the remote monitor instead?

I'm itching to add a "reset" command. Could it work by perhaps doing something like the following?

- t1
- get the current pc
- At current pc, inject a JMP instruction to a place in kernal/memory that handles the reset?
- t0

Is that feasible? Anyone know of the desired address I need to jump to for this? :)

Gurce

[Gurce Isikyildiz]

Ok, reset command in hardware, sounds good to me.

100x faster stepping via the serial monitor? That'd be awesome :) It might then open the possibility of allowing the user to add multiple software breakpoints, rather than the single hardware breakpoint we have presently.

Another thing on my to-do is to make that serial-port device name configurable in some way... It's still hard-coded at present.

Gurce

On 8 August 2016 at 13:48, Paul Gardner-Stephen <pa...@servalproject.org> wrote:

Hello,

Great work on the tab completions etc.

Adding a reset command to the serial monitor interface would not be that hard.  This might be a job that Tim can do (who will soon introduce himself here).

For the breaks, just manage them in software, because of the known problems with the hardware break.  Note that Tim will also be working on reducing the output (and thus improving the speed) of the serial monitor trace output by a factor of about 20x.  While it still won't be as fast as we might like, it will hopefully be enough to make things usable.  We can then look at increasing the serial port speed to get further gains there, e.g., to use 960Kbps instead of 240Kbps.  If we can get a cumulative ~100x or better, then 10 minutes becomes 6 seconds, which will be workable, I think.

Paul.

--
You received this message because you are subscribed to the Google Groups "C65GS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-development+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paul Gardner-Stephen]

Hello,

Ok. All sounds like a plan.

Paul.

[Gurce Isikyildiz]

Alrighty, I've tested the app on mac osx. You can now get it built and running there.

Specify your serial device as follows:

./m65dbg --device /dev/cu.usbserial-210292742986B

(replacing /dev/* with whatever you need).

At some stage, I probably should save out a settings-file to persist settings like this between runs. I'll save that idea for a later growth spurt.

Gurce

[Paul Gardner-Stephen]

Super!

I'll try it when I get a chance, and I am sure that Ben will try it soon as well.

Paul.

--

[Paul Gardner-Stephen]

... oh, I don't remember if I mentioned, but I have created a MEGA65 organisation on github (github.com/MEGA65).  You are welcome to push the latest changes to the appropriate repository there (you have write access already).  I am going to try to keep that as the central authoritative location of MEGA65-related source code.

Paul.

[Gurce Isikyildiz]

Okidoke, from here-on in, I'll push my changes directly to:

https://github.com/MEGA65/m65dbg

Ralph, please update your cloned repo to this address too, to assure you get the latest updates :)

Speaking of updates, here's one last addition for tonight, added support for watchlists! (saves you from typing sets of print commands over and over):

- We have wb (watch-byte), ww (watch-word), wd (watch-dword), ws (watch-string), which can take a parameter of an address or symbol-name:

<dbg>ws dos_requested_filename
watch added!
<dbg>wd dos_file_loadaddress
watch added!

You can then list your watches as follows:

<dbg>watches
#1: STRING  dos_requested_filename: CHARROM.M65
#2: DWORD   dos_file_loadaddress: 0FF7E000

 

You can type things like "wdel 1" or "wdel 2" to delete either item from the watchlist. You can delete both with "wdel all".

 

I've also added a "autowatch" command that will automatically list all your watches each time a disassembly is shown (eg, upon each step/n/dis). This can be used alongside "autocls" to get a reasonably clean view of your watches_disassembly upon each step:

<dbg>ws dos_requested_filename
watch added!
<dbg>wd dos_file_loadaddress
watch added!
<dbg>autocls
 - autocls is turned on.
<dbg>autowatch
 - autowatch is turned on.
<dbg>step

The screen then clears and you'll see something like this:

PC   A  X  Y  Z  B  SP   MAPL MAPH LAST-OP     P  P-FLAGS   RGP uS IO
88F9 20 2D 0B 3F BF BEF9 CFC0 3F00 9D 67 BC A4 00 N.E..I... ..P 11 -00 H-
---------------------------------------
#1: STRING  dos_requested_filename: CHARROM.M65
#2: DWORD   dos_file_loadaddress: 0FF7E000
---------------------------------------
> /home/vets/mega65/kickstart_dos.a65:1154
> 1144:
> 1145: dos_requested_filename_to_uppercase:
> 1146:         ; Convert filename to upper case for comparison
> 1147:         ldx dos_requested_filename_len
> 1148:         cpx #$3f
> 1149:         lda #dos_errorcode_name_too_long
> 1150:         bcs dos_return_error
> 1151: drftu1: lda dos_requested_filename,x
> 1152:         jsr toupper
> 1153:         sta dos_requested_filename,x
> 1154:         inx
> 1155:         cpx dos_requested_filename_len
> 1156:         bne drftu1
> 1157:         sec
> 1158:         rts
> 1159:
> 1160: dos_get_free_descriptor:
> 1161:
> 1162:         ldx #$00
> 1163: dgfd1:  txa
> 1164:         asl
$88F9      M_nnnn:2 E8 EC 66 INX
<dbg>

Then press enter, the screen will clear again and the next step command will be executed.

Gurce

[Ben-401]

Hi Gurce, well done on the m65dbg, i look forward to trying it out when i can.

Currently I use the following for the serial comms to the nexys board:
picocom in cygwin in vista
cu in console/terminal in macos
Of importance to me with the serial-monitor is the trace/debug messages, as these will help me significantly to debug while I modify the code. I think that all of these strings are prefixed with a constant string so you could easily detect them and print them unmodified.
It will be great being able to better understand the opcodes with your disassembly routines, and the extra bells-and-whistles that you are implementing.

I have prepared a list of modifications i would like to make to the serial-monitor interface on the fpga (in vhdl), some are listed below:
- when stepping during trace mode, no need to print the banner each time,
- presssing 'r' will repeat the banner
- when in tc mode, just print the line of current-registers, ie no need for the banner, maybe banner every 20 lines or so
- better help info (this is best go into your console program)
- more breakpoints instead of just one
- skip an instruction
- more compact serial protocol (as discussed with Paul and Tim).
- etc

Ben.

[Gurce Isikyildiz]

Cheers Ben, I hope the m65dbg tool comes in handy.

Looking forward to your+Tim's upcoming refinements on the vhdl-monitor side of things too.

Just one last perk for today... :)

I've refined the "dis" command to do more:

• dis = disassemble the current pc
• dis - <count> = disassemble the current pc and <count> instructions onward
• dis <addr> = disassemble the given address
• dis <addr> <count> = disassemble the given address and <count> instructions onward

 

For example:

<dbg>dis c000 10
$C000     M_immnn:1 A9 47    LDA #$47
$C002      M_nnnn:2 8D 2F D0 STA $D02F
$C005     M_immnn:1 A9 53    LDA #$53
$C007      M_nnnn:2 8D 2F D0 STA $D02F
$C00A     M_immnn:1 A9 0E    LDA #$0E
$C00C      M_nnnn:2 8D 20 D0 STA $D020
$C00F     M_immnn:1 A9 06    LDA #$06
$C011      M_nnnn:2 8D 21 D0 STA $D021
$C014     M_immnn:1 A9 0E    LDA #$0E
$C016      M_nnnn:2 20 D2 FF JSR $FFD2
$C019     M_immnn:1 A2 00    LDX #$00
$C01B     M_immnn:1 A9 20    LDA #$20
$C01D     M_nnnnX:2 9D 00 04 STA $0400,X
$C020     M_nnnnX:2 9D 00 05 STA $0500,X
$C023     M_nnnnX:2 9D 00 06 STA $0600,X
$C026     M_nnnnX:2 9D 00 07 STA $0700,X

Future improvements I'm now itching for are:
- some sort of equivalent to gdb's backtrace command
- up/down commands to quickly move through the backtrace frames and see the relevant source/disassembly

These itches never seem to go away... :)

Gurce

[Gurce Isikyildiz]

Oh, one observation worth noting.

After I did those recent improvements to the "dis" command, I noticed that it seems, erm, slow-ish.

Eg. a command like "dis c000 30" disassembles 30 lines in about 1 second... That seems kinda slow.

Each disassembly line does the following:

1) calls the raw "d<addr>" command to get a sequence of bytes, eg:

<dbg>dc000
 :777C000 A9 47 8D 2F D0 A9 53 8D 2F D0 A9 0E 8D 20 D0 A9

2) dis-assembles the first few of these bytes and prints out this disassembled output.

3) increments the <addr> value then repeats steps 1 and 2, etc...

While I haven't taken any metrics for step 2, my gut is telling me that there is something excessively slow-ish about step1.

Another example, compare it with the raw command "DC000", which outputs multiple lines:

<dbg>DC000
 :777C000 A9 47 8D 2F D0 A9 53 8D 2F D0 A9 0E 8D 20 D0 A9
 :777C010 06 8D 21 D0 A9 0E 20 D2 FF A2 00 A9 20 9D 00 04
 :777C020 9D 00 05 9D 00 06 9D 00 07 A9 0E 9D 00 D8 9D 00
 :777C030 D9 9D 00 DA 9D 00 DB E8 D0 E1 A0 27 B9 EA C5 20
 :777C040 7D C5 09 80 99 00 04 B9 12 C6 20 7D C5 09 80 99
 :777C050 C0 07 88 10 E7 A9 00 8D E3 C5 8D E4 C5 8D D4 C5
 :777C060 8D D5 C5 8D E1 C5 8D E2 C5 78 A9 00 8D 40 D6 EA
 :777C070 A3 00 58 C9 00 D0 39 A2 27 BD 88 C0 20 7D C5 9D
 :777C080 E0 05 CA 10 F4 4C 85 C0 4E 6F 20 72 65 70 6C 79
 :777C090 20 66 72 6F 6D 20 48 79 70 65 72 76 69 73 6F 72
 :777C0A0 20 2D 20 6E 6F 74 20 61 20 4D 45 47 41 36 35 3F
 :777C0B0 A9 00 4B A9 41 85 00 A9 12 8D 40 D6 EA B0 39 A2
 :777C0C0 27 BD D0 C0 20 7D C5 9D E0 05 CA 10 F4 4C 85 C0
 :777C0D0 20 20 43 6F 75 6C 64 6E 27 74 20 6F 70 65 6E 20
 :777C0E0 64 69 72 65 63 74 6F 72 79 20 66 6F 72 20 72 65
 :777C0F0 61 64 69 6E 67 20 20 20 8D E9 C5 A9 00 85 FE A9
 :777C100 10 85 FF A9 14 AE E9 C5 A0 0F 8D 40 D6 EA 93 8C
 :777C110 00 AD 00 0F C9 2E F0 EB AD 40 0F C9 05 90 E4 A8
 :777C120 88 B9 00 0F C9 31 D0 DB 88 B9 00 0F C9 38 D0 D3
 :777C130 88 B9 00 0F C9 44 F0 04 C9 64 D0 C7 AD 40 0F 38
 :777C140 E9 04 8D 40 0F A0 00 B9 00 0F 91 FE C8 CC 40 0F
 :777C150 F0 04 C0 10 D0 F1 C0 10 B0 0C A9 00 C0 10 B0 06
 :777C160 91 FE C8 4C 5C C1 AD D4 C5 18 69 01 8D D4 C5 AD
 :777C170 D5 C5 69 00 8D D5 C5 C9 90 B0 21 A5 FE 18 69 10
 :777C180 85 FE A5 FF 69 00 85 FF AD D5 C5 D3 76 FF AD D4
 :777C190 C5 C9 01 93 6E FF 20 EF C3 4C 03 C1 A3 00 20 6C
 :777C1A0 C4 20 E4 FF D0 03 20 A6 C5 C9 11 D0 0D A2 01 A0
 :777C1B0 00 20 B3 C3 20 5B C3 4C 9E C1 C9 91 D0 0D A2 FF
 :777C1C0 A0 FF 20 B3 C3 20 5B C3 4C 9E C1 C9 1D D0 0D A2
 :777C1D0 15 A0 00 20 B3 C3 20 5B C3 4C 9E C1 C9 9D D0 0D
 :777C1E0 A2 EB A0 FF 20 B3 C3 20 5B C3 4C 9E C1 C9 30 D0
 :777C1F0 09 20 D4 C3 20 5B C3 4C 9E C1 C9 39 D0 09 20 DD

When I type this command, I see a short fractional pause (perhaps measured in a few milliseconds), and then *all* these lines appear almost instantly.

That's giving me the hint that the serial transmission speed we're using (230400bps) is reasonably fast, but there is some other factor that creates this millisecond delay prior to transmitting.

Could it perhaps be all the conversions of values into hex strings? Or could it be that the system gives the monitor a low-priority and tends to its needs once-in-a-while?

Not sure, but either way, I'm suspecting there's more to this delay than just the data-size, so the prob might not go away by simply reducing the amount of data passed across, but it might need to become a study of what the root-cause of that delay-time is prior to sending data.

Anyway, just some food for thought.

Gurce

[Paul Gardner-Stephen]

Hello,

I'd be suspecting it is the USB serial interface adding the random delay.  The VHDL implementing the serial monitor has only the transmission speed as limiting factor.  Down the track, we could look at doing some crazy stuff using the ethernet interface to improve performance, but for now, focus on getting it working, and we can then work on improving the performance in various ways.

All those other enhancements sound great -- rapidly building such a powerful and versatile development environment is going to save us all many hundreds of hours of time. I really cannot emphasise too much the value of what you are doing.

Paul.

--

[Gurce Isikyildiz]

Cheers Paul.

I'd better also take some metrics on my app's side. To help out with debugging this, I'll print out some debug timestamp output at these locations:

- upon pressing ENTER key on a command

- prior to sending out the command packet

- upon receiving the 1st byte of the result packet

- upon receiving the last byte of the result packet

- upon completion of my visual processing of the result packet

Gurce

[Paul Gardner-Stephen]

Hello,

Sure. I think you will find that there will be some quite curious quantised delays due to the USB -- but yes, do measure it so that we can figure out what is going on.

Paul.

[Gurce Isikyildiz]

Hi guys,

Ralph gave m65dbg a try recently on his mac.

He encountered an occasional seg-fault and frequent stalls/freezes.

I repaired one of the seg faults. We tried debugging the cause of the stall for him.

It was a stall in serialRead(), awaiting the results of the requested command.

I had a sneaky suspicion it might've been related to my usage of serialFlush() (perhaps the flush got delayed and it lost some of the input for the result too) so we tried commenting the tcflush call out and then things worked much better for him.

As for the backstory of why I was flushing the serial port prior to every command I sent: it was to assure there wasn't any remnant/leftover data in the buffer that could screw up the parsing of the received results.

For example, if you reset the nexys board during your debugging, the board outputs a greeting msg onto the serial port as it starts up, and that would screw up the parsing of the results of the next command you typed.

So anyway, just wanted to put it on your radars, if you experience similar stalls on your mac, try commenting tcflush out.

I'll be curious to learn who else is affected by this as I have a mac book and I'm *not* experiencing this problem with tcflush. It worked fine in winxp+cygwin too.

Oh, also Ralph mentioned he wanted to commit/push this comment-out change in, but didn't have access to do so yet.

Although part of me feels that simply commenting it out isn't a complete solution, as it means you will encounter other probs with parsing the results from your commands on some occasions.

Ah well, perhaps we can iron such things out over time, especially now that a few of you are considering to revise the serial comms packets to be more succinct.

Gurce

[Paul Gardner-Stephen]

Hello,

Bear in mind that the serial monitor interface has ZERO serial buffering.  This means that you must send each character only after waiting for the previous character to have been sent.  Otherwise, the serial monitor will lose characters.

So I would write a single byte, and then flush the file descripter, and do that repeatedly. 

The alternative is that we need to implement some serial buffer in the serial monitor, which is a noble approach.  Put an issue on the mega65-core repo, and maybe someone will have the time to implement it.

Paul.

[Ben-401]

i thought the fpga serial-monitor did have an input buffer: it has dedicated circuitry to recieve chars into a string-buffer, and processes the recieved-chars when the return-char is recieved. Or do you mean no fpga-output-buffer?

i think a possable cause of problem is when the PC issues the FPGA with two successive commands, and the fpga has not finished doing the first command, ie
i think that if the fpga recieves a command to do something with the cpu like fill memory (or something else time consuming), then the fpga-state-machine may have the potential to not recieve the start of the next command because it is busy waiting for the cpu to perform the first command.

I agree that looking into this handshaking/protocol issue is now of importance, especially if the m65dbg is issuing commands REALLY fast compared to how it has been used in the past (by typing commands).

[Gurce Isikyildiz]

Some good news, I've added a "save" command (I'll figure out 'load' later, perhaps that's not as urgent at this moment).

From from the latest m65dbg repo and rebuild to get this.

So as a test, looking back on my studies of the kernal rom-loading problems, I needed to compare "MEGA65.ROM" against $20000-->$30000 in memory.

• Inside the debugger, I do:
   
  save kernaldump.bin 20000 20000
   
• Then outside the debugger, I can do my comparison:
  
  bcompare kernaldump.bin ../sdcard/MEGA65.ROM
   
  
• I get results similar to that from this thread, with that strange chunk of altered memory:
  
  https://groups.google.com/forum/#!msg/c65gs-development/q7kCars2Xqw/a_WIWMmcAgAJ

Glad that command is out of the way! :)

Gurce

[Gurce Isikyildiz]

Oops, pardon me, I meant:

I needed to compare "MEGA65.ROM" against $20000-->$3FFFF in memory.

[Gurce Isikyildiz]

Oh, Ralph hinted at an interesting idea in our skype discussions, so thought I'd share here.

He asked whether m65dbg could write a file to the sd-card, to spare him the rigmarole of having to remove the sd-card, drop in a new file, re-insert the sd-card and restart the nexys board.

Well, presently, no... But in future, it sure sounds like that would be a great facility to have! :)

Just wondering, how feasible is something like that?

He also mentioned that Paul suggested a tool he wrote called etherload. I haven't tried it yet, although I vaguely recall reading that it uploaded directly into memory? (and not to sd-card?)

[Gurce Isikyildiz]

Also, I was pondering the 'load' command, and achieving it via the s, S, or even f raw commands, but all of them report a syntax error at present. Are they commands that used to work but broke over time?

Oh, also, I noticed today that there's a "g<addr> - Set PC" raw command, that sounds really handy. It made me wonder whether I could use that to perform a reset? Just as a short-term measure until Paul's monitor-based reset is available.

[Gurce Isikyildiz]

Aah, after reading Paul's blog post on etherload, maybe the reasoning might be getting clearer for me:

https://c65gs.blogspot.com.au/2014/11/loading-data-via-ethernet.html

Paul mentioned that these serial-monitor commands weren't so reliable, do so a lack of a buffer, and bytes were getting lost.

So perhaps these commands were switched off, and etherload used in its place?

On 11 August 2016 at 07:24, Gurce Isikyildiz <gurce.is...@gmail.com> wrote:

Also, I was pondering the 'load' command, and achieving it via the s, S, or even f raw commands, but all of them report a syntax error at present. Are they commands that used to work but broke over time?

Oh, also, I noticed today that there's a "g<addr> - Set PC" raw command, that sounds really handy. It made me wonder whether I could use that to perform a reset? Just as a short-term measure until Paul's monitor-based reset is available.

--

[Gurce Isikyildiz]

Oops, apologies for the typo, the line should read:

"due* to* a lack of a buffer, ..."

[Gurce Isikyildiz]

Okidoke, I tried the "l0000400 00007e7" command tonight, but it also resulted in a syntax error for me.

That makes me wonder if my bitstream was built from a different/older branch/commit-revision to the one you and Ben are on presently.

Taking a look now, I'm on "hyperinterruptdebug" branch.

I did a call to "git show" and it reports that I'm on this commit presently

commit d793ff9e9bded8e81f9f561877550618bdd5c461
Merge: e85c50e 8661c10
Author: Gurce Isikyildiz <gurce.is...@gmail.com>
Date:   Tue Jul 12 07:57:29 2016 +1000

    Merge branch 'hyperinterruptdebug' of https://github.com/gurcei/c65gs into hyperinterruptdebug

Any preferred branch/commit I move onto?

I probably won't jump ship straight away though, as part of me feels like I'll lose my balance if too many things change at once, and I might fare better if I stay put at this commit for a while, and just let the present knowledge solidify a bit more before moving on.

It'll just mean I'll put off the "load" command for a while, which is ok, as I'm guessing there's no pressing demand for it at this stage. I only wanted it out of curiosity, to see if I could inject the corrected rom data over the broken areas, do a soft reset and perhaps see if it worked that way. No great value in that I admit, just a short-term joy :)

Perhaps my next itch is looking like it will be to add a backtrace/up/down facility.

Gurce

On 11 August 2016 at 08:38, Paul Gardner-Stephen <pa...@servalproject.org> wrote:

Hello,

You basically just have to have all the characters arrive with ~0.3ms spacing between them, which is complicated by USB clumping them together.

There is an untested bulk memory set operation in the uart monitor, which doesn't echo back, and thus can accept characters at full rate.

It would be:  l<start_addr> <end addr (must be in the same 64KB range, i.e., only the bottom 16 bits matter!)>

After sending the CR to submit the command, you then send the upto 64KB of bytes directly.

eg:

l0000400 00007e7

<1000 bytes to write over the C64 screen RAM>

As I say, I haven't actually tested this, and there might be problems with it.

There is also an "s" command that [might] work similarly, to retrieve bytes in bulk from the machine.

Both of these should get you transfers at ~20KB/sec.

Paul.

On Thu, Aug 11, 2016 at 7:08 AM, Gurce Isikyildiz <gurce.is...@gmail.com> wrote:

Oops, apologies for the typo, the line should read:

"due* to* a lack of a buffer, ..."

--

[Paul Gardner-Stephen]

Hello,

Tim on our side I think is going to start looking at fixing the l command, and generally overhauling the interface to optimise it for work with m65dbg over time.

I agree that backtrace and up/down is much more valuable right now.

Then later we can get the auto-patch and update type stuff working, time permitting. It would certainly be cool, but I think an automatically triggered reset + reload will be a good enough work flow for now.

Paul.

[Ben-401]

the c65gs/hyperinterrupt is no longer used my me.
i have now moved to:
https://github.com/MEGA65 : which is the same toplevel repo that your m65dbg is.
https://github.com/MEGA65/mega65-core.git - grab a clone of that.
branch is master, but other branches exist, as this shows:
https://github.com/MEGA65/mega65-core/network

[Gurce Isikyildiz]

Cheers Ben, I'll move to that repo+branch at some stage, but I'll stay put in the older for now until my learning curve stabilises a bit.

Guys, more additions made for back/up/down to m65dbg app just now. I'll walk through their functionality now with my present use-case example:

• b8e35 (to set a breakpoint within the innards of a rom-loading routine)
• press restore for a few seconds to restart
• r (to list registers)

• PC   A  X  Y  Z  B  SP   MAPL MAPH LAST-OP     P  P-FLAGS   RGP uS IO
  

• 8E37 02 00 0A 00 BF BEFB 4000 3F00 69 02    24 00 ..E..I... ..P 11 R00 H-

   

  Ah great, the breakpoint triggered!
   
• type "dis" to get a disassembly (and potentially the source-listing) of the current pc:
   

  <dbg>dis
  > /home/vets/mega65/kickstart_dos.a65:1937
  > 1927:         jmp sd_readsector
  > 1928:
  > 1929: dos_file_advance_to_next_sector:
  > 1930:
  > 1931:         ; Increment file position offset by 2 pages
  > 1932:         ldx dos_current_file_descriptor_offset
  > 1933:
  > 1934:         lda dos_file_descriptors+dos_filedescriptor_offset_fileoffset+0,x
  > 1935:         clc
  > 1936:         adc #$02
  > 1937:         sta dos_file_descriptors+dos_filedescriptor_offset_fileoffset+0,x
  > 1938:         bcc dfatns1
  > 1939:         inc dos_file_descriptors+dos_filedescriptor_offset_fileoffset+1,x
  > 1940:         bne dfatns1
  > 1941:         inc dos_file_descriptors+dos_filedescriptor_offset_fileoffset+2,x
  > 1942: dfatns1:
  > 1943:
  > 1944:         ; increase sector
  > 1945:         inc dos_file_descriptors+dos_filedescriptor_offset_sectorincluster,x
  > 1946:         lda dos_file_descriptors+dos_filedescriptor_offset_sectorincluster,x
  > 1947:         ldy dos_disk_table_offset
  ---------------------------------------
  $8E37     M_nnnnX:2 9D C1 BC STA $BCC1,X

   

• Now, type "back" to get the backtrace of past jsr calls that got us to this present pc:

  #0: $8E37     M_nnnnX:2 9D C1 BC STA $BCC1,X
  #1: $8FD4      M_nnnn:2 20 2E 8E JSR $8E2E
  #2: $93B0      M_nnnn:2 20 98 8F JSR $8F98
  #3: $FFFE      M_rrrr:2 53 53 9D BVC $9D53
  #4: $00DD      M_nnrr:2 0F 02 00 BBR $02,$00E0
  #5: $CAFE      M_impl:0 00       BRK
  #6: $0014      M_impl:0 00       BRK
  #7: $FFFE      M_rrrr:2 53 53 9D BVC $9D53
  #8: $007E      M_impl:0 00       BRK

  
  Currently, I just show the raw disassembly to the right of each frame#, but in future, I can try swap this to the corresponding source-code line instead.
  
  The current-frame will be inverse-highlighted (i.e., frame#0 at present).
   

• You can then use the "down" command to move down a frame.
  - This will automatically call "dis" for you afterwards and show this output:

  <<< FRAME#: 1 >>>
  > /home/vets/mega65/kickstart_dos.a65:2223
  > 2213:         bne drfim_rr1
  > 2214:         inw <dos_file_loadaddress+1
  > 2215: drfim_rr1b:
  > 2216:         lda $df00,x
  > 2217:         nop ; 32-bit pointer access follows
  > 2218:         sta (<dos_file_loadaddress),z
  > 2219:         inz
  > 2220:         inx
  > 2221:         bne drfim_rr1b
  > 2222:
  > 2223:         jsr dos_file_advance_to_next_sector
  > 2224:         bcc drfim_eof
  > 2225:
  > 2226:         ; We only allow loading into a 16MB space
  > 2227:         ; Provided that we check the load address before starting,
  > 2228:         ; this ensures that a user-land request cannot load a huge file
  > 2229:         ; that eventually overwrites the hypervisor and results in privilege
  > 2230:         ; escalation.
  > 2231:         inw <dos_file_loadaddress+1
  > 2232:
  > 2233:         ; Increment number of sectors read (16 bit valie)
  ---------------------------------------
  $8FD4      M_nnnn:2 20 2E 8E JSR $8E2E

   

• If you type "back" (for backtrace), you'll see it again, but with frame#1 now highlighted:

  <dbg>back
  #0: $8E37     M_nnnnX:2 9D C1 BC STA $BCC1,X
  #1: $8FD4      M_nnnn:2 20 2E 8E JSR $8E2E
  #2: $93B0      M_nnnn:2 20 98 8F JSR $8F98
  #3: $FFFE      M_rrrr:2 53 53 9D BVC $9D53
  #4: $00DD      M_impl:0 00       BRK
  #5: $CAFE      M_impl:0 00       BRK
  #6: $0014      M_impl:0 00       BRK
  #7: $FFFE      M_rrrr:2 53 53 9D BVC $9D53
  #8: $007E      M_impl:0 00       BRK

   

• You can use "up" command to go back up a frame again
   
  

• Currently, the backtrace is limited to 8 frames. Hope this is sufficient for now. If not, we can increase it later.

Hope that helps some.

Gurce

[Gurce Isikyildiz]

Hi guys,

I thought I'd try make a screen-recording of me walking through the various facilities of the m65dbg tool, just to help you get up to speed with it quicker.

• https://www.youtube.com/watch?v=2VT8yB3odhg

Apologies for the video/audio lag. I tried using CamStudio on this occason, but if anyone suggests a better tool, I'd be happy to hear it.

Gurce

[Ben-401]

Hi Gurce,

Great video - well done. It was a little slow for my liking but great for those needing the explanations.

I am just making use of your v1.0 now, here are some comments:

- change the version number

- if the program cant open the serial-port, it should report what it tried (as it does now), but then exit, not remain in the program.
also could instead report "set port with "-d /dev/ttyS3" for example.
$ ./m65dbg.exe
m65dbg - v1.00
======
error 6 opening /dev/ttyS4: No such device or address
- Type 'help' for new commands, '?'/'h' for raw commands.
<dbg>help

- its good that when it first enters the program, it prints the help line, but "?" and "h" dont seem to do anything. And what are 'raw-commands'?

- can you make the "<dbg>" prompt bold to help show where the last command was opposed to text output.....

[Gurce Isikyildiz]

Hi Ben,

Thanks for the feedback. I pondered your points below :)

> It was a little slow for my liking but great for those needing the explanations.

That's fair enough, I was hoping that my laid-back, meandering pace was 'tolerable' for savvy linux users and appreciated by not-so-savvy-linuxy users. I suppose it reflects my own personal nature too, and my affection towards the c64. I feel the machine has a strong connection to our youth/childhood for many of us, which was (hopefully!) an era of our lives when things were fun, warm, fuzzy and happy, so I tried to imbue some of that flavour into the video via my style, like a child figuring out this universe and enjoying the journey as they go :)

> change the version number

Sure, it's a worthwhile thing to do, agreed. I'm taking a bit of a breather from the tooling side of things though, and might just do incremental bug hunting as my time permits, but please feel free to improve on the m65dbg code as the community sees fit.

> - if the program cant open the serial-port, it should report what it tried (as it does now), but then exit, not remain in the program.
> also could instead report "set port with "-d /dev/ttyS3" for example.

Those ideas sound fine to me too, and you/others are welcome to add such finesse into the app. Just for some of my back-story on this sort of thing, at the time, I concede that I was aware of such limitations, but just endured them so that I could get a reasonably nice debugger up and running in a reasonably short timeframe so that I could then quickly switch my focus to bug-hunting.

Ie. my main motivator for building the tool was to help me hunt down the bug. So I found myself in an awkward (but familiar) position of finding that the tooling work was both helping me (find the bug) and distracting me (taking time away from finding the bug). So it felt like a delicate juggling act on how much time I should allocate to one over the other.

These days, I feel like the tool has evolved to such a level that the pendulum in my brain has swung in the other direction, and that I should now do more bug hunting than tooling, so I'll probably head in that direction next.

Again, this is probably too much detail, but please forgive me. On occasion, it's my nature to be somewhat verbose in explaining not just what I do, but some of the 'why' behind it :)

> - its good that when it first enters the program, it prints the help line, but "?" and "h" dont seem to do anything. And what are 'raw-commands'?

Ah yes, the "?" and "h" commands are what I'd consider raw commands, whereas "help" is one of the "new" commands. I'll explain my terminology:

I consider the 'raw' commands to be the ones provided by the serial monitor residing in the vhdl code.

I consider the 'new' commands to be the newer ones provided by the m65dbg tool.

I suppose I picked a term like "raw" over "old" because for some people, "old" equates to bad, so I thought that "raw" would sound more palatable and, erm, trendy ;)

So the likely reason for "?" and "h" commands not providing any info is probably due to the nexys board being off, or perhaps the specified --device setting was incorrect. Like you suggested, it's probably best to not let the app run if the serial-port was unable to be opened, hence preventing this scenario too.

> - can you make the "<dbg>" prompt bold to help show where the last command was opposed to text output.....

Hmm, personally, I didn't have too much problems picking out the "<dbg>" location of the last command, perhaps my eyes have been conditioned into spotting such things due to past experiences with gdb (which I 'loosely' based the look and feel of m65dbg from). That being said, if you think it will help you, sure, add it in. Part of me feels though that others in the community might have different preferences in regards to this sort of presentation finesse. Personally, for me, making something bold signifies 'importance', so I find it's use a little out of place for use with the "<dbg>" prompt. But anyway, give it a try, if others in the community don't mind it, I guess we're ok then.

Gurce

[Ben-401]

> It was a little slow for my liking but great for those needing the explanations.

That's fair enough, I was hoping that my laid-back, meandering pace was 'tolerable' for savvy linux users and appreciated by not-so-savvy-linuxy users. I suppose it reflects my own personal nature too, and my affection towards the c64. I feel the machine has a strong connection to our youth/childhood for many of us, which was (hopefully!) an era of our lives when things were fun, warm, fuzzy and happy, so I tried to imbue some of that flavour into the video via my style, like a child figuring out this universe and enjoying the journey as they go :)

You are so correct, thanks for your thoughts, we are alike, sometimes I am just a little inpatient -- hehe

 

> change the version number

Sure, it's a worthwhile thing to do, agreed. I'm taking a bit of a breather from the tooling side of things though, and might just do incremental bug hunting as my time permits, but please feel free to improve on the m65dbg code as the community sees fit.

Thankyou for:
- the go-ahead to continue with development on m65dbg, and
- to getting the m65dbg it where it currently is.
It really adds to our ability to understand what is going on inside. I understand Tim is almost in a position to make changes to the VHDL to improve the communication-efficiency. With this go-ahead, I will introduce him to the code and maybe get him updating both "m65dbg" and "serial-uart" in parallel.

so that I could get a reasonably nice debugger up and running in a reasonably short timeframe so that I could then quickly switch my focus to bug-hunting.

Yes, short-timeframe, the world needs more people like you
 

I consider the 'raw' commands to be the ones provided by the serial monitor residing in the vhdl code.

I consider the 'new' commands to be the newer ones provided by the m65dbg tool.

I can see clearly now. And yes, I didnt have a board connected <shame-on-me>.
 

> - can you make the "<dbg>" prompt bold to help show where the last command was opposed to text output.....

That being said, if you think it will help you, sure, add it in.

Gurce

 
Probably one of the first things I do is something with the prompt. <grin>

[Gurce Isikyildiz]

Thanks for your kind feedback Ben :) And all the best to you and Tim with your planned refinements to the serial comms.

I consider the 'raw' commands to be the ones provided by the serial monitor residing in the vhdl code.

I consider the 'new' commands to be the newer ones provided by the m65dbg tool.

> I can see clearly now. And yes, I didnt have a board connected <shame-on-me>.

Hehe, no probs. Come to think of it, now that I'm on the newer bit-streams, the 'h' and '?' prompt no longer provide a verbose response from the hardware listing all available commands, but it simply now says:

MEGA65 Serial Monitor
build develo,2c86a60+DIRTY,0820_0742
--------------------------------
See source code for help.

I guess it was removed to save some space and/or because some threads mentioned that the commands listed in there were out-of-date? Anyway, maybe these raw commands could be documented/listed within the m65dbg app instead now, perhaps via typing something like "help raw"? Just a thought, I'm open to alternatives.

Gurce