digress
-
Content Count
1,800 -
Joined
-
Last visited
-
Days Won
1
Posts posted by digress
-
-
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.
10 hours ago, Tursi said:Consider using the BML (bitmap layer) rather than a tile layer. That will give you a 256x192 with 4 colors and no color bleed. In addition, the BML supports a unique opcode in the GPU, "PIX", which will calculate the address and render a pixel in a single instruction. This can speed up the line draw since you don't need to calculate addresses, just count off the X and Y coordinates.
You do still need to handle clipping yourself. It is also, unfortunately, still 12k, but perhaps the bit plane options you were considering above will allow a tricky page flip.
You could change the color palette to turn a layer off instantly then erase it with nobody the wiser. I think you were suggesting this above, but for ECM tiles...
I had thought there was a DMA engine to do the clear, but maybe it didn't happen... I don't see it in the spreadsheet.
Disclaimer: I haven't done the above, this is just from many discussions about it with Matt.
-
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.
-
16 minutes ago, Pixelboy said:I think I understand what you're suggesting, but at a certain point, the canvas data has to be cleared before you can use it for rendering the next screen update.
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.
-
1
-
-
4 hours ago, Pixelboy said:Alright, and your game "uploads" this code from the cart to the gpu at boot/reset?
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.
-
1 hour ago, Pixelboy said:Interesting. And the Phoenix reproduces all the capabilities of the F18A precisely and at the same potential speed?
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.
1 hour ago, Pixelboy said:I just had an interesting thought regarding the Phoenix. Would it be hard to alter the ColecoVision core to replace the native VDP with a vector VDP, something that would draw vectors much like the Vectrex, but designed to output those vectors as a raster image on a regular TV screen? The ColecoVision CPU, sound chip and everything else would remain unchanged, but the VDP would generate vectors only, and the programmer would write bytes to VRAM following a different "protocol".
I can imagine several graphic modes with this alternate VDP. The most straightforward would probably be for the programmer to write two sets of screen coordinates in VRAM for each vector to draw, and once the entire screen has been drawn, the VDP would "clear" VRAM (in addition to generating a VBLANK signal to the CPU) so that the programmer has a clean slate to draw on upon each screen refresh cycle.
Another graphic mode would offer object-driven features: Define an object in VRAM as a static series of vectors, and then tell the VDP to draw the object somewhere on the screen, possibly with a scale and rotation factor applied. Not sure if the Phoenix's Spartan FPGA could handle vector scaling and rotation like that (in addition to supporting the rest of the ColecoVision architecture) but I think it would be super fun to program for.
And then there's another obvious graphic mode, which would offer colored vectors. This would add a color byte to each pair of screen coordinates.
Again, I'm not sure it can be done as I describe it. Perhaps have a bigger VRAM with multiple "page buffers", and the VDP would clear the previous page while it's writing the current page, in order to always offer a clean slate for the programmer to refresh vectors on. Having to clear VRAM manually would suck...
Anyway, I'd call this altered FPGA core the VectorVision. Catchy?
-
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
-
1
-
-
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.
-
1
-
-
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.
4 hours ago, alekmaul said:SGM and f18a are on the way, don't worry. But I need to know how Phoenix handles SGM before (don't know if it uses same ports).
-
Looks good. I will try it out on a future project.
Would be nice to have some easier access the sgm features etc.
-
8 hours ago, eebuckeye said:Just got a Dina that the picture is very noisy and the sound is static only. Seems like I need to adjust the RF? What adjustment is there in the Dina?
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.
-
1
-
-
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.
You could change the color palette to turn a layer off instantly then erase it with nobody the wiser. I think you were suggesting this above, but for ECM tiles...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Trolling / Reading / I've now got my idea!
in TI-99/4A Development
Posted
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