Maybe I am doing too much. It's true, I say "Ah I have the space on the screen!" without considering the user friendliness side. Hm...

As for the single letters, yes I agree, but here I am trying to make it fancy. A whole FOUR letters, wow, big time. This board is not for pro's, by any means, so I'm trying to make it friendly. And whole words are friendly. But screen clutter is not necessarily friendly.

I'll be pondering on this BDD, thank you. Good analysis.

Chad

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

If you're the only user, then "user friendly" is whatever makes you happy. If you like that arrangement and it works for you, there's no need to change it.

When I get around to implementing 80 column text for my C640 computer, and write a monitor for it, there's a good chance I'll end up with a more 'cluttered' screen myself. I used to work on games for Playstation 2 and 3, and I greatly miss the debugger that we had on those systems. The user could partition the main window into any number of panes, and select what was displayed in each: registers, different blocks of memory, disassembly, source code, console output, and so on. There was an option to have them update, and even edit memory, while code was running. We could set up a number of screen layouts for different kinds of debugging, and instantly flip between them. It was wonderful.

I love Linux to no end. And those commands make perfect sense to me... now. Yes, I had the learning curve as well.



I do not plan on being the only end-user here. I have bigger plans. But I am also not expecting someone to spend years of man-hours on this system, like I have on Linux. Just as BASIC has it's own style, as does COBOL, so too can any 'language'. I'm a C guy, but even I know that they overuse their symbols.



Got a name for that debugger? Would love to check that out!

Attached is some pictures of what I did to modify it to what BDD was talking about. I like it! But I am now being tempted to fill up that right side of the screen again!!!

Chad

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I'm pretty sure I'd go the other way - a front panel has lots of lights and switches because you need to be aware of and control all the state.

When debugging, a view which includes a recent instruction trace, a view of zero page, the relevant part of the stack, and relevant parts of memory - both in hex and characters - should help to see what's going on.

I think Kowalski's simulator shows this kind of effect. As do some of the in-browser offerings - for example Floooh's visual6502 remix. Although I'm sure I've seen an even better example somewhere.

The model for me is that of the 747 cockpit or the Apollo capsule - the aim is for an expert to have complete mastery. Expect a learning curve. (The opposite idea would be the snack vending machine, where any novice can wander up and get what they want.)

Unlike a cockpit, it can be helpful to have more than one alternate layout - as seen upthread, one for digging into memory and another for digging into code.

ProDG. But it was only available to developers, and required a devkit. I would be very surprised if it was possible to acquire it legally now.

Hmm, I don't know how feasible this idea is, but i might as well share it anyways.

