g – a multitasking OS for Ultimem/VICMIDI (WIP)

[pixel]

Phew! Killed processes release their resources now. Multitasking is quite a slow process but optimizing things would be a great mistake that early. There's now an VICMIDI image (VICE got problems with Ultimem sized ones) instead of an executable. http://hugbox.org/pixel/external/denial/g.zip

How it works
The core (aka kernel) is located in the +3K area. RAM bank 0 contains the master core. Every launched process gets its own copy of the core with per–process data to eliminate the need for bank switches for calls to the core. If you link a shared library instead of the core via the function at $0400 it'll also get its own core so it can link libraries as well. All in all every process or library occupies at least 16K RAM. The benefit of that is that each process or library could use up to 34K RAM. Accordingly calls to a library come with the overhead of banking. Again, lots of room for optimizing memory usage.

Multitasking… the task switcher saves the zero page from $0000–$008f, the stack starting from the stack pointer and the current bank configuration.

Am trying to keep the README at https://github.com/SvenMichaelKlose/g updated.

[groepaz]

VICE got problems with Ultimem sized ones

please report them so it can be fixed

[pixel]

VICE got problems with Ultimem sized ones

please report them so it can be fixed

Sorted.

[pixel]

"launch" can now wait until the launched process has been killed.

Can now "halt" processes or "resume" them.

[pixel]

Added target "vic20g" to the cc65 C compiler, cloned at https://github.com/SvenMichaelKlose/cc65g

[pixel]

34K address space looks like a pretty bad idea. Comes with too much overhead. Will move the core's code to $a000 to get some peace for doing the file system.

[pixel]

Codepage 437 – the IBM PC ROM charset reduced:


cc65's stdlib is doing odd things like trying to print char 0 or blocking I/O after a single console char read/print cycle. Otherwise there'd be a shell already.

[groepaz]

beware: there are two fundamental problems with using the cc65 libs in a multitasking context:
- it uses kernal I/O, meaning an occasional CLI is executed when you dont want it (eg in CHROUT)
- the cc65 library is not reentrant

i rewrote a couple of those things for my little multitasking experiment (click) back then, you'll probably have to do the same.

[pixel]

beware: there are two fundamental problems with using the cc65 libs in a multitasking context:
- it uses kernal I/O, meaning an occasional CLI is executed when you dont want it (eg in CHROUT)
- the cc65 library is not reentrant

The cc65 part doesn't use the KERNAL and every process gets its own zeropage (not including the KERNAL area) and stack.

i rewrote a couple of those things for my little multitasking experiment (click) back then, you'll probably have to do the same.

Nice and fast!

[Mike]

Codepage 437 – the IBM PC ROM charset reduced: [...]

I know it's difficult enough to design something remotely readable (read: bearable) in 4x8 pixels, and besides the fact that the glyph '[' is errorneously doubled, but ... that font just looks hideous.

Also, the inclusion of the graphic characters of CP 437 is questionable at least. The font is going to live on a bitmapped display anyway. Any 'graphic' elements that go beyond the letters, numbers and symbols of pure ASCII could be drawn directly. Finally, the choice of or restriction to ASCII surely won't be an impediment for implementing a shell.

[pixel]

Codepage 437 – the IBM PC ROM charset reduced: [...]

I know it's difficult enough to design something remotely readable (read: bearable) in 4x8 pixels, and besides the fact that the glyph '[' is errorneously doubled, but ... that font just looks hideous.

It went through some typographical adjustments. Never mind.

Also, the inclusion of the graphic characters of CP 437 is questionable at least. The font is going to live on a bitmapped display anyway. Any 'graphic' elements that go beyond the letters, numbers and symbols of pure ASCII could be drawn directly. Finally, the choice of or restriction to ASCII surely won't be an impediment for implementing a shell.

It's about compatibility with Unix (terminals). I've done that charset long before I joined Denial. As for the graphics:

They're too damn wide–spread to be ignored.

[pixel]

Looking better. Who thought that RTS and RTI store addresses on the stack differently? cc65 is doing fine.

[majikeyric]

[Mike]

It went through some typographical adjustments. Never mind.

O.K. That being cleared up, here's another one for you in g/src/core/dev/con/charset-4x8.asm:

Code: Select all

[...]
; t
    %0000
    %1000
    %1100
    %1000
    %1000
    %1000
    %1010
    %0100
    %0000
; u
[...]

(... actually, I went to insert the glyphs of ASCII 32..126 into an unsuspecting MG Text Edit to compare two instances of a Lorem Ipsum text, and found out about this. Judging from your example picture, that should be two rows of %1000 in the middle ...)

[pixel]

(... actually, I went to insert the glyphs of ASCII 32..126 into an unsuspecting MG Text Edit to compare two instances of a Lorem Ipsum text, and found out about this. Judging from your example picture, that should be two rows of %1000 in the middle ...)

O.K. But please take a look at this new set: