Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #5106 > unrolled thread

Trouble linking with ca65?

Back to article view | Back to comp.sys.apple2.programmer

Contents

  Trouble linking with ca65? Christophe Meneboeuf <christophe.meneboeuf@gmail.com> - 2019-05-25 07:59 -0700
    Re: Trouble linking with ca65? Oliver Schmidt <ol.sc@web.de> - 2019-05-25 16:15 +0000
      Re: Trouble linking with ca65? Christophe Meneboeuf <christophe.meneboeuf@gmail.com> - 2019-05-25 09:28 -0700
        Re: Trouble linking with ca65? Antoine Vignau <antoine.vignau@laposte.net> - 2019-05-25 11:04 -0700
          Re: Trouble linking with ca65? Christophe Meneboeuf <christophe.meneboeuf@gmail.com> - 2019-05-25 12:02 -0700
            Re: Trouble linking with ca65? Antoine Vignau <antoine.vignau@laposte.net> - 2019-05-25 12:13 -0700
              Re: Trouble linking with ca65? Christophe Meneboeuf <christophe.meneboeuf@gmail.com> - 2019-05-25 12:32 -0700
                Re: Trouble linking with ca65? Steve Nickolas <usotsuki@buric.co> - 2019-05-26 03:08 -0400
                  Re: Trouble linking with ca65? Michael J. Mahon <mjmahon@aol.com> - 2019-05-26 15:20 -0500
            Re: Trouble linking with ca65? schampailler@skynet.be - 2019-06-04 03:36 -0700
              Re: Trouble linking with ca65? Christophe Meneboeuf <christophe.meneboeuf@gmail.com> - 2019-06-05 11:42 -0700
        Re: Trouble linking with ca65? Christophe Meneboeuf <christophe.meneboeuf@gmail.com> - 2019-05-25 16:10 -0700
          Re: Trouble linking with ca65? Andy McFadden <thefadden@gmail.com> - 2019-05-26 08:00 -0700
          Re: Trouble linking with ca65? ol.sc@web.de (Oliver Schmidt) - 2019-05-26 20:15 +0000
    Trouble linking with ca65? Michael Pohoreski <michael.pohoreski@gmail.com> - 2019-05-29 12:20 -0700
      Trouble linking with ca65? Antoine Vignau <antoine.vignau@laposte.net> - 2019-05-29 14:55 -0700
        Trouble linking with ca65? Michael Pohoreski <michael.pohoreski@gmail.com> - 2019-05-30 09:09 -0700
          Trouble linking with ca65? Antoine Vignau <antoine.vignau@laposte.net> - 2019-05-30 10:01 -0700
            Trouble linking with ca65? lroathe@gmail.com - 2019-05-30 10:32 -0700
              Re: Trouble linking with ca65? Andy McFadden <thefadden@gmail.com> - 2019-05-31 10:34 -0700
                Re: Trouble linking with ca65? Michael Pohoreski <michael.pohoreski@gmail.com> - 2019-05-31 12:07 -0700
                  Re: Trouble linking with ca65? Antoine Vignau <antoine.vignau@laposte.net> - 2019-05-31 12:18 -0700
              Re: Trouble linking with ca65? Steven Hirsch <snhirsch@gmail.com> - 2019-06-02 09:23 -0400
                Re: Trouble linking with ca65? Andy McFadden <thefadden@gmail.com> - 2019-06-02 07:44 -0700
                  Re: Trouble linking with ca65? Steven Hirsch <snhirsch@gmail.com> - 2019-06-02 18:49 -0400
                    Re: Trouble linking with ca65? Andy McFadden <thefadden@gmail.com> - 2019-06-03 08:19 -0700
                      Re: Trouble linking with ca65? olivier.zardini@cooperteam.eu - 2019-06-03 09:29 -0700
            Re: Trouble linking with ca65? Hugh Hood <hughhood@earthlink.net> - 2019-06-02 10:33 -0500
              Re: Trouble linking with ca65? Michael J. Mahon <mjmahon@aol.com> - 2019-06-02 16:17 -0500
              Re: Trouble linking with ca65? Jeff Blakeney <CUTjeffrey_blakeney@yahoo.ca> - 2019-06-03 00:58 -0400
              Re: Trouble linking with ca65? Michael Pohoreski <michael.pohoreski@gmail.com> - 2019-06-03 07:53 -0700
                Re: Trouble linking with ca65? Andy McFadden <thefadden@gmail.com> - 2019-06-03 08:10 -0700
                Re: Trouble linking with ca65? Hugh Hood <hughhood@earthlink.net> - 2019-06-08 13:53 -0500
                  Re: Trouble linking with ca65? Michael Pohoreski <michael.pohoreski@gmail.com> - 2019-06-10 06:38 -0700
          Re: Trouble linking with ca65? mmphosis <mmphosis@macgui.com> - 2019-06-01 19:41 +0000

