Launch / build configuration helper - which options should be added ?

[prb28]

After some discussion (with @phaze101) and questions as the last one from @C64HexCoder to add the fpu option.
A configuration helper seems to be an interesting new feature.
I don't know for now how it should look like, but before that, which minimal options do you think should be added?
At least I'm thinking of:

• type of Amiga (1000/500/600/1200/3000/4000/CD32/vampirev4?)
• kickstart (version and/or select file)
• size of chip ram
• size of slow mem
• cpu (vasm options 68000/8/10/20/30/40/60/80)
• fpu (no-fpu/68851/68881/68882)

A helper will be added to the syntax checker (file build with vasm) with the options:

• cpu (vasm options 68000/8/10/20/30/40/60/80)
• fpu (no-fpu/68851/68881/68882)

Some standard amiga:

• The A500 normally has a 68000 processor and 512K or 1MB Chip RAM with 1.3 Kickstart and OCS/ECS or 2.04 Kickstart for the A500+ with ECS.
• The A1000 normally has a 68000 processor, 256K RAM, OCS and Kickstart 1.0 to 1.3.
• The A2000 shares the same hardware as the A500 but uses ZII memory, and gfx card option.
• The A600 normally has a 68000 processor and 1Mb of Chip RAM with 2.05 Kickstart and ECS.
• The A1200 normally has a 68020 processor and 2Mb Chip RAM and 3.0 Kickstart and AGA (Winuae 0.8.8 or better) for 256 colours.
• The CD32 normally shares the same hardware as the A1200 but has a built in CD ROM drive. Requires CD32 roms.
• The A3000 normally has a 68030, 1Mb Chip RAM, possibly some Fast RAM and ECS or Gfx card.
• The A4000 normally has a 68030/040/060 processor, 2Mb Chip RAM, 2Mb or more Fast RAM and AGA or a graphics card (use Picasso96 to simulate one).

Useful docs:

• Documentation of vasm : http://www.ibaug.de/vasm/doc/vasm.pdf
• winuae conf : http://pjhutchison.org/emulation/uae_config.html

[Real-MJoe]

That sounds good to me. But this would only be helpful for compiling. I always explicitly set the target configuration for WinUAE in launch.json. So I can test my code, which was compiled for 68000, on a 68020 and also debug it.
Yes, you have to create a handful of configs for WinUAE first, but I can easily use them in other projects.
So I also have a config that displays the screen *2.

[C64HexCoder]

Good idea. An online document wich describe the option, in addition, will be great. בתאריך שבת, 20 באוג׳ 2022, 20:23, מאת Real-MJoe ***@***.***>:

…

That sounds good to me. But this would only be helpful for compiling. I always explicitly set the target configuration for WinUAE in launch.json. So I can test my code, which was compiled for 68000, on a 68020 and also debug it. Yes, you have to create a handful of configs for WinUAE first, but I can easily use them in other projects. So I also have a config that displays the screen *2. — Reply to this email directly, view it on GitHub <#236 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCJAQQNOBAZQLIYY4XI5XTV2EH7ZANCNFSM57DL3EHA> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[phaze101]

I am correcting some of the above configs

A500 (standard hw Config)

• A500 is only 512K (some motherboards can be modified to have more chipram with some hardware changes but originally only 512K)
• Came with Kickstart 1.2 and Kickstart 1.3
• Is only OCS no ECS
• Can add slow mem 512K to make it 1MB machine but don't confuse with A500+

A500+ /A600 (standard HW Config)

• Kickstart 2.04 / A600 Kick 2.05 if HD
• 1MB Chipmem
• Can be expanded with 1MB Slow ram
• Total is 2MB but still 1MBChip ram
• ECS Chipset

[Real-MJoe]

Somehow I don't see the advantage of keeping "fixed" configurations for WinUAE or FS-UAE. I can create these myself and integrate them accordingly. That is a big advantage of this extension, that I can use these configurations simply.
Fixed configurations must also have a fixed path to the KS.
But that is only my opinion.

[prb28]

The idea is to help to generate the configuration files for a new user.
For an advanced user the rough path ("do it as you want") by editing the configuration files will stay.

[fredrik-m-j]

I use the approach I saw in one of @phaze101 streams where I let the extension create the example workspace, and then I start WinUAE, load its config and save changes back to it - all within the WinUAE UI. This works very well. I don't know if it works if you switch between multiple Amiga projects though. 1 project is more than enough for me :-)

[phaze101]

I have created my own configs (a500, A600 and a1200 with accurate cycle timings and their debug version) and my own binaries. The binaries are basically the same of the extension with some minor changes for WinUAE and moved them to a directory called common which I point to. Like that all the configs happen for all projects. I haven't shared this because I do not want to interfere with this project. I think @prb28 is doing a great job and in the end I know he will implement such a thing. I have shared my work with him. Also one can have a selection of examples or projects that one can select and start with something more than just a copper bar. I did start working on this but had to hold back due to life getting in the way. Also I only use Windows for my dev with WinUAE. I find WinUAE a better option then FS-UAE and hence my things have only been tested on Windows.