Suggestions?

[jkotlinski]

Any ideas for how to make durexForth more enjoyable or satisfying?
Is it done now?

[Whammo]

There is still #363

It would seem that durexForth is just getting started.

[jkotlinski]

OK, I will reopen #363, it was perhaps too hasty to close. Are there any particular remaining problems that are bothersome?

[Whammo]

Sorry to bring it up again, but I think it's the dependencies of disk.asm, with ls and v.
I don't know how feasible is separating included from loadb , saveb etc.
And, shifting dependencies to open.fs, dos.fs and thereby io.fs will impact free memory negatively.
Is it bothersome because there's no perfect solution?

[jkotlinski]

One practical reason why INCLUDED, LOADB and SAVEB are in same file, is because they all call _errorchread. All those functions are fairly high-level, they do a lot of stuff and print things on screen.

It is not clear to me how or if they should be done differently. What practical problem would it solve?

One thing that seems odd to me is the naming of LOADB/SAVEB. Why not LOAD/SAVE, or possibly LOAD-FILE/SAVE-FILE.

[Whammo]

Thanks for discussing this with me.
Somehow I got the idea that disk.asm is redundant when io.fs is installed.
It's not, of course.
I think the practical issue is disk.fs not checking for a valid IEC device, i.e. not device 2.

[jkotlinski]

Right, I created follow-up issue for this now.

#499

[IanWitham]

Would it be possible to support REUs for the editor buffer? This could free up that memory area for programs to use without destroying the "c64 native" development experience.
The buffer could be banked out to the REU on exiting the editor and banked back in on resuming the editor.

[jkotlinski]

I agree that the RAM footprint of editor buffer is not nice!

Getting any benefit from the REU would require fairly major rework.

An easy improvement could be to:

• move editor buffer to $d000-$dfff (as this RAM is now unused)
• reduce max editor file size to 4096 bytes

Obviously, it is not that nice to reduce the max file size. On the other hand, maybe it is not all bad either, to encourage small files?

A future editor could be screen-based, and allow any file size, by operating in chunks of 1024 bytes.

[Whammo]

The Dictionary is relocatable as is value buffstart in v.
It is entirely possible to use different memory configurations for editing and compiling,
and switch between them with one word.