News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

BASM: Best ASseMbler in my desk room.

Started by krusty, 13:21, 06 October 21

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

krusty_benediction

yep, and honnestly there are limitations with the current memory function as it assumes your are adressing the same space than where you are currently.
But this is not that much fancy as winape allows it too

krusty_benediction

Not a lot of features have been implemented since December.

- I have revised some architectural choices (not totally finished yet, so there can be bugs) that should bring more assembling speed. Basm still remains slower than rasm at the source parsing step. No idea if I'll reach its speed one day.
- I have added a --progress option to see the current state of assembling for long projects to assemble (yet a WIP)
- The assembler can embed some sources files (those of the decompressors are currently included to ensure the z80 decoding code corresponds to the right coding code). They can be included using a filename starting with inner:// (now it's just a matter of finding which files to add)
- I have added more compression formats (thanks to rasm integrations I have retrieved)
- I have added a web assembly support. It means that basm can be used in a Javascript application (a web page for example). Limitations are: most compression functionalities are not available, and include/incbin of files not included inside the assembler are not available
- Still no documentation, but most directives are tested here https://github.com/cpcsdk/rust.cpclib/tree/master/cpclib-basm/tests/asm

My github continuous integration does not seem to publish the built executables. I can share the executable on demand

krusty_benediction

#27
Thanks to: https://www.cpcwiki.eu/forum/programming/z80-labels-of-firmware-calls/, basm knows all the firmware calls  for CPC 6128.
They can be used on demand.

Thus, this code


snainit "../cpclib-sna/src/cpc6128.sna" ; should be uneeded by properly specifying sna properties for rom configuration

org 0x4000
run $



ld hl, text_content
loop
ld a, (hl)
or a
jp z, finished

call TXT_OUTPUT
inc hl
jp loop

finished
jp $

text_content
db "Hello, world!", 0
include "inner://firmware/txtvdu.asm"

can be executed on CPC with this command

basm --m4 192.168.1.28 tests/asm/good_hello_world.asm

krusty_benediction

Just a random post to update basm visibility ;)
No idea of what is new since last year, but the WIP documentation is here https://cpcsdk.github.io/rust.cpclib/basm/

There is also an accompanying build tool that embeds in one executable all my tools needed to build a CPC project: https://cpcsdk.github.io/rust.cpclib/bndbuild/.
It is more or less make with a yaml file description and the possibility to launch automatically commands when dependencies are updated. Roughly it serves to see the result on CPC in real time after each file modification without explicitly requesting it



There is also a graphical version too https://github.com/cpcsdk/rust.cpclib/tree/master/cpclib-visual-bndbuild




Executables for windows are automatically build at each update here: https://github.com/cpcsdk/rust.cpclib/releases
(continuous delivery is broken ATM for Linux)


norecess464

#29
Bonjour Romain !  :)

You are having a great workflow here, with symbols pushed into the emulator etc
I remember that you were using Python in the past, and then you switched to Rust. What is your experience with Rust, I suppose it's much faster now to process?

Based on your animated GIFs, I see you are compiling resources (bitmaps, generated data, etc) and then compiling Z80 source code, all in a single step, with a YAML file to describe all the steps.

I behave differently on my side now. You probably remember "Phactory", the IDE I did 10-13 years ago :) It worked relatively well, but it asked me to think "in a generic way", and this went against the idea of generating custom data for a new demo part, for example.

Since the phX days, now I use 2 separate workflows:

- To generate the assets and convert them to Amstrad CPC Format, I use a simple C++ command-line exe. I directly launch it from the IDE (debug mode), it generates the data. There are few optimisations, like parallel building (multi-threaded) + check if the resource file (SOURCE)'s datetime is higher than the destination resource file's datetime (in that case, trigger the build of that specific asset). So, it's all done by hand, but with my dedicated framework I don't feel slow to implement things.

- I also have a bash script (could be python or whatever) that compiles C code (SDCC) and Z80 (RASM). It generates the final dsk/cpr file, and stops when an error is found. It also generates a "memmap.txt" file, which shows me the size of the different internal Z80 parts. It's interesting to make the diff of that file (git history) etc. With RASM it also generates symbols. The final disc/cartridge images get generated super fast, less than 1-2 seconds for the entire process (merci roudoudou !).
Please take note the Z80 source-code include (RASM's INCBIN / INCLUDE) the generated data from the C++ part.

So: am I updating a bitmap? OK, launch-debug from the C++ IDE. Did I change some Z80 code? ok, launch the bash script.

Please take note that I'm using my "fork" of CPCEC, called cpcec-gtk (http://norecess464.weebly.com/news/cpcec-gtk-a-native-debian-based-linux-front-end-for-cpcec). When a DSK/CPR file gets opened with the emulator, it continuously monitors for file changes. So, when the DSK gets updated, the emulator reloads the disc/cartridge file, reloads the symbols, and does an "Amstrad Reset".

Voila!
ps. BTW, there is no method better than another. The best approach is the one that fits to YOUR workflow :)
My personal website: https://norecess.cpcscene.net
My current project is Sonic GX, a remake of Sonic the Hedgehog for the awesome Amstrad GX-4000 game console!

