[ / / / / / / / / / / / / / ] [ dir / bl / canada / chaos / flutter / leftpol / m / mai / newbrit ][Options][ watchlist ]

/tech/ - Technology

You can now write text to your AI-generated image at https://aiproto.com It is currently free to use for Proto members.
Name
Email
Subject
Comment *
File
Select/drop/paste files here
* = required field[▶ Show post options & limits]
Confused? See the FAQ.
Expand all images

File (hide): fd1f177cce83110⋯.jpg (68.29 KB, 590x590, 1:1, amiga.jpg) (h) (u)

File (hide): e3a06db41157660⋯.webm (6.44 MB, 640x480, 4:3, amdm.webm) (h) (u) [play once] [loop]

[–]

 No.808675>>808683 >>808834 [Watch Thread][Show All Posts]

I'm working on an Amiga Music Disk Maker. There's lots of music disks for the amiga, but they all just play one song in a loop till you switch it it manually. I wanted a playlist functionality where you can just pop the disk in and let it play on its own. My plan was to find a tiny module player that can be operated from command line and write a program that would play them one after another. I never done any coding on 68k motorola, but I can code in x86 assembly, so I thought it shouldn't be too hard to write such a tiny basic program. But then I've found HippoPlayer that does almost everything I want. It supports playlists, it can even load packed modules and extract them (requires external depacker, but still, very neat). So I took the required files : HiP, reqtools.library, LHa, Delete, Run (the last 2 are programs that come with the workbench disk), packed them into a self extracting lha archive and wrote a sript that creates a ram disk, extracts the said files to it, runs hippoplayer, deletes HiP and reqtools.library (since they are no longer needed) and run HiP with the songs specified like this : HiP song1.lha song2.lha song3.lha.... It even works with 2 floppies at the same time, some tracks can be on the other disk. Now all is left is to create a tool for PC that will take a bunch of MOD files you want and generate the ADF (amiga disk format) so you can write it to a real floppy. I couldn't find any info online on the ADF format, maybe you can help.

Couple of other things that could be done to improve this:

HippoPlayer is about 80kb and supports shit ton of different song formats, but since this whole project is aimed at stock Amigas with floppy only, it could be simplified greatelly to only support the most common format, which should reduce the size. Also, the packer LHA is about 50kb but it can create archives, supports wildcards, viewing the files etc. Just extracting would be enough and would reduce the binary size. And of course, some effect is badly needed for this thing. Who wants the boring blue shell screen when one could easely do some neat effects in the background. Gotta learn the 86k assembly and amiga HW for real to do that.

btw. Is there a way to make ffmpeg convert to webm faster ? It doesn't even use 20% of my CPU. I'm using "-threads 0" althought there's no difference if I use it or not, or with a different number.

 No.808683>>808684 >>809187

>>808675 (OP)

>Is there a way to make ffmpeg convert to webm faster ?Is there a way to make ffmpeg convert to webm faster ?

--cpu-threads N for N processors is what an anon elsewhere suggested IIRC.

Anon's 2 pass webm convert python script:

https://ghostbin.com/paste/5k32f


 No.808684>>809187

>>808683

>--cpu-threads N

correction from the linked ghostbin script:

--cpu-used 5

for fastest speed


 No.808834>>809187

>>808675 (OP)

>Is there a way to make ffmpeg convert to webm faster ?

-tile-columns 6 -frame-parallel 1

Got this off the webm site somewhere but it should work. The first one lets it split frames into 2⁶ chunks and spread encoding them over a threadpool and the second lets the player multithread decoding, you don't really need that but it's polite to enable it. There's also the -deadline option but that puts a hard time limit on frame encoding and the result usually looks like shit


 No.809187>>810438 >>810580

>>808684

>>808683

>>808834

Thanks, funny, without this one question the thread would be empty. I've found a library called ADFlib which can create adf files and write files to it, so I can start writing my program to generate the floppy images.


 No.810438

>>809187

ok got the lib to work, it's pretty nice. Now I'm hacking around the LHA packer. I already compiled it as shared library, so I can already just calls it's main (I changed the name obviously) but I'm trying to understand the whole program to only use the specific calls to pack the files.After all, I'm always gonna only pack one file and only using the old lh1 format (because that's the only version of lha that the Amiga with kickstart 1.3 can extract) and I don't want to create a file, just keep it in ram. The source code is for Unix only, but it writen in C89, so maybe I could even compile it for the Amiga without much modifications. If so, I'd also simplify it to only extract, leaving the packing features, that should produce much smaller binary (about 50kb for full lha). I also have found an archive of lots of playback routines, each is about 9 kb of assembly code, so compiled it should be even smaller. of course, these are intended for use in demos, so they have hardcoded pointers tobuffers where your mod file should be.... maybe in the next version I could write my own player using these routines that would be smaller than hippo, which is almost 100kb...... average .mod is 150kb and you only get 880kb on a floppy (even less than that because you have to store the filesystem of course) so every byte counts.


 No.810580

>>809187