Page 1 of 2  [1] 2  Next page →

#5106 — Trouble linking with ca65?

Hi! I’m a bit new in the Apple II programming landscape, so please excuse me if this question seems trivial.

I’m working on a simple rogue-like game, using ca65 / cl65 as the assembler / linker. I put my binary on a Prodos (2.4.1) disk (.dsk) using Apple Commander. I run my binary using the BRUN command.

Recently, as my program grown, I had to redo the memory mapping. What I had in mind was:
* Code from 0x803 to 0x2000
* Data segments (.BSS, .DATA…) from 0x6000 to 0xC000

Here is a link to the corresponding cfg file: https://pub.xtof.info/apple2/escape-20190525.map

When I run my program, it crashes. It seems that, although all the data is present in the binary, not all is loaded in memory. For instance, in my assembly I’ve got:

World: ; .res (WIDTH_WORLD) * (HEIGHT_WORLD)
.byte 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06
.byte 06, 02, 02, 06, 06, 06, 06, 06, 06, 06, 02, 02, 02, 02, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06, 02, 02, 02, 02, 02, 02, 02, 02, 02, 02, 02, 06, 06, 06, 02, 02, 02, 02, 06, 06, 06, 06, 06, 06, 06, 06, 06, 06

In my mapping file, World lies the right place:

Exports list by name:
---------------------
DBG_TRACE	000BE8  LA
Player_XY	00A164 RLA
World		006600 RLA

But in memory, the segment seems initialized:

6600: FF FF 00 00 FF FF 00 00
6608: FF FF 00 00 FF FF 00 00

Is it a limitation of BRUN or did I miss something with my cfg file??

Thanks in advance for any advice or help!
Christophe

[toc] | [next] | [standalone]

#5107

Hi,

> Here is a link to the corresponding cfg file:
> https://pub.xtof.info/apple2/escape-20190525.map

You linked to a map file, not a cfg file.

Regards,
Oliver

[toc] | [prev] | [next] | [standalone]

#5108

On Saturday, May 25, 2019 at 6:15:19 PM UTC+2, Oliver Schmidt wrote:
> 
> You linked to a map file, not a cfg file.
> 
> Regards,
> Oliver

Oops, my bad sorry.
Here is the link to the cfg: https://pub.xtof.info/apple2/escape-20190525.cfg

I think that my problem is I don't understand how an "executable" is supposed to be linked then loaded by PRODOS.

My binary is 5410 byte long, which I can confirm in AppleCommander. All my data is in fact loaded into the memory, but contiguously from 0x803 to 0x1C17. Thus I can see the "World" data loaded at 0x120B instead of 0x6600.

Do I have to manually relocate this data at the correct location??

I now begin to understand that I cannot leave "holes" in my mapping, but I don't know what is the correct way of loading a "big" program from 0x803 while leaving the HGR segments alone.

[toc] | [prev] | [next] | [standalone]

#5109

Christophe,
ton programme est en assembleur ou en BASIC ? Je pose la question parce que tu démarres en $803. Pourquoi pas en $800 ?

Tu es sous ProDOS avec BASIC.SYSTEM (limite RAM $95FF) ou sans (limite RAM $BEFF) - Attention les fichiers ouverts ont besoin d'un ko pour vivre.

Antoine

[toc] | [prev] | [next] | [standalone]

#5110

On Saturday, May 25, 2019 at 8:04:47 PM UTC+2, Antoine Vignau wrote:
> Christophe,
> ton programme est en assembleur ou en BASIC ? Je pose la question parce que tu démarres en $803. Pourquoi pas en $800 ?
> 
> Tu es sous ProDOS avec BASIC.SYSTEM (limite RAM $95FF) ou sans (limite RAM $BEFF) - Attention les fichiers ouverts ont besoin d'un ko pour vivre.
> 
> Antoine

Bonjour Antoine.

