|
WinUAE Demo Toolchain 5 by Lemon.
[nfo]
|
||||||||
|---|---|---|---|---|---|---|---|---|
|
|
|||||||
|
popularity : 69% |
|||||||
alltime top: #2035 |
|
|||||||
|
||||||||
added on the 2015-05-20 08:15:41 by Hannibal  |
||||||||
popularity helper
comments
hannibal.
omg.
omg.
hannibal.
omg!
omg.
Quote:
I was originally planning to make a giant surprise return demo
omg.
hannibal.
omg!
Great!
Spike, don't get your hopes up :-)
While I have plenty of ideas, I just don't have the time. And Paradroid set the bar pretty high with Redux, so I wouldn't feel happy releasing something half-assed :-)
While I have plenty of ideas, I just don't have the time. And Paradroid set the bar pretty high with Redux, so I wouldn't feel happy releasing something half-assed :-)
The force is with the Amiga community. This is UNBELIEVABLE! Thank you for putting all this awesome stuff together. I'm sure this will be of help for many many people.
I'm also looking forward to see your demo at Revision 2016 :-)
I'm also looking forward to see your demo at Revision 2016 :-)
This is pretty cool stuff. A lot of smart solutions for wellknown problems. If you would have released this half a year ago, that would have saved me weeks and month of work.
And now start to work on the demo! *hehe*
And now start to work on the demo! *hehe*
Amazing work!
Sweet, respect for all your work! At first I wasn't sure how the batch files for launching executables were that useful, as you can just drag&drop an exe to auto-boot on WinUAE anyway. However, the support for different Amiga configurations does make this .bat method quite handy indeed. Great stuff, hopefully this will inspire many new demomakers (not to mention the old ones)
Inspiring!
In light of this toolchain, excuses for not releasing stuff on Amiga is getting pretty thin :)
Awesome work.
Awesome work.
I'll be nicking a few things from this, great stuff! :-)
@Hannibal - with that out of the way you can get started on the demo and raise the bar again!
@Hannibal - with that out of the way you can get started on the demo and raise the bar again!
hmmm make me want to start Amiga coding :D
Whoa, very nice stuff!
(10 second build-and-run is far too slow for my preferred workflow but I'm pretty sure I'll be stealing other parts from this package! :D )
(10 second build-and-run is far too slow for my preferred workflow but I'm pretty sure I'll be stealing other parts from this package! :D )
Seems super awesome!
didn't look at it as i have no spare-time as always, but anyway: a big thank you for the effort!
what everyone else already said.
Damn, this is tempting...
What rez said.
I'm not (yet) an Amiga guy, but from what i understand, this is plain awesome. Makes a potential port of my "Boing" much easier =)
I've been using the previous version of the ToolChain for some time.. even for a lot of that time not knowing it was put together by my fellow Lemon. member Hannibal :)
I don't really need this as WinUAE+Asm-Pro/One works fine for me. :) I will have a look at your graphics converter though as its features sound quite nice. Thanks for releasing this and all the work you put into it!
Hope this brings us some more cool amiga demos :)
finally... Amiga starts to catchup Atari 800 dev tools :P
Now, what we need is an example for something that has an ADPCM music playing and a "a0 points to your framebuffer":D
cool
What a great announcement. @Hannibal: make great intros than if you dont have time for great demos. :)
Force is strong in Lemon. :) I will definitely have a look at it - thanks a lot for sharing this and fingers crossed for your return on Amiga! :)
Nice, but i'm waiting the biggest Lemon. Demo evermade coded by Hannibal+Dan+Paradroid :-)
I´m totally new to this community, so first of all - thank you for having me here.
I used to develop on Amiga in the 90ies wie Devpac and now plan to reactivate some of my old code. This toolchain seems to be a good starting place. Wonder if someone has done something similar on Mac though, since I dont work on Windows.
I used to develop on Amiga in the 90ies wie Devpac and now plan to reactivate some of my old code. This toolchain seems to be a good starting place. Wonder if someone has done something similar on Mac though, since I dont work on Windows.
Looks great! :) And exactly when I was thinking about giving Amiga coding a try. :)
Will give it a try soon, than will judge the tool-chain.
@buzzybee
Feel warmly welcomed than. Good luck with your coding tries.
@buzzybee
Feel warmly welcomed than. Good luck with your coding tries.
For sure.
why vasm without win32 build?
Lemon <3
@Goblinish
grab Axis' tool chain from Rockplanet Lobbster. There in the tool folder you find the win ports of VC/VASM.
https://github.com/AxisOxy/Planet-Rocklobster
I am using Oxy toolchain and it works so far. Wanted to switch to Hannibal's one because of the gfx converter seems to be more advanced than Axis' one but for my stuff works so far...
Kingcon was not compiled either but it was easily done with Visual Studio community edition. Even I could compile it :D
grab Axis' tool chain from Rockplanet Lobbster. There in the tool folder you find the win ports of VC/VASM.
https://github.com/AxisOxy/Planet-Rocklobster
I am using Oxy toolchain and it works so far. Wanted to switch to Hannibal's one because of the gfx converter seems to be more advanced than Axis' one but for my stuff works so far...
Kingcon was not compiled either but it was easily done with Visual Studio community edition. Even I could compile it :D
@Heaven: gotcha, 10x!
demo\tools\vasm
demo\tools\vasm
Nice!
@Heaven and @g0blinish: You are missing some executables? I don't know why that would be - vasmm68k_mot_win32.exe should be found in \toolchain\bin, and kingcon.exe should exist in of \toolchain. Is this not what you see when downloading the zip from scene.org?
If the example builds and runs then that should prove that the executables are there, right.
If the example builds and runs then that should prove that the executables are there, right.
offers easy start for those who wish to return to amiga :)
Nice work!
Well, I'm playing with it and it works really great! :)
So far, I have several comments.
1. It would be cool if toolchain was separated from the project instead of all projects existing in subfolders. I usually put all tools in one location and projects in separate ones. It would be great if projects could exist anywhere on the disk and refer to the toolchain via something like %WINUAE_TOOLCHAIN_DIR% instead of refering to parent directory (for my needs I did that change myself).
2. The above also goes for gfx/msx. It would be cool if they could exist in project directory and get converted there. Of course if it's doable - I see a lot of tools run on emulated Amiga and dirs need mounting.
3. C compiler is missing some default libraries. Most notably 'vc.lib' for __muls and __divs functions which took a while to find binaries of. You won't use __divs in your per-pixel loop, but for prototyping effects it's great and one or two __divs per frame somewhere in effect setup won't hurt much, too.
4. Some EXE to bootable ADF converter would be great. While WinUAE can just launch exes, I don't think that MiST can.
5. Maybe consider switching to Makefiles in next version? While the code would have to be recompiled entirely anyway, the asset conversion could use some timestamping and automatically convert any updaed assets for the project. Of course points that assumes 1. and 2. above.
Please treat the above as feedback, not complaints. Your work is great and I just wanted to post some details from a fresh user perspective. I don't know what you intend your toolchain to become and what work patterns are comfortable to you, but things above is just what came to me while using the toolchain.
Keep up the good work! :)
So far, I have several comments.
1. It would be cool if toolchain was separated from the project instead of all projects existing in subfolders. I usually put all tools in one location and projects in separate ones. It would be great if projects could exist anywhere on the disk and refer to the toolchain via something like %WINUAE_TOOLCHAIN_DIR% instead of refering to parent directory (for my needs I did that change myself).
2. The above also goes for gfx/msx. It would be cool if they could exist in project directory and get converted there. Of course if it's doable - I see a lot of tools run on emulated Amiga and dirs need mounting.
3. C compiler is missing some default libraries. Most notably 'vc.lib' for __muls and __divs functions which took a while to find binaries of. You won't use __divs in your per-pixel loop, but for prototyping effects it's great and one or two __divs per frame somewhere in effect setup won't hurt much, too.
4. Some EXE to bootable ADF converter would be great. While WinUAE can just launch exes, I don't think that MiST can.
5. Maybe consider switching to Makefiles in next version? While the code would have to be recompiled entirely anyway, the asset conversion could use some timestamping and automatically convert any updaed assets for the project. Of course points that assumes 1. and 2. above.
Please treat the above as feedback, not complaints. Your work is great and I just wanted to post some details from a fresh user perspective. I don't know what you intend your toolchain to become and what work patterns are comfortable to you, but things above is just what came to me while using the toolchain.
Keep up the good work! :)
Not sure but probably you should select CPU to be 020+ so that compiler can generate 32bit mul and div commands instead of trying to use some library. 68000, which is probably the default for compiler, does not have 32bit mul and div commands.
@lvd: I'm targetting OCS.
Also to add to the points:
6. I had to add lowest Amiga 500 configuration (Kickstart 1.3, 512MB RAM). Would be nice to have one in predefined ones.
Also to add to the points:
6. I had to add lowest Amiga 500 configuration (Kickstart 1.3, 512MB RAM). Would be nice to have one in predefined ones.
KK, re point (4) note that copy2adf is included. Fantastic toolkit I've used for some time now, although quite customised by this point :)
Thanks for the detailed suggestions, KK. I'll be happy to explain my design choices here.
1. yeah, that's definitely possible. One of my main design goals was to not require any installs/settings beyond just running the batch file, but I could change the sample bat files to check on this instead. Not sure I will get around to it
2. yeah, possible. I probably won't do this work myself either.
3. I don't know much about amiga c libraries. This sounds like a good fix. I just need to make sure that those binaries are freely sharable. Where did you find them?
4. copy2adf does all of this. It would be 3 commands or so, but it can create empty floppies and copy files to them, so you can make a simple bat-file for this yourself. BTW, the "runaXXX.bat" files internally detect if you add an adf or not, and if it is not an adf then it generates startup-sequence on the harddrive to launch it - so I use these to launch both adf and single-file demos.
5. I'm very familiar with makefiles, and it was a conscious choice for a couple of reasons:
5a. There are 2 types of programmers - the ones that are passionate about makefiles and the ones that don't care (or know) about how makefiles work - they just want to hack things together. The people that are passionate about makefiles can easily make their own makefiles, but the ones that just want to cobble things together, bat-files are simpler to read. And since I wanted to set this up to attract as many old-timers as possible - the ones that may never have bothered to learn makefiles, the choice was pretty clear for me.
5b. about asset conversion timestamping: sure, this would come automatically with makefiles, if there was a single output - however, my system spits out up to 4-5 files per asset being converted. So it's harder to have dependency checks like that. Also, it is a HUGE speedup on asset conversion to have a single executable launch that does a large batch of assets. So I wanted to do asset versioning check inside the executable instead, as part of the batch tool. I don't think I ever got it working, though - maybe later. Interestingly, the code reformatter actually does a version check - not using timestamps but by using a CRC. Also, I did the batch processing because it was fun to try to mess with threading :-)
6. Good point - To me, the gold standard is 1mb a500, but I can see the value in the 512k one.
1. yeah, that's definitely possible. One of my main design goals was to not require any installs/settings beyond just running the batch file, but I could change the sample bat files to check on this instead. Not sure I will get around to it
2. yeah, possible. I probably won't do this work myself either.
3. I don't know much about amiga c libraries. This sounds like a good fix. I just need to make sure that those binaries are freely sharable. Where did you find them?
4. copy2adf does all of this. It would be 3 commands or so, but it can create empty floppies and copy files to them, so you can make a simple bat-file for this yourself. BTW, the "runaXXX.bat" files internally detect if you add an adf or not, and if it is not an adf then it generates startup-sequence on the harddrive to launch it - so I use these to launch both adf and single-file demos.
5. I'm very familiar with makefiles, and it was a conscious choice for a couple of reasons:
5a. There are 2 types of programmers - the ones that are passionate about makefiles and the ones that don't care (or know) about how makefiles work - they just want to hack things together. The people that are passionate about makefiles can easily make their own makefiles, but the ones that just want to cobble things together, bat-files are simpler to read. And since I wanted to set this up to attract as many old-timers as possible - the ones that may never have bothered to learn makefiles, the choice was pretty clear for me.
5b. about asset conversion timestamping: sure, this would come automatically with makefiles, if there was a single output - however, my system spits out up to 4-5 files per asset being converted. So it's harder to have dependency checks like that. Also, it is a HUGE speedup on asset conversion to have a single executable launch that does a large batch of assets. So I wanted to do asset versioning check inside the executable instead, as part of the batch tool. I don't think I ever got it working, though - maybe later. Interestingly, the code reformatter actually does a version check - not using timestamps but by using a CRC. Also, I did the batch processing because it was fun to try to mess with threading :-)
6. Good point - To me, the gold standard is 1mb a500, but I can see the value in the 512k one.
Couple more comments:
3. Which libraries are this? Where did you find them? What are they from? If they are legally redistributable, I'd probably want to include them
6. I actually already had one, I just forgot: Runa500_nofast is 512chip/0fast runa500 is for 512chip/512fast.
3. Which libraries are this? Where did you find them? What are they from? If they are legally redistributable, I'd probably want to include them
6. I actually already had one, I just forgot: Runa500_nofast is 512chip/0fast runa500 is for 512chip/512fast.
3. Looks like vc.lib is just a part of VBCC (link). I used the vc.lib in "vbcc_target_m68k-amigaos.lha" archive on this page. It's on VBCC page, so license probably is the same. You'd probably want to include all the libs and headers in your framework.
And a new one:
7. Framework fails on Kickstart 3.1 even with max compatibility. Try to run example demo on A4000 kick 3.1. This is kickstart problem - I tried it with custom configs and even A500 with kick 3.1 fails, while A4000 with lower kickstart works.
And a new one:
7. Framework fails on Kickstart 3.1 even with max compatibility. Try to run example demo on A4000 kick 3.1. This is kickstart problem - I tried it with custom configs and even A500 with kick 3.1 fails, while A4000 with lower kickstart works.
7. I can't reproduce the problem, KK. I attempted these 2 things:
runa4000_60.exe exampledemo\out\exampledemo.exe (both AmigaForever or regular roms)
or
toolchain\startwinuae.exe a500 kick31 exampledemo\out\exampledemo.exe (the override only works if you DONT have amigaforever roms)
Both ran fine
Which exact roms are you seeing this on? There are multiple different Kickstart 3.1 out there (amigaforever lists different ones for a600 vs a1200 vs a4000 etc)
And what are your repro steps?
runa4000_60.exe exampledemo\out\exampledemo.exe (both AmigaForever or regular roms)
or
toolchain\startwinuae.exe a500 kick31 exampledemo\out\exampledemo.exe (the override only works if you DONT have amigaforever roms)
Both ran fine
Which exact roms are you seeing this on? There are multiple different Kickstart 3.1 out there (amigaforever lists different ones for a600 vs a1200 vs a4000 etc)
And what are your repro steps?
I'm using something called "Amiga Kickstart Roms - Complete - TOSEC v0.04" / KS-ROMs / "Kickstart v3.1 rev 40.63 (1993)(Commodore)(A500-A600-A2000).rom" for KICK31.rom.
And for the repro, I just changed launcher in BuildAndRunDemo.bat to "runa4000_40" and ran demo with debug flag to skip the packer (it dramatically increases total load time in the end).
And for the repro, I just changed launcher in BuildAndRunDemo.bat to "runa4000_40" and ran demo with debug flag to skip the packer (it dramatically increases total load time in the end).
I could repro the blank screen bug, but only if I
1. used the plain blueberry startup code (not my example demo, which was fixed), which doesn't enable screen DMA but assumes it is enabled
2. used only with kick 3.x, not with kick 1.x, because with kick 3.x it doesn't enable screen until something triggers a CLI window update, and
2. used the "-debug" flag (which disabled the compression and therefore didn't print anything on screen).
I don't think this is what you saw in your demo. Nevertheless, for next version, I will try to make it print something on screen at bootup, to not trigger this.
1. used the plain blueberry startup code (not my example demo, which was fixed), which doesn't enable screen DMA but assumes it is enabled
2. used only with kick 3.x, not with kick 1.x, because with kick 3.x it doesn't enable screen until something triggers a CLI window update, and
2. used the "-debug" flag (which disabled the compression and therefore didn't print anything on screen).
I don't think this is what you saw in your demo. Nevertheless, for next version, I will try to make it print something on screen at bootup, to not trigger this.
I have usually my own coding setup, but your ExampleBootBlock was really helpful when writing my latest bootblock and nuking bytes to make it fit. Thanks to the packer, I was finally able to cram-in a non-dos file-loader and a hunk-relocator into my bootblock. I also liked your introduction of a WinUAEBreakpoint macro. Neat!
I noticed two or three things while writing my bootblock: First, unpackbootblockwrapper breaks the Amiga calling convention of a1 containing ioreq and a6 sysbase. Not a big deal, but rather a small nuisance until you notice it. Second, StartAddress=$20000 does not work well on my real A1260. But raising it to $40000 made the bootblock work on everything I tried it on so far.
Overall a great package. Thanks for that!
I noticed two or three things while writing my bootblock: First, unpackbootblockwrapper breaks the Amiga calling convention of a1 containing ioreq and a6 sysbase. Not a big deal, but rather a small nuisance until you notice it. Second, StartAddress=$20000 does not work well on my real A1260. But raising it to $40000 made the bootblock work on everything I tried it on so far.
Overall a great package. Thanks for that!
yes Paradroid we do want you to start coding amiga again, and throwing disks like the somerset party in '92 :) :) :) :)
Rink a Dink Redux was amazing btw, got me hyped for coding amiga stuff for at least a week
+
This, a lifesaver
Good, very useful and easy to use.
I have been playing around with this yesterday, and the exampledemo works.
Then I took exampledemo.s and deleted almost all of it and disabled music to get a skeleton, but no matter what I do, it doesn't work. Symptoms look like missing bitplane and copper dma. I noticed that the exampledemo also stops working if music is disabled (similar symptoms), however. I've stared at it too long now without seeing where the damn problem is - anybody have an idea?
Then I took exampledemo.s and deleted almost all of it and disabled music to get a skeleton, but no matter what I do, it doesn't work. Symptoms look like missing bitplane and copper dma. I noticed that the exampledemo also stops working if music is disabled (similar symptoms), however. I've stared at it too long now without seeing where the damn problem is - anybody have an idea?
never used it, but seems quite useful for people wanting to get back into amiga coding
Helped a lot, thank you!
submit changes
if this prod is a fake, some info is false or the download link is broken,
do not post about it in the comments, it will get lost.
instead, click here !
Some of the key features are
* new windows-based image-to-raw converter with a billion features (images, sprites, attached sprites, bobs, animations, halfbrite, copperbars, fonts (monospace and proportional), including samples. Also spits out "preview" images to quickly review that image has been converted properly. Includes batch functionality
* one-click build-and-run single-file demo example (based on Blueberry's startup code) - with multiple music players and showing various bits of sample art, to test the converter
* one-click build-and-run bootblock example (based on Blueberry's bootblock sample) - includes compression
* 68k assembler syntax highlighting in Visual Studio 2013
* 68k assembler code prettifier
* tool to write sectors to adf-files, including bootblocks (and bootblock checksum calculation)
* bat-files to launch WinUAE with a lot of different music editors (ProTracker, OctaMED, Future Composer, and AHX), music player (DeliTracer) and titanics cruncher.
* bat-files to launch windows-based tools for sine creator, the Grafx2 graphics editor, and converting wav-files to iff
* bat-file to convert mod-files to p61
* bat-files to launch WinUAE with single-file executables or adf-files for a500/a500plus/a1200/a4000 - perfect for demo viewing
* one single shared harddrive setup (dh0 for tools/temp files and dh1 for assets)
While you can build and run the two examples without any kickstarts, you still need all kickstart roms and the Workbench 1.3 disk to get the full benefits.
Post bugs and errors here or on this thread on ADA. Check out the readme first, though.