Jump to content
IGNORED

Picture slideshow: Piccolo A8


rensoup

Recommended Posts

 

I've decided to put together the result of my work on my picture colorizer. What started out as a way to produce a nice looking picture for PoP turned into a more generic colorizer...

 

So here's a 19 pictures slideshow aptly named: "Piccolo A8".

 

piccoloA8_slide.png.7e45981b8bcd8a72be1f315a0b1d3fa8.png

 

Most pictures come from the C64 and were more or less faithfully converted by myself (It's not an automated process and it can actually be quite painful).

 

I've thrown in a tune by Makary played with Dmsc's music player.

 

On the technical side, it's just regular mode4 with color and PMGs changes per scanline. 

Colors can be changed mid scanline but I've never actually used it.

I planned to used PMGs changes mid scanline but I figured it would be too slow to be useful most of the time.

I also considered implementing the PMG stretch bug described by Phaeron but it felt too restrictive to be useful.

I will release the converter sometime in the future...

 

 

The cart is in Atarimax 128KB format and works in PAL and NTSC.


v1.0 piccoloA8_slide.zip

 

--------------------------------------------------------------------------

v1.1 piccolo_slide_v11.zip

 

I added 2 new pictures and removed one so the total is now 20 and the cart is almost fully used!

I also added a 2nd tune: "Pro BMX sim" by Matt Gray, turned into a pretty cool Pokey-Sid version by Emkay.

 

Edited by rensoup
  • Like 23
  • Thanks 1
Link to comment
Share on other sites

2 hours ago, Stephen said:

Nice production!  Not trying to nitpick, but the non-masked colour changes in the border really detract from the overall image quality.  Any chance of using missiles to mask the borders?

 

I know this is a problem that annoys everybody but the missiles are put to good use believe me! 

 

The most used colors are reassigned each scanline to the PF&BK to save the least used ones for PMGs.

 

Locking one of the PF to a single color would downgrade the quality... (though I've got an option for that in the converter but I' haven't tested it much).

Alternatively I could, like you said waste 1 PM but again it would make conversions harder and on top of that I made a mistake when writing the converter by not allowing PMG edit outside of the screen area.

 

Sometimes a single color is used a lot accross the whole screen and can be used as the background color.

 

Side note: when I considered implementing the PM stretch bug, it seemed that all the hardware was there to allow 8x or 16x width PMGs except for the size register which was only 2 bits. I guess the cost for adding an extra bit or 2 would have been close to 0 ? Kind of frustrating when thinking about the possibilities!

 

I blame the A8 designers?

 

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

2 hours ago, Wrathchild said:

Looks like images target PAL but the colour values aren't adjusted if running on NTSC? (generally $0x->$0x, $Fx->$2x and +$10 for $1x->$Ex)

I believe that's because NTSC user tweak their color output to match the PAL colors ?

 

I think @Faicuai once posted pictures of PoP running in NTSC on real HW with correct colors?

 

An emulator can be run in PAL or NTSC so not much point in fixing that.

 

"Works in NTSC" to me means in doesn't glitch because there's not enough frame time to play the tune or the tune plays too fast.

  • Like 1
Link to comment
Share on other sites

2 hours ago, Roydea6 said:

I really like it.  Even more so because it is in AtariMax cartridge format.  Not only useful in the AtariMax Cart, but UNO, Ultimate Cartridge, AVG Cartridge, and The CART!

I only recently looked into cart formats (because I wanted to play a nice tune while decompressing the picture) and it seemed like the only sensible choice!

 

Link to comment
Share on other sites

3 minutes ago, emkay said:

Hm. No idea what's wrong with the colors. They look like fitting to a PAL 130XE 

PAL looks perfect.  The confusion came about from the "NTSC compatible".  Poor old Scarlette is looking rather green in NTSC land.  No worries - I have several PAL machines, including my daily driver.

scarlette.thumb.png.fbe03ad75691865e8edb366687cfc459.png

  • Like 1
  • Haha 1
Link to comment
Share on other sites

54 minutes ago, rensoup said:

 

I

 

Side note: when I considered implementing the PM stretch bug, it seemed that all the hardware was there to allow 8x or 16x width PMGs except for the size register which was only 2 bits. I guess the cost for adding an extra bit or 2 would have been close to 0 ? Kind of frustrating when thinking about the possibilities!

 

I blame the A8 designers?

 

 

 

Really interesting about the GTIA is that they seemed to have a lot problems in designing it. GTIA is THE chip that is the "Upgrade" to the TIA chip of the 2600 system. 

First they weren't able to get the GTIA woking in time, so they used the CTIA instead. And, instead of keeping the 2600 features, they dropped it with the result of missed compatibility and the good features, just like sprite doubling. Also, TIA offers stable bass sounds. 

The GTIA was always THE chip to have the most attention, but it ended in an incomplete chip till the bitter end. 

Everything about the GTIA looks like a provisional chip till the final chip arrives, if you understand ;)

-only partially used registers, memory gaps.... 

If they managed to have the GTIA modes in character resolution at least... or the sound channel acting without CPU writes...

 

So little changes ... so much wasted chances....

 

 

 

  • Like 2
Link to comment
Share on other sites

54 minutes ago, rensoup said:

I believe that's because NTSC user tweak their color output to match the PAL colors ?

No, the palettes more or less are offset by a hue, except for the black.

 

e.g. PAL

 

image.png.7c7e049a3b2b3fbaa1c2dfdc435d0ad1.png

 

versus NTSC

 

image.png.527194cd27a7416e5566bb584f08d4ad.png

 

So, for example, in games ports / fixups such as Dropzone any 'poke' or table used to set colours was adjusted so they look more identical. Some recent releases also detect at runtime and adjust palettes accordingly.

So perhaps if your conversion tool chooses colours based on a palette you could adapt it to produce an NTSC version along with the PAL binary one by applying the suggested adjustment.

Then bundle those into a complimentary cart image for NTSC? 

  • Like 1
Link to comment
Share on other sites

32 minutes ago, emkay said:

 

Really interesting about the GTIA is that they seemed to have a lot problems in designing it. GTIA is THE chip that is the "Upgrade" to the TIA chip of the 2600 system. 

First they weren't able to get the GTIA woking in time, so they used the CTIA instead. And, instead of keeping the 2600 features, they dropped it with the result of missed compatibility and the good features, just like sprite doubling. Also, TIA offers stable bass sounds. 

The GTIA was always THE chip to have the most attention, but it ended in an incomplete chip till the bitter end. 

Everything about the GTIA looks like a provisional chip till the final chip arrives, if you understand ;)

