Author Topic: arnold wip  (Read 22681 times)

0 Members and 1 Guest are viewing this topic.

Offline arnoldemu

  • Supporter
  • 6128 Plus
  • *
  • Posts: 5.329
  • Country: gb
    • Unofficial Amstrad WWW Resource
  • Liked: 2226
Re: arnold wip
« Reply #150 on: 15:49, 06 November 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

Offline arnoldemu

  • Supporter
  • 6128 Plus
  • *
  • Posts: 5.329
  • Country: gb
    • Unofficial Amstrad WWW Resource
  • Liked: 2226
Re: Audio bugs
« Reply #151 on: 15:50, 06 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

Offline cpcitor

  • The user previously known as FindYWay
  • CPC6128
  • ****
  • Posts: 235
  • Country: fr
  • My heart still runs on traditional CPC.
    • My code for the CPC.
  • Liked: 111
Re: arnold wip
« Reply #152 on: 10:38, 07 November 17 »
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 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.

Offline cpcitor

  • The user previously known as FindYWay
  • CPC6128
  • ****
  • Posts: 235
  • Country: fr
  • My heart still runs on traditional CPC.
    • My code for the CPC.
  • Liked: 111
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:

Quote
0163     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:

Code: [Select]
BD19 MC WAIT FLYBACK

Indirections:

Code: [Select]
BDD9 TXT OUT ACTION

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

Code: [Select]
     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 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.

Offline arnoldemu

  • Supporter
  • 6128 Plus
  • *
  • Posts: 5.329
  • Country: gb
    • Unofficial Amstrad WWW Resource
  • Liked: 2226
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

Offline GUNHED

  • 6128 Plus
  • ******
  • Posts: 590
  • Country: de
  • Reincarnation of TFM
  • Liked: 269
Re: arnold wip
« Reply #155 on: 18:03, 07 November 17 »
Looking forward for the next release. Please keep us updated!  :)
http://futureos.de --> Get the revolutionary FutureOS (Recent update: 2018.08.23)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Ver.: 2018.08.15)

Offline cpcitor

  • The user previously known as FindYWay
  • CPC6128
  • ****
  • Posts: 235
  • Country: fr
  • My heart still runs on traditional CPC.
    • My code for the CPC.
  • Liked: 111
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

Code: [Select]
# ASM source
LD DE,0

Code: [Select]
# disassembly with current code
LD DE, s_IRRELEVANTLABEL

* Close matches are not counted.

Code: [Select]
# ASM source
LD (LABEL),A
LD (LABEL+4),A
LD (MYVECTOR+1),HL

Code: [Select]
# 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.

Code: [Select]
# disassembly with current code
LD DE, s_IRRELEVANTLABEL
LD (LABEL),A

Code: [Select]
# 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:

Code: [Select]
# disassembly with current code, not clear at all
LD (LABEL),A
LD (&1234),A
LD (&BDD4),HL

Code: [Select]
# 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:

Code: [Select]
# ASM source
LD (LABEL),A
LD (LABEL-5),A

Code: [Select]
# disassembly with current code, not clear at all
LD (LABEL),A
LD (&6784),A

Code: [Select]
# 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 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.

Offline artemia76

  • Speccy
  • *
  • Posts: 2
  • Country: fr
  • Liked: 0
Re: arnold wip
« Reply #157 on: 23:15, 29 December 17 »
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.


Offline Aeliss

  • CPC464
  • **
  • Posts: 26
  • Country: fr
  • Liked: 9
Re: arnold wip
« Reply #158 on: 19:04, 04 January 18 »
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.
« Last Edit: 19:08, 04 January 18 by Aeliss »

Offline artemia76

  • Speccy
  • *
  • Posts: 2
  • Country: fr
  • Liked: 0
Re: arnold wip
« Reply #159 on: 22:31, 04 January 18 »
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.
« Last Edit: 22:46, 04 January 18 by artemia76 »

Offline Aeliss

  • CPC464
  • **
  • Posts: 26
  • Country: fr
  • Liked: 9
Re: arnold wip
« Reply #160 on: 19:17, 05 January 18 »
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.
« Last Edit: 19:26, 05 January 18 by Aeliss »

Offline roudoudou

  • 6128 Plus
  • ******
  • Posts: 527
  • Country: fr
    • urban exploration
  • Liked: 701
Re: arnold wip
« Reply #161 on: 15:51, 09 April 18 »
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
use RASM, the best assembler ever made :p

I will survive

Offline roudoudou

  • 6128 Plus
  • ******
  • Posts: 527
  • Country: fr
    • urban exploration
  • Liked: 701
Re: arnold wip
« Reply #162 on: 22:22, 12 April 18 »
I compiled a working version of Arnold
But still dont know if its the last one  ;D
use RASM, the best assembler ever made :p

I will survive

Offline dragon

  • 6128 Plus
  • ******
  • Posts: 1.322
  • Country: es
  • Liked: 557
Re: arnold wip
« Reply #163 on: 13:38, 10 August 18 »
cpctech is broken. Only works the front page. I cant redownload it.
« Last Edit: 10:35, 11 August 18 by dragon »