Jump to content
IGNORED

TRS-80 CoCo 3 "Wolf-3D" style demo


remz

Recommended Posts

The Donkey Kong and Pacman remakes are both excellent. There's also a game called Crystal City that came out in 1990 as well that rivals anything on the NES IMO.

 

Yeah Crystal City and Zenixs by the same author used some of the best known graphics routines ever devised on the coco 3. These 2 games are by far the quickest in game play on the coco 3. I have clocked Zenix once and seen the ending.

When pushed the coco 3 could sure do some amazing stuff.

 

All we need now is for Potatohead to create the 1st coco 3 game using the 256 color technique he found years ago.

 

laters

 

Briza

Link to comment
Share on other sites

The Donkey Kong and Pacman remakes are both excellent. There's also a game called Crystal City that came out in 1990 as well that rivals anything on the NES IMO.

 

Yeah Crystal City and Zenixs by the same author used some of the best known graphics routines ever devised on the coco 3. These 2 games are by far the quickest in game play on the coco 3. I have clocked Zenix once and seen the ending.

When pushed the coco 3 could sure do some amazing stuff.

 

All we need now is for Potatohead to create the 1st coco 3 game using the 256 color technique he found years ago.

 

laters

 

Briza

 

Yeah, no kidding. Well, a demo at least. That's on my to-do want list for sure. Gotta get a PC interface thingy, and complete a Propeller project or two first. Emulation support would help big. I checked out that Rainbow IDE. Truth is, that's a sweet deal!

 

I kick myself for not contributing that over 10 years ago.

 

You know, another thought would be to rework a game. RadWarrior comes to mind. That one runs at 160 pixels. Could tear it apart and write it for 256...

 

I'm glad to see some movement though. It's a killer machine that deserves some more home brew love.

Edited by potatohead
Link to comment
Share on other sites

Funny you mention radwarrior. I just bought a copy off ebay for a buck. Haven't played that one in close to 20 years. I'm awaiting about 9 coco carts in the mail actually. Hope they come soon :)

 

It's a pretty great port on CoCo. I first played it on C64, and found the CoCo 3 version excellent.

Link to comment
Share on other sites

The coco 3 was capable of amazing things as witnessed by the homebrew scene on that system. Its a fantastic little system.

 

Indeed! While I do not currently have one, I always liked everything Radio Shack/Tandy put out. And I think the fact there's a homebrew scene going on is simply incredible. Great job!

Link to comment
Share on other sites

I didn't know you were a coco programmer. Thats excellent. I'd love to see some more coco homebrews. I just need to find a disk drive icon_frown.gif

 

Yeah, I was into the thing big in the early 90's. Was drawing fractals, and had written a simple bit blitter to move things on screen. Only had cassette at the time, but did have the editor assembler cart, and the stereo sound cart. (that one is cool, with two 8 bit DACs on it)

 

Anyway, when drawing fractals, I made the mistake of calling out the 640 pixel mode, while writing byte data directly to the screen in 6809 assembly. The resulting display was more than 16 colors when I came home. Thought about it for a minute, then tried setting all 4 640 pixel palette entries to black, dark grey, light grey and white. Ran a byte test, one byte per pixel, and came up with a display similar to the one in my blog.

 

What happens is simple artifacting. The CoCo 3 does not generate interlaced color composite video signals. It does what an Atari does, with fixed color timing on every scan line. On Ataris we can do artifacting to get some colors on the screen, but the top resolution is 320 pixels, and we only get 2 colors. Not much to artifact with. With that color signal timing, the native resolution of the display is 160 pixels, meaning two 320 pixels fit into there, each with two colors, giving a four color display because of artifacting.

 

On the CoCo 3, there are 640 pixels, each with 4 colors, for a total of 8 bits of information per 160 pixel sized region on the screen. That all boils down to one byte per pixel, which is just sweet for the 6809, so long as 640 pixel mode is set, and the palette holds only brightness info, not color info.

 