-only partially used registers, memory gaps.... 

If they managed to have the GTIA modes in character resolution at least... or the sound channel acting without CPU writes...

 

So little changes ... so much wasted chances....

So many wasted chances as you say:

  • No double / triple sprites (TIA)
  • No flip sprites (TIA)
  • 16 colour chip with 9 colour registers.  Seriously?
  • Single bit could have given half-bright luminosity

Much easier to look back after 41 years and wish what could have been.  I'll never be 10% smart enough to design something like this currently, let alone back then.  I love the machine for what it was, but it's fun to wonder about what could have been.

  • Like 2
Link to comment
Share on other sites

8 minutes ago, Stephen said:

So many wasted chances as you say:

  • No double / triple sprites (TIA)
  • No flip sprites (TIA)
  • 16 colour chip with 9 colour registers.  Seriously?
  • Single bit could have given half-bright luminosity

Much easier to look back after 41 years and wish what could have been.  I'll never be 10% smart enough to design something like this currently, let alone back then.  I love the machine for what it was, but it's fun to wonder about what could have been.

 

Hm...

I was thinking of that in the mid 80s. Reading books and programming the Atari, I also was very often thinking of an 7 bit system... particular in the graphics part . 

Everything in the Atari has it's greatness. except the GTIA . The designer should have taken a serious trip around the world. So the decision to use only brightness in hires wouldn't have placed there. It's an NTSC limitation. Every other displaying system was able to show real colors there. 

 

What to say about "smartness" . I was the best in math and physics in our local school for years. Imagining the perfect circumstances...who knows ;) 

  • Like 2
Link to comment
Share on other sites

Great show and even uses one of my all time favorite POKEY tunes, excellent choice!


