CollectorVision Phoenix Release Thread

[insertclevernamehere]

12 minutes ago, zaphro72 said:

Have you updated your Phoenix with the cores on the very first post? If not that is probably the problem

Yes

[Bmack36]

4 minutes ago, insertclevernamehere said:

Yes

Can you show a pic of the install cores screen?

[Swami]

Back to an earlier issue where the Edladdin controllers caused an issue with some games because of the quadrature inputs on the Phoenix, if you change the spinner position with the spinner buttons, does this fix the issues with those games?

[insertclevernamehere]

10 hours ago, Bmack36 said:

The current service menu core is A0. You should update that first. This will allow you to see the core revision numbers when you go to the core load screen or the core install screen.

Oh dear, now I'm going to have to ask a question I probably should know the answer to.  Where do I get the updated core from?

[Bmack36]

3 minutes ago, insertclevernamehere said:

Oh dear, now I'm going to have to ask a question I probably should know the answer to.  Where do I get the updated core from?

First post in this thread. Download the Service.PHX and the CORE01.PHX. Then power up the system and hit # to go to the service menu and then 3 to install service. Now you should be able to go to the install core menu and see the core revision numbers next to the cores.

[insertclevernamehere]

2 hours ago, Bmack36 said:

First post in this thread. Download the Service.PHX and the CORE01.PHX. Then power up the system and hit # to go to the service menu and then 3 to install service. Now you should be able to go to the install core menu and see the core revision numbers next to the cores.

Ok, thanks.  Will do.  I updated the CV & 2600 cores when first posted but somehow I missed the 3rd update below those.

[Inky]

Is there an issue with the 2600 core freezing when the roms are in multiple folders?

 

[nick3092]

4 hours ago, Inky said:

Is there an issue with the 2600 core freezing when the roms are in multiple folders?

 

I noticed something similar. I used the same folder structure I used for my Harmony cart, and it was taking almost 2 minutes to move from folder to folder on the Phoenix.

 

I was originally thinking it had something to do with the number of roms in each folder and started doing some testing but life got in the way. But maybe I was chasing down the wrong avenue. Maybe it is number of folders vs number of roms.

 

I reported it earlier in the thread, but no one else reported the same, and Brian didn't acknowledge it. So I dropped it. The 2600 core itself feels a bit clunky, mainly in the UI. Squished menu where the navigation doesn't feel great. Plus the long delays in navigating folders. And while navigating the menu, the running game seems to acknowledge the input. It should pause or at a minimum not send the control movements to the game. 

[insertclevernamehere]

19 hours ago, Bmack36 said:

Can you show a pic of the install cores screen?

Sorry, didn't see this originally.  Only just noticed the request.  See below.  I haven't gotten around to downloading and installing the updated service.phx yet.

[nick3092]

14 minutes ago, insertclevernamehere said:

Sorry, didn't see this originally.  Only just noticed the request.  See below.  I haven't gotten around to downloading and installing the updated service.phx yet.

Until you install the updated service core, this screen isn't very useful. One you do, it will show a version number next to the 2 cores.

[digress]

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.

[Bmack36]

15 hours ago, digress said:

Consider selling some caseless boards if that might make another run more viable.

The run is actually dictated by the board costs. We already have the sunk costs for the all of the cases already from the first run.

[Bmack36]

16 hours ago, insertclevernamehere said:

Sorry, didn't see this originally.  Only just noticed the request.  See below.  I haven't gotten around to downloading and installing the updated service.phx yet.

The important thing is to install the service core to verify which version is actually installed.

[Bmack36]

For those curious, the colecovision source code has been uploaded to github: https://github.com/CollectorVision/Phoenix-Colecovision

[insertclevernamehere]

5 hours ago, Bmack36 said:

The important thing is to install the service core to verify which version is actually installed.

Updated service core.  Install core menu now shows which version of both cores.  Also system info shows different firmware code.  Volume of CV core still lower than 2600.

 

[Ikrananka]

6 minutes ago, insertclevernamehere said:

Updated service core.  Install core menu now shows which version of both cores.  Also system info shows different firmware code.  Volume of CV core still lower than 2600.

 

 

The latest CV core is "0006" so you still need to update it with that in the first post of this thread.

Edited January 7, 2020 by Ikrananka

[Pixelboy]

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?  

 

Edited January 7, 2020 by Pixelboy

[digress]

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?  

 

 

Edited January 8, 2020 by digress

[mingus]

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?  
 

Star wars arcade port.....

[Pixelboy]

2 hours ago, digress said:

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.

Interesting. And the Phoenix reproduces all the capabilities of the F18A precisely and at the same potential speed?

 

[Swami]

I'm getting a super arcade type controller and I seem to remember certain games having issues with it on the Phoenix, mostly SGM games. Opcode's early pac-man collection and road fighter, for instance, I believe. Some newer one's also. Seemed like something to do with the quadrature inputs. Was a cause for this ever figured out and/or addressed? Anyone? Thanks. I tried searching the have dozen related threads of umpteen pages, but can't seem to pin it down besides on an Edladdin SAC+ having a glitchy keypad that found a fix.

[Bmack36]

10 minutes ago, Swami said:

I'm getting a super arcade type controller and I seem to remember certain games having issues with it on the Phoenix, mostly SGM games. Opcode's early pac-man collection and road fighter, for instance, I believe. Some new ones like Thexder. Was a cause for this ever figured out and/or addressed? Anyone? Thanks. I tried searching the have dozen related threads of umpteen pages, but can't seem to pin it down besides on an Edladdin SAC+ having a glitchy keypad that found a fix.

Still working out the best way to address the issue for that. Worst comes to worst we can make a separate core that has the encoder lines disabled, but there is probably a more elegant way to fix it.

[Swami]

4 minutes ago, Bmack36 said:

Still working out the best way to address the issue for that. Worst comes to worst we can make a separate core that has the encoder lines disabled, but there is probably a more elegant way to fix it.

Okay. Thanks! So, changing the position of the "spinner" is not a solution? I seem to remember something was mentioned about the spinner position causing the effect.

[Bmack36]

1 minute ago, Swami said:

Okay. Thanks! So, changing the position of the "spinner" is not a solution? I seem to remember something was mentioned about the spinner position causing the effect.

On a Colecovision Super Action Controller moving the spinner can fix it. In some 3rd party controllers and mods, pins 7 and 9 either disconnected or not the same. The disconnected pins can pickup noise which can leave the "spinner" in a bad state that can lock up programs. 

[Swami]

3 minutes ago, Bmack36 said:

On a Colecovision Super Action Controller moving the spinner can fix it. In some 3rd party controllers and mods, pins 7 and 9 either disconnected or not the same. The disconnected pins can pickup noise which can leave the "spinner" in a bad state that can lock up programs. 

Okay. Thanks so much.