That was maybe 90, or 91. I had just got on the net in '91, but was not doing much and never thought to post it up on USENET. Figured others had done this, because it's not a hard thing. Turns out, nobody had :(

 

Very recently, a thread here sparked that memory, and I just had to get a CoCo3, write a quickie program and post it before too much more time went by.

 

Rather than get a disk drive, it's probably better to get one of those SD card / wireless things. That's what I'll do eventually. Then development and gaming can happen right on the thing, which is needed to see what's going on with the 256 color deal. Really it's a bit less, because a few of the hues are the same, but it's still a lot of colors, with essentially NO hassle. Just set the mode, define your palette and screen pages and go to town.

 

Most of the other trick modes do Atari style palette changes while the screen is drawn, draining the CPU, and forcing a complex kernel to be written. On the composite display, drawing is straight forward, leaving time for other tricks.

 

...or one of the people who does the emulators could add that mode, making it possible to use the IDE directly for dev work.

 

The 256 is a composite only deal. I think the reason nobody explored it was the RGB monitors were avaliable, and they looked great and sharp, so the challenge on the machine was to get more colors at the higher resolutions, leaving the composite display largely ignored. Or, I just got lucky...

 

Anyway, the machine is pretty cool because the 6809 is a fun chip, and the way the video is done on the latter part of a clock cycle means no DMA occurs, leaving the full speed of the CPU available for doing graphics work. Sound is a challenge because that's got to get done too, and there is no hardware assist for that. Just a DAC.

 

This demo and that one with the sprites and scrolling are killer actually. Nice job!!

Edited by potatohead
Link to comment
Share on other sites

There is something Cloud9 sells called "drivewire" but I'm not sure how that works and there's the SuperIDE device (again, not sure how it works) but its pretty pricey. I do use a freeware program called "cocotape" that uses the cable that attaches from the cassette to the coco. You plug it into the line out from your sound card and load programs converted into wav files right into your coco, but it has some issues to, according to the author. He hasn't updated the program and may never do it.

Link to comment
Share on other sites

Yeah, I've ran that thing. Somebody also made a perl script that creates wave files. It works, but only for those things that can be loaded from cassette. Most programs need some modification. Works great for binary files though, like for a picture.

 

The device I want to get is either the MicroSD pack, or the bluetooth one. The nice thing about the micro SD is stand alone operation of the CoCo, or operation with a PC and the bit banger cable. The bluetooth one doesn't host disk images, but works wireless, which would make writing and testing things pretty easy.

 

The demo linked in this thread works on an unexpanded CoCo. That's pretty cool actually. The sprite one done by the same author also works unexpanded, I believe. Quite a lot can be done in 128K. That's what I've got. Don't know how hard expansion is, but my old one was 512K, 6309 too. :(

 

Next year will probably be the year I get some CoCo stuff. Propeller and VCS ate up the dollars this year. Next year, I plan on getting the SD adapter for Atari, the Atari <--> PC cable, A CoCo adapter, and maybe an Apple ][, with an internal SD / PCMCIA device.

 

I think a lot of CoCo users are running emulation too. Not sure, but that's the feeling I get. These run the real machine devices, across the board are getting cheaper. To me, that's where the real fun is. Not sure how many expanded machines are out there, or how many 6309 computers.

 

@remz: Where are you going with the demo? Gonna include baddies, or? (sorry for the coco chatter...)

Link to comment
Share on other sites

@remz: Where are you going with the demo? Gonna include baddies, or? (sorry for the coco chatter...)

 

No problem! It's funny you mentionned the Propeller chip, as I already coded some little demos on it in the past. It was called the HYDRA XGameStation.

Anyway about the CoCo 3 "Wolf" baddies: there is not much hope and clock cycle left to add anything :)

Although there are certainly things that could be done to turn the demo into a game. But the main goal was making it work.

 

Thanks!

Link to comment
Share on other sites

@remz: Where are you going with the demo? Gonna include baddies, or? (sorry for the coco chatter...)

 

No problem! It's funny you mentionned the Propeller chip, as I already coded some little demos on it in the past. It was called the HYDRA XGameStation.

Anyway about the CoCo 3 "Wolf" baddies: there is not much hope and clock cycle left to add anything :)

Although there are certainly things that could be done to turn the demo into a game. But the main goal was making it work.

 

Thanks!

 

Ok, well cool. Nice demo.

 

