Jump to content
Pixelboy

Team Pixelboy News Bulletin - January 1st 2019

Recommended Posts

Hello ColecoVision fans. :)

 

First and foremost, I'd like to wish you all a very Happy New Year, to you and your families and friends.

 

As you saw one week ago, I made some interesting updates to teampixelboy.com, in particular a few new titles (namely 1942, Bomber King, Ghost and Prisoner of War). All the games now listed in the "ongoing projects" section of my web site constitute my final projects as ColecoVision publisher. And I mean it this time: In the past few months, I turned down several potential projects from programmers who I consider good friends. All good things must come to an end and I want to wrap up all these remaining projects in 2019 so that I may finally retire.

 

For the short term, my plan is to release Uridium, QBIQS, The Cure, Multiverse, Booming Boy and Arcomage next spring. After that, things get a little murky. I want to finish beta-testing Space Shuttle, and I really don't know how long that's going to take. The longer it takes, the higher the odds that a couple of the final titles will get pushed back to early 2020. But anyhow, the plan (for now) is to get everything done and released by next Christmas.

 

You may also remember the eight SG-1000 ports that were announced back in 2017. I've done my part with those projects, and the ball is now squarely in Albert's court to get the boxes, manuals and cartridges manufactured, so that these games may be released via the AtariAge Store. Here's hoping there will be more progress with these games this year. It's out of my hands at this point.

 

As for the ColecoVision trading cards project, I'm going to work on that as free time permits (probably during my lunch breaks at the office) and perhaps I'll be able to release at least one series of trading cards before the year's over. No promises though, other projects on my to-do list have higher priority.

 

And that's about it. No long-winded explanations like I usually do for the first news bulletin of the year, I just want to wrap things up and walk away saying "mission accomplished". :)

 

This concludes this Team Pixelboy News Bulletin. We now return you to your regular forum activities.

 

Happy News Year! :D

  • Like 16

Share this post


Link to post
Share on other sites

By the way, I have one copy of TwinBee, one copy of Ghostbusters, and one copy of Mecha-9 which are available for immediate purchase and shipping, if anyone's interested. :)

Share this post


Link to post
Share on other sites

Thanks for the update! Looking forward to all the new games! Happy New Year!

Share this post


Link to post
Share on other sites

Great update! I understand for sure but will certainly miss if you do not publish further into the future.. Great quality and great games!

Share this post


Link to post
Share on other sites

Bomber King is now on my wishlist I may have to get The Cure, and other cool games once preorder phase starts. Happy New Year.

Share this post


Link to post
Share on other sites

Murky schmurky. Only clear blue skies & shining sun for Team Pixelboy in 2019.

Share this post


Link to post
Share on other sites

Hello ColecoVision fans. :)

 

First and foremost, I'd like to wish you all a very Happy New Year, to you and your families and friends.

 

As you saw one week ago, I made some interesting updates to teampixelboy.com, in particular a few new titles (namely 1942, Bomber King, Ghost and Prisoner of War). All the games now listed in the "ongoing projects" section of my web site constitute my final projects as ColecoVision publisher. And I mean it this time: In the past few months, I turned down several potential projects from programmers who I consider good friends. All good things must come to an end and I want to wrap up all these remaining projects in 2019 so that I may finally retire.

 

For the short term, my plan is to release Uridium, QBIQS, The Cure, Multiverse, Booming Boy and Arcomage next spring. After that, things get a little murky. I want to finish beta-testing Space Shuttle, and I really don't know how long that's going to take. The longer it takes, the higher the odds that a couple of the final titles will get pushed back to early 2020. But anyhow, the plan (for now) is to get everything done and released by next Christmas.

 

You may also remember the eight SG-1000 ports that were announced back in 2017. I've done my part with those projects, and the ball is now squarely in Albert's court to get the boxes, manuals and cartridges manufactured, so that these games may be released via the AtariAge Store. Here's hoping there will be more progress with these games this year. It's out of my hands at this point.

 

As for the ColecoVision trading cards project, I'm going to work on that as free time permits (probably during my lunch breaks at the office) and perhaps I'll be able to release at least one series of trading cards before the year's over. No promises though, other projects on my to-do list have higher priority.

 

