CFalcon030 This is not 100% clean, I kill all system interrupts at the beginning and I do some stack manipulations that a Falcon 030 may not like. But I don’t have a Falcon to test it on.
Congrats, you came to the same conclusions as I did when I made 8088 Domination/Bad Apple on PC in 2014. Use available memory as a queue; each frame is actually code, not data; deltas; ordered dithering; etc. We even have the same organisation (loading in main program loop). The issue I had to deal with that you didn't was that I had fixed bandwidth, so I had to choose what screen updates were the most important per frame if I didn't have enough bandwidth. Nice work.
Oh cool ^^ congratulations for the 8088 version, it's amazing. Once I found out that the bandwidth was enough on the ST, I did focus on quality instead of trying to make the smallest possible data file :p
I'm curious; what are the tradeoffs between loading in the main loop verus interrupt driven? I have no idea what the PC hardware provides in this regard... a quick check online says there's at least some kind of DMA.
Wonderful "Making of"! Great conversion! I didn't understand anything, but i loved every minute....I want to try this on a commodore plus/4 one day! Would be interesting to know, what tools you used for every step of the conversion...
This is nice presentation. Although I prefer bare text - that is easier to follow, and you are not defocused with effects on screen :-) Now, there are some not exactly correct things. "HDD DMA architecture:" - Actually, it has nothing with DMA. It is way how TOS, GEMDOS file access works . I know, there is no space here for some longer explanation, but this just sounds very bad, and should be rather something like: TOS hard disk/file access way. Then, that "no low level hard disk access" - sure, GEMDOS is better, actually simpler to use. But if you need max possible performance, low level is only way. . With IDE some 40% better speed than with UltraSatan is easy to achieve. Although, at price of bigger CPU load. All this is not so simple. And defragmentation helps a lot for faster disk access, so better datarate. Because that "no low level ..." I put here link to my page, where can DL some players, anim. files for. At bottom of page are 16 color videos (no low level access), and even link to guide how to make them. atari.8bitchip.info/movpst.php I had some 16 color video captures here, but they are deleted from some reason - probably copyright - like 16 color video is copy of 16Million color one :-)
MrPetari hey again! I’d really like to talk about DMA ACSI programming with you (maybe in private). I still wonder how the TOS and your drivers access files and what is exactly done with buffers since I read the DMA limitations. I’m really interested in this. For instance I didn’t round the loading to the size of an HDD sector, but it was enough for my use... I chose not to be precise in this video because I know most people don’t know the ST platform but may know generic terms like VBL/DMA. If I had the knowledge and time perhaps I would have used homemade ACSI access :p but I wanted it to work even if no ACSI was used.
What stays in literature about DMA limitation(s) is usually wrong. As I said at Demozoo. You are welcome to Exxos Atari Forum or to 8bitchip.info forum. We don't go anymore to 'great' AF - that place is for Joska/MugUk kind of people. We do this not only for fun - even if doing right things efficiently is fun :-)
@@fenarinarsa @MrPetari, I'm also curious about the low level details. I thought it a no brainer to totally bypass TOS disk access and write your own interrupt-driven DMA. But hey, whatever works! So, do I understand correcty that by "Loading occurs in the main program loop. Rendering is done in HBL." means you make TOS calls to get disk data in, and process it in interrupts? It does seem like the opposite of the obvious (but more difficult?) solution, but kudos for finding a way. :-)
Having coded something pretty similar in the late 80's on an 1MB OCS Amiga using similar techniques(blitter, rle, delta), I think you did this very well despite cheating with lots of RAM, harddrive and processing on a PC :)
That's not cheating, that's making a rational use of available resources ;) Note that it works perfectly with 1MB of RAM. It just uses all available memory in case the mass storage is a bit too slow.
What about using vectors instead of trying to store the bitmap ? I was going to try this out on the Amiga, as when I first saw Bad Apple i thought "that could so be done like State Of The Art" :)
On Amiga you could try to use the blitter fill function I guess (the one that State of the Art used : lines + fill). It may reduce the size of graphic data a lot if it's your goal. My goal was to make a near-perfect conversion so I did it on 4 bitplanes (16 greyscales), which would mean 4x more filling to do, I don't know what are the maximum fillrate of the Amiga blitter. And I kept all the fine details, so that would mean a lot of lines to draw. So you would end by doing nearly the same thing that I did : recording the moving edges and putting them back on the screen, and in that case you don't really need to fill anything after that. But that was for my goal, if you want to make a really small version, lines + fill + 4 voices mod conversion for the audio is the way to go I guess, really like State of The Art or 9fingers did :)
TT => no because it needs a blitter and it's not 68030-proof Falcon => again no because of the 68030 but now I have a Falcon, so I might be able to do a compatible version. In any case it would be easy to port. The source code is available :)
Синхронизация видео с музыкой 12/10!
Great video, I love making of's. I also appreciate the fact that you used such a clean and system friendly way to do it.
CFalcon030 This is not 100% clean, I kill all system interrupts at the beginning and I do some stack manipulations that a Falcon 030 may not like. But I don’t have a Falcon to test it on.
instablaster
Congrats, you came to the same conclusions as I did when I made 8088 Domination/Bad Apple on PC in 2014. Use available memory as a queue; each frame is actually code, not data; deltas; ordered dithering; etc. We even have the same organisation (loading in main program loop). The issue I had to deal with that you didn't was that I had fixed bandwidth, so I had to choose what screen updates were the most important per frame if I didn't have enough bandwidth. Nice work.
Oh cool ^^ congratulations for the 8088 version, it's amazing.
Once I found out that the bandwidth was enough on the ST, I did focus on quality instead of trying to make the smallest possible data file :p
@@fenarinarsa I wish I had a blitter! :-D
I'm curious; what are the tradeoffs between loading in the main loop verus interrupt driven? I have no idea what the PC hardware provides in this regard... a quick check online says there's at least some kind of DMA.
Getting out the last quantum of speed! I love it!
This video need more views, man
Amazing effects, excellent tutorial! We want more!
Ace job, impressive final result!
Very cool! Thanks for making this video.
Wonderful "Making of"! Great conversion! I didn't understand anything, but i loved every minute....I want to try this on a commodore plus/4 one day! Would be interesting to know, what tools you used for every step of the conversion...
This is nice presentation. Although I prefer bare text - that is easier to follow, and you are not defocused with effects on screen :-)
Now, there are some not exactly correct things. "HDD DMA architecture:" - Actually, it has nothing with DMA. It is way how TOS, GEMDOS file access works . I know, there is no space here for some longer explanation, but this just sounds very bad, and should be rather something like: TOS hard disk/file access way.
Then, that "no low level hard disk access" - sure, GEMDOS is better, actually simpler to use. But if you need max possible performance, low level is only way. . With IDE some 40% better speed than with UltraSatan is easy to achieve. Although, at price of bigger CPU load. All this is not so simple. And defragmentation helps a lot for faster disk access, so better datarate.
Because that "no low level ..." I put here link to my page, where can DL some players, anim. files for. At bottom of page are 16 color videos (no low level access), and even link to guide how to make them.
atari.8bitchip.info/movpst.php
I had some 16 color video captures here, but they are deleted from some reason - probably copyright - like 16 color video is copy of 16Million color one :-)
MrPetari hey again! I’d really like to talk about DMA ACSI programming with you (maybe in private). I still wonder how the TOS and your drivers access files and what is exactly done with buffers since I read the DMA limitations. I’m really interested in this. For instance I didn’t round the loading to the size of an HDD sector, but it was enough for my use...
I chose not to be precise in this video because I know most people don’t know the ST platform but may know generic terms like VBL/DMA.
If I had the knowledge and time perhaps I would have used homemade ACSI access :p but I wanted it to work even if no ACSI was used.
What stays in literature about DMA limitation(s) is usually wrong. As I said at Demozoo.
You are welcome to Exxos Atari Forum or to 8bitchip.info forum. We don't go anymore to 'great' AF - that place is for Joska/MugUk kind of people. We do this not only for fun - even if doing right things efficiently is fun :-)
@@fenarinarsa @MrPetari,
I'm also curious about the low level details. I thought it a no brainer to totally bypass TOS disk access and write your own interrupt-driven DMA. But hey, whatever works!
So, do I understand correcty that by "Loading occurs in the main program loop. Rendering is done in HBL." means you make TOS calls to get disk data in, and process it in interrupts? It does seem like the opposite of the obvious (but more difficult?) solution, but kudos for finding a way. :-)
Impressive, bravo!
cool making of!
Funny, the BASIC code looks 100% like Atari TurboBasic XL for the Atari 8-bit.
Yep, GFA Basic was made by the same guy who did TurboBasic XL...
I loved gfa basic on the ST and never knew back then it was the same author as TBXL!
ATARIIIIIIIIIII
Having coded something pretty similar in the late 80's on an 1MB OCS Amiga using similar techniques(blitter, rle, delta), I think you did this very well despite cheating with lots of RAM, harddrive and processing on a PC :)
That's not cheating, that's making a rational use of available resources ;)
Note that it works perfectly with 1MB of RAM. It just uses all available memory in case the mass storage is a bit too slow.
Mass storage? What is this sorcery you talk about? :)
How long was your video?
If you want more sorcery, check out the C64 version or (more limited), the apple 2+ version here : ua-cam.com/video/IiSFeqedcho/v-deo.html
What about using vectors instead of trying to store the bitmap ? I was going to try this out on the Amiga, as when I first saw Bad Apple i thought "that could so be done like State Of The Art" :)
On Amiga you could try to use the blitter fill function I guess (the one that State of the Art used : lines + fill). It may reduce the size of graphic data a lot if it's your goal. My goal was to make a near-perfect conversion so I did it on 4 bitplanes (16 greyscales), which would mean 4x more filling to do, I don't know what are the maximum fillrate of the Amiga blitter. And I kept all the fine details, so that would mean a lot of lines to draw. So you would end by doing nearly the same thing that I did : recording the moving edges and putting them back on the screen, and in that case you don't really need to fill anything after that. But that was for my goal, if you want to make a really small version, lines + fill + 4 voices mod conversion for the audio is the way to go I guess, really like State of The Art or 9fingers did :)
I forgot to say than on Atari STE the blitter doesn't have a fill function and cannot draw lines so vectors were not really an option there :)
Moi je dis la classe !
Could this run on an Atari TT or Falcon? If not, would it be easy to port?
TT => no because it needs a blitter and it's not 68030-proof
Falcon => again no because of the 68030 but now I have a Falcon, so I might be able to do a compatible version.
In any case it would be easy to port. The source code is available :)
Please make a Falcon port then :D
Storm Someone gaveme a Falcon a few months ago, so maybe,if I succeed in installing that bloody CF card adapter :)