digress

Is this routine meant to run on the f18a gpu directly? I'm trying to access such a routine from c that would do this very thing on a coleco

so i found in the ti forums probably what I would need. I just need to get it converted to sdcc c language equivalent. Here's the code for a F18A GPU/PIX based line drawing algorithm if anyone's interested. Note that BSTK and RSTK are WinAsm99's names for the F18A GPU opcodes CALL and RET. ********************************************************************* * * Draw a line from (x1,y1) to (x2,y2) * * Translated from C version at: * http://rosettacode.org/wiki/Bitmap/Bresenham's_line_algorithm#C * * void line(int x1, int y1, int x2, int y2) { * * int dx = abs(x2-x1), sx = x1<x2 ? 1 : -1; * int dy = abs(y2-y1), sy = y1<y2 ? 1 : -1; * int err = (dx>dy ? dx : -dy)/2, e2; * * for(; { * setPixel(x1,y1); * if (x1==x2 && y1==y2) break; * e2 = err; * if (e2 >-dx) { err -= dy; x1 += sx; } * if (e2 < dy) { err += dx; y1 += sy; } * } * } * * R0 x1 value * R1 y1 value * R2 x2 value * R3 y2 value * R13 Color (0-3) * * Modifies registers R0-R10 * LINE * Setup variables CLR R6 * R6 is sx = 0 MOV R2,R4 * R4 is dx = x2 S R0,R4 * dx = x2 - x1 JGT DXPOS DEC R6 * sx = -1 JMP LINE1 DXPOS INC R6 * sx = 1 LINE1 ABS R4 * dx = abs(dx)b CLR R7 * R7 is sy = 0 MOV R3,R5 * R5 is dy = y2 S R1,R5 * dy = y2 - y1 JGT DYPOS DEC R7 * sy = -1 JMP LINE2 DYPOS INC R7 * sy = 1 LINE2 ABS R5 * dy = abs(dy) C R4,R5 * Compare dx to dy JGT DXGTR MOV R5,R8 * R8 is err = dy NEG R8 * err = -dy JMP LINE3 DXGTR MOV R4,R8 * R8 is err = dx LINE3 SRA R8,1 * err = err / 2 MOV R4,R10 NEG R10 * R10 = -dx * Main loop LINEL BSTK @PLOT * Plot (x1,y1) C R0,R2 * Compare x1 to x2 JNE CONT * Continue if x1 != x2 C R1,R3 * Compare y1 to y2 JNE CONT * Continue if y1 != y2 RSTK * Break CONT MOV R8,R9 * R9 is e2 = err C R9,R10 * Compare e2 to -dx JLT LINE4 * Jump if e2 < -dx S R5,R8 * err -= dy A R6,R0 * x1 += sx LINE4 C R9,R5 * Compare e2 to dy JGT LINEL * Loop if e2 > dy A R4,R8 * err += dx A R7,R1 * y1 += sy JMP LINEL * Loop *// LINE ********************************************************************* * * Plot a pixel at (x,y) * * R0 x value * R1 y value * R13 color * PLOT MOV R0,R12 SWPB R12 SOC R1,R12 XOP R12,R13 * PIX RSTK *// PLOT

I will do a test with that setup. 12kb is a bit brutal of 16 kb vram though so it doesn't leave room for much else. i've never used the BML setup either but I understand it. I could still get 1 colour sprites layer too. though my thought about palette swapping you could draw new lines on to the screen and then pallet swap them into view might work with some minor erasure of the current foreground image. wouldn't be as clean as a complete page swap. I'm sure I can make this work. I would get a kick out of making a vector graphics game this way. battlezone or something like that.

I think I am wrong now that I thought about it more. what I suggested would only work for 256 tiles of ecm3 6144 = 3 x 2048 normal coleco memory uses 2048 for top 1/3 2048 for middle 2/3 which is usueally just copied from first tiles set of 256 2048 for bottom 3/3 which is usueally just copied from first tiles set of 256 total 6144 bytes same as full screen bitmap just redifines middle and bottom 1/3 to be unique now ecm3 tiles use only 256 unique tiles for the whole screen so you would have to reuse. but if in bitmap mode you can have 768 unique tiles with a custom pallette of 16 colours but will have colour bleed but you wouldn't have more than 1 unless you define a second memory location and redriect the f18a towards that new memory location everytime you flip. so you could still have 2 screens. however those 2 screens could use all 8 colours.

