Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - Emulicious Update Available

Reply to topic Goto page 1, 2  Next
Author Message
  • Joined: 14 Apr 2013
  • Posts: 430
Reply with quote
Emulicious Update Available
Post 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
  View user's profile Send private message Visit poster's website
  • Joined: 06 Apr 2011
  • Posts: 215
  • Location: Netherlands
Reply with quote
Post 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.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 1958
Reply with quote
Post 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 :)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 11899
  • Location: London
Reply with quote
Post 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.
  View user's profile Send private message Visit poster's website
  • Joined: 28 Feb 2016
  • Posts: 273
  • Location: Barcelona
Reply with quote
Post Posted: Sat Mar 11, 2017 10:10 pm
THANKYOU VERY MUCH CALINDRO !!!!!

For update and improve Emulicious, :) Great !
  View user's profile Send private message
  • Joined: 14 Apr 2013
  • Posts: 430
Reply with quote
Post Posted: Wed Mar 15, 2017 6:59 pm
Maxim wrote
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.

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.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 11899
  • Location: London
Reply with quote
Post 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.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Apr 2013
  • Posts: 430
Reply with quote
Post 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.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Sep 2016
  • Posts: 71
  • Location: Lyon, France
Reply with quote
Post 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 :)
  View user's profile Send private message
  • Joined: 09 Dec 2013
  • Posts: 104
  • Location: detroit
Reply with quote
Post Posted: Fri Apr 28, 2017 12:25 pm
But, does it play Titan - Overdrive 2? http://www.pouet.net/prod.php?which=69648
  View user's profile Send private message
  • Joined: 01 Jul 2015
  • Posts: 127
  • Location: Berlin
Reply with quote
Post Posted: Fri Apr 28, 2017 5:06 pm
Why should it? Mega Drive is not emulated by Emulicious.
  View user's profile Send private message
  • Joined: 14 Apr 2013
  • Posts: 430
Reply with quote
Post Posted: Fri May 05, 2017 12:02 pm
gligli wrote
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 :)

Hi gligli,

I've added an option for that to the Run menu. Sorry that it took a while!
  View user's profile Send private message Visit poster's website
  • Joined: 14 Sep 2016
  • Posts: 71
  • Location: Lyon, France
Reply with quote
Post Posted: Fri May 05, 2017 12:59 pm
Hi, thanks a lot! That's awesome support for an emulator that is free :)
  View user's profile Send private message
  • Joined: 28 Feb 2016
  • Posts: 273
  • Location: Barcelona
Reply with quote
Post Posted: Fri May 05, 2017 8:39 pm
Again and again, thankyou Calindro !!!!
  View user's profile Send private message
  • Joined: 17 Nov 2015
  • Posts: 92
  • Location: Canada
Reply with quote
Post Posted: Tue May 16, 2017 12:28 am
I have an example program that runs correctly under Meka but fails under Emulicious.
compression.zip (16.18 KB)

  View user's profile Send private message Visit poster's website
  • Joined: 14 Apr 2013
  • Posts: 430
Reply with quote
Post 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.
  View user's profile Send private message Visit poster's website
  • Joined: 28 Feb 2016
  • Posts: 273
  • Location: Barcelona
Reply with quote
Post 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 ;)
  View user's profile Send private message
  • Joined: 17 Nov 2015
  • Posts: 92
  • Location: Canada
Reply with quote
Post Posted: Wed May 17, 2017 5:29 am
BcnAbel76 wrote

Emulicious is really outstanding ;)


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.
  View user's profile Send private message Visit poster's website
  • Joined: 01 Jan 2014
  • Posts: 300
Reply with quote
Post 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
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 1958
Reply with quote
Post 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?
  View user's profile Send private message Visit poster's website
  • Joined: 01 Jan 2014
  • Posts: 300
Reply with quote
Post 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.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 1958
Reply with quote
Post 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!
  View user's profile Send private message Visit poster's website
  • Joined: 01 Jan 2014
  • Posts: 300
Reply with quote
Post 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.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 1958
Reply with quote
Post Posted: Wed May 17, 2017 9:38 am
psidum wrote
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)


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!
  View user's profile Send private message Visit poster's website
  • Joined: 01 Jan 2014
  • Posts: 300
Reply with quote
Post 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.
  View user's profile Send private message
  • Joined: 17 Nov 2015
  • Posts: 92
  • Location: Canada
Reply with quote
Post Posted: Wed May 17, 2017 4:32 pm
psidum wrote
If Alcoholics Anonymous tests my suggestion and it works you will know whats going from Emulicious perspective.


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.
  View user's profile Send private message Visit poster's website
  • Joined: 01 Jan 2014
  • Posts: 300
