News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

arnold wip

Started by arnoldemu, 20:52, 20 January 16

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

arnoldemu

Quote from: arnoldemu on 11:57, 29 October 17
Ok I will fix this.
This is fixed in the fossil repository. See artifact d3a82d3bc4267019. Changes are in sdl and sdl2 code.

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

arnoldemu

Quote from: cpcitor on 21:32, 01 November 17
Severity: current arnoldemu cannot be used for audio work here, or even games, as audio is too awful.
true. I will do more work on this before I do a new release.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

cpcitor

Hello.

Surprising behavior observed in Arnoldemu when using debugger. Version of arnoldemu is zip as of 2017-10-27.

How to reproduce :

* open arnold
* open debugger
* request to close CPC display window (either by clicking close button, or pressing ALT-F4 or similar)

Expected: arnold quits
Observed: close request seem just ignored.

Then

* click debugger window
* request to step or continue (e.g. press F11 or F12, or use right click on dissassembly window and choose one of the step or continue option)

Expected: execution continues (either one step or other option, as requested)
Observed: arnold quits

Is seems that the "window close" event was somehow not ignored but put on hold.

Regards.
Had a CPC since 1985, currently software dev professional, including embedded systems.

I made in 2013 the first CPC cross-dev environment that auto-installs C compiler and tools: cpc-dev-tool-chain: a portable toolchain for C/ASM development targetting CPC, later forked into CPCTelera.

cpcitor

The disassembly and memory windows are interesting trace tools.

Need for efficient disassembly/tracing.

When tracing through rom, or simply debugging calls involving well-known addresses, one often has to lookup addresses found in ROM code (code addresses, data adresses, firmware entry points in RAM, jump blocks in upper RAM). I did it this morning and ended up asking Google things like "Amstrac CPC BDD9" every other ASM line :-).

Also, this happens when stepping through one's code. For example, I had to step into running code generated by SDCC to solve difficult bugs. SDCC provides complete symbol list yet disassembly window does not know about them.

Having the information displayed would be a great time saver and enhance the disassembly window tremendously!

Tracing through ROM or other programs would make much more sense: when landing on any address (especially after a CALL, JP, RET) you know where you are.

Idea: show salient addresses when tracing

Seeing that the columns in the disassembly window could be completed (for example, add "execution time" column), I imagined an improvement: offer to "add symbols column", with symbol meaning here "free-form address-to-text association".

Such a symbol column would take as input a text file containing a number of lines associating an address with some text (free-form, not restricted only an actual symbol).

Then, any time an address is shown, it is looked up in the registered "free-form address-to-text association" sources and shown in an additional column. This makes tracing in code much easier.

Some sources could be:

* lower/upper ROM well-known address lists (when ROM is enabled)
* RAM firmware entry points, jump blocks (some are machine-dependent)
* user-supplied linker output

It could be as simple as a text file like examples below.

Addresses of known assembly code in lower ROM:

Quote0163     KL NEW FRAME FLY
016A     KL ADD FRAME FLY
0170     KL DEL FRAME FLY
0176     KL NEW FAST TICKER
0I7D     KL ADD FAST TICKER
0183     KL DEL FAST TICKER

Addresses of firmware entry points in RAM:

BD19 MC WAIT FLYBACK


Indirections:

BDD9 TXT OUT ACTION


Exemple of user-supplied linker output: map file produced by SDCC

     00001000  cpc_run_address                    crt0
     00001006  _main                              00_main
     000010A9  _config_gui_init                   config_gui
     000011B9  _cf_rungame                        controller
     000012D6  _key_to_action                     controller
     000012E8  _cf_grid_init                      model
     00001512  _cf_model_init                     model
     00001649  _walkTillObstacle                  model



The net result is that when looking at disassembly, you don't just see code, but its meaning conveyed by the text.

Implementing a proof-of-concept looks like "just" a lookup of the line address in the table(s) and show the mathing line, if any.

What do you think?
Had a CPC since 1985, currently software dev professional, including embedded systems.

I made in 2013 the first CPC cross-dev environment that auto-installs C compiler and tools: cpc-dev-tool-chain: a portable toolchain for C/ASM development targetting CPC, later forked into CPCTelera.

arnoldemu

