Actually this was my first test:

 

12f508 is an ancient, obsolete chip with no hardware debug capabilities and very limited memory. For less money you can get a newer chip like the 16F15313 that runs 8 times faster, has nearly 5 times the program memory, 10 times the ram, way more peripherals, and built in hardware debugging.
So, no, I think is a waste of time.
Bob

I already answered this (why 12f508?) question (in other forum, and I will paste it here as well). But is ok. So the answer is multiple reasons. Trust my word. The biggest reason and it might shock you profoundly and to the core, is "simplicity". I love simple devices, the simplest, the best. Im not saying the more complex is wrong, but I like to start somewhere and the best is to grab something simple to deal with. Another important reason was to get on track with asm coding. So understand that this is an --exercise-- in asm for me. Yet another reason, is to create a personal database of good asm codes that I failed doing it long time ago, also lost it along the years and numerous hard drives, stupidity and negligence. It was not that good either so Im not crying about it, but it was a good idea, so it remained with me as an important 'todo' list for 15 years. Its good to have 'todo's ! Another reason is that im doing some artpages with a sort of tutorial that is mainly pointed to myself, but is also public so anyone can understand how much it can from it. I know it is a good and to the point reminder for ME, now and in the future. Another reason is the cheapness I bought these chips, 5$ for 10pcs DIP8 package. Then I find another sweet deal you dont find often, 2$ for 10pcs but SOP8 (smd version) and I buy 20pcs. Now I have plenty to play with. You start to see my map of my multiple reasons? Yet another reason, I have all the necesary hardware for these chips, no need to buy more expensive and possibly more buggy hardware devices. Im refering to my pickit2 programmer (the BLACK box), DemoBoard that I take it along with it, and also the coresponding software which is mplab v8.92. I also made another prototyping board, specifically for 12F508 that I plug into pickit2, but it can be very easy used for other 8pin PICs, with same pinout, and usually are corresponding because this is a standardized industry and I trust it. All this represents a nice and tidy kit in my eyes, that I struggle alone and miserable to make it work along the years, put them aside and forget them for years and now reinstating them with a new and refreshed perspective in mind. I really wish things were more easier to do and make with PICs but from all my research, it turns out its actually more complicated and more buggier, especially for me, a dude out there who is using them periodically, and not that daily as you guys are doing it here. The most important lesson from you (all combined) was to stick to it, do it every day, and push it until it cracks in the middle. I believe you so easily, because I personally know it from my past experience when I was good enough - not VERY. I managed to make the most used applications with PICs and that was enough for me and I like it and I want to be able to do it again.
I am planning not to stay with 12F508 in the future, despite I have a number of them. Ideally I will consume them all, in various circuits I plan. I know there are some interesting features in the new modern PICs, very atractive on the first look, but more exponential trouble to get them to work. So I keep my calm with them until after I get on track with the asm coding. I must be more confident with asm coding, and now Im building the confidence, by accumulating these codes, discussing with you here, and doing my stuff as I know how to do best, because I am doing it alone and you know already how slow it gets.

 

Also a little update; I am starting to build this circuit I planned for debugging purposes:

 

it's done now, and working:

haha, and because 1 was not enough, I made a second video adding some corrections and a bit more explanations.

 

Dont let the nay-sayers slow you down. Noone is answering your sub, due to lack of creativity and falling into the engineer/management paradyne/tradeoff numbness. Determination wins hands down with minimal tools - engineers were better in the dark days before the internet. Yes circumstances have changed, tools evolved, but they had real brains. Look at the ZX-81 - software video, and 1/2 KB memory, but had basic etc. No i never had one, but i can dream that i could pull something like that off, go see the wiki.
Respect to you the videos on your prototype debugger 'on the blind'. I would humbly suggest you could have single-stepped the PIC by using external 'R-C' mode that uses only a single pin
and replaces the hysteresis of the 555. Just use a 10uF cap/switch to ground and 100K to VCC, with maybe 100R current limit series to OSC1.

