Hacking Need detailed technical information

[Killermech]

The only one I actually know that has some kind of direct contact with them (other than the Chinese users), is Costello.
Maybe he could be able to arrange something, like gathering the most important questions the programmers might have and e-mail them regarding them.

 

[Alynna]

It appears to me that all the initial code for ARM7/ARM9 interface is in system3.dat. I don't think anything in there is anything BUT the SDK interface code but could someone confirm for me?

If that is confirmed, i'd say we should decompile it and see what it is doing, after that is understood, we should rewrite the SDK and create our own system3.dat.

I bought the DSTWO because it seemed to me that openness was promised for the DSTWO, and I am disappoint.

 

[loby]

As I know, tools\ds2_firmware.dat is the initial and communication code for ARM7/ARM9 interface.
It seems that the file system3.dat has no use in program.

 

[Alynna]

ok thank you.

Right now I am setting up a dev system to make an attempt to port Frodo (C64 emulator) to DSTWO. I will look at the Dingoo port first to see how straightforward it is.

Right now alot of my plans are shot down just because I did get in touch with king d but he didn't really give that much more new information on the DSTWO, and many of my desired homebrews need wifi, for example i want Pidgin on the DS, as well as to port OSes. I may try to port AROS without networking but I can't see it being very useful without the networking stuff.

 

[Alynna]

I wanted to give an update since it was asked...

I am no longer attempting to port Frodo, I am writing a new emulator from scratch. The new emulator is currently called "ECh64" and it is an emulation of the Chameleon 64
The bad news is that it will take longer, as I am simultaneously working on it for Windows, Linux and DSTWO (by making I/O seperate from the machine emulation)..
The good news is that when its done it will be more like an OS that also emulates a C64. You can read the link for what Chameleon 64 is and I will echo what the features I am planning to place in the DSTWO port (the Windows/Linux ports will have everything..)
My code is being split into non-platform specific (the emulator itself) and platform specific code (The user interface). My goal right now is to make ECh64 for Windows first, then change the platform specific code for DSTWO and others. Because the UI is really just a bunch of glue, it should be fast to write that part. Probably using LibBAG for the I/O layer.

* The extended VIC-II emulation
All features of Extended VIC will be emulated, including 256 color modes, and 256 BlOB (sprite) modes.
Also a 256x192 DS native mode will be supported. Modes over 256x192 will be scaled, probably with LibBAG method.
* 8 megabyte REU (In DSTWO RAM, normal chameleon is 16mb REU, however I need to save some space for the emulator itself, so 8 megabytes is reserved for the MIPS code and data)
* 4 megabytes GEORAM will be emulated.
* MMU allowing access to 24 Mbyte DSTWO emulation area using 4 KByte blocks.
* Turbo function with full 6510 emulation and illegal opcodes, speed modes will be 1mhz, 2mhz, and Fastest possible (which will vary on emulation speed)
I am planning to write the 6510 core in MIPS Assembler to squeeze every last cycle out of it.
* DLDI access (software compatible with MMC64)
* Cartridge emulator with support for everything a real Chameleon 64 has
* Diskdrive emulation (1541 compatible, so fastloaders/speeders will work) -- Note that during disk access Turbo modes will slow down due to the additional CPU emulation.
* Keyboard and mouse emulation on touchscreen and DS controls, bottom screen will be reserved for emulator, not the Ch64 environment.
* 16 MBytes of user writable flash rom for firmware updates and storage of custom roms - Like Chameleon 64, but will be a flatfile on the MicroSD.
* Stereo SID chip emulation
* If DSTWO team ever gets their act together and gives us wifi access, RR-NET emulation will be supported over WiFi.
* Possible: Extended BASIC interpreter exposing additional features to users of Chameleon 64 and ECh64 emulators.

By doing this I feel not only do we get a good C64 emulator but we get a neat environment to create new apps in. Not to mention it'd just be more interesting for me to code. For all the work I have to do to get Frodo working in DSTWO, might as well do something right.

At this time I am not planning on cycle-exact emulation, but I am planning on instruction-exact emulation, which means I/O will be updated after every instruction, not mid-instruction. This may result in less then perfect emulation but you should be able to still see all mid-scanline effects and the speed will be excellent. For well over 99% of purposes this will work well. Perhaps I will add a cycle-exact core into the emulation but the overhead may be unacceptable. However, maybe with the power of DSTWO it won't matter.

 

[spinal_cord]

Any more news on this project at all?

 

[Ace]

Seems like no. The guy has been offline for over a month.

 

[Buleste]

Creating a brand new multi system emulator based on a Beta FPGA card that is based on an uncompleted multi 8/16 bit system emulating FPGA board has got to be harder than converting an existing emulator and then adding on extras (like SuperCPU emulation).

 

[Alynna]

While I am working on the emulator I am no longer working on it for DSTWO, at least not for now.

I can only hope that sometime in the future the DSTWO SDK improves and '0.13 beta' does not remain the only thing they release.

I can't really do what I wanted to do on DSTWO. The lack of network access is a showstopper for me. Most of the things I wanted to do (except the ChaCo emulator) requires some sort of internet access.

Sorry. I'll revisit this when the SDK is updated.

 

[Recorderdude]

While I am working on the emulator I am no longer working on it for DSTWO, at least not for now.

I can only hope that sometime in the future the DSTWO SDK improves and '0.13 beta' does not remain the only thing they release.

I can't really do what I wanted to do on DSTWO. The lack of network access is a showstopper for me. Most of the things I wanted to do (except the ChaCo emulator) requires some sort of internet access.

Sorry. I'll revisit this when the SDK is updated.

...and so, we can add Alynna to the "fix the goddamn SDK if you want me to work" list, along with Alekmaul.

Get to work, SC team.

yeah, like that's happening. The SC team hasn't updated anything besides EOS and Fireware for compatibility for a long time and probably doesn't plan to.

 

[Alynna]

or they could open the hardware specs enough for us to make our own SDK, instead of keeping us in the dark about whats happening on the ARM9/ARM7 side.
I bought the DSTWO because it seem it'd have strong homebrew support (from the SC team) and I am disappoint.

 

[pcmantinker]

My apologies for reviving an old thread, but I too am curious how the SDK works. Does it merely use the MIPS processor and feed data to the DS's ARM processors? If the MIPS and ARM processors could be accessed directly at the same time, the DSTWO could have quite the potential for great homebrew applications. I bought my DSTWO with the hope to use both the MIPS and the ARM CPUs simultaneously. It would be very nice if the SC team would release the source for their SDK.