Quote from: cpcitor on 10:06, 07 November 17
The disassembly and memory windows are interesting trace tools.

Need for efficient disassembly/tracing.

When tracing through rom, or simply debugging calls involving well-known addresses, one often has to lookup addresses found in ROM code (code addresses, data adresses, firmware entry points in RAM, jump blocks in upper RAM). I did it this morning and ended up asking Google things like "Amstrac CPC BDD9" every other ASM line :-).

Also, this happens when stepping through one's code. For example, I had to step into running code generated by SDCC to solve difficult bugs. SDCC provides complete symbol list yet disassembly window does not know about them.

Having the information displayed would be a great time saver and enhance the disassembly window tremendously!

Tracing through ROM or other programs would make much more sense: when landing on any address (especially after a CALL, JP, RET) you know where you are.

....
See the Labelmanager (access it via the dissassembly menu). You can also add labels from this menu.

You can import symbols from noi (sdcc), pasmo and other assemblers.
Does this do as you need?

For timings there are instruction timings (see dissassembly menu) that can be enabled.

Function timing is available at head revision but give me a couple more days to clean up after the big merge I did.



My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

GUNHED

Looking forward for the next release. Please keep us updated!  :)
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

cpcitor

Quote from: arnoldemu on 10:47, 07 November 17
See the Labelmanager (access it via the dissassembly menu). You can also add labels from this menu.

You can import symbols from noi (sdcc), pasmo and other assemblers.
Does this do as you need?

For timings there are instruction timings (see dissassembly menu) that can be enabled.

Function timing is available at head revision but give me a couple more days to clean up after the big merge I did.

Excellent!

The basic spirit is there.

Some observations:

* currently labels are treated like an authoritative label_prefix: like in ASM source code, yet...
* ...disassembly looks like but is not exactly ASM source code...
* ...in particular, disassembled labels are just *guessed*, not *certain*, especially when they are an operand of ASM instruction.
* Some labels with small values (0,1) are often included in compiler/linker output, irrelevant to many operations yet currently obfuscate disassembly: I have to look at the bytes column to see the actual value.

Example


# ASM source
LD DE,0



# disassembly with current code
LD DE, s_IRRELEVANTLABEL


* Close matches are not counted.


# ASM source
LD (LABEL),A
LD (LABEL+4),A
LD (MYVECTOR+1),HL



# disassembly with current code, not clear at all
LD (LABEL),A
LD (&1234),A
LD (&BDD4),HL



IMHO, it would be better to:

(1) consider labels as indicative, not authoritative, and thus show number not labels in disassembly, rather offer labels in an extra column.


# disassembly with current code
LD DE, s_IRRELEVANTLABEL
LD (LABEL),A



# Better result
LD DE, 0     # 0=s_IRRELEVANTLABEL
LD (&1230),A # &1230=LABEL


(2) if there are several exact labels, show all of them

(3) if current address does not exactly matches any label, instead of not showing anything, look below the the closest label and show bytes offset from it.

For example:


# disassembly with current code, not clear at all
LD (LABEL),A
LD (&1234),A
LD (&BDD4),HL



# Better retuls
LD (&1230),A    # &1230=LABEL
LD (&1234),A    # &1234=4+LABEL
LD (&BDD4),HL   # &BDD4=1+TXT_WRITE_CHAR


Another argument in favor of numbers in disassembled mnemonics plus an extra column is :

* to benefit, when existing, from reader familiarity with actual address (e.G. firmware area in RAM)
* to provide reader opportunity to see actual addresses, useful when other occurrences are missed because not exact (always guessed).

Example:


# ASM source
LD (LABEL),A
LD (LABEL-5),A



# disassembly with current code, not clear at all
LD (LABEL),A
LD (&6784),A



# Better result: one sees that the second write is 5 below the first
LD (&6789),A # &6789=LABEL
LD (&6784),A


What do you think?


Had a CPC since 1985, currently software dev professional, including embedded systems.

I made in 2013 the first CPC cross-dev environment that auto-installs C compiler and tools: cpc-dev-tool-chain: a portable toolchain for C/ASM development targetting CPC, later forked into CPCTelera.

artemia76

Hello there , while waiting new update from sources , I tried to fix myself the accelerated timing on linux. This can help others like me encountering the same issue.