J'avoue que je ne comprends pas bien comment le démarrage d'un programme est censé se dérouler...
Mon programme est entièrement en assembleur. L'idée est d'utiliser toutes le zones mémoires disponibles si j'en ai besoin. Sans empiéter sur les zones urilisées par ProDOS car je compte m'en servir pour lire / écrire des fichiers (pour les sauvegardes).

J'utilise ca65 qui me produit plusieurs fichier objets, puis le linker me créé le binaire. Tout cela donne une certaine illusion de modernité. Ensuite je copie le binaire en tant que fichier de type BIN à l'aide d'AppleCommander. Si je ne me trompe pas, AC ajoute une en-tête qui sera utilisée par BRUN pour charger en mémoire.

Honnêtement je ne sais pas pourquoi l'adresse de départ est 0x803 et non pas 0x800. Je suis parti d'un template fourni par cc65 pour un programme Apple II en assembleur. Il défini "STARTADDRESS: default = $0803;" et utilise les 4 octets précédant pour insérer une sorte d'en-tête. Il y a aussi un symbole "__EXEHDR__" qui est importé. Visiblement ils s'agit d'un header "AppleSingle version 2 file". Ca doit donc servir au moment du load, mais je n'en sais guère plus.

Pour répondre à ta question, sur ma disquette ProDOS il y a BASIC.SYSTEM, ainsi que PRODOS. Tout deux de type SYS. J'imagine que ces fichiers sont chargés au démarrage, afin de donner accès aux commandes et API, mais en fait je n'en sais rien...
N'ayant pas besoin du BASIC je me suis dit que je pouvais dépasser 0x9600 et aller jusqu'à 0xC000. (Quoi que tu as raison, il faut que je fasse attention à la localisation des buffers pour les fichiers).

J'ai trouvé le "ProDOS 8 Technical Reference Manual", je pense que ça ne me fera pas de mal de le lire :/

Christophe

[toc] | [prev] | [next] | [standalone]

#5111

Christophe,
I cannot tell how CA/CC65 works, I do not use it and never will but what I can tell is that, under ProDOS, if your program is bin only then:

- no need for BASIC.SYSTEM, and under ProDOS 8:
-- to make it simple: the available RAM is from $0800 to $BEFF,
-- at page $BF is the ProDOS page and you MUST NOT touch it,
-- each file requires a 1K buffer that you can set when opening a file through the Machine Language Interface of ProDOS,
--- example: you open one file, you set the buffer to $BB00..$BEFF, therefore your program cannot go beyond $BB00 or it will be replaced by the data of the file which buffer is at $BB00.
- you need a SYSTEM loader and I can help you with that, just tell me

Antoine

[toc] | [prev] | [next] | [standalone]

#5112

On Saturday, May 25, 2019 at 9:13:53 PM UTC+2, Antoine Vignau wrote:
> Christophe,
> I cannot tell how CA/CC65 works, I do not use it and never will [...]

Well I understand that. I'm seriously thinking about transitioning to Merlin32, but first I'd like to get my current binary to work as I intended ;) Plus I don't know the work that will be required to adapt the syntax.

Anyway, thanks for your answers. They're helpful. I will also gladly accept your help concerning the SYSTEM loader. What is its role exactly? Loading my binaries or loading ProDOS after booting? Do I have to write one, tailored to my needs???

Christophe

[toc] | [prev] | [next] | [standalone]

#5114

On Sat, 25 May 2019, Christophe Meneboeuf wrote:

> On Saturday, May 25, 2019 at 9:13:53 PM UTC+2, Antoine Vignau wrote:
>> Christophe,
>> I cannot tell how CA/CC65 works, I do not use it and never will [...]
>
> Well I understand that. I'm seriously thinking about transitioning to 
> Merlin32, but first I'd like to get my current binary to work as I 
> intended ;) Plus I don't know the work that will be required to adapt 
> the syntax.
>
> Anyway, thanks for your answers. They're helpful. I will also gladly 
> accept your help concerning the SYSTEM loader. What is its role exactly? 
> Loading my binaries or loading ProDOS after booting? Do I have to write 
> one, tailored to my needs???
>
> Christophe
>
>

ProDOS loads the first file in the directory of type SYS which ends in 
.SYSTEM, at address $2000.

The idea for this file in your case is to then load the rest of the 
program at wherever it needs to go.

-uso.

[toc] | [prev] | [next] | [standalone]

#5117