Reply with quote
Post 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.

Quote
A byte of VRAM is read from the location defined by the
address register and is stored in the read buffer. The
address register is incremented by one. Writes to the
data port go to VRAM.


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.
sms_vram_timings.zip (682.17 KB)

  View user's profile Send private message
  • Joined: 17 Nov 2015
  • Posts: 92
  • Location: Canada
Reply with quote
Post 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
  View user's profile Send private message Visit poster's website
  • Joined: 01 Jan 2014
  • Posts: 300
Reply with quote
Post 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
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 1958
Reply with quote
Post Posted: Fri May 19, 2017 7:59 am
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 eventually]

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 :)
  View user's profile Send private message Visit poster's website
  • Joined: 28 Feb 2016
  • Posts: 273
  • Location: Barcelona
Reply with quote
Post 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
  View user's profile Send private message
  • Joined: 17 Nov 2015
  • Posts: 92
  • Location: Canada
Reply with quote
Post Posted: Fri May 19, 2017 3:21 pm
   out (c),l
   out (c),h
   in a,(__IO_VDP_DATA)

sverx wrote

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.


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.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 1958
Reply with quote
Post Posted: Fri May 19, 2017 5:49 pm
Alcoholics Anonymous wrote
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.


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? :)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 11899
  • Location: London
Reply with quote
Post 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).
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 1958
Reply with quote
Post 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.
  View user's profile Send private message Visit poster's website
  • Joined: 17 Nov 2015
  • Posts: 92
  • Location: Canada
Reply with quote
Post Posted: Sat May 20, 2017 2:33 pm
sverx wrote
sure. He's trying to write VRAM 'safe' functions, otherwise I'm quite sure there would be no problems with screen off.


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.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 1958
Reply with quote
Post 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 :)
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 1958
Reply with quote
Post 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.
VDPtest.rar (44.13 KB)
VDP test

  View user's profile Send private message Visit poster's website
  • Joined: 05 Jul 2017
  • Posts: 50
  • Location: Cornwall, United Kingdom
Reply with quote
Post 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.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 11899
  • Location: London
Reply with quote
Post 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.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Jul 2017
  • Posts: 50
  • Location: Cornwall, United Kingdom
Reply with quote
Post Posted: Thu Aug 03, 2017 3:40 pm
Maxim wrote
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.

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.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Jul 2017
  • Posts: 50
  • Location: Cornwall, United Kingdom
Reply with quote
Post 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.

  View user's profile Send private message Visit poster's website
  • Joined: 14 Apr 2013
  • Posts: 430
Reply with quote
An update of Emulicious is available
Post 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
  • Display "suspended" in title bar when emulation is suspended
  • Bring debugger to top when a breakpoint is hit
  • CTRL+TAB switches between main window and debugger
  • Added option to "Setup Keys" dialog to allow input even when other windows of Emulicious are focused
  • Added region selection for Game Gear


Improved accuracy of Everdrive Emulation
  • ROM and RAM are persisted
  • True handling of SRAM files
  • The files from the recent files menu are accessible via a folder called RECENT


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/
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 1958
Reply with quote
Post 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...
  View user's profile Send private message Visit poster's website
  • Joined: 14 Apr 2013
  • Posts: 430
Reply with quote
Post Posted: Tue Aug 15, 2017 11:46 am
sverx wrote
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...

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.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 1958
Reply with quote
Post Posted: Wed Aug 16, 2017 8:32 am
Calindro wrote
You can set start to the line of the call and end to the line following the line.


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...
  View user's profile Send private message Visit poster's website
  • Joined: 14 Apr 2013
  • Posts: 430
Reply with quote
Post Posted: Wed Aug 16, 2017 9:13 am
sverx wrote
Calindro wrote
You can set start to the line of the call and end to the line following the line.


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...

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.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Apr 2013
  • Posts: 430
Reply with quote
Post 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/
ProcedureProfiler.png (46.44 KB)
ProcedureProfiler.png

  View user's profile Send private message Visit poster's website
  • Joined: 28 Jan 2017
  • Posts: 271
  • Location: Málaga, Spain
Reply with quote
Post Posted: Sat Sep 23, 2017 12:07 pm
Great!!!

And the procedureprofiler is a dream i have since i began with sms.
  View user's profile Send private message
  • Joined: 05 Jul 2017
  • Posts: 50
  • Location: Cornwall, United Kingdom
Reply with quote
Post Posted: Sat Sep 23, 2017 10:47 pm
Great improvements!

Thanks for your continued work on this.
  View user's profile Send private message Visit poster's website
Reply to topic Goto page 1, 2  Next



Back to the top of this page

Back to SMS Power!