You might want to look into Forth...

The problem with the 4K isn't the code so much (though certainly a factor), it's the data.

But if you had one task dedicated to the editor (and it's data), one task dedicated to the assembler, and one task as the target for the assembler, you could probably do quite a bit.

The editor would share it's work space with the file to be edited. If it's dedicated to assembly, then you can tokenize stuff and thus reduce the memory footprint. That would also simplify the assembler (since the need for a parser is reduced, though, honestly it's mostly just been moved to the editor). I think you could do an assembler in 4K, including support for labels, you just make it a single pass assembler. Any work data for the assembler is done in the targeted tasks space (rather than within the assemblers task space). Since it's quite unlikely that 4K of source code is going to render down to 4K of machine code, there is space available in the destination for work data structures used by the assembler. And if you run out of space? Well, life in the big city.

I was thinking of encouraging you to experiment with VTL02 as a task, but it is a bit of a resource hog, needing half of page zero and up to about half of page one for its run-time.

Mike B.

Well, VTL02CA2 actually works! I ported it just now as an assembler (don't know if that's what it is?).

I don't understand why tasks should not be allowed to allocate memory owned by other inactive tasks. If you only have 3 active tasks, memory and stack of the remaining 5 inactive tasks is available. These tasks will simply never be scheduled.

If memory managment would be included into the task scheduler (so far I don't see it as a kernel or even an OS) larger memory than 64k could be addressed and each task could get its own 64k including full stack and zeropage. At the same time memory is protected from other tasks and cross task communication and I/O should only be allowed through system calls.

It's just a fun little bare-bones interpreter and editor. Your comments and questions can be directed over here, if you don't want to allow your thread to drift too much.

Yea, I was looking at this in the Github and, yea, whatever this is, it's no assembler -- I'd at least rename the files.

Guys I want to make a 65c22 driver for my machine, but I can't understand WDC's datasheet for their's...
Can someone put the registers' functionality in a lay-man's term's list for me?

The one hosted at this domain is the original MOS datasheet which I've referred to for my projects. It is clear and explains the purpose of the registers well:

http://archive.6502.org/datasheets/mos_ ... v_1977.pdf

What hardware will you be attaching to the 65[c]22? Which features are you going to be writing a driver for? Parallel I/O, shift registers, timers?

I am just making sure i can do a free running timer. In the future, i will also build an onboard rs-232 and i might use the 65c22 asap for a 128x64 glcd.

I give sample code for setting up a 65c22 T1 in free-run mode for a real-time clock using the interrupt-on-rollover in my 6502 interrupts primer, about eight paragraphs below the subheading at http://wilsonminesco.com/6502interrupts/index.html#2.1 . I have sample code (partly in Forth, partly in assembly for my Forth assembler) for a 128x64 graphic LCD interfaced with SPI, at http://wilsonminesco.com/6502primer/Dis ... Acode.html, with a video of a demo.