Let's make an OS together! [KERNEL ALREADY DONE!]

[Klaus2m5]

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.

[BigEd]

GARTHWILSON wrote:

You might want to look into Forth...

A couple of ideas from that, without going to far as to switch to Forth:
- many Forths deal with code as a series of screens. You load a screen, you edit the code, you save the screen. That means blocks of about 1k of source.
- several 8-bit machines offer edit-in-place. Instead of dealing with a buffer of text, displayed dynamically on screen, supporting insert and delete, you just have a print routine to update the whole screen, you allow cursor movement, accept keys by overtyping, and then when ENTER aka RETURN is pressed, you re-interpret the current line. (And maybe by some heuristic also the previous line, if the current line looks like the last part of a longer line.)

What that gives you is something which looks a bit like a full screen editor but is actually more like a one line buffer. Much simpler and probably less memory-hungry too.

[Gradius2000]

whartung wrote:

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.

A Line-by-line Tokenizing Interface would be quite nice... I'll finish the basics and try that out!
Edit: has anyone even been looking at my github? I'm editing the assembler on there...

[Gradius2000]

Need help with the MoreStack Routine I want to add!
I want a code that uses the accumulator as a bitmask, but for every zero, extend the stack, like so:
A = 1,0,0,0,0,0,0,1
the last bit is first in a byte, so;
if it is 1, make it the default task, and goto the extend stack routine.
if it is 0, make the task unreachable, and not the default, loop and find the next 1.
the extend stack routine:
for every zero found, make that task unreachable, which will allow for more free task space on the task first found.
Does that make sense?

Edit! Never mind, it does to me now.

[Gradius2000]

barrym95838 wrote:

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 figured out that if you stop a task, you can overtake its stack and just use it! Therefore, VTL02CA2 actually CAN use that much page 1!
Currently this works, just that it requires a system restart when you want the task to stop.

Klaus2m5, thank you for your code on github! I modified it so it fits my taskswitcher! However, page 0 has been used so that the os has problems with tasksp, so I decided to remove it as of now (9/5/17).

[barrym95838]

Gradius2000 wrote:

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

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.

Mike B.

[Gradius2000]

Klaus2m5 wrote:

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.

I saw what you meant and added a stack manager. Now the task switcher calls the mmu program to make sure no stack pointers interfere with other running tasks! What you said was already doable even without this; this mmu just fixes memory overflows.

Anyway, I decided so far NOT to use an actual MMU chip because it makes machines quite large, and my goal is a MINIATURE laptop sort-of-machine.

[whartung]

barrym95838 wrote:

Gradius2000 wrote:

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

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.

[Gradius2000]

whartung wrote:

barrym95838 wrote:

Gradius2000 wrote:

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

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.

Already did.

[Gradius2000]

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?

[Aslak3]

Gradius2000 wrote:

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?

[Gradius2000]

Aslak3 wrote:

Gradius2000 wrote:

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.

[GARTHWILSON]

Gradius2000 wrote:

Aslak3 wrote:

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.

[Gradius2000]

GARTHWILSON wrote:

Gradius2000 wrote:

Aslak3 wrote:

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.

Good! Might use both!