Images generated by RastaConverter

[+Philsan]

Thank you!

 

The monitor is a 1084ST (post-Commodore but before Escom), you can read its specs and download manual here: https://gona.mactar.hu/Commodore/monitor/Commodore_monitors_by_model_number.html

 

I loaded SpideyStatue two more times and the line error isn't there. Who knows what happened the first time I loaded it...

 

EDIT

Loaded it again and it appeared two times...

[Beeblebrox]

6 minutes ago, Philsan said:

Thank you!

 

The monitor is a 1084ST (post-Commodore but before Escom), you can read its specs and download manual here: https://gona.mactar.hu/Commodore/monitor/Commodore_monitors_by_model_number.html

 

I loaded SpideyStatue two more times and the line error isn't there. Who knows what happened the first time I loaded it...

Thanks. Very stange re the line error disappearing.  Do you have a stock 800XL running these just out of interest?

[+Philsan]

Just now, Beeblebrox said:

Thanks. Very stange re the line error disappearing.  Do you have a stock 800XL running these just out of interest?

Loaded it again 4 times and line appeared again.

800XL with U1MB (320KB RAMBO memory expansion selected but test with 64KB too); loaded from my PC with FujiNet. I will do more tests.

[ivop]

26 minutes ago, Beeblebrox said:

I know that Altirra will sometimes not show these errors

If you have a sample file that shows the error on real hardware, but not in Altirra, I'm sure @phaeron would be very interested in that particular file.

[Gunstar]

Some fantastic conversions there @Beeblebrox. Welcome back.

[Beeblebrox]

25 minutes ago, Gunstar said:

Some fantastic conversions there @Beeblebrox. Welcome back.

@Gunstar Thanks, much appreciated. I have amassed quite a few of your amazing images over the last month from this listing.

[Beeblebrox]

38 minutes ago, ivop said:

If you have a sample file that shows the error on real hardware, but not in Altirra, I'm sure @phaeron would be very interested in that particular file.

@ivop Hi - sure - Currently I don't have access to my Atari's so I only have Altirra to view them on each time I convert. @Philsan has been experiencing a line error on his 800XL with the following image as per his earlier post but it isn't consistently displaying. (A dark line on one of the eyes showing up on real hardware sometimes, but never on Altirra)

spideystatue1croppedsmincomplete9.xex

[+Philsan]

I loaded the file again (I attach it) and no line defect in the right eye.

 

But... after some minutes... line appeared!

 

I tested another 800XL, stock, and after some minutes... the line appeared too!

If necessary I can test other machines.

 

Beeblebrox_SpideyStatue.xex

[Beeblebrox]

1 hour ago, Philsan said:

I loaded the file again (I attach it) and no line defect in the right eye.

 

But... after some minutes... line appeared!

 

I tested another 800XL, stock, and after some minutes... the line appeared too!

If necessary I can test other machines.

 

Beeblebrox_SpideyStatue.xex 22.08 kB · 2 downloads

Go for it - very strange. 

[drpeter]

4 hours ago, Philsan said:

Thank you!

 

The monitor is a 1084ST (post-Commodore but before Escom), you can read its specs and download manual here: https://gona.mactar.hu/Commodore/monitor/Commodore_monitors_by_model_number.html

 

I loaded SpideyStatue two more times and the line error isn't there. Who knows what happened the first time I loaded it...

 

EDIT

Loaded it again and it appeared two times...

 

This is an edge case in the timing pipeline of ANTIC/GTIA for generating PMGs.

 

As explained in the attached tutorial (an update of one I posted earlier in this forum) these artefacts occur in very specific circumstances where a player position is changed just before it is about to be displayed.

 

Usually, there is a 5 machine-cycle window in which this can occur, but clearly on some machines, and at some chip temperatures, this is extended to 6 machine cycles- which, having looked at the disassembled kernel, is what is occurring in this case....

 

 

Tutorial Walkthrough_Ver2.docx

[drpeter]

I have edited the kernel to (hopefully) remove said artefact even on 'misbehaving' machines. I'd be grateful if someone able to run it on 'misbehaving' real hardware can confirm it is fixed

spideystatue1croppedsmincomplete9_mod_PB.xex

[Faicuai]

1 hour ago, drpeter said:

As explained in the attached tutorial (an update of one I posted earlier in this forum)

Really, really nice !!!

 

Could hardly think of a better (applied) example that illustrates so many concepts and moving parts stitched together, all at once.

 