that would be simple. you would just blank that 2kb section of vram with 0's before drawing new lines so you display 1 set of rendered lines you are blanking 1 layer of rendered lines you are drawing 1 layer of rendered lines with the pallete for that layer turn to 0 then you flip which layer is displayed next. would work like a charm. the only question would how many lines could you render per cycle.

as for buffering. if using 1 colour bitmaps line like traditional asteroids so everything is white. full screen bitmap mode could actually provide 3 full screens of bitmaps of 256x192 reason being is ecm3 colour is 3 bit. 3 - 2kb layers . each layer represent a stacking effect to get the final 0-7 colour for that pixel. 000 or 100 for layer 1 000 or 010 for layer 2 000 or 001 for layer 3 however if the entire pallette was white expect 0 then you could use layer 2 & 3 to pre render lines and then update the pallette to hide the lines on the other layers layer 1 bunch of lines in 1 bit colour layer 2 bunch of lines in 1 bit colour but it's pallette entries are set to 0 layer 3 drawing a bunch of lines in 1 bit colour but it's pallette entries are set to 0 then you flip the pallette so layer 2 or layer 3 has it's coloured lines displayed

There has been some discussion about using the gpu of the f18a to run code because it runs so much faster than the z80. Specifically for speeding up graphics rendering. Later perhaps it would be nice to add vector commands that the f18a gpu could run on say the fullscreen bitmap mode where every screen pixel would definable f18a has 2k for running this code separate from the vram. if there was a few routines to clear the the tiles to black. then draw lines vectors and see how many per cycle make sense. So for games like asteroids or star trek.

yes, then you can call the routine using a port code and have it perform the operation on the vram. this of course would no longer be compatible with a standard coleco system only f18a systems.

there is gpu code rummimg in one of my games and it seems to run fine or the same on the phoenix as it did on the coleco with an f18a . So I think so.

the f18a though not a vector engine has its own gpu which runs something like 100 times faster than the z80. you can make the render engine potentially which sends those commands to the gpu and that can speed up the render. the gpu can run code. tursi or matthew would know more about this. this would also make said asteroids compatible with existing f18a colecos.

I have updated to the latest core. It works great and sounds great. I use a hdmi to rca convertor box so that might be the culprit when I hook it up casuing low sound on my lcd tv but normal on the crt. Really impressed with the phoenix system. I really like using the original controllers and cartridges. Runs all the coleco games I've tried. save state of the current game might be useful at some point. Consider selling some caseless boards if that might make another run more viable.

running it out to a hdmi powered box which converts to rca video red & white audio on the hdtv lcd I have very low volume and have to crank it up however using the same setup and outputing to a crt in another room the volime seems normal without needing cranking sounds fine either way I just need to turn the volume up much more on one lcd tv.

controller chip might need to be replaced. there 2 , 1 for each controller stick, https://console5.com/store/kits/controller-port/colecovision.html

The link goes back to this post again. I cut and pasted it into a browser and that worked. Thanks http://adamarchive.org/updates.php?d=12/31/2019 thanks for the upload. I love the manuals. Big part of the experience.

I have the Atarimax SD next to me. Use it most days. The sd card probably needs to be reseated. take it out put it back in. If it still won't work format the sd card and recopy the files back on to it or try another sd card. get the lastest firmware from this thread:

The Italian Stallion. Rocky . I literally bought Rocky 6 months before I had a colecovision and just read the manual and looked at the screen shots til christmas when I got the colecovision. You got many of the best titles in this lot.

sounds like a contacts problem. Try seating the cartridge all the way left and later al the way right in the slot. There is a small amount of wiggle room left or right

I doubt I could add anything to it that you haven't already covered. I am , occasionally, writing a c library to reuse game code written in the coleco library for colecovision to produce a pc / vga game. I got a few routines done already. The idea was I could just run a complete coleco game through it and output a vga dos game.

I suspect the same. I'm making a sgm & f18a test right now. I am testing it on f18a/sgm colecovision & and also on a phoenix console. I havn't found any incompatibility.

Looks good. I will try it out on a future project. Would be nice to have some easier access the sgm features etc.

i have one. a haven't tried it recent but try other channels. i remember it being on a weird channel. i'll set it up later and remember that way.

I've always meant to come back and fix it. I got busy with other projects. I am going to implement this and see if it helps.

DEFINE ALTERNATE I just found out about this. This will solve much of the performance issue and incorrect sprites so I can redefine the sprites quicker.

the fire button doesn't advanace past the instruction screen for me.

It was made clear to me in an email that this was a requirement to be in the club and you could get refund if didn't agree with keeping the game secret and the roms to yourself. Everyone agreed to not share the game name , or resell it or share the roms. It's not that hard to keep my word.