Archive for the ‘PCEngine’ Category

Megadrive isn’t the only one

June 29th, 2021
Comments Closed

Like I already shared, Megadrive is no longer my main focus.
For several reasons (browse Twitter, Spritesmind or this WordPress), I take a rest.

I found several systems lacking of love from developers I’d like to work on.
Here are the few, by my priority order

  • Wonderswan
  • NeoGeo Pocket
  • SuperVision
  • PCEngine
  • PV-1000

More exists, it was already difficult to select only these ones (sorry P/ECE and Loopy !)

So don’t be surprised to read more posts on them from now !

NeoGeo Pocket, PCEngine, PV-1000, WonderSwan | Posted by KanedaFr

What’s wrong with CC65’s PCE ?

December 13th, 2017
Comments Closed

While playing a little with CC65, I quickly saw a lot of problems on PCEngine target?

It’s not about the code itself, written in pure asm, since I doesn’t master the PCEngine yet but about some logic involved.

 

Compatibility between target

I understand why but trying to get the same code build the same way on some different target is a real problem.

We’re not talking about windows, macos, linux here…

We’re talking about NES, Apple2, embedded system, …

There are feature which are and will never be available on every target.

so while the ‘port CC65 lib’ to your target could be a great thing, it’s all depend on what ‘CC65 lib’ is!

And, for me, it’s too much.

 

We don’t care about this !

conio, tgi, disk, file ….it’s not what we want !

runtime, stdlib and some basic C functions are the bare minimum….and it’s perfect !

conio could be used but we don’t care about putting a char or a string on screen, we want to put tiles, with all their properties.

So perfect for a HelloWorld but no way for a game !

 

Drivers ?

Mouse and joystick are loaded like driver.

We’re not talking about a Personal Computer here, but a video game system, when optimization is the key.

So, a driver in memory, no thanks !

I want to read joy input every frame, from the gameloop

 

 

I pretty sure more problems will be spotted on the coming weeks but, for now, I need to take care of these ones.

Don’t get me wrong, CC65 is good, and the available PCEngine port (and so HuC6280’s instructions set support) is a great start.

But I think a dedicated PCEngine game port should be done.

PCEngine | Posted by KanedaFr

And what about ….the PCEngine ?!

December 13th, 2017
Comments Closed

While the Genny was/is/will be my favorite system, I was always interested by the white beauty : the PCEngine Duo R.

Thanks to a friend, I bought one years ago, before eBay…so yes, at a fair price 😉

Let be honest, it was “somewhere” on my house since then, I only plugged it 1 or 2 times to check its status.

Now that I develop on Genny, and spend half of my time fighting with the only 4 avalaible pals, my interest for the PCEngine increased over time, but not for the same reason.

Last year, I wanted to stop Genny dev, because of some personal concern with the community….but I HAD to code, it’s a real dope.

I looked at the SMS, the Lynx, the Neogeo Pocket, the GameBoy…and the PCEngine.

I moved to SMS, because sverx’s devkitSMS was looking for some love and because I found it interesting to work on the origin of Genny.

A that time, I though only HuC was available for the PCEngine and, no, sorry, coding with SmallC is not something I could do. NO.WAY!

 

Earlier this year, I learnt about CC65, a C compiler for 6502 processors, used for NES, Lynx, Atari, Apple2 and some others.

HuC6280, the PCEngine’s CPU, is a customized 65SC02 so yes, CC65 could be used to code game on PCEngine using the C language or ASM.

In fact, the PCengine is one of CC65’s target so…great !!!!

Well….yes, but no so great. PCEngine support was made to be able to build contiki on PCEngine and, while the works done is awesome, it’s not usable as-is for game development.

I made a quick hello world and, while a lot of work is required, CC65 is actually the only valid C compiler to use for PCEngine development.

 

3 months later, I’m back on it !

PCEngine | Posted by KanedaFr