krusty_benediction

Salut,

here are in random order some answers: I mainly work not alone on my Amstrad CPC demos and I need developers and non developers (without having a knowledge of assembly, programming) to be able to build the demos and so on, always in the same way without asking themself how to do it depending on the modification they made on there assets (music, gfx, palettes and so on).
So before they had tons of prerequisite to install (and some are a nightmare on windows), now there is only this single executable I share (no need of make, python, and so on).

Rust is faster to execute, but way slower to write than python ;) But it is a very fun language to use.

Of course, for a true demo effect, I would have data generators that generate assembly that would be included by the assembly program. And the computation graph of the whole project would launch it only when needed. The extern command is also for this purpose.
However, in opposite to you, I think I would favor to add as most functionalities as possible to the assembler to allow it to generate complex data without having to rely on external tool (to lower the number of languages and software dependencies to install).

ps: are you 100% sure of the gitlab link you share in your website ? It seems to be dead today


norecess464

Ah yes I migrated to Bitbucket: https://bitbucket.org/norecess464/cpcec-gtk

In conclusion: multiple workflows for the same thing 8)
My personal website: https://norecess.cpcscene.net
My current project is Sonic GX, a remake of Sonic the Hedgehog for the awesome Amstrad GX-4000 game console!

krusty_benediction

Current version of basm and bndbuild generates BRKC and SYMB snapshot chunks according to the documentation provided here https://www.cpcwiki.eu/index.php/Snapshot.
Current support is minimal, but I'll embrace all features later (I consider labels are in main ram and breakpoints are execution breakpoints without conditions).

Unless if I made something wrong, It seems AceDL/Linux ignores these chunks, so I have added a minimal support to the REMU chunk too (similar limitations of BRKC and SYMB and I do not consider alias and rom stuffs ATM).

I have not deeply tested, but Amsdos/DSK support is supposed to properly work now. 
Amsdos/HXC works too under Linux if compiled with --features hfe, but there is still no Amsdos/HXC support for the windows version, i'm unable to link it.

So, this example creates a binary named TEST that prints A in saved.hfe:

org 0x4000
BINARY_START
 run $
 ld a, 'A' : call 0xbb5a
 jp $
BINARY_STOP

 save "test", BINARY_START, BINARY_STOP-BINARY_START, HFE, "saved.hfe"




windows artifacts are here https://github.com/cpcsdk/rust.cpclib/releases, it's still up to you to build Linux ones, I have not yet fixed continuous integration issue

krusty_benediction

#33
And now, the current version is able to crunch directly using Shrinkler (version modified by @roudoudou for CPC).

So, the following proof-of-concept assembles perfectly (and I validated with a real program)


    org 0x100
    di
        ld hl, 0xc9fb : ld (0x38), hl
    ei
    ld ix, CS_START
    ld de, 0x8000
    call shrinkler_decrunch
    jp $
CS_START
    LZSHRINKLER
INNER_START
        defs 100
INNER_STOP
    LZCLOSE
CS_STOP
    assert INNER_STOP - INNER_START == 100
    assert CS_STOP - CS_START < 100
    probs=0xc000
    include "inner://deshrink.asm"
    print "UNCRUNCHED SIZE=", INNER_STOP-INNER_START
    print "CRUNCHED SIZE=", CS_STOP-CS_START

which gives

    Running `C:\Users\giotr\Perso\CPC\rust.cpcdemotools\target\debug\basm.exe .\tests\asm\good_shrinkler_decrunch.asm`
Original  After 1st pass  After 2nd pass  After 3rd pass  After 4th pass  After 5th pass  After 6th pass  After 7th pass  After 8th pass  After 9th pass
    100          3.365          3.365          3.365          3.365          3.365          3.365          3.365          3.365          3.365

Verifying... OK

Minimum safety margin for overlapped decrunching: -96

References considered:      62
References discarded:        0

.\tests\asm\good_shrinkler_decrunch.asm:31:2 PRINT: UNCRUNCHED SIZE=100
.\tests\asm\good_shrinkler_decrunch.asm:32:2 PRINT: CRUNCHED SIZE=4
Assembled in 2 passes and 0.11s.


However, this time, the continuous integration of github also fails to build the windows version... I do not understand this OS as I perfectly build it on my windows (previous example has been validated both on Linux and Windows).

Powered by SMFPacks Menu Editor Mod