Author Topic: My Absurd Demos from the 90s  (Read 481 times)

0 Members and 1 Guest are viewing this topic.

Offline AMSDOS

  • Supporter
  • 6128 Plus
  • *
  • Posts: 3.504
  • Country: au
    • index.php?action=treasury
    • Programs for Turbo Pascal 3
  • Liked: 759
My Absurd Demos from the 90s
« on: 08:14, 27 October 18 »
Back in the 90s I was putting together game discs and writing my own little Menus to select the game, though along with that Menu I also had a little demo. Sometime ago I transferred some of those from disc to disk image and came across a couple a few weeks ago and decided to update them :D



They aren't going to set the world on fire in terms of tricks there's no Rasters or Overscan or Split Modes, I did make one little Demo back then which used a program from AA17 Type-ins to split the Colours midway across the screen, though haven't included it here.





Police Car Demo

The original program is called CAR.BAS, which is a BASIC stub file (a file with BASIC followed by MC routines), back when I made it, I was using the Spriting Back Utility which was on the AA106 Covertape, which had it's own Sprite Designer. The idea with it was to draw a rectangle around the sprite and set it to 0 or whatever the background colour was, so it would wipe the Sprite as it moved. Apart from that the routine has it's own guide to how to set coordinates across the screen, I must of known how it work back then because it's quite different to Sean McManus' ESD Advance for example. The other feature of this demo is the Screen I made back then, I probably made it with the early GPaint from the AA80 covertape and then I used the early version of Colombia to compress the screen, which is what you can see in operation onscreen when CAR.BAS is initially RUNning.





Updated BASIC Version

It's still using the Spriting Back Utility from the AA Covertape, though I decided to use BASIC to draw the screen, the hardest part is the nature strip, I had to come up with a simple way of checking both sides of the curve and use MOVE and DRAW to fill those two points in, thus creating a simple FILL routine, I wasn't sure how good it would be, so I straightened out the angled edges, which left me with a bit of line to draw at the end, though generally speaking the general idea is there even if the median strip is slightly different. For the red dots to be placed in the centre of the Grassy area, it was simply a matter of working out Random Values between the 2 Points again, though use some conditioning when the Median Strip changed so it would remain within. Overall, I was happy with the result. The resulting program is called PATROL.BAS


Coding in Hisoft Pascal

From the BASIC version, I was able to come up with a Pascal equivalent, though I've been using Sean McManus' Easi-Sprite Driver Advanced, so I had to convert the sprite so it had dimensions and also changed the sprite to XOR, which means a Border isn't necessary. Since it's only a single Sprite, I also used Hisoft Pascal to build the Graphic up in sets, so the whole program handles everything from within. The most noticeable change between this and the BASIC version is obviously going to be the FILL routine, from the compiled environment it looks similar to the BASIC 1.1 FILL. The resulting Compiled Program being in PATROL.BIN


Police Cars aren't White!

Well maybe not now, but back in the 90s they were, well I suppose some still are here in Australia, a Highway Patrol car perhaps isn't, this looks more like your little Suburban Car doing it's rounds!  :D 







The Cliff Man!

I never really had a title for this, it's simply a little Viking Character I drew up myself charging from one side of the screen to the other, with a Cliff in it's Path. Back when I wrote it I had no concept of Array's so no check routine to check when he should drop, I haven't complicated things by adding one either and have just stuck to the old true method of Drawing this character so far before having them drop, this demo really shows how well my Animation sequencing works and even now it's a simple 2 sprite approach. Like my 1st Demo, this also used the Spriting Back Utility and with again Invisible Box placed around.