I took a look on EmulationWindow::OnIdle(wxIdleEvent & WXUNUSED(event)) (EmuWindow.cpp)

and I saw a static value fixed to 19968, I suppose this is the number of cycle for 20msec of CPC execution.

I try to reduce this value , and I succes to reach true speed with 12500.

Sound now play without crackle and seem to be sync with timer.


Aeliss

#158
Lol, not sure this accuracy fanatic will use it ^^.
I have noticied a prb here too, if we use 19968 sometime the sound buffer is 3528 size (normal size) but sometime 3524 (in fact the buffer is smaller than it need for the frame), and impossible to find why because the logic values for me too is 19968.

But I need to try your modification, 12500 and 19968 are rly different values.

artemia76

#159
Yes I'm agree with you , my hack not give me total satisfaction because stay in my part , not understood. But sound crackle was not the only issue on my part, for example, burnin rubber run too fast . I would try to put cpu and crtc timing in a dedicated thread to reproduce the exact original quartz clock timing. I feel on arnold arch, the sound and crtc emulation are not sync to cpu frame, that cause crackle and disproportionned cpu advance timing.  Now with C++11 , we could put it on wxwidget independant thread (std::thread) . It sure, that represent lot of work to adapt the great job done yet.

Aeliss

#160
The speed problem is clearly visible on burning rubber ? I m comparing with youtube video, I don't see something visible (I don't have real machine to test).

I don't see no more how to implement a multithreading mode because the arnold core is "sequencial", we have data for sound in same time than for data for crtc for exemple. The Kevin Core is logic for me, if the emulation go slow at a moment all should be slow down (in theory).
The problem is not the sound buffer is filled slower than it is read, it s the sound buffer is not filled at same speed than the total core. For the same frame with the same number of cycle I can't undersatand why I have sometime a size buffer of 3528 and an other 3524, and never 3532.

The better way I see is synchronise the emulation on the sound core (It's a mode you can see in lot of emulator). Instead of using cycle = 19968 use Sound_buffer_size = 3528 to check a complete frame.
With this tips, I m sure to make a code without sound problem, but for me it s not accurate at all, and  IDK that it can imply on the rest of core taht need perfect synchronisation(eg raster, interrupt, ect ...)

For information I m using it on window, I have too a version with directsound, the sound bug is less visible but still present.

roudoudou

Hi Kevin, is the link http://www.cpctech.org.uk/arnoldsrc.zip containing the last version?

Have you made a quick procedure in order to compile it with Linux?

I saw it uses wxWidget, libSDL, other???

Thanks
My pronouns are RASM and ACE

roudoudou

I compiled a working version of Arnold
But still dont know if its the last one  ;D
My pronouns are RASM and ACE

dragon

#163
cpctech is broken. Only works the front page. I cant redownload it.

roudoudou

A quick question about Arnold and snapshot extended chunks
Is there a breakpoint support (Winape compatible or ACE compatible) BRKS / BRKC
Is there a symbol support (ACE compatible) SYMB
Is there any documented specific chunk dedicated to Arnold? (breakpoints, symbols, ...)
Thanks
My pronouns are RASM and ACE

simulant

Hi I just wondered if it would be possible to add something to the TODO list if it isn't already? This may have been fixed as I run the .deb Arnold package from 19th August 2017...

I use Arnold on my laptop that uses Kubuntu - it works great and I mainly just leave it in "Translated" keyboard mode without any problems, but for some reason it doesn't translate the CTRL key.
I noticed this in HiSoft-C
I write some code, go to the compiler, hit ctrl-z and it doesn't do anything. So I have to swap to positional keyboard mode to do the ctrl-z, then swap back to translated again. This works ok swapping between, but as more code is written and then compiled to check then swap back again to change the code then back again to compile and such it really slows things down. Partly because my laptop touchpad isn't great and it is a small notebook so a bit fiddly...
It would be fantastic if the ctrl key could be translated so that it could just be left in translated mode all the time and then coding C on the Amstrad would absolutely rock out for me in HiSoft!!! :)
Amstrad BBS - https://amstrad.simulant.uk

Amstrad Hardware & Software: https://www.simulant.uk/shop/

Powered by SMFPacks Menu Editor Mod