To address the topic, in your frame of ref, yes, full hardware debug capability on a native F508 is possible, but its a 1 month project for a seasoned dev. And you'll do better with a single wire debug protocol (eg I/O on GP3/VPP pin on baseline and enhanced). So for old gen PICs this is long overdue; a lost generation of nubees are still fumbling with PICs with nothing more than a debug LED, and maybe 2% persevere to continue. And there is a legion of hubbyists that use the old parts with no debugging, or use a midrange debugging chip, then scale back the programs for F508 or the famous F675.
I personally have stacks of these chips, and they're perfect for simple projects. And as you say can be had for peanuts (eg aliexpress recycled/pulled parts with 10% duds) with cheap post - not possible for better chips. Really great for cash strapped students or developing countries. And it is hard for nubees to wrap their heads even around a F508 and 110 page datasheet and more. Now imagine the wall of pain to scale a modern PIC info mountain? Some datasheets are 500+ pages.

Steps;
1. Use a high level free compiler eg Pic Micro Pascal , PicPas, JAL, or picBasic free edition etc. This is a convenience but MPASM can be used if all you want is asm level debugging.
2. Place each asm instruction as a inline 'asm' statement on a line of its own.
Alternatively prefix each line with a SLEEP() which functions as marker that can be easily stripped out later and doesnt cause the compiler to output any boiler plate and preserves the flags, while not disturbing the optimizer if using the HLL.
3. Compile your program with full asm listing annotation .

What we now have is a .asm listing file that has clearly tagged inline asm / High-Level blocks.
You now need to write a small post-processor (eg AWK or MPASM macros) that detects each block, removes the HL compiler's inter-inline asm boiler plate (eg save bank/regs) and replaces that with;

4. save WREG, and PC (ie save LOW($) and HIGH($) to files while preserving flags - fortunately basline has SWAPF instruction). We have now saved the debugee's PC and state.
5. makes a GOTO to your debug executive (about 100 instructions but lets use a F509 which is essentially the same hardware, and place the executive on page1, your debugee code will run on page0). As a bonus since we assume the debugee is confined to page0, we dont have to save PCH9..13 via an intra-page call.
6. The executive returns control to the debugee by restoring its state (PCH=0) and using a GOTO to after the debug 'thunk' by offsetting the saved PC on restore. Because the returning GOTO will trash WREG, then we return to a small stub after the executive thunk, which restores WREG as debugee inline code. A bit fatter and slower, but we dont use the precious call stack.

Now you can effectively single step the degubee with full CPU context visibility - ie hardware level debugging. Granted the debugee will run about 5-10 time slower (but you can use conditional asm
to only trace the blocks you want to debug).
Finally, lets get lazy, and leverage MPASM's simulator to resolve PC addresses; use a autohotkey
script connected to the executive over serial, and inject 'g' goto PC address commands to track PC at the source level! Maybe we might also inject keys to update WREG, FLAGS and a few key files.

There is a AVR 'debugger' along these lines since the situation was even worse for them;
only the Dragon programmer was able to do debugging (whereas every PICkit 2+ can).

So I encourage you to keep going, you could do this on the side for a year or 2, and release it
as freeware, great giveback to the PIC community. Even seasoned devs/hobbyists would like this since debug headers are getting rare and $100 a pop, and they fail quickly. And microchip will phase them out first.

If you wanted something faster, then you could hack up a quick debug executive on an enhanced midrange that has return stack access and hardware state save, and use an interrupt to re-enter the debug interrupt after executing 1 debugee instruction. But here we're copping out on the cheap. Tell your boss we'll reduce our inventory to zero - that should enamour you with him and accounts!

 