Regarding the borders: From what I see there are many NOP cycles left. How about using a wide playfield $3f instead of $3e and extend the playfield to the border?

  • Like 2
Link to comment
Share on other sites

5 hours ago, Irgendwer said:

At least it sounds plausible, that you weren't the best in music. ? SCNR

Well, I never claimed to be a musician at all. 

But, as it seems lately, I did the best sounding music on POKEY yet ;)

If there is enough time , people could learn everything ;)

 

If you want to discuss hat further, you know my "Nothing Special" thread.

Link to comment
Share on other sites

20 hours ago, Wrathchild said:

So perhaps if your conversion tool chooses colours based on a palette you could adapt it to produce an NTSC version along with the PAL binary one by applying the suggested adjustment.

Then bundle those into a complimentary cart image for NTSC? 

I'm using tables indeed but it's such a clunky solution to produce 2 different versions... Having 2 different sets of values inside the same executable isn't great either because the kernel loads colors in Immediate mode... it would require a table of offsets to modify every value (like emkay suggested in the other thread for fading in/out)

 

Here's a PoP screenshot taken by @Faicuai in NTSC on real HW

 

ntscpop.jpeg.bb9b5980064375ca2ff65789ee913adb.jpeg

 

Doesn't look too bad...

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

19 hours ago, Stephen said:

Much easier to look back after 41 years and wish what could have been

Of course, there's a lot of stuff that could have been done better but the PM stretch bug is just the icing on the cake, the one feature that probably costed nothing ( money, dev time )?

Link to comment
Share on other sites

19 hours ago, JAC! said:

Great show and even uses one of my all time favorite POKEY tunes, excellent choice!


Regarding the borders: From what I see there are many NOP cycles left. How about using a wide playfield $3f instead of $3e and extend the playfield to the border?

Thanks!


I thought about using WidePF but it doesn't really help...

 

Here's a picture where the converter automatically assigns the most used colors to COLBK&PF each scanline:

 

pfchanges.thumb.png.54db4229a4398c81c523a7d51442fecd.png

 

If I used widePF I would still have to fill those borders with a color and as you can see, none of them is used enough every scanline to be tied to a single color register (seems that there are registers changes that are unnecessary though... need to check that!)


I have an option to force a register to a single color but it's probably buggy because I didn't really use it as it can downgrade the picture quality. Like I've said before I prefer the bugs to be outside the picture than inside.


2nd issue is the available cycles... yes there are NOPs all over the place but for palette changes, the overscan part is where they take place.

 

When outputing a converted picture, I also output a CPU usage picture like this:

 

dma.thumb.png.244cf19bbb6836852775b09a60b972f3.png

 

The color convention is similar to the Altirra HW manual (red for PMG DMA, pink for Mem refresh, ...). The CPU instructions are inserted between the various DMAs and shown as Black for a new instruction and Dark grey for a previously started instruction. Basically 2 cycles for a LDA # and 4 cycles for a STA Abs.

 

As you can see the overscan part is often full of CPU instructions and if I used a widePF I'd be stealing even more cycles from the overscan area. Remember that on new mode lines I have no cycles available while the screen is On, so overscan is the only place where I can do palette AND PMG changes.

 

  • Like 2
Link to comment
Share on other sites

5 minutes ago, rensoup said:

Having 2 different sets of values inside the same executable isn't great either

Indeed, at runtime you wouldn't go through the overhead of checks, e.g. in a change of COLPF0 in a DLI.

Either in the program startup the immediate value would be set, or if it loaded from a table then that table would be adjusted, so a one off thing.

 

13 minutes ago, rensoup said:

I'm using tables indeed

Confusion creeping in here, you mean within you picture conversion tool used to create executables used by the slideshow? Showing PoP screenshots is something different.

 

Take Rastaconverter for example, that is given the palette to target, so if you were to compare the output of the same picture processed with a PAL or NTSC palette then you'd see the majority of register loads for colour setting follow the adjustment pattern. You have to have two versions of the executable. Similar with Avery's video tools.

 

So at its simplest, where your converter is outputting a colour value, a 256 byte lookup table could be used to adjust it before outputting. e.g.

