Discussion: Next steps after Version 1.0

[scotws]

@SamCoVT first, thank you again for all the work. Tali wouldn't be even close to where it is now without you.

The question is what steps are to come next. I'll be scaling back slightly here for the next few weeks regarding any major coding (the rest of my live would like some attention), and would like to use that time to think about how to implement multitasking. My suggestion would be that we create a "stable" non-multitasking branch of some sort for further features and bug fixes, and one where we figure out what words to use etc. I'll open some issues for that.

The other question is if we raise the ROM limit of 24 Kb (22 Kb with space for user words). My suggestion would be to wait to see if there is any feedback on this (I raised it in the posting on 6502.org), and maybe considering a further 4 Kb, so 4 Kb would be left for other stuff. I know you have extra hardware routines, so I'd be grateful for your imput here.

[SamCoVT]

College will be starting up at the end of the month and I have a freshman class this semester, so I'm going to have a lot less free time until summer. I'd like to clean up the tests, but will probably scale back quite significantly after that. I'm quite happy with all of the progress that has been made, and have pretty thoroughly scratched my "I wonder if I can get a better programming language than BASIC that actually runs on my SBC?" itch. I may take a break and try doing some things that actually use Tali.

In terms of the ROM limit, I don't have much besides my serial routines in ROM right now. While I did write a very simple monitor in assembly, I've never tried to merge it with Tali as Tali has most of the things I needed built right in. I suspect the Steckschwein (I hope I spelled that right) folks might be better to ask on that front. 8K seems like a good amount to leave for other people's ROMs, but 4K sounds to me like it might be too small for some people, but I really don't know.

[scotws]

What, actually use Tali instead of writing it? What an odd idea :-).

I know what you mean about scratching the itch, I sort of stared at stuff yesterday and then wandered off to play with another project (emulator for 65816's native mode in Go, not yet ready for GitHub). I'll do some of the smaller stuff here at some point, but a break sounds good. Now that we have 1.0, I really need to flash a new version to the hardware you sent ...

[scotws]

This issue has gotten new life through the discussion at http://forum.6502.org/viewtopic.php?f=9&t=5911&start=0 - we should figure out a way to make Tali more modular, so that the user can pick and choose which parts to install. Of the top of my head, I think these could all be "optional" that way:

• Assembler
• Disassembler
• ed editor (very much so)
• Block editor
• ENVIRONMENT? (because of the string sizes)

This should include an easy way for the user to add their own modules, that is, a more sophisticated version of the user.asc system currently in place.

Of course, this would also mean figuring out some way to test all the various combinations.

I wonder if it would make sense to write an actual configuration program that lets you pick the modules and handles compiling and testing them? Or allow creating configuration files like Ansible (https://www.ansible.com/)? Whichever, it should probably be flexible enough to handle situations like those that @cstrotm has described in #243 with fragmented or limited zero page space. We'd also have to figure out some way to make sure that zero page space is split up correctly regardless of combinations. Enough people have said they want differents parts of the code at different addresses, so that might be something to configure as well.

Also, as @SamCoVT has pointed out, this would probably be a good time to switch to a different assembler, as we seem to have reached the limits of what Ophis can do. The new one should at least be able to work with conditional assembly.

I'm slightly annoyed with Python as the scripting language, because of the 2 vs 3 problem, but also because it seems the language keeps mutating all the time. Not sure I have a better suggestion, as bash would make life hard for Windows users, and Go, though stable, seems like overkill. This might be something for the far future.

Lastly, I still would really like to have Tali include multitasking in some form or shape.

Looking at this list, I would suggest the first step is to convert the existing code to a new assembler, because we can use all the old testing stuff. Then figure out how to create a way of configuring different setups for Tali.

Any suggestions?

[TheTrueForce]

CC65 is quite well-known, and depending on how you go about it, you may be able to use its linker to help modularize Tali. I don't know much about it, though, unfortunately.

[SamCoVT]

Thanks for the suggestion, @TheTrueForce . We are indeed evaluating CC65 as one of the contenders for moving to - I agree that having a linker will make it much easier to relocate things without having to resort to .org statements.

My experience with ripping things out of Tali for Druzyek's project over on 6502.org was actually quite positive - the current codebase mostly doesn't care where things are as along as the labels resolve. I have to laugh a little bit as your list is pretty much exactly what I ripped out, right down to environment? because of all of the strings. I also removed all block support and removed wordlists but then ended up putting them partially back in because Druzyek's project actually made good use of them (for removing a wordlist that was in a paged bank of memory that might not be there all the time). That's an application I certainly did not envision when writing wordlists, but it appears to work well.

[scotws]

@TheTrueForce We've decided on 64tass as the new assembler - once the conversion is done, we'll come back and look at what to do for Tali 1.0.