Steve Nickolas <usotsuki@buric.co> wrote:
> On Sat, 25 May 2019, Christophe Meneboeuf wrote:
> 
>> On Saturday, May 25, 2019 at 9:13:53 PM UTC+2, Antoine Vignau wrote:
>>> Christophe,
>>> I cannot tell how CA/CC65 works, I do not use it and never will [...]
>> 
>> Well I understand that. I'm seriously thinking about transitioning to 
>> Merlin32, but first I'd like to get my current binary to work as I 
>> intended ;) Plus I don't know the work that will be required to adapt 
>> the syntax.
>> 
>> Anyway, thanks for your answers. They're helpful. I will also gladly 
>> accept your help concerning the SYSTEM loader. What is its role exactly? 
>> Loading my binaries or loading ProDOS after booting? Do I have to write 
>> one, tailored to my needs???
>> 
>> Christophe
>> 
>> 
> 
> ProDOS loads the first file in the directory of type SYS which ends in 
> .SYSTEM, at address $2000.
> 
> The idea for this file in your case is to then load the rest of the 
> program at wherever it needs to go.
> 
> -uso.
> 

Or simply move chunks of code/data to where they belong, since a copy loop
is faster (and easier) than a file open, disk read, and file close. 

-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#5143

SAlut Christophe,

You should find a copy of the book "beneath apple prodos". It explains ingreat details the inner workings of prodos.

It helped me a lot to understand.

Stefan


On Saturday, 25 May 2019 21:02:44 UTC+2, Christophe Meneboeuf  wrote:
> On Saturday, May 25, 2019 at 8:04:47 PM UTC+2, Antoine Vignau wrote:
> > Christophe,
> > ton programme est en assembleur ou en BASIC ? Je pose la question parce que tu démarres en $803. Pourquoi pas en $800 ?
> > 
> > Tu es sous ProDOS avec BASIC.SYSTEM (limite RAM $95FF) ou sans (limite RAM $BEFF) - Attention les fichiers ouverts ont besoin d'un ko pour vivre.
> > 
> > Antoine
> 
> Bonjour Antoine.
> 
> J'avoue que je ne comprends pas bien comment le démarrage d'un programme est censé se dérouler...
> Mon programme est entièrement en assembleur. L'idée est d'utiliser toutes le zones mémoires disponibles si j'en ai besoin. Sans empiéter sur les zones urilisées par ProDOS car je compte m'en servir pour lire / écrire des fichiers (pour les sauvegardes).
> 
> J'utilise ca65 qui me produit plusieurs fichier objets, puis le linker me créé le binaire. Tout cela donne une certaine illusion de modernité. Ensuite je copie le binaire en tant que fichier de type BIN à l'aide d'AppleCommander. Si je ne me trompe pas, AC ajoute une en-tête qui sera utilisée par BRUN pour charger en mémoire.
> 
> Honnêtement je ne sais pas pourquoi l'adresse de départ est 0x803 et non pas 0x800. Je suis parti d'un template fourni par cc65 pour un programme Apple II en assembleur. Il défini "STARTADDRESS: default = $0803;" et utilise les 4 octets précédant pour insérer une sorte d'en-tête. Il y a aussi un symbole "__EXEHDR__" qui est importé. Visiblement ils s'agit d'un header "AppleSingle version 2 file". Ca doit donc servir au moment du load, mais je n'en sais guère plus.
> 
> Pour répondre à ta question, sur ma disquette ProDOS il y a BASIC.SYSTEM, ainsi que PRODOS. Tout deux de type SYS. J'imagine que ces fichiers sont chargés au démarrage, afin de donner accès aux commandes et API, mais en fait je n'en sais rien...
> N'ayant pas besoin du BASIC je me suis dit que je pouvais dépasser 0x9600 et aller jusqu'à 0xC000. (Quoi que tu as raison, il faut que je fasse attention à la localisation des buffers pour les fichiers).
> 
> J'ai trouvé le "ProDOS 8 Technical Reference Manual", je pense que ça ne me fera pas de mal de le lire :/
> 
> Christophe

[toc] | [prev] | [next] | [standalone]

#5144

Hi Stefan!

Thanks for the advice: it seems to be quite an interesting reading indeed.
I recognize that I was a bit bold to try programming a game without understanding the inner workings of ProDOS.

But thanks to people here, I have learned a lot during the last few days!

Christophe

On Tuesday, June 4, 2019 at 12:36:59 PM UTC+2, schamp...@skynet.be wrote:
> SAlut Christophe,
> 
> You should find a copy of the book "beneath apple prodos". It explains ingreat details the inner workings of prodos.
> 
> It helped me a lot to understand.
> 
> Stefan
> 