instead of trying to squeeze everything onto the screen at once, why not have a system similar to browser tabs that you can switch between with using the F keys?
for example the default "tab" on F1 would be your fullscreen main memory viewer/editor, F2 could be the Zero Page and Stack, F3 could be your disassembler.
if you're feeling fancy you could have all of them update even when not visible, so you don't need to re-enter a command to see changes. i could imagine that being useful for single-stepping code using another function key or similar (example: sit on the ZP/Stack tab while steeping through, switch back to the Disassembler tab and see where it's executing now).
and if you're feeling really fancy you could allow the user to use the arrow keys to go through memory and edit values directly so they technically don't need to use the basic view/edit commands at all if they don't want to.

damn, i might need to write my own monitor at some point, this sounds like a fun programming challenge...

You mean like this?



Very true. I am doubly seeing this as my 'operating system'. Computers from the 80's used BASIC, I'm wanting to stick to Assembly-only, yet still have 'macros' like loading from disk/tape/card, etc. This isn't DOS/UNIX because I'm not moving files around, but I am moving data around. Instead of 'dir/ls' I have 'page'. Instead of 'mv' I have 'move'. Etc.



Excellent distinction. Haha, I don't know if I'll ever look at snack machine the same now, lol! I'm going for something in between I suppose. A car's dashboard is probably close to what I'm thinking. Useable by most everyone, but still needing a bit of training. (I still can barely use the UI on my newer car...)

John West, checked that out and found it. I of course can't dig very deep with DuckDuckGo search images, but it's at least an idea. Thanks.



Love it! I will be really considering as I keep going forward. Right now I type "CODE" to enter into Assembly mode, but if I just hit F2 or whatever, yeah, that'd be nice. Maybe have the option for both. Right now the ESC key kind of resets, exits, and clears whatever you were doing, so I kinda have a function key for that already.

The arrow key thing I had last time. I do like it, and might go back to that. Good idea. Options without clutter.

So, attached are some new pictures. Implemented BDD's suggestion for the 'ascii' characters. Thing is, if you look close enough, they aren't ascii. They are PS/2 keyboard values. I have been rollin' without ascii this entire time, and so far it's ok. It's heck to do things in a normal assembler, but that's ok because I use C to convert everything back and forth anyways. This particular screenshot is where my assembly lookup table touches the help menu text.

I also switched the bytes and Assembly code, looks closer to BDD's examples, and then added another 'cursor' to help visually.

Lastly, I added a 'string' sequence in the Assembler. It is crude, because you cannot use the literal anywhere you want. Once you use it, it goes into a 'string mode' and that's it, no extra functions. So things like:

LDA #'Q
will not print:
LDA #$15
but will print:
$15
only.

But it's at least a step in the right direction.

Thanks for the suggestions, this is exactly what I needed, and still need more of

Chad

EDIT: Just re-added the memory 'cursor' code, using arrow keys to move it around. The new function BYTE $XX changes the byte at that location (does not increment). I also defaulted older functions to use the cursor location if no other parameters are specified. Attaching the code, again read at your own risk (dying kittens and all that).

EDIT2: Just added the FIND $XX command, which highlights (inverts) one particular byte value in the memory dump. I'm nearly approaching "done" status here. I probably aught to comment now.

This will be the last update for a while, because... I commented my code!

Attached are some pics, and my mostly-fully commented code. Finally!

So I made the arrow keys work again, and I added the "FIND $XX" command, which inverts the color of whatever byte you want to find. It's still very readable, and it's not too obtrusive, so that's a good compromise. There was some type of bug in the assembler, but I think I fixed it, because I'm not seeing it mess up anymore. It was kind of strange for a bit.

I'm tired of commenting If I do make updates, it will be labelled as "Monitor3" or something. I plan on putting in SD card support, and perhaps I can modularize my code some more and make it better functioning. While commenting, I noticed I had a LOT of copy/paste which I could simply down to a couple simple subroutines. Hm.

Whelp, that's it! Thanks everyone, I appreciate the input on this project. After SD cards I think I'll try a video game, finally

Chad

if you want you can check out the Commander X16's FAT32 library:

https://github.com/commanderx16/x16-rom ... /dos/fat32

Excluding the "mkfs" function it comes out to a total of ~7.3kB of code and it says it uses around 5kB of RAM.
I haven't tested it myself yet, i've only done very basic SD Card stuff in C using 65SPI, like initializing the card and getting the satus registers.

If you don't want to use a premade library you can check out this SD Interface tutorial i found:
http://www.rjhcoding.com/avrc-sd-interface-1.php
The only AVR specific thing are the "SPI Transfer" and "Wait" functions, which are simple enough to convert to software SPI or 65SPI, and whatever onboard timer you got, if any.
The entire thing is also written in C so you can either use C as well or translate everything into assembly.

either way i wish you good luck with SD stuff!

Well done Chad, thanks for the update and sharing the commented code!

I honestly thought this would have taken longer.

Finished SD card reading! Writing to the SD card won't be much different than what I'm currently doing anyways, but I'm undecided on a command name as of now.

Attached is the bird I transferred over from the SD card into the 6502 computer. It took about a minute, super slow in comparison to what it *could* do, but I have long delays built in and whatnot.

Also attached is the (commented) code. I altered the SPI stuff a bit to allow for enabling whichever device I want at the time.

Proxy, your link here was super helpful:
http://www.rjhcoding.com/avrc-sd-interface-1.php

Also I went through George's (gfoot) tutorial here:
https://github.com/gfoot/sdcard6502

Thank you very much George! That tutorial was PERFECT.

And of course, I referenced the famous Elm-Chan tutorial:
http://elm-chan.org/docs/mmc/mmc_e.html

The only issue I was having was that the MSB on R1/R3/R7 was high, which was definitely bad. I searched around and found that if I 'pump' the clock (even while CS is high) some amount of times (80 times here, like George) before EACH command, then it would work. And work it did. That little issue took hours!

Last night and this morning I was trying to decode the addressing for the read command. I figured it out finally, I need to think in "blocks" not "bytes" basically. Lastly, I tried to research FAT32 format, and failed big time. I'm so lost! So whatever, I came up with the idea to simply make an SD Card image file, and burn it directly to the SD card on the desktop:
https://www.embeddedts.com/blog/how-to- ... s-mac-osx/

So for me, I used the command:
sudo dd if=Demo1.bin of=/dev/sdg bs=512 conv=fsync

That put the bird data up top. Then I read the first 128 BLOCKS of data (that is 32K in bytes) from the SD card and put it into RAM. Then just pushed the RAM into video RAM and there you see the bird! The very top weirdness is just zero page, stack, I/O, expansion, and RAM variables.

Last stuff:

So now that the SD card is working so well, I'm re-thinking my audio data 'cassette' input. I love it, I want it, but it's not as useful all the sudden. Still, I will probably keep it in the next revision for educational sake. I'm only using the left channel for data IN, so I might use the right channel for data OUT, that would be fun to test! Beep boop beep! Another thing is that I will not be putting two DIP-8 EEPROMs on the next revision, now that I can use SD cards for a similar purpose (once I get the write function complete that is). There is still a use for one of them though, at least. And then I've been talking with Garth about 3V3 SPI, so I am going to attempt to change one of my SPI-10 5V's to SPI-10 3V3 instead. So then I would have one of both. And lastly, I'm still debating if I should use diodes or not with the color resistors for the VGA output. Bill's (plasmo) colors look great, crisp. But then I really like having 16 colors and not just 15 colors (maybe I'm just weird). We'll see.

Thanks everyone! Have a wonderful day!

Chad

We already talked privately, but nice job!


I think it's still really neat to have done, and doesn't rely on modern technology like the SD card does.


I was going to suggest on the other thread, if you make your PCB have pluggable sockets here, you could avoid soldering the resistors and/or diodes, and be more flexible down the road. You may also find that you can lay out both circuits on the same PCB, sharing as much as you can, and just not populate some of the components if you find you prefer it one way or another.

That was a super idea George! I did something in between, but still down this road. Attached is a picture from KiCad of what my VGA color resistors look like. As you can see, I have the option to switch from resistors to diodes. I checked both formats on falstad.com and they seem roughly the same in intensity. Resistors make more pastel lights and darker darks, diodes make brighter lights and even darks.

Again, thank you for this, and all the rest of your help, directly and indirectly.

So as y'all can see I'm in the process of making my 'Rev2' board already. And, I have some interesting add-ons I'm planning on including. More to come later, thanks!

Chad