[Color Computer] [Coco] ASM Coders - Round two!
L. Curtis Boyle
curtisboyle at sasktel.net
Wed Aug 30 10:34:38 EDT 2006
On Wed, 30 Aug 2006 02:11:31 -0600, James Diffendaffer
<jdiffendaffer at yahoo.com> wrote:
> Actually I've already found it in some 6809 graphics code so it's also
> valid at times there. The ability to load multiple registers and push
> them to the screen can save some clock cycles.
This was actually a fairly common technique, which a lot of us
referred to as "stack blasting" (Steve Bjork is the first person that I
know who used that term). Just off the top of my head, the XMas GRFDRV
patch from Kevin Darling, et al used it for screen scrolls, Flight Sim II
used it to draw each half of the screen, and Biosphere used it for
scrolling as well. Only problem is is that you have to shut interrupts off
to prevent IRQ's from dumping garbage onto the S stack that you just
reprogrammed as either your source or destination pointer (one of the
reasons that the 6309 patch for Flight Sim II using TFM helped modem users
so much... it originally stack blasted a large chunk of the screen on
every screen update, with IRQ's shut off the whole time).
>
> If there is a CoCo library that I can just plug in and use for music,
> sound effects or graphics please point me to it.
> I'll be happy to point poeple to Atari, C64 or even Plus/4 code if you
> really want it.
I have to agree with this (except on the OS-9 side.. there was quite a
bit of source code out for it, with things like PAC-OS9 as an example for
games). RSDOS tended not to have too much source code released, just the
binaries. I always found that the OS9 community was much more willing to
release shareware/freeware and source code than the RSDOS crowd (except
for BASIC stuff; that was fairly common and I released some myself). Some
of this was probably due to all of the driver/utility action going on on
the OS-9 side, as everybody wanted to improve the OS and what it could do,
to try and match the big boys like the PC.
I do have permission from Harvey Brofman to put up the source code for
both Dunkey Munkey and Starfire up on my games website, which I will do in
the winter once I find the disks again, if anyone is interested in that. I
wish more authors would do this, but a lot of them don't even have the
source code anymore for their projects. Another problem is everybody
seemed to use a different assembler, and a lot of the more well known game
authors (Diecom, Sundog as examples) used their own internal assemblers
that were never publicly released. I think this also helped the OS-9
crowd; until the 6309 came along, there were only two assemblers in common
usage: ASM and RMA. Even after the 6309, you had the same two, just with 2
new versions (and DISASM, which I modified for the 6309 and released as
quickly as I got it done. A side note: the first versions of NitrOS9 were
written with hand coded assembly using FCB/FDB commands, and were tested
with that version of DISASM to make sure the opcodes were right. Later, I
did most of the additions to ASM, and then Alan Dekok finished that off
after he joined the project).
> Coco's fault? Now there's a massive leap to a conclusion.
>
> I stated a fact about how much more effort is required to create a
> game for the coco... not because of the hardware but lack of sample
> code or libraries. It's obviously because PEOPLE haven't released as
> much sorce code or as many tools.
>
> Sure it's related to the fact that the coco wasn't commonly accepted
> as a major games machine and as a result there are still hundreds more
> people developing games for those platforms, but that doesn't mean I
> blame the machine. "My gripe about the coco" didn't refer to the
> hardware at all if you go back and look. Not one complaint about the
> hardware.
>
> What prompted my gripe was frustration. I see people that *want* to
> write new games for the CoCo looking for help and I can't just say
> "you can download simple examples here, here, here, here and here.
> And there are five different threads in 3 different forums dealing
> with the same thing" or "to add music just add these 12 lines of
> code and point this at your music data from the music tracker."
This is absolutely true, as I mentioned above. While some good arcade
style ML games were released for the Coco's (1,2 and 3... Chet Simpson's
BLOX, Brian O'Neil's Pac Dude, and later Pad Dude 3D Monster Maze, Hop
Bopper, and others) only Pac Dude 3D has had source code released). There
were BASIC compilers, the Game Writer System, Graf Express and other
utilities that contained subroutine packages so that even BASIC
programmers could write some decent speed games, but they were all
commercial and none have ever been released to the public that I know
of... even just as binary packages.
--
L. Curtis Boyle
More information about the Coco
mailing list