[toc] | [prev] | [next] | [standalone]

#5113

On Saturday, May 25, 2019 at 6:28:09 PM UTC+2, Christophe Meneboeuf wrote:
> 
> Do I have to manually relocate this data at the correct location??
> 

I solved the problem by copying the DATA segments from their location after BRUN does its job, to the location specified in the linker cfg file. Using the symbols defined by the linker (__DATA_START__, __DATA_SIZE__), the task was not to difficult.

I naively believed that, somehow, my segments would directly loaded at the place specified in the .cfg and appearing in the .map :/

[toc] | [prev] | [next] | [standalone]

#5115

On Saturday, May 25, 2019 at 4:10:25 PM UTC-7, Christophe Meneboeuf wrote:
> I naively believed that, somehow, my segments would directly loaded at the place specified in the .cfg and appearing in the .map :/

The ProDOS 8 loader doesn't understand anything but monolithic binary blobs.  For type BIN the load address is in the aux type, SYS loads at $2000.

If you want a minimal 64K linker script, I've been using this in SourceGen:

-----
MEMORY {
    MAIN: file=%O, start=%S, size=65536;
}
SEGMENTS {
    CODE: load=MAIN, type=rw;
}
FEATURES {}
SYMBOLS {}
-----

[toc] | [prev] | [next] | [standalone]

#5116

Hi,

>> Do I have to manually relocate this data at the correct location??

Yes.

>I solved the problem by copying the DATA segments from their location after BRUN does its job, to the location specified in the linker cfg file. Using the symbols defined by the linker (__DATA_START__, __DATA_SIZE__), the task was not to difficult.

:-)

>I naively believed that, somehow, my segments would directly loaded at the place specified in the .cfg and appearing in the .map :/

That was indeed naive because when you build an asm program you get
out exactly what you put in. If you don't supply a relocation routine
then there's no.

The alternative would have been to have the cc65 tool chain create a
"large" binary that contains all the empty space up to $6000. Instead
of just zeros your binary could contain a HGR splash screen that gets
loaded this way. If you're interested in that approach see

https://github.com/cc65/cc65/blob/master/cfg/apple2-hgr.cfg
https://github.com/cc65/cc65/blob/master/testcode/lib/apple2/hgrtest.c

as a starting point.

Regards,
Oliver

[toc] | [prev] | [next] | [standalone]

#5119

Christophe

Welcome to Apple 2 development!

An alternative solution:

Personally, I wouldn't waste your time with ca65.  Just use Merlin32 (or sbasm) and just get on with life.

The problem with ca65 is that it was written originally written by someone who never actually fucking USED an Apple ][ assembler and thus you spend more time farting around with macros to provide basic functionality that is provided out-of-the-box with other Apple ][ assemblers -- such as ASC for hi-bit / lo-bit control of ASCII, HEX strings, and DS to align code.

Also, with Merlin32 you never have to dick around with config files just because cc65 likes to play wannna-be loader when it isn't needed 99% of the time.  All you need is an ORG $0800 mnemonic.  Why would you use another tool to do memory layout when you already know how your memory is laid out and used?  If you don't then why are you writing assembly? :-)

If you are loading under DOS 3.3 you will need to generate a 4 byte meta prefix due to DOS 3.3's retarded design:  2 bytes load address, and 2 byte size, ALL in Little Endian format but that is rather easy to write.  Most of us use ProDOS which doesn't have that stupidity of mixing meta-data inside the file.

Depending on how big your program is if you need more then a "single" file read you could compress your binary program with LZ4 and use qkumba's ~169 byte decompressor, and/or use ProDOS to read it (since reading files is rather trivial under ProDOS), and/or use ProRWTS if you need the space from ProDOS being a memory pig.  Using overlays isn't THAT hard from assembly.

One lazy approach would be to use a virtual 128 KB //e, load your compressed LZ4 binary into $0800 .. $BEFF (or $BFFF), uncompress to aux memory, and move it back to main memory or the LC (Language Card.)

If you are booting from floppies, it isn't THAT hard to write a RTS (ReadTrackSector) and is trivial to read a track/sector once you know how and can be done in less then 128 bytes.  See my Fantavasion Reloaded annotation of the boot sector if you are curious:
https://github.com/Michaelangel007/apple2_fantavision_reloaded

Anyhoo, for my Apple 6502 toolchain I use this process:

