Search results

Great news. I gotta have a look at these adapters as well as I should have some 128M XDs hanging around. I found my GP32s a while back. The old trusty 32M RAM version and the FLU one (that is in pieces due half finished SD card project) :blink:

Hmm I haven't tested MacLink on Intel Macs, even if I have one. Any probs with MacLink in general? Cheers, Mr.Spiv

Actually there is no way to 'flag' interrupts from various hardware sources to 940t.. at least none is documented, except that 920-940 interface. I wouldn't be surprised that 920 has to take care of interrupts coming from hardware and then trigger 940 via the 920-940 interface. Anyway, this is...

There is already a nice way to execute raw binaries from linux.. it does not use any particular exploit, just uses existing linux system calls to modify exception vector on fly, load the code and then cause a reset.. work very well. Also.. U-boot will be replaced with something more HH dev...

OSX developers.. devkitGP2X is now also available here devkitGP2X for OSX. <_<

You wish.. <_<

I got an interest for a tlcs900 ARM core.. assuming things go as planned.

for a true hardcore try out the libbfd.a <_<

I'll excorcise the haunted box once I get back to my work place.. i.e. after next week. Sorry.

Well now I don't quite get you.. ld & linkerscripts are able to compile codes belonging to separate address spaces into one binary. That's what I after. Just like GBA guys do it.. their normal code runs in cart rom address space and IWRAM tagged funtions run iwram address space. On start crt0...

I didn't say the loader would load the code but the crt0. Slight difference. After linking etc the crt0 (or some dedicated static lib) has knowledge where the data & code for the 940 is. It is rather trivial to copy that to correct places then. And the start address of the 940 program with this...

Actually.. I'd prefer having the 940 being handled mostly by linkerscript & then managed with some e.g. crt0 provided routines. Something like this: int CODE_IN_940 foo( int bar ) { ... } char DATA_IN940 blaat[] = "mr.spiv takes over.."; And let the linker do the trick with sections and...

You guys are driving me.... maaaaad! :blink:

Aren't there still bits left in the FLAGS byte? I recall so. Only 16MB wasted... :blink: I would rather have 920t code to start 940t.. instead if crt0/loader. IMHO does not belong to a header. Integrating arm-elf-objcopy ? heh.

You can define the memory area the 940t will So in use.. then you also have a register to reset/stop the 940t. So in paper that is pretty straight forward. :blink:

mmapping the code for 2nd core again?

:blink:

Oh shut up! ;)