Somehow I overlooked the homespun capability ... didn't mean to. Brad's list is directly copyable +/- a line to·a GUI text area element except for some front matter, global variable address listings, stack variable addresses, notes, etc.... See attached.
I've used richtextbox for highlighting and created a "gutter" for line numbers and breakpoint images with an adjacent panel (terms may be off since my last serious VB programming was spring). Wasn't there a VS2008 SDK for making such tools?· Latest VS is probably necessary for windowz compatability. I'm still tied up with another project, otherwise I would have a go at it.
OT: Ya, the disk platters I remember only had 2 disks, were blue and the cover made 'em look like space-ships. The first "mini-computer" unix system I used was·68K based·Huricon (8086 was still a baby). Darn things were networked on 10Base-2·and seemed to core-dump all the time for no reason. Most of my programming back then was for board test programs. I wrote a logic simulation package in C to make my life easier ... wish I knew the commercial potential then ....
The homespun compiler listing has much more detail for debugging purposes (see attached).
It is easy for VB to locate the spin code being stepped using the hub address·in the RichTextBox but I couldn't work out how to do multiple columns (to store a debug flag). I was able to highlight the line easily. I tried VB2008 (express) but it was too much of a change to VB6 for me to bother.
OT: Hindsight is wonderful. Now, what about a crystal ball that works.·
There is some confusion about how my debuggers work, so here goes - let me know if there is something you do not understand.
Hi Cluso,
I managed to put the debugger code into my object (q6502.spin) and have it compiled so that the required bits are below $1f0.
I then start the debugger and it sends its messages to the serial port. After the initial key however no further key is accepted and nothing seems to happen.
Any hints what I could be doing wrong?
PS: Attached is the debugger with $0D replaced with 13,10 - i.e. CR replaced with CR+LF, which my terminal software needs. I don't think that these changes broke anything.
Just wondering if it is a lack of cogs?? I am sure you would have cr+lf correct as the spin code makes it easy.
I need to get back to my RamBlade and get your emulations running so that will help. WOuld you like to post your emulation code? What hardware do you need with q6502 besides the sram and sd?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
Just wondering if it is a lack of cogs?? I am sure you would have cr+lf correct as the spin code makes it easy.
I need to get back to my RamBlade and get your emulations running so that will help. WOuld you like to post your emulation code? What hardware do you need with q6502 besides the sram and sd?
I have two cogs free when starting the debugger, after I removed two instances of the AY-3-8910 emulation (which isn't really required yet).
Currently I reverted the changes, because they broke the emulation code. Funny enough now the bug why in the first place I wanted to debug the q6502.spin code is gone. Unfunny now the code is running very slow, just as if I had switched to the internal clock... I guess I have some serious overwriting of the low hub RAM range somewhere.
I can test the code only on the DracBlade. Required is keyboard and VGA output. The MICROTAN.ROM needs to be on the SD.
The XMM memory access code for the RamBlade or TriBlade is in there, but I think you don't have the keyboard and VGA on the TriBlade #2?
Some of the code is in the ./lib directory, so you need to add that path to the BST compiler preferences to build microtan.spin.
Cluso99 said...
pullmoll: Do any of your cogs require to be specific cogs. eg cog 0?
No. The only requirement is that the cog running spi_warp.spin is one of the first to be initialized. AFAIR it can be cog #1 or #2 when running from a Spin interpreter in cog #0. Usually the last thing that is started is the CPU cog which is then started with coginit(), because no Spin code is required once everything is set up.
I am wondering if coginit() is the problem as spin must remain running. I will need to dig it out again as I have not used the debugger for over a year or more.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
I am wondering if coginit() is the problem as spin must remain running. I will need to dig it out again as I have not used the debugger for over a year or more.
I also tried with cognew() when there were 2 cogs still available. No need to hurry as it seems I have accidentially cured the bug I wanted to look for. The new bug (if it is one) is nothing I could not catch with your debugger anyway, because it seems to be timing or clock related.
Comments
I've used richtextbox for highlighting and created a "gutter" for line numbers and breakpoint images with an adjacent panel (terms may be off since my last serious VB programming was spring). Wasn't there a VS2008 SDK for making such tools?· Latest VS is probably necessary for windowz compatability. I'm still tied up with another project, otherwise I would have a go at it.
OT: Ya, the disk platters I remember only had 2 disks, were blue and the cover made 'em look like space-ships. The first "mini-computer" unix system I used was·68K based·Huricon (8086 was still a baby). Darn things were networked on 10Base-2·and seemed to core-dump all the time for no reason. Most of my programming back then was for board test programs. I wrote a logic simulation package in C to make my life easier ... wish I knew the commercial potential then ....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
The homespun compiler listing has much more detail for debugging purposes (see attached).
It is easy for VB to locate the spin code being stepped using the hub address·in the RichTextBox but I couldn't work out how to do multiple columns (to store a debug flag). I was able to highlight the line easily. I tried VB2008 (express) but it was too much of a change to VB6 for me to bother.
OT: Hindsight is wonderful. Now, what about a crystal ball that works.·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439
My cruising website http://www.bluemagic.biz
Hi Cluso,
I managed to put the debugger code into my object (q6502.spin) and have it compiled so that the required bits are below $1f0.
I then start the debugger and it sends its messages to the serial port. After the initial key however no further key is accepted and nothing seems to happen.
Any hints what I could be doing wrong?
PS: Attached is the debugger with $0D replaced with 13,10 - i.e. CR replaced with CR+LF, which my terminal software needs. I don't think that these changes broke anything.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
I need to get back to my RamBlade and get your emulations running so that will help. WOuld you like to post your emulation code? What hardware do you need with q6502 besides the sram and sd?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I have two cogs free when starting the debugger, after I removed two instances of the AY-3-8910 emulation (which isn't really required yet).
Currently I reverted the changes, because they broke the emulation code. Funny enough now the bug why in the first place I wanted to debug the q6502.spin code is gone. Unfunny now the code is running very slow, just as if I had switched to the internal clock... I guess I have some serious overwriting of the low hub RAM range somewhere.
I can test the code only on the DracBlade. Required is keyboard and VGA output. The MICROTAN.ROM needs to be on the SD.
The XMM memory access code for the RamBlade or TriBlade is in there, but I think you don't have the keyboard and VGA on the TriBlade #2?
Some of the code is in the ./lib directory, so you need to add that path to the BST compiler preferences to build microtan.spin.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 6/3/2010 1:37:46 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I also tried with cognew() when there were 2 cogs still available. No need to hurry as it seems I have accidentially cured the bug I wanted to look for. The new bug (if it is one) is nothing I could not catch with your debugger anyway, because it seems to be timing or clock related.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects