The above video goes away if you are a member and logged in, so log in now!
ragnarok2040, hello man!
As they are things?
I would like to take with you a doubt, the emulator will be supported to run on DVD?
I ask because I do not use pendrive and had to burn the emulator and the ROMs in DVD to play it on my PS2!
Can not wait to get ready for your emulator can test it.
Yeah, I plan on keeping the old SMS cdvd driver for CD/DVDV support.
It's not easy to program anything on the PS2, really. After "Hello World", you essentially get dumped straight into learning about using the IOP so you can utilize various devices built into/supported by the PS2, then remote procedure protocols, cooperative multitasking, making dma chains, and various other things when you want to squeeze performance out.
If you want to start emulator development, you should look at chip-8/schip, or even start with an NES emulator as these systems are pretty simple, and documented pretty well.
I have a laptop, and another old computer with a small monitor that's collecting dust. The trouble is that trying to code on them with such small resolutions while trying to use an IDE like Codeblocks is hard. Plus, the laptop's keyboard isn't suited for coding marathons, heh.
Yes, and the lack of decent debugging tools doesn't help much either. I've been using gdb/Insight with ps2gdb but the bottle neck offered by the IOP network stack is almost unbearable.
Originally Posted by ragnarok2040
I suspect some stuff to be broken at the latest ps2sdk also; I remeber the last time I played with the TCP support I had some problems, but it could be my fault since I have few experience regarding sockets coding.
I recently thought that unit tests for the sdk could be a good addition to prevent issues to be discovered at late times and to check the health of the current sdk, but without some more colaboration it would be unfeasible to me.
If you use a high-level library like the SDL, your pain is diminished, because you can test your code in the PC also, but even using it, there will be problems.
And there is no way you can develop an emulator using it on PS2, because of speed.
My sugestion, if you want to learn how to code to PS2 and is not a coder with much time in your hands, is to port an SDL small game, so you'll need to learn (and ask for help) how simple parts as reseting (thanks again ragnarok), threads, units and modules work. From there you can start learning the gsKit and native PS2 libs.
Starting directly in the PS2 code is a bit hard, as said before, and I think there is an extra problem: lack of documentation and good examples. Also, the ps2dev.org site is down often - there is a guy doing a mirror of it, and I am thinking in starting a wiki for documentation myself...
There's ps2rd, but I'm not sure how far along it is. Also, ps2sdk has a framework for unit tests in ee/libc/regress. It's mostly for libc regression testing, but I think it would work with any portion of ps2sdk. I don't have much experience with any type of networking code, though. I remember EEUG optimized the smap or tcpip driver for SMS... Maybe it was both...
There's also a couple of other TCPIP stacks for the ps2 called ps2_pktdrv and ps2_afl_pktdrv. The first is GPL which uses the existing smap driver and the second is AFL which uses a custom nic driver.
http://minilgos.perso.sfr.fr/ps2_pktdrv.zip (GPL packet driver source for PS2, based on SMap)
http://minilgos.perso.sfr.fr/ps2_afl_pktdrv.zip (AFL packet driver source for PS2)
Made some good progress today, .
I managed to extend the list code so it's reusable for multiple types of lists, cheats, files, etc. as well as for displaying more than one list. I also completed most of the code for making the various types of lists for the browser. I just need to fix mounting of hdd partitions. For some reason, I mixed up all the partition mounting/unmounting inside of the browser instead of the list code. Separating that out will save me some headaches, . I should be able to shave off a hundred or two lines from the browser code since I'm using a two dimensional array for the path and the gsKit code is no longer needed.
Seems like your making good progress with this. I have been waiting so long for this. One question ragnarok whats the ui going to look like? Is it going to look like snes station or something different? Sorry to ask so many questions im just so hyped for this.
Here's the mockup using the textures I have right now. All these textures are just stand-ins since I need to make some new ones for Snes9x. They're pretty easy to make, however I've been focused on the code portion of the UI. It's essentially 8 images for the boxes, 2 header/footer images, 1 background image, and then miscellaneous images for buttons/scrollbars/highlights or configuration options. The dimensions are still fluid because of the limited amount of vram. For the buttons, I haven't decided if they should just be images, or generic images with overlaid text. The second option would let them be translated via a configuration file, though.
The first box will be the device list, with the second box being the file browser, with the boxes' background being black/dark gray alphablended with the background. The image in the corner will be for boxart or screenshots. There are also two buttons that will be under that for starting a rom and for configuring options. No more secret hotkeys for accessing the configuration options, . The background can be skinned as well, which the UI will overlay. It's white right now because it makes it easier to place things.
The settings screen will look somewhat similar, with categories of settings on the left, and then actual settings in the center. The large box in the center will allow me to create custom graphical menus for various settings, but I can make a new release faster by using the old menu code, which is primarily text-based.
OK nice to know, I wasn't aware of it.
Originally Posted by ragnarok2040
I think in the past I already encountered it but if I recall the core of the implementation was in the EE not totally in the IOP - that allow better speed but I'm afraid it would need some task switching managment that could get complicated at a gbs stub. I'll revisit the code.
Originally Posted by ragnarok2040
BTW: Do you know any code analisys tools targeting C (not C++) that could generate a report list of functions implemented from a set of source files? I ask this since in order to replace the TCP stack from the ps2sdk for this or the SMS optimized, it could aid the process of checking if the replacement needs some function signature change, or to check if there is some function missing. Before looking at the code I suspect it would be straightforward but that tool could help in other situations with other code, so allow me to "take the ride" and ask you : )
Doxygen would do that. The doxy.conf file that ps2sdk uses is a lot old, but it works... for the most part. If you have graphviz, you can define "HAVE_DOT = YES" in doxy.conf to generate call graphs and such. All the docs get generated in a single folder, which makes it hard to find the index.html file. I find the documentation produced by doxygen a bit confusing, too.
There are more options using a newer doxyfile, which you can generate using doxygen -g, but it would need to be edited so it would work with ps2sdk. It supports creating subdirectories, and various other things. There are also a few code analyzers that would probably work with ps2sdk, but they're more or less for bug/security checking rather than lexical analysis...
I actually use a Codeblocks project file I created for ps2sdk when I want to make changes, which allows me to use a threaded search for definitions/declarations among ps2sdk's files. It's probably not helpful if you don't use Codeblocks, but I added it as an attachment. It was made from a March 30th svn build, so a nightly build made after that date might be needed.
You can also just open up Codeblocks and search in a directory without even having a Codeblocks project. You get a nice list of results with the path, line number of the occurrence, and even a short blurb of the occurrence.
If you want to start from scratch, there's also another smap driver in iop/tcpip/udptty with a simple udp implementation. You could probably glue a tcp stack onto it, but I'm not sure how complex that would be.