.byte $00, $01, $02, $03, $04, $05, $06, $07, $08, $09, $0A, $0B, $0C, $0D, $0E, $0F
.byte $20, $21, $22, $23, $24, $25, $26, $27, $28, $29, $2A, $2B, $2C, $2D, $2E, $2F
.byte $30, $31, $32, $33, $34, $35, $36, $37, $38, $39, $3A, $3B, $3C, $3D, $3E, $3F
.byte $40, $41, $42, $43, $44, $45, $46, $47, $48, $49, $4A, $4B, $4C, $4D, $4E, $4F
.byte $50, $51, $52, $53, $54, $55, $56, $57, $58, $59, $5A, $5B, $5C, $5D, $5E, $5F
.byte $60, $61, $62, $63, $64, $65, $66, $67, $68, $69, $6A, $6B, $6C, $6D, $6E, $6F
.byte $70, $71, $72, $73, $74, $75, $76, $77, $78, $79, $7A, $7B, $7C, $7D, $7E, $7F
.byte $80, $81, $82, $83, $84, $85, $86, $87, $88, $89, $8A, $8B, $8C, $8D, $8E, $8F
.byte $90, $91, $92, $93, $94, $95, $96, $97, $98, $99, $9A, $9B, $9C, $9D, $9E, $9F
.byte $A0, $A1, $A2, $A3, $A4, $A5, $A6, $A7, $A8, $A9, $AA, $AB, $AC, $AD, $AE, $AF
.byte $B0, $B1, $B2, $B3, $B4, $B5, $B6, $B7, $B8, $B9, $BA, $BB, $BC, $BD, $BE, $BF
.byte $C0, $C1, $C2, $C3, $C4, $C5, $C6, $C7, $C8, $C9, $CA, $CB, $CC, $CD, $CE, $CF
.byte $D0, $D1, $D2, $D3, $D4, $D5, $D6, $D7, $D8, $D9, $DA, $DB, $DC, $DD, $DE, $DF
.byte $E0, $E1, $E2, $E3, $E4, $E5, $E6, $E7, $E8, $E9, $EA, $EB, $EC, $ED, $EE, $EF
.byte $F0, $F1, $F2, $F3, $F4, $F5, $F6, $F7, $F8, $F9, $FA, $FB, $FC, $FD, $FE, $FF
.byte $20, $21, $22, $23, $24, $25, $26, $27, $28, $29, $2A, $2B, $2C, $2D, $2E, $2F

So if, in PAL, you were to output $E4, then this would now output $F4 instead for NTSC.

If you can give that a try then I believe these two images (PAL left) should look more close.

 

image.thumb.png.296ae58cdb9f0f4e52bc717e4cc10087.png

Link to comment
Share on other sites

On 10/1/2020 at 9:05 PM, Wrathchild said:

Confusion creeping in here, you mean within you picture conversion tool used to create executables used by the slideshow? Showing PoP screenshots is something different.

 

Take Rastaconverter for example, that is given the palette to target, so if you were to compare the output of the same picture processed with a PAL or NTSC palette then you'd see the majority of register loads for colour setting follow the adjustment pattern. You have to have two versions of the executable. Similar with Avery's video tools.

When I said I'm using tables I meant palette files, I'm actually using the RC palettes and also the Altirra default PAL palette:

 

palettes.png.1f032b4d1e168b1e2e57bdb14a1b870d.png

 

 

Any number of them can be selected. The final color will the be the one with the smallest sum of the distances in YUV space. 

 

Usually I use the config above as it seems to give slightly better results than just using one of them. Though sometimes I just use Altirra or Laoo. 

 

I could just add an entry for NTSC and use the default Altirra NTSC palette and that would work... but having 2 carts is just a lazy solution.

 

The runtime solution would require a table with potentially hundreds of entries (3 bytes per entry), so I'd be looking at up to 1KB of extra storage... not great but a bit less crappy.

 

 

The screenshot I posted come from PoP which only exists in PAL but still looks good in -this- NTSC setup... I may just have been lucky and perhaps an intro picture wouldn't look as good. 

 

So I haven't decided yet... For now I'm focused on adding the code to load/display piccolo picture in PoP which is proving to be quite annoying 

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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