Most people here weren't around for the Amiga. I was doing scene stuff at the time but for PC. I'd recommend asking on pouet's BBS section.


 No.812806>>812884

File (hide): c4ad4f73720f662⋯.png (298.51 KB, 1860x1050, 62:35, amiga-music-disk-maker.png) (h) (u)

Allright, I made some progress. I modified the LHA packer slighty, so now it acts as a shared library that can pack my files to memory instead of writing to the hdd. It still creates a file, but as soon as it's created I read it's content to the buffer and return it to my own program, so there's one "temp" file being created, but I'll change that too. I also have to modify it a little bit to make it portable. It uses a lot of unix only code that can be easely substited with portable version of these functions (this packer is from 1988 !). It also generates a nice ASCII floppy telling you the content of it. What's left:

Make the LHA portable.

Make the alghoritm that will sort the files in the best way to fit as many files on the floppy as possible

Make a nice GUI (wxWidget probably)


 No.812884>>812938

>>812806

You really should get in touch with the amiga community as I mentioned, they'd love seeing work on the platform.


 No.812938

>>812884

yeah I know, I'm following the demoscene for couple of years now, want to write my first demo sometime soon, I wrote a similar program letting you play continuous music from tapes. I will certainly release this thing on point and similar sites, but I'm just documenting my progress here.


 No.813929

File (hide): 0e716ddb14e0e2a⋯.png (117.84 KB, 735x1033, 735:1033, Screenshot from 2017-11-02….png) (h) (u)

The program now supports generating multiple floppies disk images and sorts the files to try to fit as many as possible. I think the program is almost ready to be released, but I've read on about the amiga's file system and some Amiga programming in general and I can see how a program of this type might be made much, much better.

For starters, the OFS (Old File System, used on the Amigas with kickstart 1.X) use only 488 bytes out of 512 on the floppy block. The other 24 bytes are used for some metadata (to make floppies more reliable), also, each file takes one extra block just for it's name and other data and you can't have 2 files on the same block. Let's take 1kb file for example.

1 Block (512 bytes) just for it mere existence

3 Blocks of data (488 bytes each), the last one only takes 148 bytes, but the second file can't write to that empty space, it has to use another free block.

Also unpacking the files for the playback with real filesystem is a big problem. If you're not aware, The Amiga has 2 types of memory. Chip mem and Slow/fast mem. Chip mem is what is built in, so for the A500 it's 512 kb, Slow/Fast is what comes on expansions. Most people have the 512kb chip + 512kb slow Amiga 500. If you want to play any music or display any graphics it has to be in chip mem, custom chips can only read from there (hence the name), the other memory is only for the CPU. What's the problem then. Well, HIP player will load the file from floppy to whatever memory is available, parse it and when it finally decides that it is a music file and what routine to use it only then loads it to the chip mem so it can work with it. When you have packed file that's even worse, because first you load the packed file, then you unpack it and only then HIP can take look at the file. That's why even though I have 1MB amiga I can't play modules that are larger than about 300kb.

If I was to write my own player and depacked I'd allocate let's say 400kb of chip mem for the module and hardcode that address into the depacker so it always depacks there and the player could just go from there. I could also use all the 512 bytes of the block on the floppy disk to store more data. All of this is planned for v2 of my program, unless someone beats me to it.


 No.815338

File (hide): b3060a2cc1fc697⋯.png (64.93 KB, 1680x1024, 105:64, Screenshot from 2017-11-04….png) (h) (u)

File (hide): 5fd333419e3730a⋯.mp4 (8.32 MB, 1280x720, 16:9, amdm_v1.mp4) (h) (u) [play once] [loop]

I'm pretty much finished with this program, buy holy fuck I got a big problem with it... This player doesn't have any playlist file, you can launch the program with few songs by passing the as arguments like this:


hip.exe song1.mod song2.mod song3.mod etc...

The problem is that hip can only take 16 songs with this method, most of the times even less because the one command can be only so long. You can run this command multiple times, it won't run a second instance of the player


hip.exe song1.mod song2.mod
hip.exe song3.mod song4.mod

but that makes it add the song1 and song2, start loading song1 and when it is loaded it then adds song3 and song4 and starts loading them... This fucking sucks. I added an option to not generate the start up script that would do that and instead save all modules to a folder called "m" (I wanted to avoid that, because each directory takes at least 2 blocks away, 1kb !!) and now you can add the whole directory to the list with just few clicks... oh well. It's not 100% "just-put-it-in-and-let-it-play' like I wanted, but I don't think there's anything I can do without coding my own player.

I tried to disassemble the hip player, I'd like to just remove the function that calls the first song you pass as arguments, that would fix that, you'd only have to press play but... I couldn't find it.




[Return][Go to top][Catalog][Screencap][Nerve Center][Cancer][Update] ( Scroll to new posts) ( Auto) 5
11 replies | 4 images | Page ?
[Post a Reply]
[ / / / / / / / / / / / / / ] [ dir / bl / canada / chaos / flutter / leftpol / m / mai / newbrit ][ watchlist ]