Yeah, the Propeller is a lot of fun. I'm currently hooked on it big. :)

Link to comment
Share on other sites

remz, I just remembered another CoCo trick, while talking displays on another forum.

 

If you set the thing up for NTSC display, using whatever GIME modes you choose, the 50 / 60 HZ switch found in the GIME actually works! In other words you can display a 50Hz NTSC signal with that computer.

 

Coupled with the NTSC high color trick, it's kind of the best of both worlds. Pal compute time, and lots of colors.

 

Most all of my TV displays will display it, and that's a lot of extra blanking time for computations... In the sprite demo, perhaps that's another sprites worth?

 

Just FYI. I'll get my CoCo hooked up again and run some tests in the near future with my capture card.

Edited by potatohead
Link to comment
Share on other sites

remz, I just remembered another CoCo trick, while talking displays on another forum.

 

If you set the thing up for NTSC display, using whatever GIME modes you choose, the 50 / 60 HZ switch found in the GIME actually works! In other words you can display a 50Hz NTSC signal with that computer.

 

Coupled with the NTSC high color trick, it's kind of the best of both worlds. Pal compute time, and lots of colors.

 

In fact the result would be a 50 Hz NTSC, like the Amiga had to allow PAL game compatibility on this continent..

 

Interesting, however 50Hz flicker is somewhat visible to the eye. Indeed in the sprite demo it would allow maybe another sprite or more background animated tiles. Does the Tandy RGB monitor supports 50Hz too?

Link to comment
Share on other sites

remz, I just remembered another CoCo trick, while talking displays on another forum.

 

If you set the thing up for NTSC display, using whatever GIME modes you choose, the 50 / 60 HZ switch found in the GIME actually works! In other words you can display a 50Hz NTSC signal with that computer.

 

Coupled with the NTSC high color trick, it's kind of the best of both worlds. Pal compute time, and lots of colors.

 

In fact the result would be a 50 Hz NTSC, like the Amiga had to allow PAL game compatibility on this continent..

 

Interesting, however 50Hz flicker is somewhat visible to the eye. Indeed in the sprite demo it would allow maybe another sprite or more background animated tiles. Does the Tandy RGB monitor supports 50Hz too?

 

Bet it probably does. The guys at CoCo3.com would know this answer cold. I was musing about a Propeller demo that runs in PAL, and the 50hz gives it some time. When 50Hz NTSC came up, I thought of this thread, and so there you go...

 

Anyway, most modern displays will do the 50Hz thing, as they have to for PAL anyway, just like a PAL display will do PAL 60.

 

There is some flicker, but on low intensity backgrounds, it's no big deal. Reducing overall screen brightness helps too.

Link to comment
Share on other sites

remz, I just remembered another CoCo trick, while talking displays on another forum.

 

If you set the thing up for NTSC display, using whatever GIME modes you choose, the 50 / 60 HZ switch found in the GIME actually works! In other words you can display a 50Hz NTSC signal with that computer.

 

Coupled with the NTSC high color trick, it's kind of the best of both worlds. Pal compute time, and lots of colors.

 

In fact the result would be a 50 Hz NTSC, like the Amiga had to allow PAL game compatibility on this continent..

 

Interesting, however 50Hz flicker is somewhat visible to the eye. Indeed in the sprite demo it would allow maybe another sprite or more background animated tiles. Does the Tandy RGB monitor supports 50Hz too?

 

Bet it probably does. The guys at CoCo3.com would know this answer cold. I was musing about a Propeller demo that runs in PAL, and the 50hz gives it some time. When 50Hz NTSC came up, I thought of this thread, and so there you go...

 

Anyway, most modern displays will do the 50Hz thing, as they have to for PAL anyway, just like a PAL display will do PAL 60.

 

There is some flicker, but on low intensity backgrounds, it's no big deal. Reducing overall screen brightness helps too.

 

Hi Guys.

 

Yeah the RGB CM8 monitor will do 50 or 60hz display. I'm based in Aussie Land and I use both a Pal and NTSC hooked up to my monitor. Mentioning the 50/60hz switch in $FF98 has given me a Idea for my Hacks I do in the Gime. I just may try setting the 50Hz switch on my NTsc unit and see what happens while switching in the 640x192x4 color mode.