First, I have a BASH alias that does:

    alias m='makefile'

which makes it trivial to rebuild just by typing 'm' at the command line. I have this Makefile that assembles my program:

    all: foo

    foo: foo.s
        merlin32 $<
        merlin2symbols $@_Output.txt > $@.sym

That custom merlin2symbols utility reads the output listing file of Merlin32 and generates symbols and addresses so you have nice variable, function, and labels inside the debugger. Because who wants to read raw hex addresses today. :-)

From inside AppleWin's debugger (F7) I have a debug script called R that I execute when I have a new build.

    RUN R

That debugger script file contains:

    bload "foo",800
    symclear user
    run foo.sym
    R PC 800

It loads the binary into memory, clears the user symbol table, loads the symbol table, and starts execution.

Turn around time is EXTREMELY fast and you can spend more time writing (and debugging your program) instead of farting around with clunky toolchains.

Just an alternative for how one toolchain process could work.  There are probably smarter workflows that auto-detect when the binary has change and auto-loads it but Alt-Tab (or Command-Tab) to switch windows and typing in a few commands isn't THAT much work.  

You could even have a script that copies your binary onto a virtual .DSK image and use F2 to re-boot the emulator to re-load it.  Once again BrutalDeluxe comes to the rescue with their Cadius utlity -- a command line tool to manage .DSK images -- that can be scripted.
https://www.brutaldeluxe.fr/products/crossdevtools/cadius/

(I have my own utility but it isn't quite production ready.)


Anyways, welcome to the newsgroup!  It is pretty helpful most of the time when it isn't getting side-tracked by petty flamewars. =)  One of the programmers here is even writing an RPG for the Apple 2!  There are some pretty knowledgable people in c.s.a2.programmer and c.s.a2.  Feel free to ask your question -- you're bound to get an answer.

Cheers,
Michael

[toc] | [prev] | [next] | [standalone]

#5122

Nice toolchain, Michael!
av

[toc] | [prev] | [next] | [standalone]

#5124

Thanks Antoine!  It works. ;-)

I demand iteration time to be near instant.  Over in the C/C++ world none of this 30+ minute bullshit waiting for the compiler. Instead, compile ONE file which includes everything else ("Bulk Build" / "Unity Build") and BOOM -- almost instant compilation. /Oblg. xkcd 303

I *love* the design philosophy of Merlin32:

* Portable across Windows, Linux, OSX, and does 99% of the common cases without requiring the user to fuss around. 
* It solves _actual_ problems that Apple 2 assembly programmers WILL run into.  
* Plus, I like the fact that it doesn't use three-letter (or longer) mnemonics when two will do. DB, DS, etc. :-) I *hate* having to type out "byte" in other assemblers.  Sure, you can use a define / macro but then that annoys everyone else.

Any chance you guys could throw it up on GitHub proper so we can log a few bugs?
i.e. "LDX #" will unfortunately crash the assembler if you leave off the immediate number. :-/  Not a biggie since Vim has undo / diffs but would be nice to have to assembler be "bullet proof."

While I'm asking -- please also put Cadius up on GitHub so we can get a proper cross-platform support. :-)

Anyhoo, back to the toolchain.  If I was smarter / not-so-lazy I would set up my toolchain so that if the source .s file is changed it would automatically reassemble it and put it on a disk image.

AppleWin still sucks in this regard that it will "lock" mounted disk images IIRC.  That would be a much appreciated QoL (Quality of Life) that I probably should fix.
i.e.
AppleWine.exe  -automount

Maybe it's time for a new thread: What's your toolchain?  Pros? Cons?

Michael

[toc] | [prev] | [next] | [standalone]

#5127

I know other devs have put Merlin 32 and Cadius on their github account. I'll tell them to come here and provide a link,

av

[toc] | [prev] | [next] | [standalone]

#5128

Cadius on GitHub:

https://github.com/mach-kernel/cadius

Merlin32 on Github:

https://github.com/apple2accumulator/merlin32

Merlin32 integrations:

https://github.com/OlivierGuinart?tab=repositories

[toc] | [prev] | [next] | [standalone]

#5129

On Thursday, May 30, 2019 at 10:32:20 AM UTC-7, lro...@gmail.com wrote:
> Merlin32 on Github:
> 
> https://github.com/apple2accumulator/merlin32

A number of Merlin 32 bugs are filed in that repository.  If you find more, or have feature requests, please open an issue there.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.sys.apple2.programmer

csiph-web