General update

I have managed to get a minimally functional gui using Qt5, which was not an easy feat since the tutorials available at this time are geared toward Qt4. Things like what must be #included have changed, and also a line must be added to the .pro file: QT += widgets. Once I waded through all that, plus just general confusion due to lack of experience, I was able to use the tutorials to create functioning examples with qtcreator, the Qt IDE, which I could then study and use to figure out how to integrate my existing c++ code. I also found out that in order to have dual output to a gui and a console window, for instance to use cout, you have to compile and run the code from a console, not from within qtcreator. This involves generating a makefile with qmake and then running make. If you run qmake -project like it says to do in the tutorials, you have to add the QT line mentioned above in order for make to succeed. Apparently the version of qmake that comes with Qt5 still creates a Qt4 .pro file?

When I first started to work on this a couple of weeks ago, I decided that since I was mainly interested in displaying contents of "memory locations," I would use chars since they were small, were used in the input file, and were readily displayed. However, since I have now decided to use QT for the gui, this means that chars must all be converted to qchars to be able to display them. Since I'm going to have to convert everything anyway, I have now decided to completely redo the "memory" scheme. Instead of using arrays of chars, I am most likely going to use vectors of bitset<8>'s. This seems to make more sense since it comes closer to being actual 8 bits in a byte of memory. But this also means I have to redo the parser and most of what I have already done. But that's ok. For the program memory, I plan to start out with a minimal size vector, initially fill it with zeros, then resize whenever iter = end or something like that. The only experience I have with vectors so far is in a classroom. But it should allow me to have random access from the start to a dynamically resizeable memory structure so that I don't have to grab maximum memory every time even for the shortest pic18 programs, which is what I would have to do if I used arrays. And really, for picMicroView, most of the assembly language applications input by the user will probably be relatively short. Next file upload will probably include gui and new memory scheme. H