And that's about it. No long-winded explanations like I usually do for the first news bulletin of the year, I just want to wrap things up and walk away saying "mission accomplished". :)

 

This concludes this Team Pixelboy News Bulletin. We now return you to your regular forum activities.

 

Happy News Year! :D

HAPPY NEW YEAR TO YOU ALSO LUC! We all know how you have impacted the ColecoVision community and thank you for your ongoing support of it.

Share this post


Link to post
Share on other sites

Well that's bittersweet news. Lots of splendiferous goodies for 2019 but then nothing. Team Pixelboy are no more. I wonder if CollectorVision and/or Opcode will take on some of those projects turned down by Luc? I've only had a Colecovision for 13 months and don't have a Team Pixelboy game but I preordered "Multiverse" a while back. Will likely preorder "Ghost" and "Prisoner of War" too. I'm sure I speak for everyone that Team Pixelboy will be greatly missed but nobody will resent your well earned "retirement". All the best for the future.

Share this post


Link to post
Share on other sites

Luc, Happy New year to you and yours, hoping that 2019 (and beyond) are great for you. Having said that, it will be hard and also very sad, personally, to see you stop publishing games for the Colecovision and go into retirement but totally understand as well.

 

You were the first publisher I bought homebrews from when I got back into the CV and discovered "homebrews". Your games from box, manual, cartridge and most important, gameplay, have been top quality all the way. Your presence has been felt in the community for many years and you will absolutely be missed when your "game is over"!!!

 

Thank you for all that you have done and also for what you continue to do.

 

A very big THANK YOU, and I hope you enjoy relaxing from the pressures of releasing games and can enjoy your more quiet time.

 

Brandon

Share this post


Link to post
Share on other sites

Happy new year Luc

Yeah, that's a rather sad news.... But Team Pixelboy being a one-man operation, I certainly understand your decision
You did bring alot of awesomeness to the CV community and this is something that will always be remembered by all of us here

If you ever need help on something in the future, do not hesitate to contact any of us at CollectorVision
The door will always be open for you

So thanks Luc, thanks for everything you've accomplished!


Cheers!


J-F

Share this post


Link to post
Share on other sites

By the way, I have one copy of TwinBee, one copy of Ghostbusters, and one copy of Mecha-9 which are available for immediate purchase and shipping, if anyone's interested. :)

Ghostbusters has found a buyer. TwinBee and Mecha-9 are still available.

 

 

Happy new year Luc

 

Yeah, that's a rather sad news.... But Team Pixelboy being a one-man operation, I certainly understand your decision

You did bring alot of awesomeness to the CV community and this is something that will always be remembered by all of us here

 

If you ever need help on something in the future, do not hesitate to contact any of us at CollectorVision

The door will always be open for you

 

So thanks Luc, thanks for everything you've accomplished!

 

Cheers!

 

J-F

Thanks J-F. :)

 

As I was telling a friend recently, with the CollectorVision Phoenix, the F18A will go from being an obscure CV graphic chip upgrade to something 200+ ColecoVision fans will have built-in. Just removing the 4-sprites-per-scanline limit will make some homebrew games possible that were mostly impossible before, like fighting games with both fighters made with overlapping magnified sprites, or an actually decent version of the Popeye arcade game, just to name a couple of possibilities. Even Opcode's Donkey Kong Arcade can exploit it directly. Pretty interesting possibilities there... But not enough to keep me from retiring. :P

Share this post


Link to post
Share on other sites

Ghostbusters has found a buyer. TwinBee and Mecha-9 are still available.

 

 

 

Thanks J-F. :)

 

As I was telling a friend recently, with the CollectorVision Phoenix, the F18A will go from being an obscure CV graphic chip upgrade to something 200+ ColecoVision fans will have built-in. Just removing the 4-sprites-per-scanline limit will make some homebrew games possible that were mostly impossible before, like fighting games with both fighters made with overlapping magnified sprites, or an actually decent version of the Popeye arcade game, just to name a couple of possibilities. Even Opcode's Donkey Kong Arcade can exploit it directly. Pretty interesting possibilities there... But not enough to keep me from retiring. :P

 

Yes, very true

 

That's something I'm considering for Sydney Hunter & The Yucatan Jungle

There's a whole lot of possibilities now :)

 

 

Share this post


Link to post
Share on other sites

