6502 multitasking

[tebe]

org $2000

tasks equ 2

main

/*
 Initialize TASK
 copy current stack to TASK1.STACK and TASK2.STACK
*/
cld

tsx

ldy #0
cp
lda $0100,y
sta task1,y
sta task2,y
iny
bne cp

// init stacks

lda >task1.init
sta task1,x
lda <task1.init
sta task1-1,x
lda #$a4
sta task1-2,x

lda >task2.init
sta task2,x
lda <task2.init
sta task2-1,x
lda #$a4
sta task2-2,x

// init stack pointers

:3 dex
stx task_point
stx task_point+1 

/*
 Initialize NMI vector
*/
lda $14
_wai cmp $14
beq _wai
 
sei
lda #0
sta $d40e
sta $d400

mva #$fe $d301

mwa #nmi $fffa

mva #$40 $d40e


// LET'S GO 
jmp task1.init


/*
 NMI routine
*/
.proc nmi

bit $d40f
bpl vbl

dli rti

vbl
sta rA+1
stx rX+1
sty rY+1

sta $d40f


// OLD TASK

tsk ldy #0

lda task_stack,y
sta _dst+2

ldx #0
_src lda $0100,x
_dst sta $ff00,x
inx
bne _src

tsx
txa
sta task_point,y

lda rA+1
sta task_regA,y
lda rX+1
sta task_regX,y
lda rY+1
sta task_regY,y


// NEW TASK

iny
cpy #tasks
bne skip

ldy #0
skip
sty tsk+1

lda task_stack,y
sta src+2

ldx #0
src lda $ff00,x
sta $0100,x
inx
bne src

ldx task_point,y
txs

lda task_regA,y
sta rA+1
lda task_regX,y
sta rX+1
lda task_regY,y
sta rY+1

rA lda #
rX ldx #
rY ldy #
rti

.endp


/*
 TASK NO.1
*/
align

.proc task1

stack
.ds 256

init
jmp start

start
lda #$88
sta $d01a
jmp start

.endp


/*
 TASK NO.2
*/
align

.proc task2

stack
.ds 256

init jmp start

start
lda #$26
sta $d01a
jmp start

.endp


task_stack dta h( task1 , task2 )
task_point .ds tasks
task_regA  .ds tasks
task_regX  .ds tasks
task_regY  .ds tasks

;---
run main

opt l-
icl 'align.asm'
icl 'xasm.asm'

mtask.zip

[Dr. Van Thorp]

Could you give a little information about what this code does? Are you just switching out stack and register information in to a block of memory? Is this interupt based?

[danwinslow]

Well, I've been looking at it, and it seems to be driven off of one of the NMI interrupts, and he is doing full page stack copies on context switch. There are 2 tasks set up. The basic idea for multitasking is to preserve the stack and all of the CPU registers for each task, and then copy them down for a context switch. In practice page zero locations, at least some of them, need to be preserved as well, due to the fact that page 0 is used as virtual registers a lot.

[analmux]

For bigger programs you'd also need to copy the zeropage registers.

 

But if you run 2 (or maybe 4) small executables then you can also split the stack area (page 01) in two (/four). You'd just have to backup stackpointer values. I think I've seen this kind of split-stack multitasking once.

[TXG/MNX]

Nice to see interest in multitasking

 

Here a nice project...

 

Lunix (open source 6502 assembler)

 

Lunix already support 32 processes and tcp/ip, slip, ppp and such...

Would rule when someone could port something like that to the 8-bit with WARP4 support

[mos6507]

The last Lunix update was 4 years ago. The project is dead.

 

I think general multitasking on the 6502 is not that useful because you will run out of CPU time to do anything meaningful at once (or memory).

 

On a 20mhz 65816 it would be a different story.

[Fröhn]

On a 20mhz 65816 it would be a different story.

Especially because a 65816 doesn't need to copy the zeropage and stack.

[Garak]

The last Lunix update was 4 years ago.  The project is dead.

 

No, it isn't dead at all. The newest release (v0.21) came out on September of last year. It still is being updated currently albeit slowly. At least the C64/C128 versions are being worked on. Link: LUnixTNG

 

I think general multitasking on the 6502 is not that useful because you will run out of CPU time to do anything meaningful at once (or memory).

853812[/snapback]

 

Possibly. Now if one looks at the Contiki OS however...

 

Garak

[danwinslow]

I *have* looked at contiki. It's very cool. If I get my ethernet thingy working I am going to mod contiki to use it.

 

As far as multitasking goes, they are probably correct that something like a full fledged MT OS is impractical. However, a very thin, non-preemptive task switching system is practical. There would be a main thread, and then background service threads ( possibly interrupt driven ), but no large amount of tasks, memory protection or virtual memory as such.

Edited May 12, 2005 by danwinslow

[mos6507]

The last Lunix update was 4 years ago.  The project is dead.

 

No, it isn't dead at all. The newest release (v0.21) came out on September of last year. It still is being updated currently albeit slowly. At least the C64/C128 versions are being worked on. Link: LUnixTNG

 

 

Yeah, but look at what it's being used for:

 

screenshots

 

I'd rather see some multitasking programs in which the individual programs are fully featured and graphical.

[danwinslow]

I'd rather see some multitasking programs in which the individual programs are fully featured and graphical.

 

Well, so would all of us, but thats a tall order on an 8 bit atari. Maybe you shoudl go write one for an IBM PC with 1GB memory and a p4 processor. Oh wait, its been done.

[mos6507]

I'd rather see some multitasking programs in which the individual programs are fully featured and graphical.

 

Well, so would all of us, but thats a tall order on an 8 bit atari. Maybe you shoudl go write one for an IBM PC with 1GB memory and a p4 processor. Oh wait, its been done.

854600[/snapback]

 

My point is that when you consider all of the single-tasking 8-bit software that uses the full capabilities of the machine, writing a multitasking kernel without writing anything to use it beyond simple shell programs that do directory lists or stream out text files like some kind of dumb terminal is kind of a step backwards in the end. I do like how Lunix does runtime relocating of the binaries, which prevents you from having to alter your sourcecode. I bet it makes the loading a lot slower, though. It's a step in the right direction but it's not enough.

 

With ConTiki they thought about the applications first and the multitasking was just a means to an end.