-Thank you for your comment. It's a bit late now.
-You created 2 answers posts with the exact same content. Please delete one post and leave only the one that you intended.
-I understood something from your explanations/suggestions. I cant say i understood everything. You are clearly more advanced and more into PIC's than I am. Im good, but not THAT good.
-At some point you mention I have a boss, but no, I am a simple guy, not working for a decade, staying home, because Romania.
-Thank you for the encouragements -a bit late-, and Im not into making bizniz with electronics. Nothing can sell here in my country so I dont bother. All that I do, I do for myself as a learning experience and practice. Its the only reason. Making money from what I know and what I can do, is a capitalistic dream. It remains, still, even today, just that, a dream. Nothing can reach into reality and is a shame if you ask me, but thats how things really are. At least from my perspective. It would be nice to make money in capitalism.... hmmm, from stuff I can make... but... it is a dream, and I know it. Im not young either, I lost all the good vibrant energy I had in those young years. It got eaten by stupidity and mediocrity. As usually things are, right? Hahahaha.
- Again, thank you for your comment. (and clean your double comment)

 

There always comes a time when you need to upgrade to newer tools and parts if you want to stay relevent....
I suggest this dev board from Microchip
https://www.microchip.com/en-us/development-tool/dm164137#
$43 with integrated debugger and dip socket to handle 8-pin to 20-pin 8-bit PICs...

 

to @wraujr
Microchip CURIOSITY DEVELOPMENT BOARD, is an interesting board and is the first time I hear about it; but is way too expensive!
My solution is FREE, and will work with any MCU, regardless of the brand or resolution. My solution is limited as well (for the moment). My solution was and still is, an experiment and an exercise. If anyone likes it, can use it, and is free to do so. No Problemo.
- The first thing I searched for, was the list of supported PIC microcontrollers that are compatible with the Microchip Curiosity Development Board that you recommend in your link. Check the attached file "MCDB.txt". You will notice that 12F family is not present. The Curiosity Development Board is primarily designed to support a wide range of 8-bit, 16-bit, and 32-bit PIC microcontrollers, but it does not include specific support for the PIC12F508.

 

I saw the rest of your videos #79 #80 quite a achievement - for the naysayers - the debugee CPU is pulsed by another PIC12F508 in bursts of 4 to get a machine cycle 'step'. I'm breathless just how low level q12x has gone, and made himself part of the CPU execute-decode cycle. The sort of busy work students in the west do at conservative universities at undergrad level. But you know they need that level of appreciation and 'looking deep under the hood' and exerting themselves mechanistically in order to identify and syncronize their efforts with the machines they hope to master.

Now idea for you - breakpoints. So your 'debugger' has a run mode; output a clock of say 100KHz (assuming your running on the internal 4MHz clock) and monitors the LED logic level. If it sees any
change , then it stops the clock, reads the switches in binary, and output that many*4 pulses. At least now you can reliably stop at an abitrary point in your program, and then forward to the exact instruction you want to single step. No longer 'blind debugging'. Definitely far more useful than blink the LED debugging. We could even take it a step further, and have a multi-pass breakpoint that is triggerred on the n'th LED transition.

I know most are scratching their heads at this point, and fumbling to find a 'down-vote' button somewhere. All I can say to them, is you'll never know the feeling of achieving something remarkable with severely constrained tools and resources, like it was in the 70's - 80's when debugging was all in your head. Half the time we didn't have datasheets ... I'm seeing now that i'm much more productive and analytic in Scilab precisely because i spend more time thinking rather than relying on the painful 'debugger'.

I can only say to read period papers, memoirs and books written in the early era of computing - von Neumann, Konrad Zuse, William Shockley . Read about the evolution from mainframes to minis. There is a lost culture and tradition here, the likes of which we will probably never see again. And they worked under enormous preassures to be the first to shatter the world by absolute dedication. How can we belittle the likes and ways of these great mavericks? Precisely the reason why we are destined to go nowhere, and follow clandestinely in their footsteps. Maybe then we could place a few toes daintily outside the box.

 

>> -Thank you for the encouragements -a bit late-, and Im not into making bizniz with electronics. Nothing can sell here in my country so I dont bother. All that I do, I do for myself as a learning experience and practice. Its the only reason. Making money from what I know and what I can do, is a capitalistic dream. It remains, still, even today, just that, a dream. Nothing can reach into reality and is a shame if you ask me, but thats how things really are. At least from my perspective. It would be nice to make money in capitalism.... hmmm, from stuff I can make... but... it is a dream, and I know it.

