BigDumbDinosaur wrote:
BTW, when I wrote Supermon 816, I copied the user interface of Supermon 64, which had been around in one form or another since the 1970s. I saw no reason to deviate from something that every Commodore assembly language programmer and his pet donkey had used since antiquity.
I found this:
https://github.com/jblang/supermon64Essentially the command style is the same as what I was thinking. Use single letter functions, type stuff after it, hit enter, stuff happens. Print results on a need-only basis (as in, don't print out the entire 256 byte page of data each time!). If you are fancy, be able to go back up to those existing lines, modify, and hit enter, stuff happens.
Because my video display is write-only, vertical scrolling is out of the question (unless I duplicate everything in RAM of course). That is why I went with a non-conventional display style. But I will highly consider what you are saying BDD. Being more "universal" is very important.
What was the name of your pet donkey?
BigEd wrote:
I'd advise looking as widely as possible at other monitors - not restricted to Commodore, or to Apple, or even necessarily to 6502.
It is very difficult to search for "monitors" on the web. Because this LCD display thingy I'm viewing this all on is also called a "monitor". Plus, I was a baby/toddler in the 80's so I don't remember any names of these things. More often than not, I simply stumble upon them while searching. Is there some type of list of monitors that I can start looking more specifically into?
BigEd wrote:
It might be worth thinking how to display the story of machine states if and when you implement single-stepping.
Hm. Hadn't even thought of that. Maybe I'm looking for an "Assembler" and not a "Monitor"?
barrym95838 wrote:
BigDumbDinosaur wrote:
It was not one of Wozniak’s sterling programming efforts and, in fact, is a sort of “black sheep” in today’s 6502 world.
Are you speaking on behalf of today's 65xx world, or just your corner of it?
WOZMON is notably limited, but in my
opinion was a perfect mate to the hardware on which it ran (256 bytes of ROM, no cursor controls except CR). The "address-first" command structure is a matter of taste, and kind of reminds me of RPN in a pleasing way. Would your "black sheep"
opinion apply to classic HP hand-held calculators as well? There's nothing wrong with having a personal
opinion, as long as it's characterized as such.
I didn't want to start a fight
I personally like WozMon, I think it's super compact and makes sense. Yes, it's primitive, but it was for the Apple 1, not Apple 2.
floobydust wrote:
The user interface will most likely be something that you're comfortable with. I wouldn't say you should pattern it after another monitor, but as Ed noted, look at other monitor programs to get an idea on how the UI was done and what functions were included. As far as functions go, I'd suggest making a list of requirements you think you will need to make working with the hardware easy and functional. Having a consistent command structure is also nice, as many commands will have similar input parameters.
Ok, that is also good advice. Honestly I've been thinking of going with a more 'menu' approach. Or some type of 'autocomplete'. I know that sounds fancy, but it is just trying to prevent errors and help the computer with parsing.
floobydust wrote:
I did take a look at your source code....
Uh oh...
floobydust wrote:
I will take a "stab" at it.... it's not very useful, in my opinion of course. What I see here is a lack of structure, virtually no comments and very little to suggest what is being done in the routines. You might want to consider creating a separate BIOS for your hardware and make those routines accessible via a JUMP table, which is quite common. The BIOS would have a clearly defined set of functions against the hardware that can be used by a Monitor program or other applications/utilities. The Monitor part could also be written as a separate program that only uses the BIOS to communicate with your hardware. It also could have a JUMP table to make core routines accessible from other applications/utilities.
I included my code just as an afterthought. My first intention here was to find what the user side of things would be like. "Hey guys, what makes a car nice to drive in? Radio? Four doors? Air conditioning? Cigarette lighter?" Kevin, your response was, "Dude, let's pop the hood!" Haha! And yeah, my fuel line is dangerously close to the radiator, I'm lacking a idle screw on my carburetor, and it's emitting blue smoke from the exhaust. A warning light is on the dash, something about my alternator. And the lightbulb to my license plate is out: TICKET!
floobydust wrote:
I would recommend getting copies of some existing manuals, such as the "6502 Assembly Language Subroutines" by Leventhal/Saville. You will find many useful bits of code there which you can likely adapt to what you need, or at least get a better idea on how to write certain types of routines. Going back to your code, there are so many sections which are a "brute force" approach, i.e., sending a mnemonic to your screen. You load the A reg with each character and send it through a routine. Writing a routine that sends a string of characters would be most useful here and significantly reduce your code size.
I know that my code is very inefficient at this point. I'm still so new to Assembly. I think like I'm programming in C still. Still, I also feel like I usually learn this stuff best when the need arises. For example, the brute force method of mnemonics, at this point is no big deal because I have a TON of ROM left over, and I'm too lazy to focus on making that portion of code efficient. However, my PS/2 keyboard signals were having overlapping interrupts, and so I had to tighten that code a lot to make it work. And work now it does, so I move on to the next thing. This is not best practices, but I'm not a professional anyways. I learn best when I need to learn it.
floobydust wrote:
One last bit of input from my side.... I tend to put limits on the amount of space any code should be. For my current C02 Pocket SBC, I have a limit for the BIOS of 2KB less the I/O window, which is 160 bytes located at $FE00. I also have a JMP table at $FF00. The BIOS code starts at $F800. For the Monitor code, it has a limit of 6KB, from $E000 to $F7FF. There are also limits on how much Page Zero space is used for the BIOS and Monitor. I also think you might want to break up the code a bit... separate modules that you can link together, one being a set of code defines and equates for your hardware addresses, page zero usage, etc. Feel free to grab any of my code from my GitHub page and use whatever you like. You'll find some areas of my code that others (like Mike Barry and BDD) have suggested as improvements and were implemented.
I looked up one of your monitors:
https://github.com/floobydust/Micromon- ... croMon.asmI see you are using the single letter instructions, and I think you have a focus primarily on MONITORING the system. I don't even have a command to look at the accumulator! I think more and more that I am really just wanting an "Assembler", not a "Monitor" so much. Hm.
The jump tables are interesting to me. I don't yet understand their usefulness entirely though. I see we have two things:
RTS is "go somewhere for a bit, and come right back"
JMP is "go somewhere and do not come back"
If I were to "go somewhere and not come back", well that is the next line of code anyways! As in, straight-lining code is itself a long list of "go to the next line and do not come back".
floobydust wrote:
Finally, have fun doing this... and comment everything, as years down the road, when you look at your own code, you'll be scratching you head asking yourself what it all does
Hope this is useful...
Yes it is, thank you very much. I definitely need to comment. I *will* do that soon enough. Right now I'm still experimenting. If this whole code I've been typing gets deleted tomorrow, I wouldn't cry much. I'm still learning, so this is one big tutorial essentially. Comments and efficient will come eventually.
Well, thank you everyone for this so far! I am starting to see that I really just want an Assembler, not an Monitor. Well, monitor is still good and all, but maybe not the first reasoning. I don't care so much about "what is in the accumulator" or "how many clock cycles have elapsed" or "single stepping through code". Instead I'm looking for "write this code, execute, see results" or "download this pre-existing code and run it". A replacement for BASIC, but using Assembly language instead. So, in the very least, you all have helped me see my goals better. Thank you for that.
Chad