build errors
114 views
Skip to first unread message
Gurce Isikyildiz
Jul 9, 2016, 12:01:08 PM7/9/16
to C65GS Development
Hi guys,
I was starting to feel like I should move my incremental build-error experiences into google-groups, as it seemed like the forum-site is more of an "end-user" audience and this group seems to be more of a "dev" audience.
Here's what I had so far, I'll just link it in, to assist with continuity.
http://mega65.net/build-errors
Apologies if it comes across as too much detail, but I hope I can assure you that it is with good intent.
Mainly, I tend to work in a way that assumes that any mistake or error I bump into on this journey, the next person that follows this path will also bump into. So if I jot down info on errors encountered and how they were resolved now, then there's a better chance that next person will google that error and might get some value out of some insights I jot down here (and hopefully figure things out quicker than me! :D).
There's also a hope that if I jot it down here, other devs might be familiar with the issue I'm up against and throw a suggestion or two my way once in a while. But not to worry if you're busy, I can plod along at my own pedestrian pace and hopefully figure things out eventually too :)
Regards,
Gurce
I was starting to feel like I should move my incremental build-error experiences into google-groups, as it seemed like the forum-site is more of an "end-user" audience and this group seems to be more of a "dev" audience.
Here's what I had so far, I'll just link it in, to assist with continuity.
http://mega65.net/build-errors
Apologies if it comes across as too much detail, but I hope I can assure you that it is with good intent.
Mainly, I tend to work in a way that assumes that any mistake or error I bump into on this journey, the next person that follows this path will also bump into. So if I jot down info on errors encountered and how they were resolved now, then there's a better chance that next person will google that error and might get some value out of some insights I jot down here (and hopefully figure things out quicker than me! :D).
There's also a hope that if I jot it down here, other devs might be familiar with the issue I'm up against and throw a suggestion or two my way once in a while. But not to worry if you're busy, I can plod along at my own pedestrian pace and hopefully figure things out eventually too :)
Regards,
Gurce
Gurce Isikyildiz
Jul 11, 2016, 6:06:18 AM7/11/16
to C65GS Development
Here's the response from Paul:
Hello,
Work from the hypervisorinterruptdebug branch, as it is the current head of development activity.
I have pushed a fix to the to_hstring() routine from my newcpu repository that fixes the underlying possibility of this problem.
Let me know how you go.
Gurce Isikyildiz
Jul 11, 2016, 8:41:19 AM7/11/16
to C65GS Development
Hi Paul,
Here's progress on this:
Here's progress on this:
- I did "git checkout hyperinterruptdebug" to jump to the desired branch
- Running "make", I encountered this prob:
kickstart.a65:2498: Could not read diskmenu_c000.bin 1 error make: *** [Makefile:48: kickstart65gs.bin] Error 1
I resolved it by editing the "Makefile" and adding the following dependency:# diskmenu_c000.bin yet b0rken kickstart65gs.bin: $(KICKSTARTSRCS) Makefile diskchooser version.a65 diskmenu_c000.bin ../Ophis/bin/ophis -4 kickstart.a65 -l kickstart.list
- Running "make" progressed a bit further, then died with:
../Ophis/bin/ophis -4 diskmenuc000.a65 -l diskmenuc000.list diskmenuc000.a65:19: Unmatched .scope
To fix this, I edited "diskmenuc000.a65" and added the .scend line, as follows:.org $c000 .scope .include "diskmenu.a65" .scend
- After these tweaks, "make" ran fine for me
- Next up, I tried "make simulate", which got me:
make: *** No rule to make target 'ghdl_ram8x32k.vhdl', needed by 'simulate'. Stop.
I encountered this prob before, so recycled my solution from last time:
git show 0dc967bfbe73017db71d0a1f6399710fe0bed8e8:ghdl_ram8x64k.vhdl > ghdl_ram8x32k.vhdl
sed -i ghdl_ram8x32k.vhdl -e "s/ram8x64k/ram8x32k/g"
- Now running "make simulate" get me the "cpu_test.exe"
- I then did "./cpu_test 2> err.log" and assessed the output after it died. It seemed to die at the same point I experienced in my older era of the repo:
debugtools.vhdl:26:9:@183100ns:(assertion error): HWRITE Error: Trying to read vector with an odd (non multiple of 4) length ./cpu_test:error: NULL access dereferenced ./cpu_test:error: simulation failed
So unfortunately, still experiencing this prob on the latest code on hyperinterruptdebug branch.
Gurce
PS. If the tweaks/workarounds are worth preserving (do others experience similar probs?), then should I try commit these changes to the github repo? If the probs are unique to me and my cygwin setup, I can hold back.
Gurce Isikyildiz
Jul 11, 2016, 8:56:42 AM7/11/16
to C65GS Development
Oh, re-reading my own summary of approach before, I noticed an aspect that might be the cause of this... Perhaps it relates to my workaround of creating a "ghdl_ram8x32k.vhdl" file.
It came to mind, because I recall the ghdl backtrace upon the assert error looked something like this:
#1 work__debugtools__hwrite at debugtools.vhdl:26
#2 work__debugtools__to_hstringO1 at debugtools.vhdl:72
#3 work__debugtools__to_hstringO2 at debugtools.vhdl:80
#4 work__ram8x32k__ARCH__behavioural__P0__PROC at ghdl_ram8x32k.vhdl:48
Ie, it died on the newly generated file I created for the workaround. Hmm, not sure what to make of that as yet, but just thought I'd raise it, in-case it rings any alarm bells for you :)
It came to mind, because I recall the ghdl backtrace upon the assert error looked something like this:
#1 work__debugtools__hwrite at debugtools.vhdl:26
#2 work__debugtools__to_hstringO1 at debugtools.vhdl:72
#3 work__debugtools__to_hstringO2 at debugtools.vhdl:80
#4 work__ram8x32k__ARCH__behavioural__P0__PROC at ghdl_ram8x32k.vhdl:48
Ie, it died on the newly generated file I created for the workaround. Hmm, not sure what to make of that as yet, but just thought I'd raise it, in-case it rings any alarm bells for you :)
Gurce Isikyildiz
Jul 11, 2016, 6:47:19 PM7/11/16
to C65GS Development
This from Paul:
No probs Paul if you're busy. I'm happy to dig away at it slowly and nut things out that way, and I'm content with the occasional prod in the right direction ;)
I've braved the github learning curve this morning and tried a pull request for my first time, let's see how it goes.
I'll try investigate debugtools.vhdl further this evening.
Gurce
Hello,
Do send through a git pull for your changes.
Also, check that the debugtools.vhdl can handle any width string in to_hstring() -- a simple test rig can verify this.
I'm still in Samoa at a conference, so unfortunately don't have a lot of time to explore the problems myself.
I've braved the github learning curve this morning and tried a pull request for my first time, let's see how it goes.
I'll try investigate debugtools.vhdl further this evening.
Gurce
Gurce Isikyildiz
Jul 12, 2016, 9:01:40 AM7/12/16
to C65GS Development
After doing a I haven't been able to replicate that assert error anymore on the "hyperinterruptdebug" branch.
Not sure why, I'm pretty sure I called "make simulate" again on the new branch to generate the cpu_test.exe file... But perhaps it kept remnants of the old compilation... I suspect after doing a "ghdl --remove" then followed by a "make simulate", it definitely built everything from scratch and I no longer experienced that error ((assertion error): HWRITE Error: Trying to read vector with an odd (non multiple of 4) length).
Hmm, moving on then, I thought I'd study the "cpu_test 2>&1 | grep MAP" output further, it got up to this point and seemed to stall:
91012:gs4510.vhdl:1201:9:@19860ns:(report note): $9968 8D 05 D7 sta $D705
91641:gs4510.vhdl:1201:9:@20020ns:(report note): $996B A9 00 lda #$00
92727:gs4510.vhdl:1201:9:@20300ns:(report note): $996D 8D 06 D7 sta $D706
93355:gs4510.vhdl:1201:9:@20460ns:(report note): $9970 A9 9A lda #$9A
94435:gs4510.vhdl:1201:9:@20740ns:(report note): $9972 8D 01 D7 sta $D701
95059:gs4510.vhdl:1201:9:@20900ns:(report note): $9975 A9 2D lda #$2D
It stalled here for 4 minutes, then came back to life with a few more instructions run:
1808656:gs4510.vhdl:1201:9:@428020ns:(report note): $9977 8D 00 D7 sta $D700
1809280:gs4510.vhdl:1201:9:@428180ns:(report note): $997A A9 FF lda #$FF
1810372:gs4510.vhdl:1201:9:@428460ns:(report note): $997C 8D 04 D7 sta $D704
1811464:gs4510.vhdl:1201:9:@428740ns:(report note): $997F 8D 05 D7 sta $D705
1812091:gs4510.vhdl:1201:9:@428900ns:(report note): $9982 A9 00 lda #$00
1813175:gs4510.vhdl:1201:9:@429180ns:(report note): $9984 8D 06 D7 sta $D706
1813801:gs4510.vhdl:1201:9:@429340ns:(report note): $9987 A9 9A lda #$9A
1814888:gs4510.vhdl:1201:9:@429620ns:(report note): $9989 8D 01 D7 sta $D701
1815516:gs4510.vhdl:1201:9:@429780ns:(report note): $998C A9 4E lda #$4E
Then it stalled here for another 5 minutes, but then a fairly steady stream of instructions were run:
3835883:gs4510.vhdl:1201:9:@922860ns:(report note): $998E 8D 00 D7 sta $D700
3836487:gs4510.vhdl:1201:9:@923020ns:(report note): $9991 A9 00 lda #$00
3837539:gs4510.vhdl:1201:9:@923300ns:(report note): $9993 8D 05 D7 sta $D705
3838147:gs4510.vhdl:1201:9:@923460ns:(report note): $9996 A9 01 lda #$01
3840137:gs4510.vhdl:1201:9:@923980ns:(report note): $9998 1C 30 D0 trb $D030
3840741:gs4510.vhdl:1201:9:@924140ns:(report note): $999B A9 08 lda #$08
3841790:gs4510.vhdl:1201:9:@924420ns:(report note): $999D 8D 01 CE sta $CE01
3842389:gs4510.vhdl:1201:9:@924580ns:(report note): $99A0 A2 00 ldx #$00
...etc...
Ok, so I guess ghdl simulation is finally working reasonably fine for me. But are those two stall moments normal? Other people experience this too? Perhaps due to me being on a winxp vbox, performance isn't so great. I wonder if simulation would be faster on a higher-spec pc (and the stalls less of a prob).
Anyway, still, it's progress :)
Not sure why, I'm pretty sure I called "make simulate" again on the new branch to generate the cpu_test.exe file... But perhaps it kept remnants of the old compilation... I suspect after doing a "ghdl --remove" then followed by a "make simulate", it definitely built everything from scratch and I no longer experienced that error ((assertion error): HWRITE Error: Trying to read vector with an odd (non multiple of 4) length).
Hmm, moving on then, I thought I'd study the "cpu_test 2>&1 | grep MAP" output further, it got up to this point and seemed to stall:
91012:gs4510.vhdl:1201:9:@19860ns:(report note): $9968 8D 05 D7 sta $D705
91641:gs4510.vhdl:1201:9:@20020ns:(report note): $996B A9 00 lda #$00
92727:gs4510.vhdl:1201:9:@20300ns:(report note): $996D 8D 06 D7 sta $D706
93355:gs4510.vhdl:1201:9:@20460ns:(report note): $9970 A9 9A lda #$9A
94435:gs4510.vhdl:1201:9:@20740ns:(report note): $9972 8D 01 D7 sta $D701
95059:gs4510.vhdl:1201:9:@20900ns:(report note): $9975 A9 2D lda #$2D
It stalled here for 4 minutes, then came back to life with a few more instructions run:
1808656:gs4510.vhdl:1201:9:@428020ns:(report note): $9977 8D 00 D7 sta $D700
1809280:gs4510.vhdl:1201:9:@428180ns:(report note): $997A A9 FF lda #$FF
1810372:gs4510.vhdl:1201:9:@428460ns:(report note): $997C 8D 04 D7 sta $D704
1811464:gs4510.vhdl:1201:9:@428740ns:(report note): $997F 8D 05 D7 sta $D705
1812091:gs4510.vhdl:1201:9:@428900ns:(report note): $9982 A9 00 lda #$00
1813175:gs4510.vhdl:1201:9:@429180ns:(report note): $9984 8D 06 D7 sta $D706
1813801:gs4510.vhdl:1201:9:@429340ns:(report note): $9987 A9 9A lda #$9A
1814888:gs4510.vhdl:1201:9:@429620ns:(report note): $9989 8D 01 D7 sta $D701
1815516:gs4510.vhdl:1201:9:@429780ns:(report note): $998C A9 4E lda #$4E
Then it stalled here for another 5 minutes, but then a fairly steady stream of instructions were run:
3835883:gs4510.vhdl:1201:9:@922860ns:(report note): $998E 8D 00 D7 sta $D700
3836487:gs4510.vhdl:1201:9:@923020ns:(report note): $9991 A9 00 lda #$00
3837539:gs4510.vhdl:1201:9:@923300ns:(report note): $9993 8D 05 D7 sta $D705
3838147:gs4510.vhdl:1201:9:@923460ns:(report note): $9996 A9 01 lda #$01
3840137:gs4510.vhdl:1201:9:@923980ns:(report note): $9998 1C 30 D0 trb $D030
3840741:gs4510.vhdl:1201:9:@924140ns:(report note): $999B A9 08 lda #$08
3841790:gs4510.vhdl:1201:9:@924420ns:(report note): $999D 8D 01 CE sta $CE01
3842389:gs4510.vhdl:1201:9:@924580ns:(report note): $99A0 A2 00 ldx #$00
...etc...
Ok, so I guess ghdl simulation is finally working reasonably fine for me. But are those two stall moments normal? Other people experience this too? Perhaps due to me being on a winxp vbox, performance isn't so great. I wonder if simulation would be faster on a higher-spec pc (and the stalls less of a prob).
Anyway, still, it's progress :)
Gurce Isikyildiz
Jul 12, 2016, 6:03:01 PM7/12/16
to C65GS Development
Paul's reply and my follow-up q's below:
Ah fair enough, I checked my macbook's specs, 2.5GHz - i5 from 2012 era, so I'll give it a try on an i7 soon and see how it goes.
Your mention of address $D700 for DMA made me want to get more familiar with the io mapping addresses. I recall in a past forum post, you suggested getting this info from:
https://github.com/gardners/c65gs/blob/master/iomap.txt
I had a look here and only saw a mention DMA registers at $D653-->D658. Or is perhaps this file outdated and those were addresses used in an older era of the project?
I thought I'd take a look at Ben-401's github repo fork, dockit branch, to see if there was a newer version there, but couldn't find the "iomap.txt" file there at all.
After sniffing through his commit history, I saw it got deleted with the comment:
deleted "iomap.txt" because it is generated
to compile in "diskmenu.a65" commented-out ".scope"
...
Aah, okidoke, so I guess my next step will be to build the bitstream and hopefully get this "iomap.txt" file back, and I guess that'll show the newer location of the DMA registers?
Oh, just another q on the ghdl output, after a while of running the cpu_test simulation, I noticed the output was starting to repeat over and over again. Not sure if this was normal, so thought I'd copy/paste the output here:
13185196:gs4510.vhdl:1201:9:@3268260ns:(report note): $961D CE 20 D0 dec $D020 A:00 X:00 Y:15 Z:00 SP:BEF9 P:27 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.IZC H 110 48MHz
13187321:gs4510.vhdl:1201:9:@3268740ns:(report note): $9620 EE 00 03 inc $0300 A:00 X:00 Y:15 Z:00 SP:BEF9 P:25 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.I.C H 110 48MHz
13188741:gs4510.vhdl:1201:9:@3269060ns:(report note): $9623 D0 F2 bne $9617 A:00 X:00 Y:15 Z:00 SP:BEF9 P:25 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.I.C H 110 48MHz
13191065:gs4510.vhdl:1201:9:@3269580ns:(report note): $9617 EE 20 D0 inc $D020 A:00 X:00 Y:15 Z:00 SP:BEF9 P:25 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.I.C H 110 48MHz
13192483:gs4510.vhdl:1201:9:@3269900ns:(report note): $961A 20 46 9C jsr $9C46 A:00 X:00 Y:15 Z:00 SP:BEF7 P:25 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.I.C H 110 48MHz
13194265:gs4510.vhdl:1201:9:@3270300ns:(report note): $9C46 AD F1 D6 lda $D6F1 A:00 X:00 Y:15 Z:00 SP:BEF7 P:27 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.IZC H 110 48MHz
13194979:gs4510.vhdl:1201:9:@3270460ns:(report note): $9C49 29 01 and #$01 A:00 X:00 Y:15 Z:00 SP:BEF7 P:27 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.IZC H 110 48MHz
13195688:gs4510.vhdl:1201:9:@3270620ns:(report note): $9C4B D0 01 bne $9C4E A:00 X:00 Y:15 Z:00 SP:BEF7 P:27 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.IZC H 110 48MHz
13197457:gs4510.vhdl:1201:9:@3271020ns:(report note): $9C4D 60 rts A:00 X:00 Y:15 Z:00 SP:BEF9 P:27 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.IZC H 110 48MHz
13199884:gs4510.vhdl:1201:9:@3271540ns:(report note): $961D CE 20 D0 dec $D020 A:00 X:00 Y:15 Z:00 SP:BEF9 P:27 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.IZC H 110 48MHz
13202348:gs4510.vhdl:1201:9:@3272020ns:(report note): $9620 EE 00 03 inc $0300 A:00 X:00 Y:15 Z:00 SP:BEF9 P:25 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.I.C H 110 48MHz
13203975:gs4510.vhdl:1201:9:@3272340ns:(report note): $9623 D0 F2 bne $9617 A:00 X:00 Y:15 Z:00 SP:BEF9 P:25 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.I.C H 110 48MHz
13206083:gs4510.vhdl:1201:9:@3272860ns:(report note): $9617 EE 20 D0 inc $D020 A:00 X:00 Y:15 Z:00 SP:BEF9 P:25 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.I.C H 110 48MHz
13207340:gs4510.vhdl:1201:9:@3273180ns:(report note): $961A 20 46 9C jsr $9C46 A:00 X:00 Y:15 Z:00 SP:BEF7 P:25 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.I.C H 110 48MHz
13208914:gs4510.vhdl:1201:9:@3273580ns:(report note): $9C46 AD F1 D6 lda $D6F1 A:00 X:00 Y:15 Z:00 SP:BEF7 P:27 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.IZC H 110 48MHz
13209552:gs4510.vhdl:1201:9:@3273740ns:(report note): $9C49 29 01 and #$01 A:00 X:00 Y:15 Z:00 SP:BEF7 P:27 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.IZC H 110 48MHz
13210187:gs4510.vhdl:1201:9:@3273900ns:(report note): $9C4B D0 01 bne $9C4E A:00 X:00 Y:15 Z:00 SP:BEF7 P:27 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.IZC H 110 48MHz
13211764:gs4510.vhdl:1201:9:@3274300ns:(report note): $9C4D 60 rts A:00 X:00 Y:15 Z:00 SP:BEF9 P:27 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.IZC H 110 48MHz
Hmm, in the iomap.txt, I see that:
GS $D6F1 - Read FPGA switches 8-15
Is it an endless loop waiting for an fpga switch?
Hello,
Glad to hear it is proceeding.
The pauses between instructions is because the CPU is doing a DMA job then, as revealed by the write to $D700.
Not
sure what you can do to improve performance. Obviously a faster CPU
will help. In particular, a CPU with an on-board memory controller, so
that you have lower memory access latency will likely help, e.g., an
Intel i7 instead of i5 or i3. All the AMD CPUs have had on-board memory
controllers for a while now.
Ah fair enough, I checked my macbook's specs, 2.5GHz - i5 from 2012 era, so I'll give it a try on an i7 soon and see how it goes.
Your mention of address $D700 for DMA made me want to get more familiar with the io mapping addresses. I recall in a past forum post, you suggested getting this info from:
https://github.com/gardners/c65gs/blob/master/iomap.txt
I had a look here and only saw a mention DMA registers at $D653-->D658. Or is perhaps this file outdated and those were addresses used in an older era of the project?
I thought I'd take a look at Ben-401's github repo fork, dockit branch, to see if there was a newer version there, but couldn't find the "iomap.txt" file there at all.
After sniffing through his commit history, I saw it got deleted with the comment:
commit f5f87fbf42e23a26c9119e4a1c680ac06212806d
Author: Ben-401 <-------@flinders.edu.au>
Date: Thu May 12 15:45:57 2016 +0930
deleted "iomap.txt" because it is generated
to compile in "diskmenu.a65" commented-out ".scope"
...
Aah, okidoke, so I guess my next step will be to build the bitstream and hopefully get this "iomap.txt" file back, and I guess that'll show the newer location of the DMA registers?
Oh, just another q on the ghdl output, after a while of running the cpu_test simulation, I noticed the output was starting to repeat over and over again. Not sure if this was normal, so thought I'd copy/paste the output here:
13185196:gs4510.vhdl:1201:9:@3268260ns:(report note): $961D CE 20 D0 dec $D020 A:00 X:00 Y:15 Z:00 SP:BEF9 P:27 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.IZC H 110 48MHz
13187321:gs4510.vhdl:1201:9:@3268740ns:(report note): $9620 EE 00 03 inc $0300 A:00 X:00 Y:15 Z:00 SP:BEF9 P:25 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.I.C H 110 48MHz
13188741:gs4510.vhdl:1201:9:@3269060ns:(report note): $9623 D0 F2 bne $9617 A:00 X:00 Y:15 Z:00 SP:BEF9 P:25 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.I.C H 110 48MHz
13191065:gs4510.vhdl:1201:9:@3269580ns:(report note): $9617 EE 20 D0 inc $D020 A:00 X:00 Y:15 Z:00 SP:BEF9 P:25 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.I.C H 110 48MHz
13192483:gs4510.vhdl:1201:9:@3269900ns:(report note): $961A 20 46 9C jsr $9C46 A:00 X:00 Y:15 Z:00 SP:BEF7 P:25 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.I.C H 110 48MHz
13194265:gs4510.vhdl:1201:9:@3270300ns:(report note): $9C46 AD F1 D6 lda $D6F1 A:00 X:00 Y:15 Z:00 SP:BEF7 P:27 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.IZC H 110 48MHz
13194979:gs4510.vhdl:1201:9:@3270460ns:(report note): $9C49 29 01 and #$01 A:00 X:00 Y:15 Z:00 SP:BEF7 P:27 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.IZC H 110 48MHz
13195688:gs4510.vhdl:1201:9:@3270620ns:(report note): $9C4B D0 01 bne $9C4E A:00 X:00 Y:15 Z:00 SP:BEF7 P:27 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.IZC H 110 48MHz
13197457:gs4510.vhdl:1201:9:@3271020ns:(report note): $9C4D 60 rts A:00 X:00 Y:15 Z:00 SP:BEF9 P:27 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.IZC H 110 48MHz
13199884:gs4510.vhdl:1201:9:@3271540ns:(report note): $961D CE 20 D0 dec $D020 A:00 X:00 Y:15 Z:00 SP:BEF9 P:27 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.IZC H 110 48MHz
13202348:gs4510.vhdl:1201:9:@3272020ns:(report note): $9620 EE 00 03 inc $0300 A:00 X:00 Y:15 Z:00 SP:BEF9 P:25 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.I.C H 110 48MHz
13203975:gs4510.vhdl:1201:9:@3272340ns:(report note): $9623 D0 F2 bne $9617 A:00 X:00 Y:15 Z:00 SP:BEF9 P:25 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.I.C H 110 48MHz
13206083:gs4510.vhdl:1201:9:@3272860ns:(report note): $9617 EE 20 D0 inc $D020 A:00 X:00 Y:15 Z:00 SP:BEF9 P:25 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.I.C H 110 48MHz
13207340:gs4510.vhdl:1201:9:@3273180ns:(report note): $961A 20 46 9C jsr $9C46 A:00 X:00 Y:15 Z:00 SP:BEF7 P:25 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.I.C H 110 48MHz
13208914:gs4510.vhdl:1201:9:@3273580ns:(report note): $9C46 AD F1 D6 lda $D6F1 A:00 X:00 Y:15 Z:00 SP:BEF7 P:27 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.IZC H 110 48MHz
13209552:gs4510.vhdl:1201:9:@3273740ns:(report note): $9C49 29 01 and #$01 A:00 X:00 Y:15 Z:00 SP:BEF7 P:27 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.IZC H 110 48MHz
13210187:gs4510.vhdl:1201:9:@3273900ns:(report note): $9C4B D0 01 bne $9C4E A:00 X:00 Y:15 Z:00 SP:BEF7 P:27 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.IZC H 110 48MHz
13211764:gs4510.vhdl:1201:9:@3274300ns:(report note): $9C4D 60 rts A:00 X:00 Y:15 Z:00 SP:BEF9 P:27 $01=F5 MAPLO:4000 MAPHI:3F00 ..E-.IZC H 110 48MHz
Hmm, in the iomap.txt, I see that:
GS $D6F1 - Read FPGA switches 8-15
Is it an endless loop waiting for an fpga switch?
Paul Gardner-Stephen
Jul 12, 2016, 6:52:55 PM7/12/16
to Gurce Isikyildiz, C65GS Development
Hello,
Yes, it is probably waiting for an FPGA switch. You can make the cpu_test test harness default to different values on those inputs. To be honest, I never ran the simulation that long.
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-developm...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Gurce Isikyildiz
Jul 13, 2016, 9:38:17 AM7/13/16
to C65GS Development, gurce.is...@gmail.com, pa...@servalproject.org
Hi Paul,
> Yes, it is probably waiting for an FPGA switch. You can make the cpu_test test harness default to different values on those inputs. To be honest, I never ran the simulation that long.
Alrighty, I'll give that a try in a future attempt at ghdl. No worries, at the time, I was just curious about what the ghdl simulation stuff looked like (and getting it to work in windows-cygwin), and I guess my curiosity is mostly satisfied with it now :)
I thought I'd try brave my first attempt at building/synthesising a bitstream tonight, following Ben-401's handy steps here:
https://github.com/Ben-401/c65gs/blob/dockit/doc/build.md
Here's a summary of how it went:
- I tried building the latest code in the "hyperinterruptdebug" branch via ISE.
- It took about 2 hours and I got my resulting "container.bit" file
- I took the precaution to reformat the sd-card and copied across the "container.bit" file first
- I copied all other items, as specified in Ralph's wikified docs here:
- http://gurce.net/mega65/doku.php?id=mega65_prerelease_starter_s_manual#preparing_a_sd_micro_card - When I boot up the nexys board, I saw the following kickstart messages appear:
MEGA65 KICKSTART V00.04 GIT COMMIT: D793FF9E9BDED8E*+DIRTY LOOKING FOR SDCARD... FOUND AND RESET SDCARD MOUNTED 01 PARTITIONS RUNNING KICKED HYPERVISOR MEGA65.D81 SUCCESSFULLY MOUNTED ROM CHECKSUM FAIL - LOADING ROM LOADED CHARROM.M65 (0010 PAGES)Hmm, that "checksum fail" line looks worrying...
I then see the c65 startup screen, but it jumps to the monitor straight away. If I try exit, it just returns to the monitor again
- I was able to boot into c64-mode by holding down the commodore/ctrl key and warm-resetting
- I tried running SYS49152 for the d81 selector app, and it reported the following:
No reply from Hypervisor - not a MEGA65?
- I tried doing a LOAD"$",8 and LIST, but the result is just:
0 "
Hmm... That doesn't look good
- I tried running SYS58552 to return to c65 mode, and I again saw the startup screen followed by the jump into the monitor again...
Ah well, it's my first time doing this bitstream stuff, so perhaps I've screwed up somewhere. I kinda thought I did everything right with the sc-card preparations, but who knows, maybe I overlooked something there too. I'll look over it all with fresher eyes tomorrow.
Oh, I also took a look at the auto-generated "iomap.txt" file, it still didn't make a mention of the $D700 for dma. There's probably some internals I need to grasp to figure out why on that one. No worries, a step at a time.
Gurce
Gurce Isikyildiz
Jul 13, 2016, 5:18:55 PM7/13/16
to C65GS Development, gurce.is...@gmail.com, pa...@servalproject.org
Paul's response and my response below:
Ok, I'll put my hand up to investigate the VFAT bug :D I've started my reading up on it, might take a while to sink in, but I'll narrow my focus onto this and try nut it out.
Gurce
Hello,
Well done! You have almost everything working correctly.
The break to monitor thing is, if I remember correctly, a result of a subtle bug in the VFAT driver in the Hypervisor. If you look through $20000 - $3FFFF using the serial monitor interface, i.e., connecting to the 2nd serial port that the USB cable to the NExys4 purports to provide at 230400bps, you will see a simple debug/control interface for the MEGA65 that is VERY useful. Check all memory in that 128KB range, and you will probably find that there is a blank 8KB section or two -- this is a sign that the bug has happened. Solution: Delete the ROM file from the SD card. Copy some arbitrary file of at least 128KB on, then copy the ROM back on. Rinse repeat, until it works. The bug is a mis-calculation in sector numbers from cluster numbers in the VFAT code. You are welcome to debug that and fix the problem at your leisure! ;)
In kickstart.a65 you can tell it to include diskchooser instead of diskmenu. That will get you a more useful SYS49152 function, until such time as Ben and I debug the Hypervisor trap bug that is causing diskmenu to fail to detect that it is on a MEGA65 (it uses a Hypervisor trap to do so).
We can try to track down the absence of $D700 from the IOMAP.TXT file. You could search for it in the VHDL files directly as well (this is how IOMAP.TXT gets generated). It is probably just missing the @:65 or similar prefix in the comment that is used to tell the generator script which comments are IO location documentation.
Paul.
Ok, I'll put my hand up to investigate the VFAT bug :D I've started my reading up on it, might take a while to sink in, but I'll narrow my focus onto this and try nut it out.
Gurce
Gurce Isikyildiz
Jul 23, 2016, 9:37:41 AM7/23/16
to C65GS Development, gurce.is...@gmail.com, pa...@servalproject.org
Just thought I'd touch base with how things are faring with my vfat studies. No great findings as yet, just initial learning curve underway.
I've been nibbling away at reading through topics such as MBRs, VBRs and FAT throughout the week. I made a new drive for my winxp vbox and tried adding a few FAT partitions to it and studied the dd output of the MBR/FAT details, just to help get acquainted.
Today, I extracted out the equivalent contents of the sd-card via dd on my macbook's terminal and am getting acquainted with the field contents there.
I've never really focused on FAT to this detail before, but I'll keep plugging away at it incrementally until hopefully it sinks in and I can tackle the issue at hand.
I've been nibbling away at reading through topics such as MBRs, VBRs and FAT throughout the week. I made a new drive for my winxp vbox and tried adding a few FAT partitions to it and studied the dd output of the MBR/FAT details, just to help get acquainted.
Today, I extracted out the equivalent contents of the sd-card via dd on my macbook's terminal and am getting acquainted with the field contents there.
I've never really focused on FAT to this detail before, but I'll keep plugging away at it incrementally until hopefully it sinks in and I can tackle the issue at hand.
Paul Gardner-Stephen
Jul 23, 2016, 7:43:22 PM7/23/16
to Gurce Isikyildiz, C65GS Development
Hello,
Thanks for your efforts and persistence on this. If you have any questions, please let me know, as I have gained some reasonable understanding of FAT, in particular VFAT32, which is the only standard I think we need to support on the MEGA65.
Paul.
--
Gurce Isikyildiz
Jul 27, 2016, 5:33:37 PM7/27/16
to C65GS Development, gurce.is...@gmail.com, pa...@servalproject.org
Hi Paul,
Making some incremental progress on following up things you suggested earlier, such as using the remote serial monitor to examine the memory between $20000 - $3FFFF.
I compared the byte vals there against those in the original "MEGA65.ROM" file and saw the affected region that you described. On this occasion for me, it was in the range: 0036200 <--> 0036FFF:
So I felt my next port of call seemed be to learn how this *.ROM file got loaded into memory. I think I've spotted that in "kickstart.a65" at this point:
I was thinking of digging into that dos_readfileintomemory call a bit deeper to learn how it goes about things, but if you've got any suggestions on other relevant areas worth digging into, you're welcome to put them on my radar too :)
Gurce
Making some incremental progress on following up things you suggested earlier, such as using the remote serial monitor to examine the memory between $20000 - $3FFFF.
I compared the byte vals there against those in the original "MEGA65.ROM" file and saw the affected region that you described. On this occasion for me, it was in the range: 0036200 <--> 0036FFF:
So I felt my next port of call seemed be to learn how this *.ROM file got loaded into memory. I think I've spotted that in "kickstart.a65" at this point:
txt_c65gsrom: .byte "MEGA65.ROM",0,0...
loadc65rom:
ldx #<txt_c65gsrom
ldy #>txt_c65gsrom
jsr dos_setname
; Prepare 32-bit pointer for loading whole ROM ($0020000)
lda #$00
sta <dos_file_loadaddress+0
sta <dos_file_loadaddress+1
sta <dos_file_loadaddress+3
lda #$02
sta <dos_file_loadaddress+2
jsr dos_readfileintomemory
bcs loadedokI was thinking of digging into that dos_readfileintomemory call a bit deeper to learn how it goes about things, but if you've got any suggestions on other relevant areas worth digging into, you're welcome to put them on my radar too :)
Gurce
Paul Gardner-Stephen
Jul 28, 2016, 1:44:44 AM7/28/16
to Gurce Isikyildiz, C65GS Development
Hello,
Ok. This is the kind of issue I expected it would be, i.e., that part of the file is not loaded correctly.
What is a bit odd is that it is $E00 bytes that are loaded incorrectly. Unless your cluster size is 512 bytes, it doesn't look like a cluster addressing issue, but rather a sector addressing issue, i.e., at some point when it is adding $200 to the address of the last sector, it is (probably) causing some strange carry bug.
Here is the routine:
dos_file_advance_to_next_sector:
; Increment file position offset by 2 pages
ldx dos_current_file_descriptor_offset
lda dos_file_descriptors+dos_filedescriptor_offset_fileoffset+0,x
clc
adc #$02
sta dos_file_descriptors+dos_filedescriptor_offset_fileoffset+0,x
bcc dfatns1
inc dos_file_descriptors+dos_filedescriptor_offset_fileoffset+1,x
bne dfatns1
inc dos_file_descriptors+dos_filedescriptor_offset_fileoffset+2,x
dfatns1:
It is quite possible that the BCC should be a BNE or some similar logic bug here, although seems like it should be fine.
Anyway, that is where I would start. You could add a hypervisor debug call to report the calculated offset.
Else, my best guess would be a bug in dos_file_read_current_sector or one of those related routines.
In any case, if you add the hypervisor debug output, and then monitor the serial debug interface, you can get a really nice trace of what is going on, that should make it MUCH easier to debug.
If we don't have documentation on how to use that interface, we should write it.
Paul.
--
Gurce Isikyildiz
Jul 30, 2016, 8:36:25 AM7/30/16
to C65GS Development, gurce.is...@gmail.com, pa...@servalproject.org
Hi Paul,
While searching for info on hypervisor, I saw some info in Ben's fork that I thought might have been related to the issue at hand:
He mentioned there:
|
Well, I wrote a little c-app to assess if any of the cluster-chains were fragmented, also as an excuse to get better acquainted with FAT. It turned out that there was no fragmentation, so I can rule that out as the source of the present problem.
Next, I'll look into the assembly source you mentioned. I'm not familiar with the "add hypervisor debug output" method you're suggesting. Is it some sort of flag that I need to turn on in the source, then re-build, to get access to more output within the serial monitor? Would you be able to walk me through that a little, as I don't think I've been able to locate and docs regarding it.
Paul Gardner-Stephen
Jul 30, 2016, 6:37:04 PM7/30/16
to Gurce Isikyildiz, C65GS Development
Hello,
The ROM loading code can handle fragmented files. It is only disk images that are required to be contiguous on disk. That requirement is because the floppy controller emulator works by pointing the controller to a start address on the SD card, and allowing it direct access to that 800KB extent.
As for the debug interface, all you need is to put something like:
jsr checkpoint
.byte 0,"drce_ignore_lfn_piece",0
wherever you want a checkpoint. You can find the checkpoint routine in kickstart.a65. Switch 12 controls whether the debug messages are output.
Note that the hypervisor checkpoint/debug facility is only in the newer branches (my hypervisor debug one has it). You can also make your code mutate the message string, so that it can include dynamic content.
Note that you cannot start the machine with sw12 on. You can only turn it on after it is looking for the SD card, due to some complications that I have yet to sort out (basically the watchdog has to be setup correctly, and there might be some other race conditions to satisfy). Therefore I would suggest:
0. Make sure you are connected to serial debug interface via USB
1. Remove SD card.
2. Boot with SW12 off.
3. Turn SW12 on when Kickstart message appears
4. Reinsert SD card
5. Watch the fire-hose of checkpoint/debug messages.
Paul.
--
Gurce Isikyildiz
Jul 30, 2016, 7:45:49 PM7/30/16
to Paul Gardner-Stephen, c65gs-de...@googlegroups.com
Oops, I forgot to reply-all this time :)
Also, I had another thought. Would it be possible for me to debug this "kickstart_dos.a65" - dos_file_advance_to_next_sector() function via the remote monitor by adding a breakpoint and stepping through a bit?
I saw in the compiled "kickstart.list" file the offset that seemed to correspond to the point of interest:
8E2E AE F5 BC LDX $BCF5
8E31 BD C1 BC LDA $BCC1, X
8E34 18 CLC
8E35 69 02 ADC #$02
8E37 9D C1 BC STA $BCC1, X
8E3A 90 08 BCC $0044
8E3C FE C2 BC INC $BCC2, X So next thing I was wondering, whereabouts is kickstart mapped into memory? I'm having a look around but haven't located it yet. I was guessing I should look for a reference in the code where the "kickstart65gs.bin" file gets loaded in, but I had no luck finding it as yet.
Gurce
On 31 July 2016 at 09:10, Gurce Isikyildiz <gurce.is...@gmail.com> wrote:
Thanks Paul. I was wondering, if I was to add extra jsr checkpoint calls to help debug, then I'd need to re-build the bitstream. I was a little hesitant to re-do it at this stage, since my first successful build/synthesis took about 2hours to complete on my vbox.So just wondering, if my sole modification since that prior build was to tweak .a65 source files (and not .vhdl files), would the re-build/re-synthesis be any quicker? (a bit like in the c/makefile world, how "make all" will be faster than "make clean all"?). Or is vhdl-world a bit more unforgiving? :)
Gurce Isikyildiz
Jul 30, 2016, 8:12:01 PM7/30/16
to Paul Gardner-Stephen, c65gs-de...@googlegroups.com
Oh wait, to answer my own question, I seem to have handled it this way.
- I started up the nexys board
- in remote monitor, I typed "b8e35" to set the breakpointPaul Gardner-Stephen
Jul 31, 2016, 1:10:01 AM7/31/16
to Gurce Isikyildiz, C65GS Development
Hello,
On Sun, Jul 31, 2016 at 9:41 AM, Gurce Isikyildiz <gurce.is...@gmail.com> wrote:
Awesome, the breakpoint hit :) After reading Ben's monitor docs, I learnt that the ENTER key can act as a step-instruction command, awesome.- I see kickstart restart and freeze after the line "MOUNTED 01 PARTITION"- I pressed RESTORE for 3 seconds on my USB keyboardOh wait, to answer my own question, I seem to have handled it this way.- I started up the nexys board- in remote monitor, I typed "b8e35" to set the breakpoint
Right. It is also possible, in principle to recompile kickstart and update it on a running system by putting the new version into kickup.m65 file on the sd card, and then reboot. Search for kickup in the .a65 files to see how it all works.
Part of me is itching to write a c-app to massage the remote-monitor serial input so that shows disassembled output too (I'm guessing it'd be a waste of space to add logic like that into vhdl, as the FPGA resources can probaby be spared for better things). But maybe that'd be quite a detour/distraction from the task at hand, so I might keep the idea on the backburner for now, and just manually follow the PC alongside the .a65/.list source for now :)
Yes, it would be great to make something like that. Java would be good so that the one tool could work on Mac, Linux and Windows.
Paul.
Gurce Isikyildiz
Jul 31, 2016, 8:02:04 AM7/31/16
to C65GS Development, gurce.is...@gmail.com, pa...@servalproject.org
Yep, sure, Java's fine by me, I'll aim for that once that itch grows and needs to be scratched... Actually, as I step through code tonight, the itch is growing quite rapidly, so I'll start nibbling on the idea soon :)
Paul Gardner-Stephen
Jul 31, 2016, 8:05:43 AM7/31/16
to Gurce Isikyildiz, C65GS Development
Hello,
For extra bonus marks, you could make the tool allow uploading of a new hypervisor directly over the serial monitor interface. That would make for a much simpler development process for the hypervisor.
Paul.
Gurce Isikyildiz
Jul 31, 2016, 5:14:40 PM7/31/16
to C65GS Development, gurce.is...@gmail.com, pa...@servalproject.org
Hi Paul,
Hehe, sure, it'd be great to evolve such a tool with more handy facilities and muscle over time. I'm guessing my first stab at it will be fairly bare-bones though, and hopefully there'll be time to add some meat as time goes on :)
I've been reading up on Java-support for serial-comms here:
https://en.wikibooks.org/wiki/Serial_Programming/Serial_Java
It's sounding like a world of pain, with Sun's JavaComm library end-of-life'ed for windows, and other parties (RxTx) stepping in to try fill the void. Have you ventured into this java-serial world before? If so, and you reckon it's worth the rough ride, then ok, I can stick it out.
Another thought was that maybe it could be a Python app, as then it might be able to take advantage of some of the code within Ophis (perhaps it could help out with disassembly?). There seems to be a python-library available for the serial port, so I might have a sniff into that option too.
https://pythonhosted.org/pyserial/
Gurce
Hehe, sure, it'd be great to evolve such a tool with more handy facilities and muscle over time. I'm guessing my first stab at it will be fairly bare-bones though, and hopefully there'll be time to add some meat as time goes on :)
I've been reading up on Java-support for serial-comms here:
https://en.wikibooks.org/wiki/Serial_Programming/Serial_Java
It's sounding like a world of pain, with Sun's JavaComm library end-of-life'ed for windows, and other parties (RxTx) stepping in to try fill the void. Have you ventured into this java-serial world before? If so, and you reckon it's worth the rough ride, then ok, I can stick it out.
Another thought was that maybe it could be a Python app, as then it might be able to take advantage of some of the code within Ophis (perhaps it could help out with disassembly?). There seems to be a python-library available for the serial port, so I might have a sniff into that option too.
https://pythonhosted.org/pyserial/
Gurce
Paul Gardner-Stephen
Jul 31, 2016, 6:04:32 PM7/31/16
to Gurce Isikyildiz, C65GS Development
Hello,
I'd be fine with Python. I'd also be fine with C, if it was POSIX, i.e., ran on Linux and Mac. But it would be a little harder to do that, and also have Windows support. I'm guessing you would have to use Cygwin.
Paul.
--
Gurce Isikyildiz
Aug 2, 2016, 8:39:02 AM8/2/16
to C65GS Development, gurce.is...@gmail.com, pa...@servalproject.org
Alrighty, I'll stick with posix-c for now. I'm underway, with some starter code that's just acting as a poor/simple terminal from within cygwin.
I'll drop what I have in a new github repo:
https://github.com/gurcei/m65dbg
It's very early days, no fancy/clever parsing as yet, I just wanted to get the serial plumbing out of the way first. It's presently hard-coded to "/dev/ttyS4", which is what the USB-serial device is called on my vbox. I probably should make that configurable at some stage, as it's probably different for other people/systems.
Anyway, it's a start... :)
Gurce
I'll drop what I have in a new github repo:
https://github.com/gurcei/m65dbg
It's very early days, no fancy/clever parsing as yet, I just wanted to get the serial plumbing out of the way first. It's presently hard-coded to "/dev/ttyS4", which is what the USB-serial device is called on my vbox. I probably should make that configurable at some stage, as it's probably different for other people/systems.
Anyway, it's a start... :)
Gurce
Paul Gardner-Stephen
Aug 2, 2016, 4:52:01 PM8/2/16
to Gurce Isikyildiz, C65GS Development
Hello,
Cool -- I'll take a look when I get a moment.
Only yesterday Ben and I were talking about how we are looking forward to this, as I was disassembling 4502 opcodes in my head trying to track down a bug.
Yes, the serial port needs to be configurable, because it can have totally weird names on a Mac, for instance something like /dev/cu.usbserial.otherseeminglyrandomstuff.
Paul.
--
Paul Gardner-Stephen
Aug 2, 2016, 4:53:29 PM8/2/16
to Gurce Isikyildiz, C65GS Development
Hello again,
For help disassembling, take a look at the VHDL code in gs4510 that disassembles instructions for display in the debug code that is used during simulation. It is relatively simple.
Paul.
Gurce Isikyildiz
Aug 2, 2016, 5:49:32 PM8/2/16
to Paul Gardner-Stephen, c65gs-de...@googlegroups.com
Oops, forgot reply-all again.
Just an update that I added in readline-library support in a way to work under cygwin. I suspect it might have issues to be ironed out in mac/linux, I'll try chase those up after (I've got my macbook and a linux vbox to test on, so just need the time to test them out).On 3 August 2016 at 07:02, Gurce Isikyildiz <gurce.is...@gmail.com> wrote:
GurceHi Paul,Thanks for the info, will chase these up too. I'm presently studying how to make use of the readline library within the app. Thought it might be nice to have a history of past commands and all that CTRL-R reverse-search stuff at our fingers tips too :)
Gurce Isikyildiz
Aug 4, 2016, 5:02:04 PM8/4/16
to C65GS Development, pa...@servalproject.org
Hi Paul,
Ok, I'm having a read around gs4510.vhdl at present.
I also observed there was a "dis4510.c" file in the project too, I'm wondering, if this in good working condition, maybe I can draw some copy/paste inspiration from it.
I noticed it references a "64net.opc" file to parse in the cpu opcodes, is this instruction set we need?
Gurce
Ok, I'm having a read around gs4510.vhdl at present.
I also observed there was a "dis4510.c" file in the project too, I'm wondering, if this in good working condition, maybe I can draw some copy/paste inspiration from it.
I noticed it references a "64net.opc" file to parse in the cpu opcodes, is this instruction set we need?
Gurce
Paul Gardner-Stephen
Aug 4, 2016, 7:50:15 PM8/4/16
to Gurce Isikyildiz, C65GS Development
Hello,
On Fri, Aug 5, 2016 at 6:32 AM, Gurce Isikyildiz <gurce.is...@gmail.com> wrote:
Hi Paul,
Ok, I'm having a read around gs4510.vhdl at present.
I also observed there was a "dis4510.c" file in the project too, I'm wondering, if this in good working condition, maybe I can draw some copy/paste inspiration from it.
I don't remember how far I got with it.
I noticed it references a "64net.opc" file to parse in the cpu opcodes, is this instruction set we need?
Yes, that's the 4502 instruction set. We would eventually also need a 6502 version, so that when the CPU is in 6502 mode (which it doesn't yet support), that we can disassemble that properly as well.
Paul.
Gurce
--
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.
Gurce Isikyildiz
Aug 6, 2016, 7:34:32 AM8/6/16
to C65GS Development, gurce.is...@gmail.com, pa...@servalproject.org
Whew, finally made some good progress getting some live disassembly happening of he current instruction.
Here's some output from the app. Note that I made "n" the command for "next" instruction (in the native monitor, this is achieved via pressing enter). The reason for this change in behaviour was to permit the use of the enter key to repeat the last command.
But still, I'm happy I've got this far :)
Gurce
Here's some output from the app. Note that I made "n" the command for "next" instruction (in the native monitor, this is achieved via pressing enter). The reason for this change in behaviour was to permit the use of the enter key to repeat the last command.
m65dbg - v1.00 ====== - Type 'h' for help <dbg>n PC A X Y Z B SP MAPL MAPH LAST-OP P P-FLAGS RGP uS IO E167 01 DB 01 08 00 01D9 82A0 B300 29 01 64 00 .VE..I... ..P 11 -00 -- $E167 M_rr:1 F0 0C BEQ $E075 <dbg> PC A X Y Z B SP MAPL MAPH LAST-OP P P-FLAGS RGP uS IO E169 01 DB 01 08 00 01D9 82A0 B300 F0 0C 64 00 .VE..I... ..P 11 -00 -- $E169 M_nnnn:2 20 2D E6 JSR $E62D <dbg> PC A X Y Z B SP MAPL MAPH LAST-OP P P-FLAGS RGP uS IO E62D 01 DB 01 08 00 01D7 82A0 B300 20 2D E6 64 00 .VE..I... ..P 11 -00 -- $E62D M_nnnn:2 AD 28 11 LDA $1128 <dbg> PC A X Y Z B SP MAPL MAPH LAST-OP P P-FLAGS RGP uS IO E630 00 DB 01 08 00 01D7 82A0 B300 AD 28 11 66 00 .VE..IZ.. ..P 11 -00 -- $E630 M_immnn:1 89 C0 BIT #$C0 <dbg> PC A X Y Z B SP MAPL MAPH LAST-OP P P-FLAGS RGP uS IO E632 00 DB 01 08 00 01D7 82A0 B300 89 C0 E6 00 NVE..IZ.. ..P 11 -00 -- $E632 M_rr:1 F0 54 BEQ $E588 <dbg> PC A X Y Z B SP MAPL MAPH LAST-OP P P-FLAGS RGP uS IO E688 00 DB 01 08 00 01D7 82A0 B300 F0 54 E6 00 NVE..IZ.. ..P 11 -00 -- $E688 M_impl:0 60 RTSSomething seems a bit screwy with the relative maths of the beq call, I'll look into soon.
But still, I'm happy I've got this far :)
Gurce
Paul Gardner-Stephen
Aug 6, 2016, 7:41:41 AM8/6/16
to Gurce Isikyildiz, C65GS Development
Well done!
--
Gurce Isikyildiz
Aug 6, 2016, 9:42:12 AM8/6/16
to C65GS Development, gurce.is...@gmail.com, pa...@servalproject.org
Hehe, no probs, happy to :)
I fixed the relative-address bug, then gave it a try with stepping through that sector issue.
I still found I was getting lost with the location in the source after each rts, so I looked into how to get the generated "kickstart.list" list file to provide hints on which source-code and line-number each compiled line relates to.
I created a patch to Ophis to make this happen, see attached "ophis_verbose_list_file.patch".
After applying this patch, and re-compiling kickstart with:
The output of the "kickstart.list" file will now look like this:
Cool, hope that'll help me from getting dis-oriented when stepping around :)
I fixed the relative-address bug, then gave it a try with stepping through that sector issue.
I still found I was getting lost with the location in the source after each rts, so I looked into how to get the generated "kickstart.list" list file to provide hints on which source-code and line-number each compiled line relates to.
I created a patch to Ophis to make this happen, see attached "ophis_verbose_list_file.patch".
After applying this patch, and re-compiling kickstart with:
../Ophis/bin/ophis -4 kickstart.a65 -l kickstart.list -m kickstart.map
The output of the "kickstart.list" file will now look like this:
8E2B 4C 6A 96 JMP $966A | /home/vets/mega65/kickstart_dos.a65:1927 8E2E AE F5 BC LDX $BCF5 | /home/vets/mega65/kickstart_dos.a65:1932 8E31 BD C1 BC LDA $BCC1, X | /home/vets/mega65/kickstart_dos.a65:1934 8E34 18 CLC | /home/vets/mega65/kickstart_dos.a65:1935 8E35 69 02 ADC #$02 | /home/vets/mega65/kickstart_dos.a65:1936 8E37 9D C1 BC STA $BCC1, X | /home/vets/mega65/kickstart_dos.a65:1937 8E3A 90 08 BCC $0044 | /home/vets/mega65/kickstart_dos.a65:1938 8E3C FE C2 BC INC $BCC2, X | /home/vets/mega65/kickstart_dos.a65:1939 8E3F D0 03 BNE $0044 | /home/vets/mega65/kickstart_dos.a65:1940
Cool, hope that'll help me from getting dis-oriented when stepping around :)
Gurce Isikyildiz
Aug 6, 2016, 9:01:15 PM8/6/16
to Paul Gardner-Stephen, c65gs-de...@googlegroups.com
Okidoke, will figure out the Ophis fork stuff soon.
Yup, hopefully I can push in the direction you're thinking of over time. I've taken a baby-step in that direction today. If you run the app in the path containing the *.list files, they'll get loaded by the app and some file:lineno info will appear as you step through now.m65dbg - v1.00 ====== - Type 'h' for help |
Loading "diskchooser.list"... Loading "diskmenuc000.list"... Loading "kickstart.list"... <dbg>dis > /home/vets/mega65/kickstart_dos.a65:1937 $8E37 M_nnnnX:2 9D C1 BC STA $BCC1,X <dbg>n PC A X Y Z B SP MAPL MAPH LAST-OP P P-FLAGS RGP uS IO 8E3A 02 00 0A 00 BF BEFB 4000 3F00 9D C1 BC 24 00 ..E..I... ..P 11 -00 H- > /home/vets/mega65/kickstart_dos.a65:1938 $8E3A M_rr:1 90 08 BCC $8E44 <dbg>n PC A X Y Z B SP MAPL MAPH LAST-OP P P-FLAGS RGP uS IO 8E44 02 00 0A 00 BF BEFB 4000 3F00 90 08 24 00 ..E..I... ..P 11 R00 H- > /home/vets/mega65/kickstart_dos.a65:1945 $8E44 M_nnnnX:2 FE BE BC INC $BCBE,X <dbg>n PC A X Y Z B SP MAPL MAPH LAST-OP P P-FLAGS RGP uS IO 8E47 02 00 0A 00 BF BEFB 4000 3F00 FE BE BC 24 00 ..E..I... ..P 11 -00 H- > /home/vets/mega65/kickstart_dos.a65:1946 $8E47 M_nnnnX:2 BD BE BC LDA $BCBE,X <dbg>n PC A X Y Z B SP MAPL MAPH LAST-OP P P-FLAGS RGP uS IO 8E4A 01 00 0A 00 BF BEFB 4000 3F00 BD BE BC 24 00 ..E..I... ..P 11 R00 H- > /home/vets/mega65/kickstart_dos.a65:1947 $8E4A M_nnnn:2 AC 04 BC LDY $BC04 |
My next step will be to try read these lines out from the file:lineno reference. Deep down inside, I'm craving something like gdb's TUI window, ie, breaking out the console-screen into two viewports, the upper viewport containing the active source (with current line highlighted, which you can scroll up and down with the arrow keys), while the lower viewport being used for the typing of the monitor commands.
My gut says it's a fair bit of elbow-grease to get something like that, so I might have to hold off on that dream for a bit :)
Gurce
On 7 August 2016 at 10:22, Paul Gardner-Stephen <pa...@servalproject.org> wrote:
Cool. Do send a pull request against my Ophis fork so that we can merge that in.An interesting forward step would be to get to the point where we can show the source code +/- 25 lines with the current line highlighted etc, together with the stack trace. That would, I think, really help to advance the rate of progress.Paul.
--
Gurce Isikyildiz
Aug 6, 2016, 9:19:28 PM8/6/16
to Paul Gardner-Stephen, c65gs-de...@googlegroups.com
Cool, now I've got the actual source-line contents showing as you step through :)
<dbg>n PC A X Y Z B SP MAPL MAPH LAST-OP P P-FLAGS RGP uS IO 8E53 01 00 00 00 BF BEFB 4000 3F00 38 A5 00 N.E..I.C. ..P 11 R00 H- > /home/vets/mega65/kickstart_dos.a65:1953 > rts $8E53 M_impl:0 60 RTS <dbg> PC A X Y Z B SP MAPL MAPH LAST-OP P P-FLAGS RGP uS IO 8FD7 01 00 00 00 BF BEFD 4000 3F00 60 A5 00 N.E..I.C. ..P 11 R00 H- > /home/vets/mega65/kickstart_dos.a65:2224 > bcc drfim_eof $8FD7 M_rr:1 90 14 BCC $8FED <dbg> PC A X Y Z B SP MAPL MAPH LAST-OP P P-FLAGS RGP uS IO 8FD9 01 00 00 00 BF BEFD 4000 3F00 90 14 A5 00 N.E..I.C. ..P 11 R00 H- > /home/vets/mega65/kickstart_dos.a65:2231 > inw <dos_file_loadaddress+1 $8FD9 M_nn:1 E3 1A INW $1A <dbg> PC A X Y Z B SP MAPL MAPH LAST-OP P P-FLAGS RGP uS IO 8FDB 01 00 00 00 BF BEFD 4000 3F00 E3 1A A5 00 N.E..I.C. ..P 11 -00 H- > /home/vets/mega65/kickstart_dos.a65:2234 > inc dos_sectorsread $8FDB M_nnnn:2 EE A9 BC INC $BCA9 <dbg> PC A X Y Z B SP MAPL MAPH LAST-OP P P-FLAGS RGP uS IO 8FDE 01 00 00 00 BF BEFD 4000 3F00 EE A9 BC 25 00 ..E..I.C. ..P 11 -00 H- > /home/vets/mega65/kickstart_dos.a65:2235 > bne drfim_sector_loop $8FDE M_rr:1 D0 D4 BNE $8FB4 |
I'll get the Ophis fork and pull-request out of the way next.
Gurce Isikyildiz
Aug 6, 2016, 10:13:50 PM8/6/16
to Paul Gardner-Stephen, c65gs-de...@googlegroups.com
I've pushed another perk into m65dbg.
- I've made the "step" command act as "step into" (i.e., equivalent to pressing enter in raw monitor)Paul Gardner-Stephen
Aug 6, 2016, 11:39:15 PM8/6/16
to Gurce Isikyildiz, C65GS Development
Hello,
I was actually going to suggest that. Then all you need is step-out-from.
We can also make a shorter output format for the usb serial monitor interface so that it can go faster. If you can tell me the minimum data you need, I'll make a more compact format when I get a moment.
Paul.
Gurce Isikyildiz
Aug 7, 2016, 2:15:41 AM8/7/16
to Paul Gardner-Stephen, C65GS Development
Ah yup, step-out-from, okidoke, I'll ponder that next.
Here's a few extra perks added recently:A new "dump" command that outputs hex-data + printable-chars in right-hand column
<dbg>dump bc67 :777BC67 42 4F 4F 54 4C 4F 47 4F 2E 4D 36 35 00 53 41 42 | BOOTLOGO.M65.SAB
I've added a 2nd optional parameter to act as a count of bytes:
<dbg>dump bc67 50
:777BC67 42 4F 4F 54 4C 4F 47 4F 2E 4D 36 35 00 53 41 42 | BOOTLOGO.M65.SAB
:777BC77 41 20 4D 45 4C 4F 4E 20 50 52 4F 44 55 43 54 49 | A MELON PRODUCTI
:777BC87 4F 4E 20 53 54 41 54 49 53 54 49 43 53 20 28 32 | ON STATISTICS (2
:777BC97 30 30 37 2D 32 30 31 31 29 2E 54 58 54 20 20 20 | 007-2011).TXT
:777BCA7 20 20 01 00 CB 03 00 00 CD 03 00 00 00 00 00 CD | ..............
There's a "ps" print-string command to print out null-terminated string-values.
<dbg>ps bc67 BOOTLOGO.M65
Gurce Isikyildiz
Aug 7, 2016, 3:11:20 AM8/7/16
to Paul Gardner-Stephen, C65GS Development
I've added an "mdump <addr> [<count>]" dump command now too (for 28-bit addresses).
I also tried adding a step-out-from command, I called it "finish", as that's what gdb seems to call it.
Ralph Egas
Aug 7, 2016, 4:36:30 AM8/7/16
to C65GS Development, pa...@servalproject.org
Hi Gurce,
Had been involved a while back writing the manual for Nexys etc. Now back a full pace (whatever that means along side a busy job ;)) working on getting GEOS to work on MEGA65. How about we also connect on Skype / Slack? Reach me at ralph...@abstractiongames.com / ralph.egas (Skype).
Cheers,
Ralph
--
To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-developm...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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-developm...@googlegroups.com.
Paul Gardner-Stephen
Aug 7, 2016, 4:43:24 AM8/7/16
to Gurce Isikyildiz, C65GS Development
Super :) For a modest speed up, I can still look at implementing a shorter format for the single-step instruction output, which will allow more instructions per second.
Paul.
Gurce Isikyildiz
Aug 7, 2016, 6:37:38 AM8/7/16
to C65GS Development, pa...@servalproject.org
Hi Ralph,
Ah yes, I remember reading through your Nexys doc when I first got my board, and it really helped me get up to speed with it, thanks for your efforts there :)
Sure thing, I added you on skype now.
Oh, does the mega65 project have a slack team? How do I join up for that? :)
Regards,
Gurce
Ah yes, I remember reading through your Nexys doc when I first got my board, and it really helped me get up to speed with it, thanks for your efforts there :)
Sure thing, I added you on skype now.
Oh, does the mega65 project have a slack team? How do I join up for that? :)
Regards,
Gurce
Gurce Isikyildiz
Aug 7, 2016, 6:51:02 AM8/7/16
to C65GS Development, gurce.is...@gmail.com, pa...@servalproject.org
Yup, sure. I'd better have a think over of the bare-minimum data I need then. Maybe it could be a minimal binary protocol instead of ascii too, if that'll help save space.
One last perk for tonight, I'm now loading in the "*.map" files so that I can use symbol names instead of addresses for some commands, for example:
One last perk for tonight, I'm now loading in the "*.map" files so that I can use symbol names instead of addresses for some commands, for example:
m65dbg - v1.00 ====== - Type 'h' for help Loading "diskchooser.list"...
Loading "diskchooser.map"...Loading "diskmenuc000.list"... Loading "kickstart.list"...
Loading "kickstart.map"...
<dbg>ps dos_requested_filename dos_requested_filename: BOOTLOGO.M65
With such long symbol-names, it makes me itch for tab-completion, maybe something to mull over for another occasion :)
Another itch that is slowly gnawing at me is having some sort of user-defined macro/function facility, like gdb has. Might be a good way print out a few essential variables within loop-activity quickly, rather than via lots of manual stepping. Again, that's too much for me to chew off at this stage, but one day... :)
Gurce
--
To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-developm...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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-developm...@googlegroups.com.
--
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-developm...@googlegroups.com.
Gurce Isikyildiz
Aug 7, 2016, 7:18:07 AM8/7/16
to C65GS Development, Gurce Isikyildiz, Paul Gardner-Stephen
Ok, absolutely last itch I wanted to scratch tonight... :)
For each step, show a wider span of source-code and highlight the current line:
Ok, that'll do for today :)For each step, show a wider span of source-code and highlight the current line:
<dbg>n PC A X Y Z B SP MAPL MAPH LAST-OP P P-FLAGS RGP uS IO 8FCE 00 0D 0A 0D BF BEFD 4000 3F00 EA 27 00 ..E..IZC. ..P 11 R00 H- > /home/vets/mega65/kickstart_dos.a65:2218 > 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 $8FCE M_nnnnY:2 92 19 1B STA ($19),Z
Gurce Isikyildiz
Aug 7, 2016, 9:10:24 AM8/7/16
to C65GS Development, Gurce Isikyildiz, Paul Gardner-Stephen
After having a play with my new debug facilities, I'm seeing times when the "n" (next) command can take several minutes to complete for a JSR (if the call had a lot of work to do, lots of loops, etc).
I'm starting to think that it might not be a big enough saving to just minimise the serial comms (eg, if it cuts down a 10 minute wait to 5 minutes, that's still a long wait).
Ben-401
Aug 20, 2016, 8:45:08 AM8/20/16
to C65GS Development
the build-error component of this thread now is here:
https://groups.google.com/forum/#!topic/c65gs-development/gNG5-SSXDHQ
https://groups.google.com/forum/#!topic/c65gs-development/gNG5-SSXDHQ
Reply all
Reply to author
Forward
0 new messages