Software Sprites are 10 Times Better with Machine Language than BASIC - Part 2
Вставка
- Опубліковано 28 вер 2024
- @ACs 8-Bit Zone Part 2 in a series on Sprites, Animation, Graphics, and Programming Video Games on Retro console gaming and home computer systems from the 1980s. Tandy Radio Shack TRS-80 Color Computer. Atari 800XL. Texas Instruments TI-99/4A. Commodore 64. TRS-80 Coco 2
I can't get enough 6809 assembly stuff, it's so cool to see the CoCo getting some love. I always like to learn more and getting someone else's perspective is always a good thing. You did a great job with the example code and how you explained what the code is doing and your video production quality was excellent.
The cool thing about the 6809 is there are so many ways to do things. In the past I've definitely learned get your program working in whatever way you can, no matter how messy the code is, just get it done. Once your program does what you need you can then go back and optimize it later (but only if you need to).
Your video shows you can make a great and fast game on the CoCo even though the CoCo doesn't have any sprite hardware and it all has to be done by the 6809. It would have been amazing to have this same video to learn from back in the 80's. Maybe it's just me but I would have watched a CoCO assembly TV Show back in the 80's 24 hours a day :).
Thanks for sharing, these videos make the community stronger and might help someone start writing their own CoCo game.
Many thanks for those comments and the great feedback. Yes we really could have used some clear instruction back in the 80s for learning how to take advantage of assembly language. Unless you knew an older person who had some resources and know-how with micros, it was difficult to gain experience with it. Oh and, really nice work you've been doing lately with your game ports!
Looks good,Keep up the good work.
Excellent explanation
Excellent video! High quality software and hardware in the same video!
Thank you very much!
very well done! thank you
If I knew all of this back in the 80s, I could have been a Tom Mix millionaire. Or maybe thousandaire. ASM was black magic to me back then.
Now that I can understand it, it's nice to wrap back around and try some of the programming techniques that I wanted to try back then!
@@acs8-bitzone651 I wrote a basic GUI for the Coco 3 a few years back that I always wanted to incorporate more ML into... This is great motivation
BASIC graphic animation was black magic to me back then. ML was pure wizardry!
Great stuff! Thank you 👍
Glad you liked it!
Nice video…I really like your explanations of handling these sprites in ASM. But I’m trying to determine how the idle instruction orange bar on the left works. I imagine you coded that. Is it just a matter of having an “idle” routine that counts until the next VSync fires? Then on the next frame you might have a draw idle bar to show how much cpu instructions are left?
this is a late response... You are right. I believe it was counting in an idle loop and waiting for Vsync. When it happens, I clear the previous bar from top to bottom and then display a new number of stacked bits to correspond to the idle count.
Good work.
Thanks!
dont forget to post these programs, i am myself in the middle of learning 6809 asm myself!
Let me take a moment in the next couple of days and then I'll post the link. Thanks for your comments and for watching!
Could you share this code with us? Both the BASIC and assembly. It would help a lot.
Ah yes.... good old software blitting.
Hey Gorf, I had to look up that term. I heard it a long time ago and forgot it. It's woven deep into the parlance of 2D graphics. Much reading material ... Thanks!
@@acs8-bitzone651 It's what you are doing in this video! 👍
Excellent video, when I was a kid I always wanted to understand how sprites worked in the CoCo. Would you recommend a book about the 6809E architecture and instruction set?
Are you going to publish both programs?
I have been bouncing back and forth between "TRS-80 Color Computer Assembly Language Programming" by William Barden, Jr, and "6809 Assembly Language Programming" by Lance Leventhal. For graphics, I'm using "Color Computer Graphics" by William Barden, Jr. Also "500 Poke, Peeks, and Execs" for some of the graphics modes.
Yes, I can provide the programs. I wasn't thinking that anyone would want them though. Do you want the assembly one from Sprites 2?
Thanks for your feedback Gman!
@@acs8-bitzone651 Yes the basic and the assembly program
@@acs8-bitzone651 I've just started assembly on the coco again after so many years. I have a Coco 3 with a GIME-X and could use some good examples like the ones you just showed. Keep up the good work.
I started to learn assembler on C64 6502 CPU and then i switched to intel 80286 CPU and there is a vsync that we can use on VGA display, but this is not enough for a flicker free movement with very large objects high resolution 32 bit color, we have to use double or triple buffering with vsync. We draw all objects on an invisible screen memory and if it is all done we switch the screen to this location and start to draw in the next unvisible screen.
Yes! The double-buffering. I remember doing the same when I used BASIC as a kid. A BASIC program could take a while to render a graphics screen and you would often want to hide the drawing phase until it was completely ready to show. Thanks for the view and that information.
Wing Commander seems to use only a single buffer and update it scanline by scanline. So you get tearing, but no flicker. I could not get the Vsync to sync on the smooth scroll register and the address start register correctly. When the vsync bit changes, how much time to we have to set the address start register? I would guess the whole blanking of 10 scanlines or so! And smooth scroll register should act per scanline. Unfortunately, back in the day I already had access to a single PC and lost interest in 72 Hz smooth scrolling and thought it was a bug of the graphics card and not something about timing. Maybe I should check on vsync =0 instead of =1 . Or it really was a bug of the ET3000 . At least all C64 VIC II are equal.
I should look up if commander keen uses double buffering. With its small sprites it may very well be that all objects are sorted by Y. Then you only have to do half of the work for the background edges on scrolling. You can read out the timer in the PC or the scanline of the graphic card I think and could drop updates of some sprites if a frame is too full so you are not caught while you just restored the background around the sprite ( for animation ), but no yet redrew the next frame of the sprite. A 268 @ 20 MHz is a whole lot faster than a 6502. You can use the read modify write cycle on EGA to copy 32 bit at once with in VRAM, but you only send 8 bits over the ISA bus. So it runs fast on old PCs.
With sprite overlap .. so I watched some arcade and have to says that there is not much sprite overlap on screen. But if you have to drop a sprite update, you still have to redraw the sprite in the overlapping region. So you may have to drop the next sprite .. okay with a lot of action we better use double buffer.
Okay, EGA or VGA don't tell us the scan line, nor can the interrupt the CPU. So you gotta use some math and en.wikipedia.org/wiki/Intel_8253
@@ArneChristianRosenfeldt
mov dx,3DA
A:
in al,dx
test al,8
jnz A
B:
in al,dx
test al,8
jz B
...action..
@@maxmuster7003 that is what I did. And on my PC address register and smooth scroll were not in sync (one frame off). Maybe I wrote that part in C. The crappy Borland compiler was able to expand even simple lines of C code into hundreds of machine language instructions. But unlike in some 8-bit home computers, you could not just inline assembly. So I would have to fiddle with the linker. I don't know why build systems suck so much. It was easier to write code completely in MASM, than to link it to BorlandC++. I corrected it by writing a modified version to the shift register. I mean, it makes no sense .. but then of course it did not work on PCs of two others where I tried it. Then I learned that you cannot develop for PC nor Android without access to different hardware. You cannot dev on a small budget in the basement of your parents home. It is like the VSP bug. Some C64 have it, others don't. So yours may not have it, you invent VSP, and then code for a year and then your game does not run on 50% of your customers PCs. I guess that smooth scroll on PC was indeed buggy because besides Commander Kenn and Cannon Fodder nobody seems to use it. And 256 color mode .. I don't like the double scan .. but anyway, I think it could scroll. You change the pitch to 324 px.
Back in the day I did not really understand ModeX. VGA has 4 bitplanes like EGA, so it cannot do planar 8 bit colors. So the read out circuit always reads out the four planes and displays the bytes next to each other. I think you should be able to scroll through the whole VGA memory. But usually CPU access is configured in a way that you cannot set the two highest significant bits. Thus in ModeX .. I mean in Wolfenstein3d they changed the CPU access back to the EGA way. It means that you can only draw vertical lines ( efficiently ). So this is bad for line vectors, but not a problem for filled vectors or sprites. I still wonder why the VGA could no repurpose the mask bits as a paging register. All SuperVGAs could do that. Or have an official paging register so that all SuperVGAs would use it. Like two nibbles for x y windowing like LCD controllers offer it today.
The unspecified timing relation between Vsync and address start register may be the reason that Doom only looks at Vsync and copies the pixels from main RAM to VRAM. On a slow VGA this has the benefit that the CPU gets exclusive access to VRAM in the vertical borders. If games target a low frame rate and lots of overdraw, this is faster. And all those 16 bit color to 8 bit color conversion because IBM could not be arsed to just also specify a true color mode.
Nice!
TY!