I updated again using ESD Advanced with Hisoft Pascal just to see how well the Animation with a Background in play would perform, was also an opportunity to use the simple mask pattern generator to draw a background, however while I was in the process of using it, I found a bug which relates to when the position changes (from the left side of the screen it works perfectly fine, but offsetting the x-coordinate and problems begin to emerge, the solution which I hadn't done in my BASIC example was to add X to the Final value from within the FOR loop, thus correcting that), in this demo the pattern shifts when the 1st lot of ground on the left side is found and needs to follow down to the displaced ground that the Viking Falls down to. Overall again I'm happy with the result.  :D




« Last Edit: 08:19, 27 October 18 by AMSDOS »
* Using some of the hardly used Amstrad compilers :D
* I use Firmware in my Assembly code :P
* Have interpreted some BASIC 1.1 programs for BASIC 1.0. :)

Offline AMSDOS

  • Supporter
  • 6128 Plus
  • *
  • Posts: 3.504
  • Country: au
    • index.php?action=treasury
    • Programs for Turbo Pascal 3
  • Liked: 759
Re: My Absurd Demos from the 90s
« Reply #1 on: 12:08, 27 October 18 »
Had a bit of a read up on the Spriting Back Utility from the AA106 Covertape Page, it appears Simon Forrester was going to write a followup article about it, though it appears it never eventuated. It's been setup though for someone new to Sprites and looking to add Sprites into a simple program. The Coordinate system is setup to be quite broad though, it's not a true Text Coordinate system, although in a sense it's setup as a grid 80 squares across (equivalent to MODE 2), 50 squares down, which would make that every 8 pixel lines, which when running in conjunction with my earlier Demos is the reason why the Sprites Move quickly across the screen.
* Using some of the hardly used Amstrad compilers :D
* I use Firmware in my Assembly code :P
* Have interpreted some BASIC 1.1 programs for BASIC 1.0. :)

Offline Gryzor

  • Administrator
  • 6128 Plus
  • *****
  • Posts: 14.698
  • Country: gr
  • CPC-Wiki maintainer
    • CPCWiki
  • Liked: 2769
Re: My Absurd Demos from the 90s
« Reply #2 on: 16:34, 01 November 18 »
Thanks for sharing :)

Offline AMSDOS

  • Supporter
  • 6128 Plus
  • *
  • Posts: 3.504
  • Country: au
    • index.php?action=treasury
    • Programs for Turbo Pascal 3
  • Liked: 759
Re: My Absurd Demos from the 90s
« Reply #3 on: 11:42, 08 December 18 »
Something's been bugging me about my Cliff Man! Demo unfortunately which I compiled using Hisoft Pascal, CLIFFMAN.BIN
This demo was posted on CPC-Power, but in one of the screenshots bits of my Character were missing, so I played around with CTRC settings in Winape and CPCBox and found different CTRCs settings were having an impact of the result as well as my Sound Routine. Everything seems to work as it should when Type 0 CTRC is used, but Type 1 & 2 seem to be running the demo faster as well as showing the top portion of my Sprite while it's on the Top Platform, when in Freefall, the Sound commences but doesn't cease when the Sprite reaches the Bottom Platform (that's what occurred while I was playing around with it in Wiinape). Ok, perhaps I shouldn't be poking around with CTRC settings and I should only have it on 0 for emulating 464, though I'm mighty confused since I've setup Winape to emulate a 464, I'm unsure what I'm meant to have for it (CTRC wise), though I got the impression it depends on when that 464 was built, which leaves me concerned that my demo may look good on some real computers, but crap on others. I'm also confused because after reading the CTRC guide, it details stuff which I'm not even using, so like why for example is sound performing correctly for one CTRC, but wrong on others when all I've made is a simple Firmware Sound Queue which waits until the no carry (nc) is true?
* Using some of the hardly used Amstrad compilers :D
* I use Firmware in my Assembly code :P
* Have interpreted some BASIC 1.1 programs for BASIC 1.0. :)

Offline mr_lou

  • 6128 Plus
  • ******
  • Posts: 2.745
  • Country: dk
    • index.php?action=treasury
    • 8-bit Memoirs - a Blu-ray diskmag-like eBook about the 8-bit era
  • Liked: 958
Re: My Absurd Demos from the 90s
« Reply #4 on: 15:22, 08 December 18 »
Not sure how I missed this thread first time around.