Did not see it before, so... plenty of (good) reading to do, now... 

[drpeter]

16 hours ago, Rybags said:

I'm fairly sure they should work fine on a 48K Ram older system, just make sure no cartridge is present and use a compatible Dos or menu loader.

 

Stephen's IK+ pic worked fine on an emulated machine for me...Stephen_IK.xex

The Rasta executable starts just above $2000 (8K boundary), so DOS, loaders etc. need to be loaded below that, or above 36K (see below)

$2000->$5800 (22K boundary) is the screen bitmap data, display list and player data.

The kernel is from $5800 upwards- generally it's ~12K, so maybe to $8800 (34K) or $9000 (36K) at a push.

The executable does write PORTB to activate full 64K of RAM in the XL/XE lines, but that shouldn't cause an issue with 400/800 hardware (although obviously you won't get 64K RAM) and as can be seen from memory map above, even 40K should be ample to load & run a Rasta .xex

Edited May 19, 2021 by drpeter

[drpeter]

It would be interesting if all those observing this artefact on the original Spiderman statue xex could report the model & year, and whether it happens every time or only when the chips have warmed up.

 

I suspect it's a batch of the later GTIA chips that are causing this 'non-standard' behaviour when they warm up...

 

@phaeron can then include this non-standard behaviour in the next edition of the Altirra Hardware Reference Manual -and possibly even include an option in Altirra to emulate it...

 

I wonder also if it only happens with Player 3 (as in this case), or other players too, and whether the player is also displayed a colour-clock 'late' or 'early' (i.e. to the right or left) after the chip has warmed up...

Edited May 19, 2021 by drpeter

[Beeblebrox]

@drpeter  - thanks for the explanation and tweak - (I had downloaded your tutorial last month and planned to read it at some stage). 

Thanks everyone else re your input - it's facinating to see you guys at work. Will be interesting to see how the tweaked file displays on your Atari hardware's. I didn't appreciate that the quirks of individual Atari hardware/GTIA chip temperature could have such an effect - makes sense.

 

Incidentally I have a general question that ya'll may be able to answer.

 

I have seen in the past that XEX and ATR files for Rasta convereted images have had music linked to them which runs when the files are launched.

 

