jonnosan wrote:
1) Cool! BTW any idea what changes would be need to the NB65 API and/or memory usage to make it possible to use as-is under geos?
Hopefully nothing more than what I've outlined, except possibly zero-page usage (see below). It would be nice if it were easier to build without TFTP and TCP, which in my test build accounted for over 2K.
jonnosan wrote:
2) As I'm sure you'll notice, there's a *lot* of opportunity for improvement in the function_dispatcher.s - it really should be table driven, it started as a quick 'proof of concept' hack that has now grown pretty hairy. If you come up with something neater here i'd be more than happy to push changes back into the main codebase.
The trick with all of this, of course, is to find something that could work in any environment: GEOS, Power C and other programming languages, cartridges, standalone programs, &c. without making assumptions about how much control you have over the machine. But it doesn't seem that ugly to me; it's a clearly defined API.
jonnosan wrote:
3) one thing to note - I've ended up reusing some zero page variables in a pretty inconsistent manner, i.e. initially each routine had a seperate ZP location, then decided I to be frugal and ended up then reusing the same 2 (the copy_src and copy_dest from copymem.s) in pretty much everything new. Which has then caused some nasty bugs. So again i think there's a bit of cleanup possible here as well.
I noticed that. But keeping zero-page usage to a minimum increases the number of environments that ip65 can be ported to: you may not have a lot of ZP available, and it may not be contiguous.
jonnosan wrote:
4) the check_for_abort_key could just be stubbed out - it's there (and also in the tftp/dhcp/tcp code) so you can kill something that's not working without having to wait for a timeout, but the timeouts are usually only a few seconds anyway.
I've got it stubbed out now, but it would be nice to have. Maybe something more generic that could be implemented in different ways, i.e. just "check_for_abort". The abort may be a mouse click or a routine to see if a flag has been set.
jonnosan wrote:
5) the ip65 code is not designed to be re-entrant, so you should have a flag to that's set on entry and cleared on exit. otherwise weird things could happen.
Do you mean that I must be careful not to let the polling run if the previous poll ran longer than expected and is still running? Good point, I hadn't thought of that.
jonnosan wrote:
6) what's the benefit over assigning a fixed load address?
Making every possible byte available to GEOS programs. Normally, GEOS programs load from $0400 to $6000, assuming they don't double-buffer the screeen. I ended up with ip65 loading at $3000, although I could have gone up to about $3600. It would be nice if I could figure out how to get the linker to build the code as high in the GEOS address space as possible.
Thanks for the advice; I'm going to go ahead with a proof of concept GEOS program and see what happens.