I'm curious to know If maybe the Gime designer used the 50/60hz switch on a NTSC unit which is what may cause the something Odd to occur. Stuff it I will try out that idea tonight. Thanks PotatoHead for the idea.

 

Have fun guys.

 

Laters

 

Briza

Link to comment
Share on other sites

remz, I just remembered another CoCo trick, while talking displays on another forum.

 

If you set the thing up for NTSC display, using whatever GIME modes you choose, the 50 / 60 HZ switch found in the GIME actually works! In other words you can display a 50Hz NTSC signal with that computer.

 

Coupled with the NTSC high color trick, it's kind of the best of both worlds. Pal compute time, and lots of colors.

 

In fact the result would be a 50 Hz NTSC, like the Amiga had to allow PAL game compatibility on this continent..

 

Interesting, however 50Hz flicker is somewhat visible to the eye. Indeed in the sprite demo it would allow maybe another sprite or more background animated tiles. Does the Tandy RGB monitor supports 50Hz too?

 

Bet it probably does. The guys at CoCo3.com would know this answer cold. I was musing about a Propeller demo that runs in PAL, and the 50hz gives it some time. When 50Hz NTSC came up, I thought of this thread, and so there you go...

 

Anyway, most modern displays will do the 50Hz thing, as they have to for PAL anyway, just like a PAL display will do PAL 60.

 

There is some flicker, but on low intensity backgrounds, it's no big deal. Reducing overall screen brightness helps too.

 

Hi Guys.

 

Yeah the RGB CM8 monitor will do 50 or 60hz display. I'm based in Aussie Land and I use both a Pal and NTSC hooked up to my monitor. Mentioning the 50/60hz switch in $FF98 has given me a Idea for my Hacks I do in the Gime. I just may try setting the 50Hz switch on my NTsc unit and see what happens while switching in the 640x192x4 color mode.

I'm curious to know If maybe the Gime designer used the 50/60hz switch on a NTSC unit which is what may cause the something Odd to occur. Stuff it I will try out that idea tonight. Thanks PotatoHead for the idea.

 

Have fun guys.

 

Laters

 

Briza

 

Ok Guys.

 

I just ran a hack using Potatoheads theory of the 50hz switch on a Ntsc unit. It sure does work. You get a slight flicker but it is very small. Phead is right you do get multiple colors appearing in a 640x192x4 color mode. Some hues are the same but overall you get more then 16 colors. I would take a guess and say you get the whole 64 color palette with different color hues for each 64 colors in the Composite output only. Now is the question can it be used for a game tho.

 

laters

 

Briza

Link to comment
Share on other sites

Cool. I didn't have my CoCo hooked up to vet it. I know most of my TV's at the time would display it, and I thought that would be true today with most chipsets being international for economies of scale.

 

The key to the 640x200x4 mode is this:

 

Set the four palette entries to the 4 intensity levels. Palette 0 is black, palette 1 is dark grey, palette 2 is light grey, and palette 3 is white. That's the most obvious way. Trading the dark grey and white gives a similar palette, and a different texture to the pixels.

 

Now, once that's been done, drawing is just one byte per pixel, period. On my capture card, there were well over 192 colors. I didn't sample all of them, but most of them. On a TV, it might be a bit less, depending on the accuracy of the TV, it's color circuit qualities, etc...

 

As long as one byte per pixel is used, a game will be no problem. Everything is consistent at that level, in that the same byte will render the same color anywhere on the screen. I wonder about speed, as one byte per pixel is easy, no sprite shifting, no pre-shifting of data either. Cool. But it's the most writes per object, and I don't know the balance there, whether or not that cancels out the easy addressing.

 

To get some more speed, the scan line doubling register can be used to do 160x100x256, and that's the mode where it's just sweet. Memory foot print is lowest, resolution is still useful and nicely retro looking, screen fill speed is highest, and the 50Hz gives the longest compute time during blanking for motion.

 

The smaller memory foot print means being able to easily double buffer the display on an unexpanded CoCo as well, as a full screen is only 32K. Being able to double buffer opens a lot of doors for object motion and such, where a 64K screen makes that a lot harder.

 

