You saved the sample as 8bit signed but IIRC it’s declared as unsigned char in your code. (I didn’t get the name of the tool that you used to convert it to C array.)
ultimately, doesn't matter from the compiler's standpoint. the tool I used to create the data is called 'xxd' and it has an -i function that can take any input and spit out a C array.
You put your period size as a constant but why not put instead the calculation you make? Like NTSC_CLOCK/SAMPLE_RATE (might be good to put the value for PAL too)
@26 mins, the presenter yawning during the compile, fitting. As for topics. A suggestion would be a exposition of the Ports, and messaging. I don't recall from that time programs that worked together sharing the same data and going to sleep and being awakened by a change in a shared resource (memory). Wait() MsgPort(...1
I want to put together a game and video set using the ROM routines, including lots of little exec tasks. That's what the routines were for in the first place.
Love your excitement, but as a game developer who has had to deal with multithreading, UX, and audio priority a little, I'm not sure you're well in tune with the actual needs. Those priorities are more likely to get in the way than help. They're probably good enough for arbitrating between applications, but within a game you're most likely going to want something tailored to the purpose. Ideally, you reserve a specific number of channels and then deal with priority yourself. I also would definitely not use OS threads for most scheduling -- it can make sense to have a separate sound thread if that means you don't need to implement an ISR or callback, but beyond that I'm very skeptical. Multithreading is hard to design around, hard to debug, causes unpredictable latency problems, and generally is a tax on performance if you don't have multiple cores to parallelize over.
I have done this for the Amiga in the past, using the OS routines, and intend to do so again, in a video series. But I appreciate the condescending pat on the head. p.s. if you're going to try and push against what I've done, provide code. otherwise sod off.
There's a distinction to be made between the situation on Windows(which most gamedevs today are familiar with) and the Amiga, and why you'd land on one or the other set of best practices. On Windows, you are in an adversarial environment and have to do things through a hardware abstraction layer that talks to vendor device drivers. There's no method to access audio hardware registers because that's not something you abstract. The abstraction may change internally. And the abstraction falls over when the layers you don't control break. Therefore a Windows dev doing something complex and timing-dependent is inclined to be paranoid about what the operating system provides and attempt to grab whatever the lowest level of control is, then hold it statically until the program exits, because you don't know what sort of mystery meat is in between you and the hardware, so the next best thing you can do is to hoard all the system resources. The Amiga is a more holistic design - one vendor doing hardware and software together - and it's designed from a position of trusting the user software, which keeps it uncomplicated. There's no motive to be paranoid, and therefore it's reasonable to view Kickstart as a framework that you can use directly for the deep internals of your programs.
@@JH-pe3ro These libraries were originally designed to be used when the Amiga was to be a game console, and were designed by an interesting confluence of people: * Bob Pariseau came from Tandem, big iron. * Carl Sassenrath came from the big iron HP world, who wrote Exec. * As did Dale Luck, who wrote graphics.library. * RJ Mical and Sam Dicker came from Williams Electronics, and were part of Eugene Jarvis' Vid-Kidz team. They were all in VERY close quarters, right next to each other, for the better part of 18 months, assembling all this library code onto a SAGE IV with a set of terminals hanging off of it. (Exec actually had its first bring-up on an HP 64000 development system) As such, progress literally happened via (as the great Ron Milner once put it) "spatial devance" as print-outs would cross from one side of the room to the other. The result literally was a well thought out homogenous set of routines intended to be used together to make games, which, because there was just enough wiggle room in the design, was able to make the leap to being a computer when RJ Mical wrote Intuition, which leveraged the graphics, layer, and input libraries. It's a very rare thing when you have a set of people who are so comfortable, yet driven, and have such a will to work together, that you're able to produce something so well designed.
@@tschak909 I didn't come here just to be a jerk, I love the coding nostalgia hit and I really appreciate the videos and the time you put into making them! I suppose it wasn't clear but I appreciate you're using the pac man project to showcase AmigaOS. That's something I want to see. So thank you! As I alluded I've worked on a bunch of titles with different teams going back a couple decades, so from my perspective my money's already where my mouth is. When I say "I would not do that" it's literal, not speculative: _I am the putative game developer._ Obviously you do what you like, I just happen to align with the conventional wisdom. There are some natural uses of threads for gameplay, for example to manage long running jobs like pathfinding, but if you tried to build a realistic case, we'd probably be here all year. I don't really want to argue in comment threads, if you want to have a metaphorical or literal beer and chat, I could probably find you on the FujiNet discord, but I'm only doing that if it would bring you joy to hash out. Everybody busy, I want to contribute to your happiness, and it seems I'm starting out in debt. That all said, of course I think you'll be successful! There are simpler and more robust idioms for gameplay, but what you're doing _can_ work. At any rate, I'm not here for game programming advice, what I want is to see you implement tasks -- I was suffering it out with DOS long past AmigaOS' market decline, and it's fascinating to see now what I could have been working with instead!
Love these videos
You saved the sample as 8bit signed but IIRC it’s declared as unsigned char in your code. (I didn’t get the name of the tool that you used to convert it to C array.)
ultimately, doesn't matter from the compiler's standpoint.
the tool I used to create the data is called 'xxd' and it has an -i function that can take any input and spit out a C array.
You put your period size as a constant but why not put instead the calculation you make? Like NTSC_CLOCK/SAMPLE_RATE (might be good to put the value for PAL too)
That's a good idea! :) Why don't you do a fix and a PR? github.com/tschak909/amiga-orch-beep
@26 mins, the presenter yawning during the compile, fitting.
As for topics. A suggestion would be a exposition of the Ports, and messaging. I don't recall from that time programs that worked together sharing the same data and going to sleep and being awakened by a change in a shared resource (memory). Wait() MsgPort(...1
I want to put together a game and video set using the ROM routines, including lots of little exec tasks. That's what the routines were for in the first place.
Or go 2.04 and do some Arexx scripting :)
Love your excitement, but as a game developer who has had to deal with multithreading, UX, and audio priority a little, I'm not sure you're well in tune with the actual needs.
Those priorities are more likely to get in the way than help. They're probably good enough for arbitrating between applications, but within a game you're most likely going to want something tailored to the purpose. Ideally, you reserve a specific number of channels and then deal with priority yourself.
I also would definitely not use OS threads for most scheduling -- it can make sense to have a separate sound thread if that means you don't need to implement an ISR or callback, but beyond that I'm very skeptical. Multithreading is hard to design around, hard to debug, causes unpredictable latency problems, and generally is a tax on performance if you don't have multiple cores to parallelize over.
I have done this for the Amiga in the past, using the OS routines, and intend to do so again, in a video series. But I appreciate the condescending pat on the head.
p.s. if you're going to try and push against what I've done, provide code. otherwise sod off.
There's a distinction to be made between the situation on Windows(which most gamedevs today are familiar with) and the Amiga, and why you'd land on one or the other set of best practices. On Windows, you are in an adversarial environment and have to do things through a hardware abstraction layer that talks to vendor device drivers. There's no method to access audio hardware registers because that's not something you abstract. The abstraction may change internally. And the abstraction falls over when the layers you don't control break. Therefore a Windows dev doing something complex and timing-dependent is inclined to be paranoid about what the operating system provides and attempt to grab whatever the lowest level of control is, then hold it statically until the program exits, because you don't know what sort of mystery meat is in between you and the hardware, so the next best thing you can do is to hoard all the system resources.
The Amiga is a more holistic design - one vendor doing hardware and software together - and it's designed from a position of trusting the user software, which keeps it uncomplicated. There's no motive to be paranoid, and therefore it's reasonable to view Kickstart as a framework that you can use directly for the deep internals of your programs.
@@JH-pe3ro These libraries were originally designed to be used when the Amiga was to be a game console, and were designed by an interesting confluence of people:
* Bob Pariseau came from Tandem, big iron.
* Carl Sassenrath came from the big iron HP world, who wrote Exec.
* As did Dale Luck, who wrote graphics.library.
* RJ Mical and Sam Dicker came from Williams Electronics, and were part of Eugene Jarvis' Vid-Kidz team.
They were all in VERY close quarters, right next to each other, for the better part of 18 months, assembling all this library code onto a SAGE IV with a set of terminals hanging off of it. (Exec actually had its first bring-up on an HP 64000 development system)
As such, progress literally happened via (as the great Ron Milner once put it) "spatial devance" as print-outs would cross from one side of the room to the other.
The result literally was a well thought out homogenous set of routines intended to be used together to make games, which, because there was just enough wiggle room in the design, was able to make the leap to being a computer when RJ Mical wrote Intuition, which leveraged the graphics, layer, and input libraries.
It's a very rare thing when you have a set of people who are so comfortable, yet driven, and have such a will to work together, that you're able to produce something so well designed.
@@tschak909 I didn't come here just to be a jerk, I love the coding nostalgia hit and I really appreciate the videos and the time you put into making them! I suppose it wasn't clear but I appreciate you're using the pac man project to showcase AmigaOS. That's something I want to see. So thank you!
As I alluded I've worked on a bunch of titles with different teams going back a couple decades, so from my perspective my money's already where my mouth is. When I say "I would not do that" it's literal, not speculative: _I am the putative game developer._ Obviously you do what you like, I just happen to align with the conventional wisdom. There are some natural uses of threads for gameplay, for example to manage long running jobs like pathfinding, but if you tried to build a realistic case, we'd probably be here all year. I don't really want to argue in comment threads, if you want to have a metaphorical or literal beer and chat, I could probably find you on the FujiNet discord, but I'm only doing that if it would bring you joy to hash out. Everybody busy, I want to contribute to your happiness, and it seems I'm starting out in debt.
That all said, of course I think you'll be successful! There are simpler and more robust idioms for gameplay, but what you're doing _can_ work. At any rate, I'm not here for game programming advice, what I want is to see you implement tasks -- I was suffering it out with DOS long past AmigaOS' market decline, and it's fascinating to see now what I could have been working with instead!