New DC emulator

[rhay]

New DC emulator: http://dknute.livejournal.com/

The page's in Polish so if you don't know it (and you probably don't), there are still some numbers and screenshots that may be of your interest.

It may be fake, it may be real. I dunno. I'm just giving the link.

Please don't ask me about the project itself, because neither am I in any way related to the project nor I know the person behind it.

[dynamicVoidMain]

Cheers, thanks for that.

I'm leaning on fake without even looking at it, but I'm the sort of person who likes to be proven wrong with good news


edit: Looking at it, it isnt really promisign to run soul calibur at 60fps with high definition with onlie mode, its still showing off box tech demo's, so my new stance is that its real.

[JKKDARK]

It only runs some homebrew demos. Anyway, I will wait for the public version.

[Hard core Rikki]

Originally Posted by JKKDARK

It only runs some homebrew demos.

Is SAID to run homebrew demos, allow me to correct. Still sounds fishy to me, as most aspects of emulation are pretended to be fixed over 80%, apart sound.

Suxx0rz too bad Dreamcast still isnt emulated after such a long period.
This whole emu scene seems to be plagued by source code "losses", early project abortions (supposedly lack of motivation), and proprietary lockin (GPL guarantees continuation).

Hell, for all these, exists "THE Final Solution" : Reverse Engineering !!

If it's okay to revengine big softs from big corps, I dont see any reason not to remake an emu from scratch by learning from a discontinued + undocumented one.

[Robert]

Does it have a name besides "Dcemu"?

[-=TRIXSTAR=-]

Originally Posted by Hard core Rikki

If it's okay to revengine big softs from big corps, I dont see any reason not to remake an emu from scratch by learning from a discontinued + undocumented one.

Woop!
*Sits down and shuffles nervously in chair*
Seriously though rev-eng 'ing all that info would be completely pointless.
In the time it took a team to reverse (an anywhere near decent) emulator
they may as well code they're own!
Its often not hard, just time consuming and ,well, quite frankly boring.
RevEng'ing isnt the answer 'freedom4knowledge' loving authors are...

Unless the prize is high enough (rarly emulated machine)or you're
doing it to learn from it, it simply isnt worth it.

__________________
Making friends and fighting people.
Fighting round the world.

---

Last edited by -=TRIXSTAR=-; October 31st, 2006 at 11:53.

[JKKDARK]

Originally Posted by Robert4

Does it have a name besides "Dcemu"?

I hope that they change this name, because there is a great emulation forum called dcemu

[Hard core Rikki]

Lets hope this emu exists actually, or else it'll probably be known as D-Outcast and their 'makers' as D-Outcast Team.

[blueshogun96]

Hmmm, so far it sorta looks real to me... but I'm not going to get my hopes up just yet. Best wishes though.

__________________

[Sagat] Windows XP x64 Pro | AMD Athlon 3000+ (~2.0GHz) | NVIDIA GeForce 6600 PCI-E | Realtek AC97 Audio | 512MB Ram | NVIDIA NForce 4-4X chipset | Seagate HDD 160GB | LG 8614 DVD-ROM | HP DVD 1040d CD/DVD -/+ RW w/ LightScribe
[Raylene] HP dv2000 | Windows Vista Home Premium | Intel Core2 Duo @2.2GHz | NVIDIA GeForce 8400 GS 128Mb (Dedicated) + 1264Mb (Shared) | 3GB Ram | 220GB HDD

GeneralEmu - December 27, 2005 and beyond!
My programming, emulation and Xbox blog! - Click or die! (Updated Sunday, October 26, 2008)

[tuesday20102001]

web page translator for the link in polski http://www.translation-guide.com/fre...ish&to=English

__________________
PC desktop hardware:
processor: Intel Celeron D 340 Prescott 2.93GHz (over clocked at 166Mhz).
Motherboard: ASRock P4i65G Socket 478 Intel 865G Micro ATX Intel Motherboard.
Video card: AGP: PowerColor 9550 GameFX card.
Audio (PCI): sound blaster audigy SE.
Memory: 1gb PC 3200 DDR.
Hard Drive: SATA.
operating system: dual boot windows xp sp2, kubuntu-6.10.

[KanedA]

wow, I'm impressed... it's too much text to translate at this moment (I'm kind a very very busy...) anyways it's called dcemu because... author doesn't have any idea for name translated from this:

Originally Posted by dknute

W założeniu mam tu pisać o postępie prac nad projektem emulatora konsoli Dreamcast. Nie miałem pomysłu na ładną nazwę, a katalog trzeba było założyć, więc zostało "DCemu".

Originally Posted by dknut

Uprzedzając kilka pytań: Nie, ani wersja skompilowana, ani tym bardziej kod źródłowy nie są publicznie dostępne. To pierwsze będzie jak emulator osiągnie stan w którym można przynajmniej spróbować odpalać gry z obrazu/CD, to drugie pewnie nigdy nie opuści mojego PCta.
Wymagania to Windows 2000 (bo takiego mam, na XP wydaje się także działać) i procesor zgodny z Pentium 2. Oczywiście, cokolwiek poniżej Athlona XP to proszenie się o kłopoty
Do tego DirectX 9c, sensowna karta graficzna (mam Radeona 9800XT). Nie są wymagane, póki co, shadery, ale jak karta nie umie _szybko_ wykonywać operacji typu "render to target surface", albo ma problemy z dynamicznie generowanymi teksturami i konwersją między typami, to będzie rwać. GeForce4MX 400 ma z tym problemy...

Translation:
Before you ask: No, there's no compiled version of this emu, just as source code isn't available for public. There's a chance for compiled version if (or rather when) it be able to start games from CD/iso, source code probably will never be released to public. What you need is system based on Pentium 2 processor (but anything below Athlon XP is just getting trouble), DirectX 9.0c, some reasonable gfx card (i have an Radeon 9800XT). So far you don't need shaders, but if your gfx card can't handle operations "render to target surface" (and do it fast) or has problems with quick rendering of dynamic textures and convertion between types, emulation will be cho0opy. And yes, GeForceMX 400 has problem with above.

well... that's all I can do now

__________________

[rhay]

Stan emulacji na chwilę obecną:

ARM7 SPU: 5% (czytaj: praktycznie brak)
SH4 CPU/rdzeń: 95% (działa, co nie znaczy że nie ma błędów)
SH4 CPU/układy: 75% (na razie wystarcza, ale brak RTC, DMAC i TMU robią to co najważniejsze, SCI(F) mógłby mieć własne okno, MMU nie ma i raczej nie będzie, itd.)
PVR2: 80% (2D: trudno to określić, bo nie wszystko działa zgodnie z oczekiwaniami)
PVR2/TA: 50% (3D: TA jest emulowany i działa przez SQ i DMA, oraz zapis bezpośredni - sposób w jaki to zrobiłem nie jest idealny... może da się szybciej... no i chwilowo dopuszcza jedną teksturę tylko
Maple: 80% (jako szyna danych, bo np. obsługi kart pamięci nie w tej chwili wcale, kwestia zrobienia "wtyczki" która będzie emulowała konkretny typ urządzenia)
ASIC: 80% (ponieważ jest praktycznie nierozerwalnie powiązany z PVR2, był pisany równolegle, DMA np. działa tylko do znanych urządzeń)

Rdzeń jest interpreterem, bo rekompilator nie ma obsługi FPU (tzn. ma, przez interpreter i poza tym wykazuje może 30% wzrost wydajności. To jest z pewnością wina słabego rekompilatora, ale głównie tego że interpreter mi wyszedł bardzo udany. Niestety, oba nie radzą sobie z samo-modyfikującym się kodem. To się da zrobić, ale to poważnie spowolni emulację. Czekam z tym na jakąś motywację, np. jak się okaże że BIOS przez to dalej nie idzie, to dorobię.

Zakończyłem właśnie pewien etap prac nad obsługą kontrolerów gier (przez DirectInput) i póki co jestem z zadowolony z efektu. Oto obrazki z tego co już można zobaczyć:

(screens go here)

W DCQUAD da się grać :P

Present state of emulation:

ARM7 SPU: 5% (read: almost nothing)
SH4 CPU/core: 95% (works, which doesn't mean there are no bugs)
SH4 CPU/devices: 75% (sufficient for now, but there's no RTC, DMAC and TMU do what's most important, SCI(F) could have it's own window, MMU doesn't have and is not likely to get one, etc.)
PVR2: 80% (2D: hard to say, because not everything works as expected)
PVR2/TA: 50% (3D: TA is emulated and works through SQ and DMA, direct write - the way I did it is not perfect... possibly it could be faster... and as of now it supports only one texture
Maple: 80% (as a bus, because e.g. memory cards are not supported now, it's a matter of making a "plugin" which would emulate a concrete device type)
ASIC: 80% (because it is almost inextricably connected with PVR2 it was written simultaneously, DMA for example works only for known devices)

The core is an interpreter because a recompiler doesn't have FPU support (well, it has by inrepreter and it shows something like 30% of performance gain. This is for sure the fault of a weak recompiler, but mostly because the interpreter came up very nicely. Sadly, none of them handle self-modifying code. It can be done, but it will slow down the emulation. I'm waiting with it for some motivation, e.g. if it turns out that the BIOS freezes beacause of it, I'll fix it.

I've just finished a stage of work concerning game controllers support (through DirectInput) and I'm satisfied with the results. Here are some screenshots of what can be seen:

(screenshots go here)

DCQUAD is playable :P

Walka z SPU


Dorwałem się w końcu do dokumentacji zestawu rozkazów rdzenia ARM7, która zawiera coś więcej niż listę dozwolonych mnemoników. Co prawda wiedziałem to już wcześniej, ale lektura utwierdziła mnie w tym przekonaniu - sensowny kod na te procki jest w stanie wygenerować tylko kompilator. Każda napisana w asemblerze przez człowieka procedurka będzie już po kilkunastu linijkach mniej optymalna od tego, co zrobi maszyna. System kodowania rozkazów jest naprawdę zdrowo pogięty.

Niestety, żadne dostępne mi źródło nie precyzuje czy w DC siedzi rdzeń ARMv4 czy też ARMv4T. Trzeba jednak podejść do problemu optymistycznie - zrobię emulację ARMa z wykrywaniem próby przejścia w tryb Thumb. Jak na tym kiedyś wyleci to trzeba będzie zaimplementować...
Jedno szczęście że szacowana docelowa prędkość emulacji ARMa to ok. 10Mop/s. To oczywiście wszystko kosztem czasu dla SH4 i PVR2

Myślę że zrobienie prostego 1-krokowego interpretera zajmie mi ok. 2 tygodni do miesiąca. Mam nadzieję że będzie już wtedy dość stabilny by go zacząć optymalizować - ostatecznie pogięty czy nie, to dość prosty procesor. Zupełnie inną sprawą jest dopracowanie modułu AICA i uruchomienie go na DirectSound, ale być może zrobię to równolegle.

Jest kupa demek, w tym działający już (ale krótko Asteroids, które przestaną wreszcie wylatywać na assercie w libdream.

The fight with the SPU

I finally got my hands on ARM7's core instruction set, which contains something more than the list of allowed mnemonics. I knew it before, but the reading reassured me that only the compiler can generate a resonable code for this processors. Any little procedure written by human in assembler after few lines will be less optimal than what a machine can do. Instruction coding system is really weird.

Unfortunately none of the sources available to me says precisely, wheter DC has ARMv4 or ARMv4T. But the problem should be approached optimistically - I'll do the emulation of ARM with detection of trying to go into Thumb mode. If it crashes at this, it will have to be implemented...
Fortunately estimated target ARM emulation speed is something like 10Mop/s. Of course at expense of time for SH4 and PVR2

I think that doing a simple 1-step interpreter wille take me about 2 weeks to month. I hope that it will be stable enough to try optimize it - wicked or not, it's a quite simple processor. Finishing up the AICA module and running it on DirectSound is a compleatly different matter, but maybe I'll do it simultaneously.

There's a lot of demos, including working (though shortly Asteroids, which will stop crashing on libdream assert.

Wieści z frontu


Weekend był średnio udany - miałem kupę zajęć które mnie odrywały od projektu. ARM7 emuluje na razie tylko rozkazy skoków Widzę tu już pole do popisu dla rekompilatora. 2-rdzeniowe procki by mocno zyskały na podziale zadań na wątki... Rdzeń 1 by wziął na siebie SH4 i główną pętlę, rdzeń 2 ARM7, PVR2 i ogólnie najbardziej czasochłonne odwołania do DirectX. Trzeba to jeszcze przemyśleć.

W końcu jednak przeniosłem obsługę odwołań do pamięci na nowy system, który obmyśliłem jakiś czas temu. Zyski prędkości emulacji rdzenia to jakieś 20% Niestety, zje to przyszła obsługa ARM7, choć może nie w całości. Znalazłem też kilka wrednych błędów tu i tam (zachciało mi się CMOVa w rekompilatorze, no...).

Z przełomowych odkryć - jak zrobię 2 najbardziej "pomysłowe" grupy kodów rozkazowych ARM7, to potem będzie już z górki. I jak się okazuje - nie tylko ja popełniam błędy. Czasem to kod który emuluję jest zwalony, tak jak w przypadku demka "256b.bin", które korzysta nagle z rejestru R6 którego wcześniej nie ustawia. Może to pora na zrobienie systemu łat na kod, oprartych o CRC obrazu dla procka?

News from the front

The weekend wasn't too succesful - I had a lot of things that took my time from the project. ARM7 emulates only jump instructions now I see a field for the recompiler to show off. 2-core processor could gain a lot on dividing the tasks... Core 1 could handle SH4 and the main loop, core 2 ARM7, PVR2 and generally the most time consuming DirectX calls. This needs another thought.

I finally moved memory access calls to a new system I came up with some time ago. Core emulation speed gains are around 20% Unfortunately, future ARM7 support will consume it, though maybe not all. I found some nasty bugs here and there (I craved for CMOV in a recompiler...).

As for breakthroughs - when I make 2 most "ingenious" groups of instruction codes ARM7, it will be over the hill. As it comes up - I'm not the only one who makes mistakes. Sometimes the code I emulate is messed up, as it was with "256b.bin" demo, which suddenly uses R6 register, which it doesn't set earlier. Maybe it's time to make code patch system, based on CRC of image for processor?

Wiem, że nic nie wiem


Rdzeń ARM potrafi już wykonywać większość operacji logicznych, zostały do zrobienia rozkazy mnożenia i te przeklęte transfery blokowe. Emulacja na poziomie 5 MIPS pochłania potworne ilości procka... no nic, trzeba zrobić krok w tył żeby potem wyskoczyć naprzód. Chciało by się jednak już zobaczyć efekty tej pracy :]

Szalenie mało informacji jest dostępnych o module AICA. Zależnie od źródła, ARM7 chodzi na 45 lub 22,5 MHz. Zapis rejestrów AICA po bajtach też jest upierdliwy w obsłudze (lub raczej: muszę to zrobić inaczej, żeby było szybciej). Same rejestry zaś są 16-bitowe, ale leżą na adresach wyrównanych do 32-bit, tak więc w pierwszym odruchu zrobiłem po prostu tablicę podwójnych słów. Teraz jednak coraz bardziej zastanawia mnie co kosztuje więcej - te kilka(naście) cykli procesora więcej na zamaskowanie adresu do słowa itp., czy choćby jedno nietrafienie w pamięć podręczną L1/L2, które kosztuje kilkaset cykli. A wszystko do L2 nie wejdzie, ba, ledwie procenty wszytkich struktur się tam znajdą :|

Nie da się cały czas siedzieć nad jednym problemem - a przynajmniej ja nie potrafię. Tak więc zajrzałem przy okazji do rekompilatora SH4 i przypadkiem odkryłem że źle dekoduję numery rejestrów w rozkazie FIPR. Ten sam błąd był w interpreterze.
Do tej pory jedną z nierozwiązanych zagadek było co za bzdurne struktury (ściany bez punktów) BIOS wysyła do TA na starcie. Teraz już nie są bzdurne i ok. 350 punktów zaczyna generować obraz startowy Dreamcasta Bez odpowiedzi od SPU i bez obsługi wielu tekstur na tym jednak się kończy, także "zakręcone logo" na pewno nie pokaże się wcześniej niż zrobię porządnie dźwięk. Tak w sumie to pewnie najpierw będzie słychać, a potem widać :P

I know that I know nothing

ARM core can do most of logical operations now, multiplying and those damn block transfer need to be done. Emulation at level of 5 MIPS absorbs huge amount of processor... well, you need to make a step back, to leap ahead. I wish there were some visible effects of the work :]

Hardly any information is available about AICA module. Depending on the source, ARM7 runs at 45 or 22,5 MHz. Writing to AICA registers per byte is a pain in the ass too (or rather: I have to do it other way, so it is faster). The registers are 16-bit, but they lay on 32-bit aligned addresses, so I instinctively made a table of double words. But I'm thinking what is more expensive - those few more processor cycles for masking the address to word etc., or even one miss into the L1/L2 cache, which costs few hundred cycles. And everything won't fit into L2, only few percents of all structures will go there :|

It's impossible to work on one problem all the time - for sure I can't do that. So I took a peek at SH4 recompiler and I accidentally found that I'm incorrectly decoding register numbers in FIPR instruction. The same mistake in the interpreter.
Up till now one of unsolved mysteries were nonsense structures (wall without points) that BIOS send to TA at startup. They are no longer nonsense and about 350 points are beginning to generate start image of Dreamcast Without response from SPU and no multiple texture support that's it, so the "curly logo" won't show up before I do the sound. I think that it can be first heard and then seen :P

ARM nabiera rumieńców

Emulacja rdzenia ARM7 nadal kuleje, ale są już programy które go nie wywalają. Wstępna komunikacja SH4<->AICA została więc nawiązana :]

Efekty widać na obrazkach poniżej, KOS/libdream przechodzą przez inicjalizację SPU i idą dalej:

Teraz należałoby podpiąć to pod DirectSound i sprawdzić czy gra, czy charczy

BIOS, pomimo programu na ARMie, nie idzie specjalnie dalej. Albo emulacja jest zbyt kiepska, albo czegoś mu jeszcze brakuje. Z większych rzeczy pozostała w zasadzie obsługa GD-ROMa, która jest obecnie kapkę szkieletowa. Pytanie jednak brzmi, czy wystarczy rozwinąć obecne HLE, czy trzeba to będzie zrobić od postaw na I/O. Czas pokaże...

ARM starts to blush

ARM7 core emulation still limps, but there are applications that don't crash it now. Preliminary SH4<->AICA communication has been established :]

Effects can be seen below, KOS/libdream goes through SPU initialization and goes further:

(screenshots go here)

It should get plugged into DirectSound to see if it plays or buzzes

BIOS doesn't go anywhere further, despite ARM programm. The emulation is too poor or it's still missing something. From bigger issues, only GD-ROM support is left, which is a bit skeletal now. The question is whether it is sufficient to evolve HLE, or it has to be done from the groud up on I/O. Time will tell...

---

Last edited by rhay; November 4th, 2006 at 21:07.

[rhay]

Czemu BIOS robi wszystko po swojemu?!

Ech, późno już i nie ma się co rozpisywać. Kupę błędów poprawiłem, zarówno w ARM7 jak i (o zgrozo) w SH4. Do tego drobne poprawki w module PVR2/TA i cały dzionek spędzony nad implementacją zapętlonych kanałów ADPCM w AICA.
Muszę sobie zrobić parę dni wolnego od projektu...

Teraz dobre i złe wieści. Dobre są takie że GD-ROM to jest w praktyce napęd ATAPI, więc da się to zaemulować na warstwie I/O zamiast HLE - dokumentacji "ogólnej" jest pod dostatkiem. Złe że to mimo wszystko kolejny moduł do napisania od zera, a jest jeszcze tyle rzeczy do zrobienia...

Why BIOS does everthing it's way?!

Well, it's late now, so I won't write much. I fixed a lot of bugs in ARM7 and (also!) SH4. Additionally few patches in PVR2/TA module and a whole day spent on implementing looped ADPCM channels in AICA.
I need a few days of break...

(screenshots go here)

Now good and bad news. Good are that GD-ROM is in practice ATAPI drive, so it can be emulated on I/O layer instead HLE - there's enough "general" documentation. Bad news are that another module needs to be done from ground up, and there are still so many things to be done...

[KanedA]

małymi kroczkami do przodu

little step by step to perfection

__________________

[Bigshot]

I don't get it.

[mxgmer]

He seems to have grasped that software can interpret the GD-rom! or at least that's what I get out of it...I often thought so after reading the tech on them but I'm not a software geek by any means. I'm sure it can be done with modded CD-roms but if he can do that with software he's an F'n genius and my hats off to him. Keep the translations coming. This is one to keep an eye on IMO.

[KanedA]

Originally Posted by Bigshot

I don't get it.

be more specyfic

__________________

[skid]

Originally Posted by mxgmer

He seems to have grasped that software can interpret the GD-rom! or at least that's what I get out of it.

Sounds more like he can emulate the GD-ROM, which means that he can get the software to read off an ISO image/CD. The part that gives it away is the HLE bit. He would never have considered reading a real GD-ROM from a CD-ROM drive using HLE.

The ATAPI drive bit means that the GD-ROM is similar enough to an ATAPI drive that he can use the ATAPI documentation to emulate the GD-ROM using ATAPI's I/O commands.

[Bubbafat]

Hey id be happy if it loaded cd's. It saves hassle and stress

[Chuckdawg]

Well I must say, it's great news to hear that people are still taking their time to develop a Dreamcast Emulator. I certainly cannot wait for this to happen. It would be lovely to play Sonic Adventure 2 again, oh how I miss that game. On other circumstances I would also love to play Shenmue 2. I've seen great progress with Chankast, so at least we know it's very possible to see Dreamcast Emulated. However, we also need to face the facts. It'll be awhile before we see one running really good. Just look how long it took SEGA Saturn at least, and it still isn't 100% complete, but looking mighty fine. Who knows though. I'm still waiting for that one Dreamcast Emulator that is suppose to run quite alot of games. I believe it was the one that was re tooken over by the one who was suppose to develop ICARUS. However, I could be incorrect about this. Well anyways, sorry about the long post.

__________________

Original Image Copyrighted by Antony LeVay and The Church of Satan.
Note to the Admins: Sorry for the first sig that was too big, I have made it smaller to fit your demands.