4dsdev
Views: 614,208 Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search 11-24-17 05:17 PM
Guest:

Main - Posts by coto


coto
Posted on 05-22-15 10:09 PM, in hi Link | #150
well hi everyone.

I'm very new, just registered.

Currently I decided to sign here because I didn't earlier and well, let the code begin!

cheers

coto
Posted on 05-23-15 04:19 PM, in hi Link | #153
thanks guys

also it seems something I ve been doing for these 2 years is nearly completion. Maybe

coto
Posted on 05-24-15 08:35 PM, in Staplehax -- Ninjhax with kernel access Link | #157
Posted by profi200
I just registered. As long as this place doesn't get flooded by GBAfail trolls i will stay.

And on topic: Nice work :)


I just read this, can't be more 100% agreed.

Let's hope the staplepowers vanquish most useless trolls / crap posts ever born. There is way too much talent around to let it go because of children.

-

To do not derail this topic I would like to add something:

besides the rainbow ponies I want to know if the 3DS has mirrored FCRAM addresses , (NDS does with MPU and cached areas) because that speed ups most emulators. Like from 2% to 80%. I mean the physical linear memory the MMU takes to create protected pages of virtual addresses.

coto
Posted on 07-10-15 08:48 PM, in Homebrew random stuff! (rev. 3 of 07-11-15 01:35 PM) Link | #255
Well this thread is for sharing experimental code that does whatever. If you're one of those who write random homebrew or quick snippets of code that would later be added to release projects, well this is a nice thread to share with!

My ARMv4 dynarec:

https://github.com/cotodevel/armv4core/

it runs on NDS, emulates the ARMv4 Core very nice. I use it for debugging Homebrew/GBA Games (by restoring the stacks/ewram from some GBA emu memory dump). Supports PC relative fetches from memory (apparently ok), and it's full of bugs. But works.

I'm looking forward your future homebrew projects as well!

ciao

coto
Posted on 08-09-15 08:19 PM, in Staplehax -- Ninjhax with kernel access Link | #300
refactor is the key when a project-s purpose has been defeated. Reuse code

coto
Posted on 08-09-15 08:35 PM, in blargSnes -- SNES emulator for the 3DS (rev. 2 of 08-09-15 08:45 PM) Link | #301
Posted by StapleButter

2) distribute processing more. Server runs most of the emulation, and things like PPU/DSP writes are sent to the clients, and everyone handles PPU/DSP emulation. This would mean less data to transmit and thus less overhead, but also requires something to keep everyone in sync (for things like software vs hardware PPU, faster New3DS, etc...). While PPU emulation could be separated reasonably well (most of its interaction with the system can be separated from the rendering process), DSP has the issue that the game can choose to read back from it-- in this case, you end up with multiple instances of the DSP which might have produced different results.



how about a command overlayer that reads cpu, ppu and dsp cycle timings, and if certain timeline is met (be it snes cpu cycle profiling), a command is sent over network, so the other client updates with a loss of one frame-interval (taking frame 60 for receive/sync/update emulation cycling on client, from server). So snes emulation would be stopped for that frame (so no desync problems arise) then restored

for example server loops/executes the main core, but override input to p1, while client executes main core but overrides input to p2.

edit: though for syncing , this would require accurate tracing of how many cpu cycles eat each opcode execution. something like polled cycle sync

this is a fairy tale idea ,i know


coto
Posted on 08-18-15 09:24 PM, in blargSnes -- SNES emulator for the 3DS Link | #337
isnt that related to broken services?

coto
Posted on 08-22-15 12:43 PM, in So in the end, where is this going? Link | #362
So this means this board should only be about 3DS engineering?

Because imho I really like talking about DS engineering.

coto
Posted on 10-09-15 12:39 PM, in DSi reverse-engineering? Link | #462
I too like DS reverse-engineering / virtualization, so I would like to talk about stuff like this and not only 3ds-only related stuff.

So I support this thread idea

coto
Posted on 10-27-15 08:36 PM, in blargSnes -- SNES emulator for the 3DS Link | #581
cool stuff staple.

coto
Posted on 10-28-15 08:08 PM, in Possible board merge Link | #593
I'd prefer the seriousness separated from more relaxed stuff. I am one of those guys that when is developing, prefers to have focus on the matter.

So if there's serious threads for research/development as long they are moderated OK / well respected among users then I don't mind..

coto
Posted on 11-05-15 10:01 PM, in blargSnes -- SNES emulator for the 3DS Link | #690
Nice find. Some blackscreens are by unimplemented banked interrupts of some nature (external chip latching the source counter) which happen synchronously/asynchronously by the time the CPU access that register.

