C16 Plus4 code into A8 and vice-versa

[José Pereira]

Is it simple and quick to a 6502 coder transfer/run a bitmap mode 4colours static screens and software sprites game between the two machines just changing adresses (the Plus4 with same 64KBs)?

[Rybags]

I've done a couple of conversions from Plus4 to A8.

 

Quadrillion (to VBXE) was from the source code. VBXE is able to do blit conversion of bitmap graphics on the fly since Plus4 bitmap is like C64, ie char cell based where A8 is scanline based. VBXE also takes care of colour map which A8 normally doesn't have.

 

Spectipede I did from a raw dump of memory which I generated source from. This was actually easier and I had it going in a couple of hours mainly due to it being a fairly simple game. Although again the game relies on VBXE to provide all the features like extra colour but also runs fine on a standard machine.

 

Main differences of Plus4 vs 64K Atari:

- memory mapping different of course. Plus4 allows practically all 64K to be accessed where Atari has a 2K memory hole which can't be gotten at.

 

- Atari has PMGs, Plus4 has no such feature. Generally this creates a problem only if wanting to port from A8 -> Plus4.

 

- Bitmap graphics mapping is char cell based like C64 on Plus4, raster based for Atari. This is one of the biggest gamechangers. A game doing softsprites in bitmap mode will need significant rework for porting either way.

 

- Colour mapping. Atari doesn't have this, to a degree it could be fudged with PMGs or just run the game with reduced colour content or in some cases use DLIs for colour changes.

 

- 256 chars vs 128. Another big hurdle. Many Plus4 games are char based and heavily use redefined chars since there's no sprites. I got lucky with Spectipede, the movement is all cell based rather than granular and character usage fairly low.

 

- OS. Mainly would be a hurdle A8 -> Plus4 since Atari's OS provides many functions mainly in VBI which games rely on.

 

- Sound. Plus4 only has 2 channels but since the master clock is the same on both machines, a simple algorithmic formula means we can convert Plus4 frequencies to run on 16-bit Pokey channels. Plus4 only has 2 channels with pure tone or "noise", the noise is reasonably close to what Pokey is able to generate.

 

 

For simple 2 or 4 colour static screens. It's just the bitmapping sequence that needs reordering. A simple program that does a pick/place operation can convert these screens.

Naturally though, either machine is like at least 20 times too slow to be able to do this on the fly with a game, not to mention you'd be doubling the graphics Ram requirement.

[José Pereira]

I know that their Multicolour Bitmap Mode is like C64 but it's two common colours for all screen and two different possible in each cell/char.

But wich bit-pairs are the common and wich are the different ones?

 

And in Multicolour Char Mode is it like C64 with only one different colour per char that is [11]?

 

Just two last questions:

Does they have a different colour register for the Borders like C64 or it is the same as us on ANTIC4/5 bit-pair [00] that is one of their common colours for all the screen?

And their screen size is always [40Bytes x 200scanlines]?

[Rybags]

The bitpair assignment is inconsequential, as simple as a pic can be remapped the bitpair assignments could also be changed.

 

Text multicolour mode allows either hires or multicolour per cell like C64 does. Plus4 has a distinct seperate border colour like C64.

 

Screen architecture is somewhat fixed but hardware exploits have allowed tricks like H/V overscan and interlace to double vertical resolution. However, overscan tricks can be CPU intensive and cause Pal/NTSC incompatabilities.

Quite a few demos use hardware exploits for graphics trickery but not many games.

 

Forgot to mention earlier - the available colours themselves are different. Plus4 palette of 121 colours has entire different mapping vs Atari. The colours although only allowing 8 luma levels do have a better saturation level than Atari so look more vibrant.