Try to channel you energies into some positive direction, its easy to become dissillusioned. OK in a repressive shatterred post-communist state its challenging to remain positive. Konrad Zuse continued his 'relay computer' construction right through the war, until a stray bomb destroyed it. OK, he could have given up, but no Mk II was born like a phoenix from the ashes. Get in touch with some electronic and computer user groups, i hear Russians are very savy with tech and buy much more low-level hardware on Aliexpress. Some have designed stuff. Hand distribute little kits, 10-off home made dev boards for $2 to cover costs. A lot can be done, and young people are enthusiastic and quick to learn, they can help you later. Publish a few articles, blogs, even print something with kits. Once you get yourself busy with this, you won't even notice there's a war next door, no time to pay attention to hungry stomach. My father finnished his PhD with litteraly cut and paste - used a manual typewritter, to print corrected words and sentances, and pasted them into his manuscript with glue. Liquid paper was a revolutionary invention at the time. Reach out to people that have an open mind, who want to hear you, are interrested in you ideas. Create awareness, get people involved, bring back the excitement of hobby electronics into the local community. Reach out over the internet, start a blog of your own. And most of all take yourself seriously. You're smart, creative, and able to see things in a new light. And if its at hobby level, then you dont need to prove anything to anyone, its the enjoyment and happyness that counts. There's a lot of judgemental negativist thinking going on, and suppression of healthy open mindedness. A lot of good doctors have been shoe-horned into a collective 'hive-mind' thinking that only strives to peddle one way of doing, and sometimes that's misguided. But forward they go, despite the many red 'wrong way go back' signs on the highway.

 

And staying on topic (being motivated is always on topic), lets expand the function of that LED. So we write a little function (callable from any code page) that has a global file, which the bebugee sets a bit in using BSF , this avoids trashing WREG. The file value is used to set the period that the LED is blinked. The debugger can now measure this time and use that to identify 1 or 8 breakpoint addresses which is clocked to a 4017 which is the user's readout on where the breakpoint occurred. Your 'blind debugger' actually is starting to look pretty user friendly. MPASM has user variable that can increment so you dont have to mentally track eack breakpoint ID. On return from the debug monitor call, it sets the debug file to 0x81 . This way you can get an extra ID's with SWAPF, INCF, CLRF, COMF, RLF, RRF, ie 14 breakpoint ID's total. MPASM allows macros to redefine mneumonics to you can transperantly prefix PIC instructions with a breakpoint ID instruction and a debug CALL.
So now you have a very doable relatively functional debugger, which can easily debug 14 lines of code with 2 instruction overhead. You can juggle the breakpoint ID's in your head, or use the .MAP file to tell you which and where. All this is at your skill level, and doable NOW! Looking forward to your next video implementing this (very little coding needed) ; tick. No money needed; tick. Objective reached; tick. Time needed, about an afternoon; tick.
Simplify; lets get rid of that 4017 circuit. Instead the F508 clock board, after stopping the debugee's clock, looks at the state of the LED, and inverts it cathode (no longer grounded) and flashes it acording to the breakpoint ID. Since we want to flash in either polarity make it a bi-directional LED. Since we want to read the debugee's LED level, parallel a 10K resistor, cathode to output pin on clock board;

DEBUGEE
|
R ....<--------------------LED current limit resistor
|
-
v R ....<--------------------(bi-dir LED and resistor)
-
|
DEBUGGER CLOCK BOARD

-zero extra hardware or connections; tick!

 

I saw the rest of your videos #79 #80 quite a achievement

there is another one, an extended movie I made, #81 ! Here @ #24 post .
Here is how it is looking from my side. It should be the same to you as well. You should be able to see that #81 too. Very strange you didnt see it.

And thank you for your thoughts !

 

Apropos microchip:

 

Apropos microchip:

Steve is a great guy and a good person.