Fri Nov 2 23:21:38 CET 2007
e2 + interpreter
i'd like to make 'transmit' and 'receive' late bound. that way it's
easy to switch the interpreter's default I/O. but i need to do it
cheaply: using vector.f and execute.f requires too much boot space.
wait.. that's the case for catkit. for the 2620 i have a lot more
room. maybe i should go that route then, and solve the catkit problem
when it poses itself.
time to make some decisions:
* allow both serial + e2 ?
* build e2 in boot loader?
actually, i do need e2 in boot loader. working as a safety
measure. hmm.. let's get it to do what it needs to do first.
ok. i can ping krikit. fixed the saving/restoring of the a reg so i
can access the stack. code upload doesn't work yet. i guess it has to
do with a missed 'ack' due to interrupts being disabled. maybe i
should build in the ack in the fprog?
NOTE: about saving the a reg. if there are interrupts, the a reg
needs to be saved anyway (or it's use protected with cli), so maybe
it's best to just always save on clobber? alternatively, always save
on clobber in isr.
i added an ack to fprog and ferase, but apparently that's not
enough. one line can be written, then it messes up. some code is
needed to properly resync the transceiver after programming so it
picks back up at the next idle INT0.
for debugging purposes, i should make a version that uses polling
only, so it can be used to setup interrupts. thinking about it, i
probably need to modify all opcodes so they give a sync themselves, so
no buffering is required. (uart has 1 byte). hmm.. it's not so simple
actually, it is: all interpreter tokens have RPC semantics: they
return at least one value, except '00' which is a sink, and 'reset'
which can't have a return value. the 'ack' opcode can then be
eliminated, an possibly replaced with 'interpret'.
nop, reset -> no ack
receive -> ack
transmit -> value
jsr, lda, ldf -> ack
n@a+, n@f+ -> stream of bytes, no ack necessary
n!a+, n!f! -> ack
ferase, fprog -> ack
chkblk, preply -> stream of bytes, no ack necessary
this should get rid of the requirement to have buffered io. remaining
timing issues can be handled with appropriate delays.
an interesting extension when 'receive' and 'transmit' are made
dynamic is to have them read from memory. that way a small program
could execute from ram.