ie the source interrupt latch happens once the CPU access the register once, against the source interrupt latch regardless CPU access. (effectively causing the CPU to enter IRQ/NMI mode when desired)

coto
Posted on 11-09-15 04:39 PM, in blargSNES: event scheduler design Link | #699
About the IRQ that may trigger an event after set, and then would be unset right before the IRQ cycle count IRQ says it would be triggered:

spinlock_sched() runs on any hardware IRQ (for example vblank) handler. (or at least in a process that runs separately from the cycle counter thread)

process_id = you assign one up to 10 or any other number
u8 status = 0/1 (enabled/disabled)
callback = (u32)&handler pointer
spinlock_createproc(u8 process_id,u8 status,u32cback_ptr new_callback) //allocate a process

spinlock_modifyproc and spinlock_deleteproc should speak for themselves

-

//if set to 0 it will run the handler registered / 1 it wont
spinlock_perm(u8 process_id,u8 status)


-

SPINLOCK.H
http://pastebin.com/Hzg5FAuf

SPINLOCK.C
http://pastebin.com/Jqeam9kX

Very basic I know, but it really works.

For example if you want to run process #0 registered Only on scanline # 100 and #110
currentscanline_thread(){

if((scanline == 110) || (scanline == 100)){
spinlock_perm(0,0);
}

}

//then later on scanline end
nextscanline_thread(){
spinlock_perm(0,1);
scanline++;
}

coto
Posted on 11-17-15 10:18 AM, in Possible board merge Link | #738
i see, well I will try to repost whatever useful i'd/will write then.

coto
Posted on 03-05-16 09:27 AM, in blargSnes -- SNES emulator for the 3DS (rev. 2 of 03-05-16 09:28 AM) Link | #975
heres some wild ideas:

1) move planar 2 gpu opcodes to ARM9, so arm11 only cares about cycle processing and send commands (flush, gpu, sound and emulator commands).

how? make an overlayer (like gbaemu4ds handles exceptions), so you will have to ROP ARM9 right before it goes to sleep waiting for interrupts, so it would have to jump to your gadget (command handler) (which could be @ 0x00080000 AXI WRAM ) . This would mean saving CPSR and doing a stackframe snapshot (saving r0-r7,r11,r12,lr), then on exit these would be restored .

So ARM9 cpu would:

handle 3DS services first
rops
enter command handler ( implement planar 2 linear opcodes, for example, here)
exit
goes to sleep

as for the IO map that would be some shared memory between ARM11 and ARM9 .


edit: use GNU C to compile ARM9 gadgets (you implement emu stuff there as well)

also dont discourage. You are a great developer.

coto
Posted on 03-05-16 09:53 AM, in blargSnes -- SNES emulator for the 3DS (rev. 2 of 03-05-16 09:54 AM) Link | #977
ah. I confused VRAM banks with GPU memory

https://www.3dbrew.org/wiki/Memory_layout

"ARM9 Physical memory regions", my mistake!

But my point still stands. I actually have done something like that before (for an experiment with gba code)

coto
Posted on 05-10-16 01:29 AM, in Possible board merge Link | #1015
Posted by StapleButter
the 'merge' would mostly be 'redirect all activity to Kuribo64 and repost the important shit there', although that would be a good occasion to update the tutorials and other junk


as for being careful, Kuribo64 isn't a total cesspool either, it mostly has the same moderation standards as this place (see, Margen67 was banned ages ago for example)


technically: this board would be replaced with a 'go to Kuribo64' page with a timed redirect
IRC post reporting would need some tweaks too (Kuribo64 posts are reported to its official channel which isn't #3dsdev)
this would reduce maintenance, too


I still wonder if it's worth the effort though, given the state of the 3DS scene

like ive said a few times before, yes I support the idea!


coto
Posted on 08-22-16 10:44 AM, in Hey everyone! Link | #1073
cool!

coto
Posted on 10-12-16 08:08 AM, in Big server update (rev. 2 of 10-12-16 08:11 AM) Link | #1105
Come to think about it, everything loads a bit faster. Good work :D


edit:

"Possible board merge"
http://4dsdev.org/thread.php?id=98&page=2

SQL Error

Apparently the ID per page was either not found or not tied to actual content


Main - Posts by coto

Page rendered in 0.019 seconds. (2048KB of memory used)
MySQL - queries: 22, rows: 97/97, time: 0.011 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2017-11-20)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.