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

[nathanallan]

Potatohead, do you have a page showing what you have been doing with the propellor proc's? I'm looking into small ish devices, and would love to see what awaits me (if I go with a propellor).

 

@remz, The Tandy demo looks amazing, though I have a Coco2 not a 3:( I want a 3, might do a few things in Basic with the one I have here. Also in need of tape or disk drive, or figure how to make a serial cable and program to use a PC for local storage.

 

Nathan

[potatohead]

Well, I had written up a nice post and came back to it not here.... So, here I go again

 

Deffo get a 3. It's a killer machine that never got the love it should have.

 

As for the Prop, I've been working on the things for a while now. Great little chip. It's got a lot of power, but can be challenging. On the flip side, the graphics capability it has is largely software driven, with some hardware to keep it sane. Those things make it perfect for retro projects. It can closely duplicate the look and feel of many different retro systems at the video level. I like this a lot, and that was what attracted me to getting into the scene in the first place.

 

My blog has some project details. Not all of them, but some. I just got a nice 80 column color text driver done and put into the Object Exchange.

 

http://obex.parallax.com --> This is the repository of completed Propeller code. Lots of great stuff in there. Most things on Propeller are software, so there is a lot of code for connecting to things in that OBEX. That also keeps the chip simple, as a lot of things can be done with only a few additional components.

 

http://forums.parallax.com --> The current center of user activity. There are some games in progress. Somebody just knocked out a dead on Boulderdash clone. Look in the HYDRA game forum for that, and ports of FREEWAY, ADVENTURE, and HERO in progress using a VCS like driver. The video output of that isn't quite VCS authentic, but will be changed here in the very near future. The programs written won't need a change when that occurs.

 

http://propeller.wikispaces.com --> A growing wiki, where lots of tips, techniques, code, games and such are archived. On that wiki, I used the same technique that delivers a 160 pixel, 256 color screen on the CoCo 3, to get a freaking ton of colors on Propeller. On the wiki, I've a screenie showing a nice chunk of them. Probably can get double that.

 

My current projects are: FREEWAY port, and a first pass at running a 6502, through a Propeller to see whether or not it makes sense to use one for classic hardware emulation. Most of the electronics have arrived, and the rest will show in a week or two.

 

The idea behind that one is to blend hardware and software for a replacement / upgraded VCS. I have a lot of interest in the kinds of things needed to do that, and am stoked about it right now. We've tried emulation of a 6502, but the result of that is a Prop not being fast enough to really get it done like a VCS would need it done. So, the next best thing is to put a real 6502 in the mix, and see about emulating the rest of a VCS. There is interest in doing an Apple (likely to work) and a Vic 20 (maybe not so likely) as well.

 

I've an 800XL here that I would love to connect to a Prop as well. I don't think I know enough yet however. Baby steps first.

 

I'm into the hardware element as well as the emulation of graphics chips and such from that time. All of that can be done on the PC, but fuck that. No disrespect to people who are doing it, but it's just not retro for me. Running on the original hardware is cool, and I like that. Building some stuff has some appeal too.

 

Propeller are interesting little chips. They are not like other CPU's both micros and bigger, newer faster CPU's. They are multi-processors. A Propeller has 32K of main RAM, called HUB ram, shared among the 8 CPUs, or COG's that run in parallel inside the thing. There are no interrupts and there is no stack either, which make the programming model interesting and kind of addictive. The CPU's are called COGs, and they run together, each getting round robin access to the shared HUB memory. The twist here is that each COG has a memory where it's assembly programs run, or the SPIN intrepeter runs. Once a COG is running, it does not have to disturb the others AT ALL.

 

The intriguing things to me are:

 

1. Very little external hardware is required. You literally can assemble a few resistors, game controller port, Prop, crystal, and some power components, or battery, onto a breadboard and be playing Donkey Kong for maybe $20. The Demo Board I suggested runs most things, and is $50, I think. Proto Boards are pre-soldered for power, crystal, and leave the rest open for people to build their own board up. If you can solder, one of these is the cheap and easy way in. There is lots of hardware help, and suggested circuit layouts to be had too.

 

People are selling great, custom boards as well. Parallax encourages this, which makes the whole thing cool. I've a HYDRA, HYBRID, Demo Board, and Proto Board, along with some spare propellers, and a Professional Propeller Dev Board, where I'll be bread boarding the VCS circuit.

 

2. Programming is a mix of assembly language and SPIN, which is a higher level interpreted language that resides on chip. SPIN programs run about as fast as Atari assembly language programs do, and propeller assembly runs at 20MIPS. Multiply that by 8 CPUs and the thing has a lot of horsepower.

 

3. Being a multi-processor is very interesting. Lets say somebody wants to use the 80 Column Text driver I just finished. It is a 2 COG driver. So that gets launched, and a video memory is defined. From there, that users program can treat it just like a graphics chip in hardware. Nothing their program does would impact it, so they just write to the video text memory, and characters appear in the same way they would on an Atari. (Uses the same font actually)

 

4. One chip can do a lot of things. Want to run two TV displays, one VGA, take input, make sound, and blink a bunch of lights? All possible on one Propeller.

 

5. IMHO, it's one of the most easy to learn micros out there, and it's easy because the electrical requirements are low enough to not get in the way, and for how the programming is done. There are challenges with that, but the good kind, not, "I can't even blink an LED kind".

 

6. The software nature of it means driving lots of displays is possible. Everything from little LCD to TV to VGA, NTSC, PAL (well not the best quality, but still PAL), etc... can be done with just resistors and some code. Damn cool.

 

Baggers has the first level of WOLF3D rendering on the thing, with textures @ 60FPS NTSC / 50hz PAL. No baddies, for lack of RAM, but graphically very impressive. That is a dynamic display, like the VCS does too. IMHO, more impressive. A propeller took first place in the Wild competition last year too. Amazing demo. A video is in my blog. The guy who did that also did CRAFT on an AVR the year before. (we sent him a prop, LOL!!)

 

http://www.pouet.net/prod.php?which=53003

 

http://www.propgfx.co.uk/

 

It's a fun chip, with a lot of gaming potential. There are some nice games done, but the real fun isn't just gaming, it's programming and building too, with an excellent retro, but modern feel.

 

The buy in is either some time to build up a circuit board, or something for maybe $50, or get a board already built for the same, up to about $100 or so. If you've got electronics laying around, chances are you can go for a pre-built programming plug for $30, and raw chips for $8.

Edited December 14, 2009 by potatohead

[nathanallan]

That seriously whets my appetite for some hardware, potatohead. It's an idea that's been bouncing around in my head for a while, just the hardware has never been as affordable as it is now.

 

I think I want to make something like the Hydra, just a bit different. Maybe portable. Maybe it'll take more head-bouncing to get it to actually happen

[briza]

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.

 

Hi PotatoHead.

 

Yeah I switched around the Grey and white order. You do get a different color result I find using the White before Grey gives you a duller set of colors while having Dark Grey before white gives you Brighter(intensity) colors will need to further experiment with this and determine why this is so.

As for Cassette routines I have no clue. The best person to ask for that is Robert Gault in the coco 3 website his the local guru when it comes to knowing the ins and outs of the coco's. Leave a post in the forums there and RG will be 1 of the 1st to leave you the stuff or routines you need.

 

 

1 quirk I did find and notice using the 640x192x4 color mode. $FF99 you have bit settings 6-5 have a reserved setting for Vres when set for #%10(210line mode)this causes a bouncing endless scrolling thru memory and on the interrupts you get a screen splashed up with multiple colors Ok. Well if you set the Cres bits to 2,4,16 color mode usually you will only get the amount of colors selected by these bits on the Splash color part. Well 640x192x4 color mode should only give you 4 colors but it does not do that you actually get the whole 64 color palette appearing with the different hues of each color which total around 256 colors. Which means to me that this 640x192x256 color mode thingy you stumbled across could give us clues to how the Hardware byte/pixel 256 color mode could be activated. I am starting to think that the 640x192x4 color mode is the key to unlocking this special graphics mode Mr X's mentions. Will need to do further hacking in the Gime and try it on all Gime versions made. 1986 and 1987 chips. If it only works on the 86 gime then it could possibly mean that something is hidden in there.

 

laters

 

Briza

[potatohead]

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.

 

Hi PotatoHead.

 

Yeah I switched around the Grey and white order. You do get a different color result I find using the White before Grey gives you a duller set of colors while having Dark Grey before white gives you Brighter(intensity) colors will need to further experiment with this and determine why this is so.

As for Cassette routines I have no clue. The best person to ask for that is Robert Gault in the coco 3 website his the local guru when it comes to knowing the ins and outs of the coco's. Leave a post in the forums there and RG will be 1 of the 1st to leave you the stuff or routines you need.

 

 

1 quirk I did find and notice using the 640x192x4 color mode. $FF99 you have bit settings 6-5 have a reserved setting for Vres when set for #%10(210line mode)this causes a bouncing endless scrolling thru memory and on the interrupts you get a screen splashed up with multiple colors Ok. Well if you set the Cres bits to 2,4,16 color mode usually you will only get the amount of colors selected by these bits on the Splash color part. Well 640x192x4 color mode should only give you 4 colors but it does not do that you actually get the whole 64 color palette appearing with the different hues of each color which total around 256 colors. Which means to me that this 640x192x256 color mode thingy you stumbled across could give us clues to how the Hardware byte/pixel 256 color mode could be activated. I am starting to think that the 640x192x4 color mode is the key to unlocking this special graphics mode Mr X's mentions. Will need to do further hacking in the Gime and try it on all Gime versions made. 1986 and 1987 chips. If it only works on the 86 gime then it could possibly mean that something is hidden in there.

 

laters

 

Briza

 

Well, that's kind of interesting.

 

What I don't get about the 256 color mode is how it is supposed to output. From what I can tell, the machine has only 4 intensities. I've never seen a GIME display where there were more than 4 intensities. If there is a 256 mode, wouldn't more than 4 be seen?

 

Because of this, I've always thought the 256 mode was unlikely, at least on the RGB monitors.

 

Good luck hunting.

 

Do know the colors shown when running 640xwhateverx4, are caused by the display system and it's limits. As far as GIME is concerned, it's doing a rather ordinary 640 pixel 4 color display.

 

If the designers of the CoCo would have provided S-video, there would only be 4 colors. (well, maybe a fringe color or two, but nothing like what we see on composite)

 

Also, had they used interlaced color, where the phase alternates each line, the number of colors would be reduced to only a few as well, C64 style.

 

Do you have a short extended basic program that can reproduce this mode you are seeing? I would love to get a screen capture of it for observation.

Edited December 15, 2009 by potatohead

[briza]

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.

 

Hi PotatoHead.

 

Yeah I switched around the Grey and white order. You do get a different color result I find using the White before Grey gives you a duller set of colors while having Dark Grey before white gives you Brighter(intensity) colors will need to further experiment with this and determine why this is so.

As for Cassette routines I have no clue. The best person to ask for that is Robert Gault in the coco 3 website his the local guru when it comes to knowing the ins and outs of the coco's. Leave a post in the forums there and RG will be 1 of the 1st to leave you the stuff or routines you need.

 

 

1 quirk I did find and notice using the 640x192x4 color mode. $FF99 you have bit settings 6-5 have a reserved setting for Vres when set for #%10(210line mode)this causes a bouncing endless scrolling thru memory and on the interrupts you get a screen splashed up with multiple colors Ok. Well if you set the Cres bits to 2,4,16 color mode usually you will only get the amount of colors selected by these bits on the Splash color part. Well 640x192x4 color mode should only give you 4 colors but it does not do that you actually get the whole 64 color palette appearing with the different hues of each color which total around 256 colors. Which means to me that this 640x192x256 color mode thingy you stumbled across could give us clues to how the Hardware byte/pixel 256 color mode could be activated. I am starting to think that the 640x192x4 color mode is the key to unlocking this special graphics mode Mr X's mentions. Will need to do further hacking in the Gime and try it on all Gime versions made. 1986 and 1987 chips. If it only works on the 86 gime then it could possibly mean that something is hidden in there.

 

laters

 

Briza

 

Well, that's kind of interesting.

 

What I don't get about the 256 color mode is how it is supposed to output. From what I can tell, the machine has only 4 intensities. I've never seen a GIME display where there were more than 4 intensities. If there is a 256 mode, wouldn't more than 4 be seen?

 

Because of this, I've always thought the 256 mode was unlikely, at least on the RGB monitors.

 

Good luck hunting.

 

Do know the colors shown when running 640xwhateverx4, are caused by the display system and it's limits. As far as GIME is concerned, it's doing a rather ordinary 640 pixel 4 color display.

 

If the designers of the CoCo would have provided S-video, there would only be 4 colors. (well, maybe a fringe color or two, but nothing like what we see on composite)

 

Also, had they used interlaced color, where the phase alternates each line, the number of colors would be reduced to only a few as well, C64 style.

 

Do you have a short extended basic program that can reproduce this mode you are seeing? I would love to get a screen capture of it for observation.

 

Yeah I also do find this odd that the Gime only has 4 intensities levels. But when you change white around with Grey either you get bright colors or duller colors.

As for a basic program to reproduce this effect I am not the guy to do it. I'm hopeless with Basic coding. I find ML coding more easier to understand, I will ask a friend who is great at basic to try and create the same display in basic, But if this cannot be done in basic then this is only a ML code feature. Will let you know how I go PotatoHead.

 

Also this mode only displays on the CMP output only. RGB does give you more colors but this I believe to be a Color blending trick I found when I activated a 640x192x4 mode on top off a 320x192x16 color mode this seems to mirror the same effect but it seems this method you found gives a better color detail then my find earlier this year.

 

laters

 

Briza

Edited December 16, 2009 by briza

[potatohead]

Can you post a short 6809 assembly routine showing what you are doing with the GIME?

 

(I read 6809 just fine)

[briza]

Can you post a short 6809 assembly routine showing what you are doing with the GIME?

 

(I read 6809 just fine) Ok Potatohead here is the code I'm using. Robert G has taken out what code is no needed amd simplified it. which I think makes it more user friendly.

 

==============================================================

* RG This is a completely reworked program. Everything that is not needed

* to obtain the results has been removed.

* Dec 19, 2009

 

org $e00

 

start orcc #$50

lds #stack move stack out of the graphic area

 

clr $ff40 stop drives

sta $ffdf *All Ram Mode!

 

* Make sure MMU and constant DRAM are on

lda #%01001100

sta $ff90

* Setup MMU blocks for Task0.

lda #$38

sta $ffa0 Task0

* MMu blocks at $60000, start of graphics screen. ROM code wiped!

ldd #$3031 *Hi-Res graphics page1 address

std $ffa1

addd #$0202 $3233 *Hi-res page 2

std $ffa3

addd #$0202 $3435 *Hi-res page 3

std $ffa5

addb #2 $36 *Hi-res page 4

stb $ffa7

 

* Set border color

ldb #000000 xxRGBrgb

stb $ff9a border color is Black

 

* Set 1st 4 Palette Slots for 640x192x4 color mode

lda #000000 Black

sta $ffb0

lda #111111 White

sta $ffb2

* These are CMP colors

lda #010000 Dark Grey

sta $ffb3

lda #100000 L Grey

sta $ffb1

 

* Set Video Offset registers to show screen at $60000

ldd #$c000 $60000/8=$c000

std $ff9d

clr $ff9c Disable Vertical scroll Reg

 

* Set up video format

lda #%10000000 *graphics, 0 screen lines per row, 50hz

sta $ff98

ldb #111101 *160bytes across, (640x200x4)

stb $ff99

 

* Place a band pattern on the screen

CLRA initialize two pixels

LOOP LDX #$2000 location

LDY #160 bytes per line,

LDB #50 number of bands to draw

PSHS B

L1 LDB #4 number of lines per band

L2 STA ,X+ store two pixels

LEAY -1,Y count bytes

BNE L2

LDY #160 reset counter

DECB count lines

BNE L2

INCA increase pixel data

DEC ,S count bands

BNE L1

LEAS 1,S pop the stack

* Now set up a new screen pattern with different colors

 

wait ldb #2

b@ ldx #0

a@ leax -1,x

bne a@

decb

bne b@

 

bra LOOP Start a new screen with different colors

 

rmb 50

stack equ *

 

end start

[potatohead]

L2 STA ,X+ store two pixels

 

On a composite display, this is actually one pixel, but you know that

 

Does this display your hack, or just a machine language implementation of the 256 color artifacting? I don't see where the GIME mode changes are anything BASIC doesn't do.

[briza]

L2 STA ,X+ store two pixels

 

On a composite display, this is actually one pixel, but you know that

 

Does this display your hack, or just a machine language implementation of the 256 color artifacting? I don't see where the GIME mode changes are anything BASIC doesn't do.

 

 

I have no idea if you could do the same thing in Basic. My original Hack program was scaled down into this current code you see. Originally I had it set to execute in the protected page($FE00) and had it set on a Timer based interrupt using the IRQ bits in $FF92 plus other routines for relocation etc. But we found that the other stuff was not necessary. Now Robert G is playing around with it he will find out if the Scrolling reg's $FF9F and $FF9C(Vertical) will still work and not effect the Color Artifacts displayed.

On a Plus note your Ideas for this have made it pretty clear that the coco 3 Gime chip does better color artifacts then what the coco 1,2 Pmode4 modes did. Now we just need people to play around with it, Maybe create a game or even re-design graphic viewers to use this new technique.

But I do think that even basic could use this new artifact mode you discovered over 10 years ago. As basic is already set up to do the 640x192x4 mode anyway So I would have to say YES it could do it.

 

laters

 

Briza

[potatohead]

Vertical should be fine, if we are talking about the same thing. I really need to get something to run more than a simple basic program on a real CoCo.

 

Horizontal would require scrolling in increments of (4) high-res 640 pixel mode pixels, or the colors will shift. Effective resolution is 160.

 

What I did in basic years ago was plot really great looking fractals. Took a day or so to get a plot. Should have video taped them...

 

Yeah it does. In fact, it's the best artifacting of the 8 bitters as most others used a more complex color signal that limits the number of colors produced. This is why a CoCo 3 running composite looks kind of bad at high resolutions.