160x200x256 = 32K per graphics page.

 

160x96x256 = 16K!! per graphics page, and less sprite data vertically.

 

320x200x16 = 32K by comparison.

 

Fill rate should still be good, as the CoCo can toss a 32K screen about nicely enough.

 

The double height pixels render best on most displays. I have found that PC capture cards will really show all the colors as different as they can be. My modern TV is pretty good, rounding some of them off, resulting in a few duplicates, and my older TV has a lower overall color effect, best shown with the double height pixels.

 

Also worth noting is the flicker will vary with display type. CRT displays will flicker the most as their persistence is lowest. Modern LCD TV's, Plasma, etc... will flicker much less, and their color circuits vary more too.

 

The best is a dark background, or low intensity background, with game objects being brighter.

 

It's reasonable to expect well over say 128 useful colors easy with this kind of display, and you get the max compute time to render objects with. If one turns up the color saturation, the differences are easier to see.

 

Briza, at the time I thought the CoCo 3 should be able to render most of the classics with really great color. 160 pixels is the Atari native resolution, at either one scan or two scans high.

 

With the extra blanking time, if needed, good looking VCS / Atari 8 bit game displays should look great, with the potential for a lot of motion.

 

C64 type titles can be done already with the 16 color modes, as that is all that machine has. No worries there. The 50Hz will help with moving objects.

 

The intensity levels of the CoCo are a bit weak, but in terms of sheer number of colors on the screen, there is plenty of room to make up those differences.

 

Most of the CoCo game efforts were centered around the 320 mode, with 16 colors, few using 160 that I know of, and none actually throwing a lot of color around. That's all fine and good. Not slamming anybody or anything.

 

However, going retro style at the 160 pixels, opens the door in new directions, given a composite display is used...

 

What is needed really is emulator support for that mode. Need to run a few TV's with the possible palettes, where black is always palette 0, but the other three can be shuffled around some to get the best overall color set.

 

Sample that with a paint type program, average the values out, and that's the emulator palette. If we could get that in emulation, then the really great rainbow IDE would be worth checking out.

 

(that looks to be just killer, BTW and is on my list of things to check out on CoCo)

 

Frankly, those things done means being able to do some killer retro things with lots of colors. Maybe that won't appeal to the hard core CoCo crowd, always working on that 640 pixel mode RGB, but retro gamer / home brew types would groove on classic style games with a lot of color. Well, at least I would :)

 

160x200 or 160x96 x 256 is pretty sweet actually. Maybe it's time to port over a picture or two to show it off better.

Edited by potatohead
Link to comment
Share on other sites

Cool. I didn't have my CoCo hooked up to vet it. I know most of my TV's at the time would display it, and I thought that would be true today with most chipsets being international for economies of scale.

 

The key to the 640x200x4 mode is this:

 

Set the four palette entries to the 4 intensity levels. Palette 0 is black, palette 1 is dark grey, palette 2 is light grey, and palette 3 is white. That's the most obvious way. Trading the dark grey and white gives a similar palette, and a different texture to the pixels.

 

Now, once that's been done, drawing is just one byte per pixel, period. On my capture card, there were well over 192 colors. I didn't sample all of them, but most of them. On a TV, it might be a bit less, depending on the accuracy of the TV, it's color circuit qualities, etc...

 

As long as one byte per pixel is used, a game will be no problem. Everything is consistent at that level, in that the same byte will render the same color anywhere on the screen. I wonder about speed, as one byte per pixel is easy, no sprite shifting, no pre-shifting of data either. Cool. But it's the most writes per object, and I don't know the balance there, whether or not that cancels out the easy addressing.

 

To get some more speed, the scan line doubling register can be used to do 160x100x256, and that's the mode where it's just sweet. Memory foot print is lowest, resolution is still useful and nicely retro looking, screen fill speed is highest, and the 50Hz gives the longest compute time during blanking for motion.

 

The smaller memory foot print means being able to easily double buffer the display on an unexpanded CoCo as well, as a full screen is only 32K. Being able to double buffer opens a lot of doors for object motion and such, where a 64K screen makes that a lot harder.

 