Yes, very true

 

That's something I'm considering for Sydney Hunter & The Yucatan Jungle

There's a whole lot of possibilities now :)

This introduces a small technical difficulty however: How does a game detect the F18A, or the new "virtual" WSG sound chip in the Phoenix? If one was to develop a game specifically for the Phoenix, he would need to detect the custom hardware and display a "sorry" message if a regular ColecoVision console was used.

 

Also, I don't know anything about the SEX7264 Courtney WSG, but I have to wonder if it could replicate the deep sounds of Asteroids. T'would be nice to have a version of Asteroids that really sounds like the arcade original, as most home ports are sub-par in the sound department. Even better, playing Asteroids with the CollectorVision Spinner controller would be a different (yet always optional) experience. :)

Share this post


Link to post
Share on other sites

T'would be nice to have a version of Asteroids that really sounds like the arcade original, as most home ports are sub-par in the sound department. Even better, playing Asteroids with the CollectorVision Spinner controller would be a different (yet always optional) experience. :)

 

Or just one of these:

https://www.cedmagic.com/tech-info/remote-control/starplex-controller.html

Share this post


Link to post
Share on other sites

Quick update: TwinBee has been sold, all I have left in stock is one copy of Mecha-9. :)

  • Like 1

Share this post


Link to post
Share on other sites

Luc,

 

I have bought all your releases except I somehow missed one or two of your special editions. I have to say, I am very impressed with all your hard work. Great games, nice communication, excellent boxes/cartridges, awesome packaging and always sent in a timely manner.

 

I think you have done really great for the small Colecovision community and been a big part of an excellent homebrew scene. Of course I will purchase all of your remaining releases and I wish you a happy and adventurous future.

 

Big thanks //Mikael

  • Like 1

Share this post


Link to post
Share on other sites

This introduces a small technical difficulty however: How does a game detect the F18A

I can answer this one easily enough. The F18A contains status registers designed for detection (including version), but there's a simpler way. You can simply upload a 6 byte GPU program which changes a byte of VRAM. Upload it to VRAM and set the registers to run, then read the VRAM byte (no need to wait). If it changed, you have an F18A. Otherwise you don't. ;)

Share this post


Link to post
Share on other sites

I can answer this one easily enough. The F18A contains status registers designed for detection (including version), but there's a simpler way. You can simply upload a 6 byte GPU program which changes a byte of VRAM. Upload it to VRAM and set the registers to run, then read the VRAM byte (no need to wait). If it changed, you have an F18A. Otherwise you don't. ;)

Interesting. :)

 

So after uploading this 6-byte GPU program to the F18A and running the test, does the programmer need to re-upload something to the F18A to return it to its "standard" functioning mode?

 

Also, while we're on the subject of the F18A, I know the 4-sprite-per-scanline limit can be removed, but can the F18A display more than 32 sprites at once? In other words, could it be configured to have a longer sprite attribute table? Just curious. :)

Share this post


Link to post
Share on other sites

Interesting. :)

 

So after uploading this 6-byte GPU program to the F18A and running the test, does the programmer need to re-upload something to the F18A to return it to its "standard" functioning mode?

 

Also, while we're on the subject of the F18A, I know the 4-sprite-per-scanline limit can be removed, but can the F18A display more than 32 sprites at once? In other words, could it be configured to have a longer sprite attribute table? Just curious. :)

I think it should by changing the sprite attribute register start address midway down the screen with the second table already set in VRAM. Kinda like how Commodore 64 does it, multiplexing sprites. You'll have to have the CPU check for sprite collision detection or 5 sprite on a line flag to know where your scanline is at on screen then do the change. Then you'll run into sprite pattern limitation, which you can only hold 64 pattern at a time. You can switch the sprite pattern start address midway down the screen like NES mapper chip do.

Edited by Kiwi

Share this post


Link to post
Share on other sites

I think it should by changing the sprite attribute register start address midway down the screen with the second table already set in VRAM. Kinda like how Commodore 64 does it, multiplexing sprites. You'll have to have the CPU check for sprite collision detection or 5 sprite on a line flag to know where your scanline is at on screen then do the change. Then you'll run into sprite pattern limitation, which you can only hold 64 pattern at a time. You can switch the sprite pattern start address midway down the screen like NES mapper chip do.