One of my fav games (one I used to play on my mate's Amiga BITD) was a vertical shooter called Battle Squadron . (I suspect it needs no introduction. I still remember the adrenaline as the game loaded between levels and loved the weapon upgrades, bombing mechanics and dual co-op play mode). I have already converted the original splash screen for it, although I am not happy with the colours (too purple),  so plan to do a re-run later this week.

 

However one of the key things with the game was the amazing soundtrack.

 

To my surprise/delight I happen to come across a recent rendition of it (see Youtube vid posted below) by Emkay which sounds amazing coming from the pokey chip - it took me right back!  I am pretty sure ya'll know but it's a new experimental format by rensoup (Prince of Persia savior)  where it's being decompressed real time.

Vinscool had also be working on the track:

 

My thinking was that at some stage  - and with Emkay's blessing of course, it would be great if this music track was merged with the Battle Squadron splash screen Rasta image once generated.

 

My question is: Can the Atari cope with simultaniously running of this new format music track whilst displaying the Rasta image with all the computational power the latter requires?

 

Check out the tune - it's a faithful rendition - I am 14 again blastin the hell outta swarms of alien scumm - heh heh :

 

 

I am looking forward to playing the new release of The Last Squadron which has shades of Battle Squadron gameplay. 

Edited May 19, 2021 by Beeblebrox

[drpeter]

For those taking an interest in the 'coming and going' artefact, I attach a test image and Rasta file which clearly demonstrates the 'canonical' behaviour when run in Altirra.

 

The black bands appearing across the players (in sequence Player 0- orange, Player 1- pink, Player 2- mauve, Player 3- light blue) are caused by the artefact.

 

The vertical level, as indicated by the numeric scale on the left, shows how many colour-clocks GTIA needs from writing HPOSPx to the display of the player - 5 in this 'canonical' case for every player.

 

The vertical 'tramlines' exactly aligned either side of the players on the bottom half of the screen demonstrate that the players are appearing in the correct horizontal position.

 

Feel free to try this on your own hardware, starting from cold and after the GTIA has had time to warm up, and report back, ideally with model & year of manufacture...

 

drpeter_Artefact_Test.xex

Edited May 19, 2021 by drpeter

[+Philsan]

After two 800XL, I tested Spidey picture with a 130XE.

I had to wait more, circa 20 minutes, and the line in the eye appeared.

 

Regarding @drpeter test image, after 30 minutes nothing changes:

 

 

 

 

[drpeter]

1 hour ago, Philsan said:

Regarding @drpeter test image, after 30 minutes nothing changes:

Interesting...

Perhaps the reason for this is more subtle than a simple extension of both the trigger delay and the 'too late to write HPOSPx' window to 6 machine cycles...

I'll have to give this more thought, to see how it can be flushed out...

[drpeter]

PS @Philsan, am I correct that the modified Spiderman xex I posted above no longer shows the artefact on any of your machines, after any wait?

[a8isa1]

9 hours ago, drpeter said:

For those taking an interest in the 'coming and going' artefact, I attach a test image and Rasta file which clearly demonstrates the 'canonical' behaviour when run in Altirra.

 

The black bands appearing across the players (in sequence Player 0- orange, Player 1- pink, Player 2- mauve, Player 3- light blue) are caused by the artefact.

 

The vertical level, as indicated by the numeric scale on the left, shows how many colour-clocks GTIA needs from writing HPOSPx to the display of the player - 5 in this 'canonical' case for every player.

 

The vertical 'tramlines' exactly aligned either side of the players on the bottom half of the screen demonstrate that the players are appearing in the correct horizontal position.

 

Feel free to try this on your own hardware, starting from cold and after the GTIA has had time to warm up, and report back, ideally with model & year of manufacture...

 

drpeter_Artefact_Test.xex 18.29 kB · 7 downloads

On my 1981 NTSC 800 the line appears at marking 6, whether cold or warmed up. 

 

My 800XL cases and motherboards have been swapped so many times I cannot say the age of the system.   Current incarnation has a second revision NTSC Antic if that matters.  Line always appears at marking 5.

 

Regards,

 

SteveS

[drpeter]

PPS @Philsan, I wonder if when you have a moment you could try this revised test xex on your misbehaving machines!

Sorry, it's very difficult to do this when I have no hardware to test it on.

 

Here I have tried to reproduce as closely as possible the kernel code that seems to cause the problem in the Spiderman picture.

 

If the fault occurs in the same way, something weird should happen to the rightmost of the two pale blue blocks mid-left of the screen- probably that it just disappears (except for possibly the top line)...

drpeter_Artefact_Test_2.xex

[drpeter]

3 minutes ago, a8isa1 said:

On my 1981 NTSC 800 the line appears at marking 6, whether cold or warmed up. 

 

My 800XL cases and motherboards have been swapped so many times I cannot say the age of the system.   Current incarnation has a second revision NTSC Antic if that matters.  Line always appears at marking 5.

 

This gets more and more interesting...

[drpeter]

7 minutes ago, a8isa1 said:

On my 1981 NTSC 800 the line appears at marking 6, whether cold or warmed up. 

 

Any chance you could send a picture, ideally good enough to show scanlines?

[rensoup]

17 hours ago, Beeblebrox said:

To my surprise/delight I happen to come across a recent rendition of it (see Youtube vid posted below) by Emkay which sounds amazing coming from the pokey chip - it took me right back!  I am pretty sure ya'll know but it's a new experimental format by rensoup (Prince of Persia savior)  where it's being decompressed real time.

Vinscool had also be working on the track:

Glad you like that BS tune, it's also one of my favourite tunes, and Vinscool's cover is my favourite A8 cover ever ?

(and also covered at my request ?) It runs at 100Hz but can be converted down to 50Hz easily with RMT2LZSS with minimal loss.

17 hours ago, Beeblebrox said:

My question is: Can the Atari cope with simultaniously running of this new format music track whilst displaying the Rasta image with all the computational power the latter requires?

You bet... the LZSS player is much faster than RMT so if RMT can be played, it's no problem either for LZSS. I don't know if anyone did RC + LZSS though I know @pps did a G2F + LZSS app.

 

Any volunteer ?

[a8isa1]

57 minutes ago, drpeter said:

 

Any chance you could send a picture, ideally good enough to show scanlines?

Sorry, no scanlines.   My display these days is limited to a pretty basic and now old scan converter and a low end VGA 4:3 LCD. Scanlines get filtered out.

 

These are the best pictures I can manage.

 

 

 

 

 

 

 

Edited May 19, 2021 by a8isa1