Looks very nice! Great material for an 8-bit Memoirs story.  ;)

Offline andycadley

  • Supporter
  • 6128 Plus
  • *
  • Posts: 794
  • Liked: 348
Re: My Absurd Demos from the 90s
« Reply #5 on: 15:27, 08 December 18 »

CRTC differences seem unlikely to make any noticeable difference in anything like this, it's almost always when you're pushing the limits when it actually matters. It's possible if you're trying to read various CRTC registers that you'll get different results, but again that seems unlikely as there would be little reason to do so.

Offline AMSDOS

  • Supporter
  • 6128 Plus
  • *
  • Posts: 3.504
  • Country: au
    • index.php?action=treasury
    • Programs for Turbo Pascal 3
  • Liked: 759
Re: My Absurd Demos from the 90s
« Reply #6 on: 04:58, 09 December 18 »


Not sure how I missed this thread first time around.


Looks very nice! Great material for an 8-bit Memoirs story.


Sadly I don't advertise my materials very well and after presenting these Demos I move onto something else to code.
What got me concerned was after I noticed a Screenshot on CPC-Power of "The Cliff Man!" demo with bits of the Main Character missing (mainly the bottom half). I played around with it on CPCBox as well as Winape and the output looks great when CRTC 0 is using it, but terrible is it's anything else.

CRTC differences seem unlikely to make any noticeable difference in anything like this, it's almost always when you're pushing the limits when it actually matters. It's possible if you're trying to read various CRTC registers that you'll get different results, but again that seems unlikely as there would be little reason to do so.



I would generally agree, unfortunately I transferred the demo to my 6128 and the results from that weren't good. I made a video of it as poor in quality as it is, the character is invisible along the top in the 1st few frames until it reaches that falling position, at the 18 second mark the character is visible along the top platform which is blinking. At one point after exiting the demo with ESC and running at the RUN (y/n) prompt again, the character was doing something like the emulators were doing after altering to CTRC 1 & 2, printing the top portion of my character with gradual flashes of it's body and legs. The sound is also out, which is meant to cease when my character reaches the bottom ground, the Video from my 6128 also confirms this isn't the case :(  I tested this out earlier to see if it was a Firmware 1.0/1.1 thing occurring, but found that using an emulated 6128 with CTRC 0 was no different to emulated 464. Sadly I don't know what CTRC my 6128 is using guessing it using either 1 or 2, on one occasion while using CPCBox with CTRC 2 after exiting and running a couple of times the program was performing correctly.
So I can only guess that if there's nothing in my code which should affect it, then perhaps Hisoft Pascal is doing something during initialisation phase?
* Using some of the hardly used Amstrad compilers :D
* I use Firmware in my Assembly code :P
* Have interpreted some BASIC 1.1 programs for BASIC 1.0. :)

Offline andycadley

  • Supporter
  • 6128 Plus
  • *
  • Posts: 794
  • Liked: 348
Re: My Absurd Demos from the 90s
« Reply #7 on: 22:58, 10 December 18 »

The character being invisible near the top of the screen is almost certainly a result of the background graphics being restored before the "sprite" is being drawn. The raster beam is updating the display before the code gets around to printing the sprite, so it just draws what is in the video memory at that time which happens to be the background pattern.


You can see this happening in WinAPE if you slow emulation right down to like 10% speed, on some frames the sprite isn't entirely there at the point the screen is drawn (this is where the flicker comes from you can see at normal speed). Additional ROMs or Firmware /BASIC revisions may well also magnify this effect to some degree because they're potentially running more code as part of the frame flyback interrupt than a stock 464. FWIW switch CRTC in WinAPE doesn't really seem to make any noticeable difference to me regardless of which CPC I have WinAPE set up as (and I wouldn't expect it to).


The sound issue is stranger, but it's possible Hisoft Pascal does something odd somewhere along the way that doesn't work all the time or that gets upset by some other combination of ROM/firmware in an unexpected way.