160x200x256 = 32K per graphics page.

 

160x96x256 = 16K!! per graphics page, and less sprite data vertically.

 

320x200x16 = 32K by comparison.

 

Fill rate should still be good, as the CoCo can toss a 32K screen about nicely enough.

 

The double height pixels render best on most displays. I have found that PC capture cards will really show all the colors as different as they can be. My modern TV is pretty good, rounding some of them off, resulting in a few duplicates, and my older TV has a lower overall color effect, best shown with the double height pixels.

 

Also worth noting is the flicker will vary with display type. CRT displays will flicker the most as their persistence is lowest. Modern LCD TV's, Plasma, etc... will flicker much less, and their color circuits vary more too.

 

The best is a dark background, or low intensity background, with game objects being brighter.

 

It's reasonable to expect well over say 128 useful colors easy with this kind of display, and you get the max compute time to render objects with. If one turns up the color saturation, the differences are easier to see.

 

Briza, at the time I thought the CoCo 3 should be able to render most of the classics with really great color. 160 pixels is the Atari native resolution, at either one scan or two scans high.

 

With the extra blanking time, if needed, good looking VCS / Atari 8 bit game displays should look great, with the potential for a lot of motion.

 

C64 type titles can be done already with the 16 color modes, as that is all that machine has. No worries there. The 50Hz will help with moving objects.

 

The intensity levels of the CoCo are a bit weak, but in terms of sheer number of colors on the screen, there is plenty of room to make up those differences.

 

Most of the CoCo game efforts were centered around the 320 mode, with 16 colors, few using 160 that I know of, and none actually throwing a lot of color around. That's all fine and good. Not slamming anybody or anything.

 

However, going retro style at the 160 pixels, opens the door in new directions, given a composite display is used...

 

What is needed really is emulator support for that mode. Need to run a few TV's with the possible palettes, where black is always palette 0, but the other three can be shuffled around some to get the best overall color set.

 

Sample that with a paint type program, average the values out, and that's the emulator palette. If we could get that in emulation, then the really great rainbow IDE would be worth checking out.

 

(that looks to be just killer, BTW and is on my list of things to check out on CoCo)

 

Frankly, those things done means being able to do some killer retro things with lots of colors. Maybe that won't appeal to the hard core CoCo crowd, always working on that 640 pixel mode RGB, but retro gamer / home brew types would groove on classic style games with a lot of color. Well, at least I would :)

 

160x200 or 160x96 x 256 is pretty sweet actually. Maybe it's time to port over a picture or two to show it off better.

 

Hi PotatoHead.

 

Yeah I set the Palette Slots to the colors you suggested. They sure do make a difference to the resulting colors displayed.

Btw RainbowIde is `1 killer Compiler. I use that and VCC to test real disks on my Hardware. Sure does make a difference, I tried Disk Edtasm I hated using that. So RainbowIde is the way to go for fast compiling and testing of code.

I can't wait for you to do some pics showing off the 256 colors generated in the 640x192x4 color modes.

Imagine creating RemZ demo using this feature it would be kick ass for sure. How about it Remz willing to give it shot mate.

 

laters

 

Briza

Link to comment
Share on other sites

Did you try swapping white, and dark grey, or light grey? Which color set do you like the best? Just curious.

 

Also do you know of some simple cassette routines that will load a picture into RAM pages, then set the GIME to display? I'm in a mode where I could give this a little time to get a picture or two displayed, but not enough time to really pound through programming that from square one, which is where I'm at, with CoCo 3 and cassette only. Maybe that work has been done...

 

After thinking about the picture a bit, seems to me building a palette from the sampled colors isn't tough. From there, reduce a few pictures to the resolution. From there, it's all about just building that binary file. I don't know how to BLOAD something into RAM for that purpose. Hints?

 

A coupla nice pictures would do a world of good.

 

RE: Demo above in that mode.

 

Well, I think it would kick some ass. The only real bummer on CoCo is having 4 intensities only. Lots of hues, but not all that many intensities... If there were time for textures, well that's a different ball game then.

 

A better target would be scrollers, shooters and puzzlers where the broad set of hues makes great sense.

Edited by potatohead
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...