search

SamCoVT / TaliForth2

A Subroutine Threaded Code (STC) ANSI-like Forth for the 65c02
Other
29 stars 5 forks source link

Illustrates a 12K config in a 16K image #42

Closed patricksurry closed 5 months ago

patricksurry commented 6 months ago

Makes disassembler an optional word, and strips out some strings to create a workable py65mon image in $c000-$efff

Also corrects a couple of typos, and updates some comments/memmap picture in py65mon config to match the defs.

SamCoVT commented 5 months ago

Also, just FYI, you don't need to resolve conflicts with generated files like the labelmap, listing, binary for py65mon, or test results - I will regenerate all of those while merging. They are kept in the repo to help with troubleshooting so that I have the listing and labelmap that correspond to a given version and can do A-B testing, but they will always conflict if I push changes while you are working on a branch.

patricksurry commented 5 months ago

I think I responded to all your comments, and resolved the obvious ones. Others I left open with discussion above.

Without removing see (which I agree is better) I needed to save a few more bytes to stay under 12K so I made ctrl-n/p history buffers configurable. This also frees up the associated 1Kb of buffer RAM which will come in handy for my app.

The optional inclusion of forth_user_words is not ideal, but I couldn't see a better way of conditionally removing the startup strings there, since we want them to stay by default. I could just note that config in the minimal platform file so people can decide if they want to undo it?

SamCoVT commented 5 months ago

This all looks good. I'm in the process of merging it now. Just one note - if you are that close on bytes, Tali tends to drift in size by +/- 2kb or so, so there may come a time when this minimal platform file doesn't work anymore and there is no testing for that, so it will be a silent failure. I see you've already added a warning if it overlaps the py65mon I/O. I did also just merge your s\" improvements (including reduced size), so that gives you a bit of breathing room for now. I think my plan is to not worry about it until someone complains about it.

You're welcome to add an extra word to allow see and its strings to be removed, but you'll have to open a new pull request if you want to do that.

I might go back and add a comment on what the xi business is doing in strings and maybe give that variable a clearer name - it looks like it could be confusing if you don't know what it's doing. I do like that solution, though, as it allows items in the middle of the table to be removed and all the following strings shuffle up.

patricksurry commented 5 months ago

I like having see there, so I'm fine with that. Agree about the potentially silent failure - but hopefully that warning will at least give someone a clue what's going on. If people end up using the minimal config we could start considering whether new features should be opted in or out of it to keep the size down. But let's see if people use it.

I considering both lowering the start address and/or using non-default py65mon magic IO addresses higher in ROM (e.g. $ffxx instead of $f0xx) but the latter seems a bit of a barrier to beginner usage. Also I like the idea of keeping under 12K within the top 16K of memory ($c000) since that's a kind of normal config someone might build hardware for. Anyway, lots of options I guess.