Thank you so much for this video! I saved for whole YEAR to be able to buy Lattice C (later called SAS right?) for my A2000. They two gray books with compiler options was HARD for a 14 year old buy that have never written ANYTHING.😀 An old unix guy bought be a real C book at got me started. Yes still coding 35 year later 🙂 What an extremely nice time of my life. I really think the Amiga UI (and especially the font) looked great!. Later I got an A1200. I remember thinking 800x600 is just the perfect resolution. Thank thanks thanks!
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.
@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<<Usebits...) well you know the rest.
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.
Nicely explained. I've heard it said that HAM is tricky because in RGB it doesn't make much sense. However, it's interesting to note that the Amiga was originally going to be a YUV system, suddenly HAM makes a lot more sense!
Always found that interesting when using DPaint in Ham modes. You'd see the colours bleeding next to the crosshairs. Not heard it called fringing before, great way to put it.
Color fringing artifacts are often helpful by providing smoother blending between colors. This especially helps when the display is an NTSC TV where Amiga "low res" pixels are already half the size of a TV color clock.
Here's a good example of HAM6 animated for a WIP JRPG game: Amiga 1000 ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-XDdMoglmUbs.html ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-JJczdYO8N1c.html And a HAM6 game from back in the day: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-z1uUccmHSXE.html Finally, an AGA HAM8 paint program: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-zGl80mjT2-8.html
30:00 - I was always fond of the AVAIL FLUSH command parameter which forces the OS to flush memory lists of any de-allocated memory that hasn't been returned... :)
you didn't touch upon fringing, artifacting which can happen if you're trying to get to a color that's not so trivial to get to. Good image conversion tools like The Art Department Pro took pains to try to avoid this, of course, but it could still very easily happen anyway.
I didn't. and am trying to think of the best way to explain this, as so many miss the fundamental reason this happens. I tried to address it obliquely by showing how the "colorful" demo in the RKM deals with it: it always does an explicit modify of all three color components, which cuts horizontal resolution, but guarantees the color can be reached.
So to be able to display photos in HAM mode you have to convert them first, don’t you? Basically, you would have to select a strategic base color for each line and then modify that in a certain way to approximate the original real color information? Sounds tricky and hard to generalize.
Correct; they made programs whose main purpose was to convert 24-bit (or otherwise) images into HAM (or other modes) for display. The Art Department Professional comes to mind, which was a holistic image processing tool (rather than a paint program). It could do a lot of other things as well but this was one of the major things it was used for. It was also one of the first applications that I felt the need to upgrade my RAM (from 1MB) for (IT BEGINS).
I notice the project is in one source file, and you're using a make script. Did you write it? Also, the heat data - the driver for the map. Did this come from a source, maybe I missed it but the data integration went by very quickly. With more features planned and the program likely growing into the 1000s of lines across multiple files are you going to use the Lattice make with build rules? It was in their compiler companion that included grep and other tools.
The Make* scripts came with the Lattice C. Lattice Make was a separate product at this point in time, and I may integrate it at some point as I need to build more source files. I did not show where the heat data came from, it was something I cooked up, because I wanted to focus on the visualization aspects.
Why do you have to do DIR CAR: ? That threw me off and I re-flashed it again 🤦♀ Can I copy the SDX image to an ATR on my SD card? Was trying to mount the ATR as device D2 and copy the contents of D1 but I don't know what I am doing apparently lol
I wanted textcraft and graphicraft when i got my amiga 1000 in 86. because the box art had the same type graphic pictures as my amiga 1000 manuals. my amiga 1000 came with kick 1.1 WB 1.1 and a black EA kaleidoscope disk. Several months later I got KICK 1.2, WB 1.2, EXTRAS 1.2, Dpaint I , And Adventure Construction Set, Thank You for making this video.
Somewhere around 1:06:00 when you pasted in the marked block for description you must have done it twice. By 1:08:00 when you saved the file it was 280 lines which is more than 30 lines greater than the previous save. Of course, everyone knows the actual cause is that you use emacs. You accidentally invoked an obtuse demonic function provided by emacs origins in the underworld. I theorize it transported code from another version of you. In that you's video he lamented why his description definition disappeared and had to retype it. Several times your video exceeded the capabilities of the 1986 Atari ST. Yes, definitely for the heatmap program. Not just the heatmap program, but your workflow also had more than four windows open. (cue an Atari ST choking to death.)
The two desktops have not been scaled correctly giving the impression the two are comparable. The sun demo window is 256x256 8-bit pixels and the Amiga demo window is 64x32 2-bit pixels. Just not comparable.
Good stuff! Compiler warning 30 on line 324 might be fixed if you cast the value returned by GetMsg as a pointer to IntuiMessage. For example, message = (struct IntuiMessage *) GetMsg(wHeatmap->UserPort);
Re. the PDF readers - I feel the same way about the "infinite scroll" on websites. My internet connection is fast enough. Just give me option to see the full listing... I programmed in K&R C while in college, and my memory is that even though you could put variable names in the parameter list for function declarations (without types), they were ignored. All the C compiler required for function declarations was the return type, the function name, and an empty parameter list. Re. how Intuition manages windows - Interesting commentary. I programmed in 32-bit MS-Windows in C++ in the early 2000s, and I remember when using GDI, there was a refresh event that you were expected to respond to. In that case, all your handler did was redraw everything you wanted on the graphics context. The Windows system would trip the refresh event whenever you moved the window, or it was partly, or fully uncovered. It did automatic clipping on the context, so you didn't need to know the boundaries of the area to draw. It seemed wasteful, because it didn't have you take the visible area into account. You just blanket redrew all of your content. It was still fast, though. The redraw wasn't noticeable. It looks like Commodore designed their libraries to use abstract data types. That has some pluses. It's a better idea than what I've seen in other GUI frameworks.
I'm on an Atari 800 and cannot scroll down any remote directory! gonna keep looking for stuff, and probably need to update the fujinet itself (linux problems rn lol), but im really confused since nowhere seems to mention this issue...
Something I think is worth mentioning for this is how you get the necessary system software, to get into the Intuition interface. I did some research on that a year or two ago, to see how to do this with UAE, since by itself, all you can load into UAE are boot disks for games. It turns out that while I think the Kickstart disks are freely available, the Workbench disk is still commercially licensed. I forget the fee. It's not too much, I think $20, but that's what one would need.
This process ran surprisingly slow. I did some C programming on my Mega STe many years ago, using a PD compiler called Sozobon C (also on the command line, with a hard drive). The MSTe came with the ability to switch to 16 Mhz, though. The projects I was working on ran in TOS/VDI. I was able to compile and link a lot faster than this. Though, I didn't get a good look here at the size of what had to be compiled. Like you were saying, this was with the first tools (looked to be from DRI), maybe not very optimized. Seems like it must've felt like murder to try to write an application for the platform with this. I'm imagining you'd try hard to fix as many bugs as you could, doing dry runs through the source code, before attempting to compile, since each attempt would take a lot of time. Thanks for posting.
Not an apples-to-apples comparison, since the Amiga frame demo is dumping premade bitmaps, and the Sun demo renders them from vector graphics. That being said, Sun workstations were heavily overpriced, and the hardware was actually surprisingly close (10Mhz 68010 vs 7.5Mhz 68000). Still, Sun had memory protection, more RAM by default, and much higher resolution with a non-interlaced display, things you really want to have in a workstation.
Nobody chooses to pay $30K for a workstation, unless that's the only way you'll get one. All those, Apollo, Sun and later Alpha were insanely out of reach. At my 1980s workplace we were connected by Wyse or Tektronix terminals to a SEL 32/77. Amiga was my first chance to even come close to that capability at home.
Interesting since some of the Amiga design team members were SUN UNIX users when they worked on the Amiga Lorraine project (as were some of the programmers of AmigaOS, including v 2.x and 3.x).
I wonder if one is a realtime calcululation of a globe and another is simply showing pre-rendered images. What happens when the globe goes fullscreen on both systems. Commodore cheated a lot in their advertisements when they "forgot" to mention their animations were not realtime calculated.
@@Maraka77i I'm rather sure they're both just animations. I think most of the speed difference can be attributed to the Sun 2/120 sending higher resolution pictures over a socket to a display server (the X window system) which are then plotted by the CPU to the frame buffer, while the Amiga has rather direct access to the hardware, which includes a blitter designed just to quickly copy pictures to the frame buffer without CPU intervention.
@@storerestore It's not X. it's the SUN windowing system, which is in-kernel. They are both pre-rendered bitmaps loaded into memory and blit to screen.
Oh man, I'd forgotten about the "Give" modes where it treated prior clicks as part of the current shape's definition! Things were so wide open and interesting back before things got homogenized. When I began seriously doing art on Amiga I was using a mix of Photon Paint and Deluxe Paint II. But I was also sending files back and forth to my HP 9000 to take advantage of the features of xpaint. We've lost a lot of nice low level drawing features from the early software as painting software specifications have become homogenized by a few leading software packages that were mostly promoted by a clueless computer media, like PC Magazine that would literally count menu items to determine which programs were more "useful." (While ignoring the multiplying effects of modality in the menu choices, where one menu selection changes how the others all work, simplifying the menus but dramatically expanding the functionality of the software.) Amiga was one of the few communities where there was media representation by actual artists (especially in AmigaWorld magazine), and the superior art software offerings, even compared to most of today's offerings, showed that influence.
I need some help with my Fujinet. I tried looking up as many resources as I could but still run into problems. I tried pressing the reset button on my 400/800 version Fujinet with my 600XL and rather than going back to the Fujinet menu it just goes back to what I loaded in. I can also only get slot 1 to load. I try selecting slot 2 but 1 is the only one it reads. Am I doing something wrong? I even tried putting programs I downloaded on to the SD card but they just go missing.
There are three buttons on the FujiNet. Pressing the button that's by itself, will reset the unit, so that the next time you boot, it will boot into CONFIG. If you power entirely by the computer, then powering off the computer will also reset the FujiNet. There are 8 drive slots on the FujiNet. These correspond to drives 1 to 8 (D1: to D8), just like with a real disk drive, the Atari can only boot from disk drive 1.
At the time, we wrote software on a Macintosh. When the NeXT appeared, I was blown away, and we switched to the NeXT platform using ObjC dev for many European customers. It was the best machine and frameworks ever. I was super happy when everything came back to the Mac and, later, the iPhone. I still have my Cube, and it sits directly beside the dev environment I use now. Thanks for this video; what memories!
The first situation looks like it's deinterlacing and separating the fields into two parts of the viewport. The embedded display looks better... could the display be interrupt-driven, and it's not generating the interrupts until you prod it? Not knowing anything about SUN, I'm just spit-balling here.