I can't picture myself doing something like that, mainly because a sprite may cross the scanline boundary you're describing, which means the sprite would get cropped. That could be a useful hack in certain types of games, however, like a split-screen two-player game.

  • Like 1

Share this post


Link to post
Share on other sites

Interesting. :)

 

So after uploading this 6-byte GPU program to the F18A and running the test, does the programmer need to re-upload something to the F18A to return it to its "standard" functioning mode?

 

Also, while we're on the subject of the F18A, I know the 4-sprite-per-scanline limit can be removed, but can the F18A display more than 32 sprites at once? In other words, could it be configured to have a longer sprite attribute table? Just curious. :)

Kiwi's trick for changing the sprite table (or any other table) partway down the screen is the only way to get more sprites. One nice thing is that you can use the GPU to do this, which will detect with rock-solid accuracy and cost zero host CPU time. The GPU is a 100MHz 9900 (16-bit CPU with direct access to VRAM), so it can do quite a bit. I have a GPU sample showing the performance here:

 

To your first question: you need to reset the affected VDP registers if you detect that it's not an F18A.

 

Let me sneak a little psuedocode in here... I'll put it behind a spoiler for those who don't care.

 

 

 

So the first thing you need to do is "unlock" the F18A. Until you do that, it does its best to operate like a 9918/9929 (the main exception being that 80 column text is unlocked from the start, for compatibility with some 9938-based apps).

 

The F18A supports many more registers than the 9929, but they are all accessed using the same method - write to the address port with the most significant bit set.

 

So, to start, you have to write the value 0x1C to VDP register 57 (0x39). This would be writing the address 0xB91C (0xB9 = 0x80 set for register write, and 0x39 for the register index).

 

You have to write this twice in a row. Matt selected this value and this sequence as something that would be very unlikely to do intentionally. On a 9929, the masking will make this write Register 1 -- but for the test you just ignore that (you can't read it back anyway).

 

After writing this register twice, the F18A will unlock its register set and extended features. So you can go ahead and upload some code to try and run the GPU.

 

I actually use a 10 byte program, so just because I know it's tested I'll post that one, but six bytes can be accomplished using the "CLR" (zeros a word) or "SETO" (sets a word to 0xffff) opcodes.

 

The program I use is this:

 

GPUTEST
    DATA >0200,>1234        LI R0,>1234
    DATA >C800,>1C10        MOV R0,@>1C10
    DATA >0340              IDLE
The bytes on the left are the TI TMS9900 assembly bytes (TI uses ">" to indicate hex).

- The first instruction (Load Immediate) loads Register 0 (there are 16 general-purpose registers) with the hex value 0x1234.

- The second instruction (MOVe) moves the value in R0 to the absolute (@) address 0x1C10 (in VDP memory!!)

- The third instruction (IDLE) puts the GPU back to sleep

 

(First note: the GPU is a 16-bit processor and has direct 16-bit access to all video RAM, as well as 2k of its own. Also note there's no impact to GPU execution -- you can run the GPU in a tight polling loop and it won't impact any other operation at all. It's really nice. ;) )

 

Anyway, copy those bytes to somewhere in VDP RAM, I personally use address 0x1C10. This will make the program overwrite its own first word, meaning no extra initialization of VRAM is needed.

 

At this point, to trigger the GPU, you have to load the new PC to two VDP registers. You write the MSB (0x1C) to register 54 (0x36), and then the LSB to register 55 (0x37). Order is important - writing the LSB starts the program. So that would mean writing the address port with 0xB61C and then 0xB710.

 

The GPU is far faster than the host CPU, so you can immediately check. Read back address 0x1C10 from VDP RAM (or, if you want to really check, pull both bytes). If you get 0x02 (first byte of the program), it did not run the GPU and you have no F18A. If you get 0x12 (value changed by the program), then it did run the GPU and you do have an F18A.

 

Finally, if you don't have an F18A, you will want to set your VDP registers for normal 9929 operation now. The unlock sequence overwrote Register 1, and the GPU set overwrite Registers 6 and 7. I personally just do my F18A check before I load my initial configuration, but if you want to check later, those are the three registers you need to restore.

 

 

Edited by Tursi
  • Like 2

Share this post


Link to post
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.

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...