|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
Goto page 1, 2 Next |
Author | Message |
---|---|
|
Emulicious Update Available
Posted: Thu Mar 09, 2017 11:43 pm Last edited by Calindro on Sat Sep 23, 2017 11:26 am; edited 1 time in total |
Due to some unfortunate circumstances I'm a bit late to announce this on here:
There's an update of Emulicious available since last week. Instead of loading a BIOS file from Emulicious's path only you can now freely choose your BIOS files from the Emulation menu of a system. Another addition is Everdrive Emulation. You can load an Everdrive OS file and run your games as if they were run on an Everdrive. The emulation also mimics the known flaws so it can be used to test whether a rom would run properly with an Everdrive or not. Another advantage is that the OS actually gets executed and therefore the state of the emulated system should be closer to the state of the actual system with an Everdrive. Last but not least, the Memory Editor got an upgrade. It is now possible to select and modify multiple bytes at a time. Additionally, copy&paste functionality has been added. The interaction between the Memory Editor and the Debugger has been improved as well: A context menu has been added and the highlighting from the debugger is shown there as well now. Users of Emulicious can receive the update via the automatic update system, if they haven't yet. And others can find a download on: http://emulicious.net/downloads/ Edit Sep 23th, 2017: The most recent update is announced here: http://www.smspower.org/forums/16568-EmuliciousUpdateAvailable#99646 |
|
|
Posted: Fri Mar 10, 2017 9:43 am |
Thanks for the constant improvements!
I've been debugging a lot lately and making my code work on real HW would have taken a lot of time and trail-and-error if it wasn't for this excellent emulator. |
|
|
Posted: Fri Mar 10, 2017 10:14 am |
this is my emulator of choice, also because it's emulating screen borders behavior like no other :) | |
|
Posted: Fri Mar 10, 2017 8:29 pm |
So does that mean you reverse engineered (or otherwise got details for) the Everdrive interface? It'd be nice to make some custom loaders to work around some of the issues in the official one, if I had the time :) for example maybe a search feature to reduce paging. | |
|
Posted: Sat Mar 11, 2017 10:10 pm |
THANKYOU VERY MUCH CALINDRO !!!!!
For update and improve Emulicious, :) Great ! |
|
|
Posted: Wed Mar 15, 2017 6:59 pm |
Yes. Do you mean a file search? Currently the emulated FAT only contains the currently loaded file so there's not much to search through. |
|
|
Posted: Wed Mar 15, 2017 8:06 pm |
Before trying it I imagined you might present the user's system disks as a virtual file system, like /c/users/etc... which would then make it more flexible to mess with the OS - but then again the native file picker is more friendly. The former would be really interesting for making homebrew capable of accessing the SD card - since we'd want it to present multiple data files. | |
|
Posted: Sun Apr 02, 2017 3:30 pm |
A small update of Emulicious has been released.
VRAM watchpoints can now be added via the Memory Editor and the Breakpoint Window. In the Breakpoint Window a VRAM watchpoint can be created by prefixing an address with 'v'. Additionally, the file "WhatsNew.txt" has been added. |
|
|
Posted: Fri Apr 28, 2017 8:25 am |
Hello,
Is there a way to make emulicious debugger not halt execution on ROM entry point? By the way, great emulator! Coding for the SMS would be way worse without it :) |
|
|
Posted: Fri Apr 28, 2017 12:25 pm |
But, does it play Titan - Overdrive 2? http://www.pouet.net/prod.php?which=69648 | |
|
Posted: Fri Apr 28, 2017 5:06 pm |
Why should it? Mega Drive is not emulated by Emulicious. | |
|
Posted: Fri May 05, 2017 12:02 pm |
Hi gligli, I've added an option for that to the Run menu. Sorry that it took a while! |
|
|
Posted: Fri May 05, 2017 12:59 pm |
Hi, thanks a lot! That's awesome support for an emulator that is free :) | |
|
Posted: Fri May 05, 2017 8:39 pm |
Again and again, thankyou Calindro !!!! | |
|
Posted: Tue May 16, 2017 12:28 am |
I have an example program that runs correctly under Meka but fails under Emulicious.
|
|
|
Posted: Tue May 16, 2017 6:26 pm |
You can use the Error Breakpoint "Break on invalid VDP access" to identify why your program doesn't run correctly. You can enable it in the Breakpoints Window accessed from the menu of the Debugger. | |
|
Posted: Tue May 16, 2017 7:02 pm |
Hello, I think you are writting port (c) on C2, C4, C8 and CA too fast, then with VDP constraits activated it is not working correct, maybe you can insert an NOP instruction before OUT (c), x
In others emulators you don't emulate VDP data corruption. Emulicious is really outstanding ;) |
|
|
Posted: Wed May 17, 2017 5:29 am |
Yes that's why I check with it too :) The question is is this actually a timing violation? As you pointed out, Emulicious is flagging a timing violation where you indicate but this routine has been discussed in this thread: http://www.smspower.org/forums/16620-IsThisVRAMVRAMCopyRoutineSafe where it's mentioned it (probably?) has been tested on real hardware. The code snippet is this: ld c,__IO_VDP_COMMAND outer_loop: push bc ld b,a inner_loop: ; must yield opportunities for an interrupt to occur di out (c),l out (c),h in a,(__IO_VDP_DATA) out (c),e out (c),d ;;;;; EMULICIOUS FLAGS VIOLATION out (__IO_VDP_DATA),a ei inc hl inc de djnz inner_loop Emulicious flags a timing violation at the point indicated above. As far as I can see, there should be no violation on successive VDP COMMAND writes? The reads from the VDP DATA register seem to be sufficiently separated. |
|
|
Posted: Wed May 17, 2017 7:17 am |
Any access to vram requires a 26 cycle before hitting the vdp again including writing to registers.
Consecutive register updates alone are fine which is why you are not getting an issue earlier. The violation is happening on the line prior to the one you have marked and emulicious is flagging this after execution. You need to update the code similar to this to avoid the issue. You can re arrange the code for minimal hit at the expense of readability. inner_loop:
; must yield opportunities for an interrupt to occur di out (c),l out (c),h in a,(__IO_VDP_DATA) cp 0 ; pad 15 cycles (15 + 11 = 26) nop nop out (c),e out (c),d ;;;;; EMULICIOUS FLAGS VIOLATION out (__IO_VDP_DATA),a ei inc hl inc de djnz inner_loop |
|
|
Posted: Wed May 17, 2017 8:10 am |
since you have to add some delay, why not re-enabling the interrupts there?
di
out (c),l out (c),h in a,(__IO_VDP_DATA) ei *** add some more delay here *** di out (c),e out (c),d ;;;;; EMULICIOUS FLAGS VIOLATION out (__IO_VDP_DATA),a ei edit: BTW, are you guys sure on the real hardware one shouldn't write to the VDP COMMAND port too soon after reading the VDP DATA port? What might happen here if one does that? |
|
|
Posted: Wed May 17, 2017 8:50 am |
Pretty confident, I remember learning the hard way.
The 3D section in be no sqr was originally factored around needing to only delay 26 cycles between vram read/writes. It ran fine on Genesis and emulators at the time but completely fell over when I got someone to test it on actual SMS hardware (i didn't have an SMS at the time). It took some time to work out what was going on. |
|
|
Posted: Wed May 17, 2017 8:57 am |
I really thought the problem would happen only when writing to DATA port, not when reading from it. I mean, after you've read the data, what can happen to it? Have you got some more details on what went wrong on BeNoSqr (like a fragment of that code that wasn't working on hardware)?
Thanks! |
|
|
Posted: Wed May 17, 2017 9:13 am |
The problem code is long lost I am afraid. It uses multiple nametables and sprite attribute tables. For every line in active display the following would occur...
- x-scroll value updated (register update) - current nametable updated (register update) - current sprite table updated (register update) - Y value of two sprites updated (always consecutive, vdp pointer update + vram write) - cram update (vdp pointer update + cram write) Technically the most impressive yet visually the most boring effect. Fun fact, vram is almost all used yet only contains 2 tiles. Anyway this is where i ran in to the problems. Pretty confident I experienced same issue with vram reads on more recent projects. |
|
|
Posted: Wed May 17, 2017 9:38 am |
so this means you weren't reading from VRAM, right? ;) I know I can be quite annoying, I'm sorry - it's only I'm trying to understand. @Alcoholics Anonymous: can you send me the code that isn't working on Emulicious? I would love to test it myself on emulators and on my hardware :) - edit: oh, sorry, it's already there! |
|
|
Posted: Wed May 17, 2017 10:04 am |
That example didn't but as I said from memory more recent stuff confirmed its both read and write but best way is to test. All this stuff is easy to get mixed up. If Alcoholics Anonymous tests my suggestion and it works you will know whats going from Emulicious perspective. | |
|
Posted: Wed May 17, 2017 4:32 pm |
To get Emulicious to run without complaint I had to do this: ld c,__IO_VDP_COMMAND di outer_loop: push bc ld b,a inner_loop: ; must yield opportunities for an interrupt to occur ;; di out (c),l out (c),h ei cp 0 di in a,(__IO_VDP_DATA) ei cp 0 di out (c),e out (c),d out (__IO_VDP_DATA),a ;; ei inc hl inc de djnz inner_loop ld a,b pop bc djnz outer_loop ei There has to be delays before *and* after the IN instruction. The after is the only delay required to get the program to run properly under Emulicious but it will still flag the lack of before delay with a violation. A required delay after an IN doesn't make sense to me since you've already read the byte. I can see maybe the vdp is doing an autoincrement of the current vdp address and maybe the vdp is scheduling a read of the byte there into a buffer (to allow IN without wait states) that might be delayed while the screen is being drawn. So if the vdp cannot cancel such an operation when an out occurs, there could be a timing violation? This has to be checked against real hw if it hasn't already. A required delay before the IN instruction? Yeah if the vdp has to schedule a read intermingled with access for display then maybe this is needed. A check on real hw would be useful. |
|
|
Posted: Thu May 18, 2017 11:22 am |
VDP has read buffer and VRAM reads are pre fetched so both 'in' and 'out' have a VRAM access followed by address increment, 'in' being pre fetch for next read. In regards to setting a read address (different to write address) the following is from charles's doc.
Here is some tests validating Emulicious behavior. It covers all the delay stuff we talked. The last two are the ones you are probably interested in. reg > read: vdp address is updated for read then the value read without padding. read > reg > write: vram is read, address updated without padding, vram is written to with padding. This is done on a vram write address which i assume is same as your code. Source is included. |
|
|
Posted: Fri May 19, 2017 12:04 am |
Thanks psidum. I don't have real hardware so I can't actually run the tests to do checks on my own. I just have to rely on what the sms community says will not work. Like everyone, I'm always a little disappointed when I have to slow things down :)
It sounds like I am missing charles' doc so I will have a look for that now. So far this appears to be the situation: out (c),l ; write to vdp command ; must be 26 cycles to IN in a,(vdpdata) ; read vdp data ; must be 26 cycles to OUT out (c),l ; write to vdp command, vdp is busy doing autoincrement and read out (vdpdata),a ; must be 26 cycles to any vdp here, vdp is busy with write and autoincrement |
|
|
Posted: Fri May 19, 2017 2:18 am |
Thanks Alcoholics. It would be nice for someone to do their own independent tests for further confirmation. It is quite unintuitive.
The doc i referenced can be found here http://www.smspower.org/uploads/Development/msvdp-20021112.txt |
|
|
Posted: Fri May 19, 2017 7:59 am Last edited by sverx on Tue May 29, 2018 11:25 am; edited 1 time in total |
I confirm... the "compression" example program fails on my SMS II too. :(
Now I'm very puzzled. Let's reason this together. If we just do out (c),l
out (c),h in a,(__IO_VDP_DATA) we won't of course have any problem - register A will contain the value in VRAM at HL. So this means that the byte we need is "ready" right after updating the VDP address. So, I think the problem may be arising from the fact that we might want to perform another read/write operation when a previous read/write operation is still pending: what I mean is that after issuing the in a,(__IO_VDP_DATA)
the VDP will increment its internal pointer and -as soon as possible- perform a new read from VRAM so that a new byte will be ready in case we need to issue a new in a,(__IO_VDP_DATA)
... and we might also expect this to require 26 cycles, as per the write [this last assumption about delay may be proved wrong, but we'll investigate further possibly] So maybe the point is: if you write to the VDP data port before the queued read operation is performed, you'll probably have VDP read the byte over the I/O buffer we just wrote our byte. So maybe we should try to prove this with some kind of out (c),l
out (c),h in a,(__IO_VDP_DATA) out (c),e out (c),d ; *** VERY LONG DELAY HERE - let's put some 100 cycle for the sake of it *** out (__IO_VDP_DATA),a and see what happens. What do you guys think about this? I can run tests on my SMS II at home - post here the ROMs we need to check :) |
|
|
Posted: Fri May 19, 2017 12:22 pm |
Can you insert a subroutine call and do a nop loop until Emulicious says no corruption?
Then before test it in real hardware |
|
|
Posted: Fri May 19, 2017 3:21 pm |
out (c),l
out (c),h in a,(__IO_VDP_DATA)
Might there be a problem though? After the VRAM address is set, the vdp has to read the memory contents which can be delayed if it is generating the display. After the IN, the situation is similar except it also has to do an auto-increment. in a,(__IO_VDP_DATA) ei cp 0 di out (c),e out (c),d out (__IO_VDP_DATA),a After the IN, I think it's possible the auto-increment might change the vram address being written by the following OUT instructions. Now that it's clear that Emulicious is right about the original code, I think I will insert padding as Emulicious demands and wait to see if some of that padding can be shaved off with your tests. |
|
|
Posted: Fri May 19, 2017 5:49 pm |
You mean actually there should be a delay before the IN opcode to ensure that the data we want is ready? It seems reasonable - but I've never read anything detailing about this problem. True that reading from VRAM isn't so common after all. (AFAIR this aPlib source is working on hardware... well, actually there's a massive [unintentional] delay between setting the address and reading the byte, so it doesn't help with our doubts..) Calindro: can you share your knowledge with us? Did you run a specific test you can share with us for your investigations? :) |
|
|
Posted: Fri May 19, 2017 6:37 pm |
But all this refers to access during display, it's not an issue with the screen off. I'd expect to have to delay a lot during active display as described above (before reading and after writing). | |
|
Posted: Fri May 19, 2017 10:11 pm |
sure. He's trying to write VRAM 'safe' functions, otherwise I'm quite sure there would be no problems with screen off. | |
|
Posted: Sat May 20, 2017 2:33 pm |
Yes I settled on this for safe vram to vram copy and the original for unsafe. The "ei; cp 0; di" sequence was also changed to "ei; nop; nop; di" because I don't think the first one will allow any interrupts to occur. |
|
|
Posted: Mon May 22, 2017 12:49 pm |
I made a program that runs semi-automatic tests such as this. So far it works as expected on emulators.
I'm going to run it on my SMS II this evening and share it with you all if everything works as expected :) |
|
|
Posted: Thu May 25, 2017 7:44 am |
OK, it seems to me now I'm pretty confident on how to safely read from VRAM. When screen is ON, after setting VRAM address, you have to wait for the data to be ready (26 cycles probably) before reading the byte. And again wait 26 cycles (this is tested!) for any next byte. No waits are needed when screen is OFF.
VDP test attached. The program can be easily tweaked to run other tests. Emulicious gives exactly the same results as the hardware (Calindro: I didn't forget you. I need to run more tests about that 'other' quirk...) other emulators just 'pass' all the tests, even those failing on the hardware. |
|
|
Posted: Thu Aug 03, 2017 9:29 am |
Some feature requests:
1. shortcut keys to work across modes (I have to focus debugger or emulator window to use those keys, on macOSX) 2. exported .inc files with address in filename to be zero padded so they sort correctly in file manager 3. region change JP/US/EU Amazing work, this is such great emulator and debugger. |
|
|
Posted: Thu Aug 03, 2017 12:11 pm |
You would have to number the files in decimal, Windows does a natural sort which totally fails with hex no matter what padding there is. | |
|
Posted: Thu Aug 03, 2017 3:40 pm |
I'm using Mac OS X and if I rename the files to add zero padding they sort correctly. Anyway, Calindro tells me the disassembly settings are changed for the next version. |
|
|
Posted: Thu Aug 10, 2017 9:37 am |
For all Mac OS X users you should disable the "accent popup" (that the OS shows when you hold down a key) as it breaks Java apps. Even though it does not appear when you press and hold a key in Emulicious. This was causing me major grief in my debugging/re sessions.
http://www.techradar.com/how-to/computing/apple/easy-mac-hacks-disable-the-pop-u... Thanks to Calindro for a debug session trying to figure out what was going on! It was driving me crazy. |
|
|
An update of Emulicious is available
Posted: Mon Aug 14, 2017 6:28 pm
|
An update of Emulicious is available.
It improves the emulation accuracy of the Everdrive and comes with several minor improvements. Minor improvements
Improved accuracy of Everdrive Emulation
Users of Emulicious can receive the update via the automatic update system, if they haven't yet. And others can find a download on: http://emulicious.net/downloads/ |
|
|
Posted: Tue Aug 15, 2017 11:08 am |
Thank you! :)
Is it possible (how?) to set the profiler so that it stops when it RET? Sometimes I have to profile functions that have more than a single return, and setting the stop to just one of them will screw counts when the program flow goes to another... |
|
|
Posted: Tue Aug 15, 2017 11:46 am |
You can set start to the line of the call and end to the line following the line. If it's just about testing the function you could wrap it into another function. |
|
|
Posted: Wed Aug 16, 2017 8:32 am |
Sure, that's what I usually do - but if that function gets called from many different locations in code it gets wild to profile them all :| I'm thus suggesting an enhancement - something like placing some special keyword as the 'profile end' address such as 'RET' or just 'R' or whatever... |
|
|
Posted: Wed Aug 16, 2017 9:13 am |
I guessed so, that's why I had proposed to wrap the function call into another function: wrapper:
call functionToProfile ret And replace every call to 'functionToProfile' by a call to this wrapper. Then you can profile inside the wrapper function. This should work out for now. |
|
|
Posted: Sat Sep 23, 2017 11:24 am |
An update for Emulicious is available.
A procedure profiler has been added. It detects procedures automatically and profiles them. SRAM Watchpoints can now be added in the Memory Editor and in the Breakpoint Window using the prefix ’s‘ so entering „s0“ would add an SRAM watchpoint on the SRAM address 0. Support for the new format of z88dk map files has been added. Users of Emulicious can receive the update via the automatic update system, if they haven't yet. And others can find a download on: http://emulicious.net/downloads/ |
|
|
Posted: Sat Sep 23, 2017 12:07 pm |
Great!!!
And the procedureprofiler is a dream i have since i began with sms. |
|
|
Posted: Sat Sep 23, 2017 10:47 pm |
Great improvements!
Thanks for your continued work on this. |
|
Goto page 1, 2 Next |