Tue Jun 2 09:51:41 CEST 2009
I'm moving back to the previous approach, which is a pattern I've seen
a lot in Forth code:
- set "current context"
- operate on it
This isn't so bad, given that there is no other way to have any form
of data locality. For this we're not going to use the extended
instruction set: just some uniquely named accessors that operate on
the current object in the a register, without changing the pointer.
OK. Replied to GET_DESCRIPTOR, now there's a SET_CONFIGURATION coming
Problem is now that probably again i'm not properly acknowledging this
request, since there is a STALL coming in, and the host gives
It would have been so much simpler if they'd just made it into a
single flat namespace and a uniform RPC mechanism instead of all this
I guess it doesn't get much muddier than this. Interfacing with
hardware that's designed for minimal _hardware_ complexion sucks. You
get all the shit..
So it looks like i don't understand replies yet.. When to set the DATA
toggle for instance.
Enough for today..
Anyways, it looks like this problem is general enough to be solved
with humility and acceptance. It's one of those problems that
seems to be not there. Maybe it's so hard because it actually does
something really important: throwing away the right information.