@Hammer

Quote:

Hammer wrote: @cdimauro Quote: I don't follow the demo scene, because I don't like them (yes, it was OK to watch some demo from time to time, but definitely not that much interesting). Demos are a big source of incompatibilities because of the stupid idiots that coded them doing tricks against the guidelines. I don't know if there exist some demo which is fully compliant with the guidelines, but if yes then kudos to the coders! I use the demo scene to check software legacy support.

It's up to you. I prefer games and applications.
Quote:

Quote: No, it was because we wanted to squeeze the most from the system. Primarily for the memory (which wasn't that much). Secondarily for the performances. Custom disks were also used because they allowed to pack more data on a single track. 12 sectors per track were easily achievable. My custom loader pushed it to 12.25 (12 x 512 bytes + 1 x 128 bytes sectors). Anti-piracy measures included the practice of distributing software on disks that contained secret "keys" on high-numbered tracks that were officially unused. The Amiga disk drive officially supported tracks 0–79 from a double-density disk, but could actually read tracks 80 through 82. Standard disk-imaging software ignored these tracks, so that a duplicate of a boxed disk would not contain the key and the software would not work.

It was normal on Amiga to copy all tracks from the game's discs, included the ones above the standard 80 ones. A protection relying only on this was too easy to con.

And keys didn't need to be stored on the extra, non-standard tracks: something else was possible.
Quote:

Turrican 2 is not extended tracks, but it uses long track copy protection. Long tracks have more data written to them than is normal for a standard Amiga format. This is why some cracked versions of long-track protected games came on more disks than legitimate copies.

Indeed. But long tracks weren't non-standard: they were perfectly "legal" according on how disk drives worked. It was a nice way to both store much more data and protect the game while being sure that the game was working on all Amigas.
Quote:

Quote: In fact it was enough to: - query & set the graphic mode; - get the linear address to the frame buffer; - set the CLUT. This could be achieved without incompatibilities DOS Duke Nukem 3D's VESA/SVGA 640x480 mode is broken on modern EVGA GeForce GTX 980 Ti GPU's VESA 3.0 implementation https://youtu.be/bS9hiSwL1KY?t=490

I don't expect many modern cards to fully support VESA, since it's a too old standard. So, this might happen.

Nevertheless, games used VESA because it was a standard and it was reliable. In fact, Duke Nukem 3D used it, as you can see...


@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @cdimauro Quote: don't know if there exist some demo which is fully compliant with the guidelines, but if yes then kudos to the coders! Well two demos’ groups come to mind. Elude & Decadence, everything else is just crap as you say. If you really, really want things to work on everything, it’s not easy, I see OS4 demos breaking because of wrong resolution or image format, ARGB or BGRA, RAGB some graphic drivers / resolutions don’t give you what you expect, not carefully checking what it is, will break sh*t. where did the 15bit go, no one knows, 24bit was replaced by 32bit. Many demos don’t know what 16bit is. Kind of problem you run into when trying to run newer demos from late 99’s and early 2000’s, they do support RTG but wrong resolutions and modes.

So, same story: demos continued to be done slapdash even on post-Amiga systems...


@kolla

Quote:

kolla wrote: @cdimauro Any modern demo in particular that you find is breaking the guidelines?

It's so long now which is difficult to recall all details. I roughly remember that when I've added the Kickstart 2.0 on my Amiga 2000 then some demo stopped working. And when I switched to my Amiga 1200 then it was bloodbath.

Actually the one which I recall having problems was State of the art, because it required slow memory. So, not playable on my Amiga 1200 even with 2MB of memory available. This I remember only because it's one of the most famous demo on Amiga.
Quote:

It’s typical a compo rule that demo must exit cleanly.

Usually demos were like games: they booted from the floppy and killed the o.s.. So, no soft exit to the o.s. when they finished.
Quote:

I find it much more annoying with productivity software that “plays dirty”,

Absolutely.
Quote:

but I can understand why it was done, as differences in performance between “correct” and “dirty” can be formidable and a matter of whether the software is at all useful or not.

I beg to differ: a software could be correct AND having very good performance. Good practices don't hurt performances even when directly banging the hardware.

@Hypex

Quote:

Hypex wrote: @Karlos That sounds pretty good. How was the sequencer controlled? And where did the synth send the audio?

Are you talking about the PHP demo engine? I create a process for Sox or APlay and pipe the audio as it's generated into it.

As for generation of the audio, I use a packet approach. Rather than have something constantly generating streams of packets and mixing them down, I work backwards from the output. I ask the mixer for a packet of audio, it asks each of its inputs and mixes them. The inputs in turn may have other inputs and so on until you hit a final leaf, which is usually an oscillator of some kind. I like to think of it as being like the trunk of a tree, drawing water up from increasingly more dendritic roots.

Ultimately the whole thing is modular (in the modular synth sense) with oscillators, envelope generators, filters etc. and I've made several preset machines out of these. There's an analogue drum machine, a simple chiptune machine, a two oscillator subtractive synth, a fixed 2 operator FM synth and a 2-8 operator FM synth (matrix modulation and different waveforms allowed).

The sequencer is a specialised unit but it will works this way. It effectively thinks of the event timeline in terms of the nearest output packet position and calls the various control methods of all the units when it reaches them.

Ultimately working backwards this way allows for a reduction in calculation not unlike tracing rays backwards from the observer in ray tracing.

_________________
Doing stupid things for fun...

@cdimauro

Quote:

It's up to you. I prefer games and applications.

Besides the MMU and FP80 issues, Amiga 68K software that can run on DraCo is easier to support.

On real 68K or PiStorm, there are issues with existing software such as Deluxe Music 2 or Bars and Pipes doesn't play when SoftSynth/CAMD/GMPlay is active. Horny MIDI sequencer works with
SoftSynth/CAMD/GMPlay. I configured TiMidity (Amiga port) with GUS patch samples to exploit 68060 and PiStorm increased compute power.

68060 @ 62.5 Mhz (similar to Pentium 60) can struggle with TiMidity and Quake.

On Pentium 166 to Celeron 300A era, I used S-XG50 (Yamaha SoftSynth) to exploit Pentium P54 /Pentium II era compute power.

I still use Cakewalk SONAR and recently Cakewalk by BandLab with VSTi (Arakula VSTi to driver bridge) S-XG50 or physical Yamaha DGX-640 with my current gaming PCs.

In terms of my high bit-rate MP3/MPEG video/SoftSynth/Quake/Quake II usage, PiStorm/Pi3a/Emu68 for Amiga 500 is similar to Pentium II 266/Celeron 300A-based PC.

GLQuake, Quake II GL, and Quake III require OpenGL acceleration and my Celeron 300A had NVIDIA TNT. This is where AmigaOS 4.1 with Radeons PCI OpenGL has an advantage, but these are yesteryear's PCs.

Quote:

It was normal on Amiga to copy all tracks from the game's discs, included the ones above the standard 80 ones. A protection relying only on this was too easy to con.

Workbench 1.3's Disk Copy tool only copies 0 to 79 tracks. The end user needs something like 3rd party software such as XCopy/ XCopy Pro or Dcopy or Nibble copy.

Disk copy protection and defeating them is an arms race e.g. XCopy evolved with evolving disk copy protection schemes.


Quote:

I don't expect many modern cards to fully support VESA, since it's a too old standard. So, this might happen. Nevertheless, games used VESA because it was a standard and it was reliable. In fact, Duke Nukem 3D used it, as you can see...

Refer to SciTech UniVBE e.g. http://www.sierrahelp.com/Utilities/DisplayUtilities/ScitechUniVBE.html

https://www.vogons.org/viewtopic.php?t=15190
Topic: Useful utilities for shoring up your video card's VESA VBE support.


For vesafx18.zip

This little tool fixes some (not all!) bugs in the VESA VBE implementation
of 3DFX Banshee based gfx cards. If you have problems with some old dos VESA
games/utilities try it, maybe it will solve your problem.

When installed, the program eats about 2kb of dos memory, so either run it
before the game/tool you want to fix or put it into your autoexec.bat.
I've written/tested it on Creative Labs 3D Blaster Banshee.

3dfx received buglist so maybe some future bios upgrade will make this
program unnecessary but for now, it might help.

I found several programs that will work properly after installing VESAFIX,
for example: Flight Unlimited, ZSNES, Terranova, Midplay, Vbetest, etc.

Last edited by Hammer on 20-Sep-2022 at 06:07 AM.
Last edited by Hammer on 20-Sep-2022 at 06:07 AM.
Last edited by Hammer on 20-Sep-2022 at 06:06 AM.
Last edited by Hammer on 20-Sep-2022 at 06:03 AM.
Last edited by Hammer on 20-Sep-2022 at 05:59 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@cdimauro

Quote:

So, same story: demos continued to be done slapdash even on post-Amiga systems...

Yep.. I remember tried to generalize everything down to the pixel in PublicPaint.
create function pointer table for etch graphic mode, worked ok, on Linux on dual core 1.8 Ghz athlon, then tried it on a lot slower AmigaONE-XE 800Mhz, wow that sucked.

Now I think better approach is not to generalize too much, instead make complex routines supporting etch resolution, the other why just too wasteful.

Anyhow, maybe with C++ templates I might able to pool it off, without having to duplicate major code sections. Anyhow this was before templates, so not an option, yeh macros existed.

I’m coming from coding school of don’t repeat your code twice, as adds complexity and bugs, I guess that school never cared about speed.

Every OS friendly game worth talking about will write directly to the bitmap memory, avoid the graphic library as much as possible, this RastPort based drawing commands are really slow. CGX and P96 has some functions, but really not a lot to play with.

Last edited by NutsAboutAmiga on 20-Sep-2022 at 04:55 PM.
Last edited by NutsAboutAmiga on 20-Sep-2022 at 04:54 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@cdimauro

Quote:

Yes, but Kickstarts CHANGED over the time, so applications relying on specific code sequences won't work anymore.

Yes, however, if they were calling specific routines like a direct address of an Exec function call it should be easy enough to patch them with a wrapper that calls into a jump table. They needed to be patched anyway. Unless it relies on MMU tricks and AFAIK WHDLoad didn't need an MMU the code would need patching to redirect a ROM address into the RAM location of the soft kick.

Quote:

Then "just" buy an Amiga 500 for OCS/ECS games and an Amiga 1200 for AGA games and you're done! But, yes: you've to insert the floppies!

I sold my A500 years ago but only the floppy works on my A1200 so I can insert floppies on that.

Quote:

With Cloanto's Amiga Forever you don't need to pirate the ROMs: you've a regular license for them. For just a bunch of money.

I don't have that. But it seems silly for me to by an Amiga emulator for the purpose of playing games on the real thing. OS4 has ROMs included but they may have not worked.

I recall some Android app that may have included ROMs if purchased. Okay just checked and there is an Amiga Forever app that gives the ROMs for a few bucks and can be used with other Amiga apps Good for mobile Amiga but slightly awkward for transfer to an Amiga.

Quote:

I used to reboot and run the complete game only when I needed to test the complete game (e.g.: new graphic assets and/or new audio assets to be integrated and tested).

That's fair enough.

Quote:

Please share it, if you recall some.

This one comes immediately to mind!

https://www.youtube.com/watch?v=7sOjdusDUzE

Quote:

So, when I code it will be only for my personal projects.

At my stage in life I only code for my personal projects.

Well I do share them online when finished.

But I did venture into the outside world once. At the Amiga club I've been going to for decades now I'm sure we had a guy came in who was looking for an Amiga coder. I don't know why but I always seemed to be the guy who was consistently programming on his Amiga. He found me and told me he worked for a video production company that used Amiga A1200's with Scala MM500. This would have been in the late 90's and even at the time I was surprised Amigas were still in use. And they connected the composite out through a BNC connector which I didn't think was the best quality. So they had some deal of sorts to display info for a local race course. But they needed to display real time clock data for the tracks. So they needed someone who could program Scala to receive a serial stream of clock data, decode it and tell Scala to display the counter on screen. I researched into it. I knew Scala could do it somehow but I didn't have all the guides or plug ins but I did have Scala from somewhere. Not sure if it was on coverdisk but I do have a boxed Scala since years. In any case the answer for me was ARexx. Scala had an Arexx port. So I found how to program it. I wrote a few test programs in AmigaE, with some snappy names I cannot remember lol, that could read over serial, decode the clock timer, and finally send it to Scala as an ARexx packet. In fact I didn't even use Arexx, since an ARexx packet (as I called it) is simply an Exec message in Arexx format. Can be fully binary for speed, just need to put commands as text. I was given an A1200 for the purpose of assisting and set up a serial link between the two with one acting as the clock sender. The whole operation, from when sending the clock data, to my program decoding it and re-encoding it as Scala text commands, sending the commands and Scala actually displaying was one second. Suppose that wasn't so bad, just a one second latency. The guy was happy with that. But I recall being less happy because I thought it was too slow! He let me keep the A1200 which became my payment. I don't know if it was ever used. I gave him the binaries but didn't give way the source. However, it was a good experience and for doing some Amiga programming for possible use in the outside world, I thought it was worth getting involved in.

Quote:

Similar thing, but I've swapped my Plus4 with a C128 after just one month because of lacking of software for this new hardware platform (plus, the Amiga 1000 was too much expensive).

That's very short. After a month I was still tracking tapes on my C16. The C16 was my first computer so I didn't really need any software. It was all exciting. The only issue I faced was later on when I wanted to print school assignments and didn't have a word processor. Plus/4 would have helped me there. It wasn't practical after a while to program a document in BASIC and send each line to the printer with PRINT statements. So, WordWriter was born, my first practical application. Ii was a lot faster being able to type the words in normally. But the cursor was slow in my BASIC word editor.

After the C16 I thought the C128 was like a dream machine. But a few years back I found it only has the C64 palette. Which I thought was a real downgrade after the superior C16 palette of 121 odd colours and didn't feel so bad.

Quote:

Maybe you can meet Reneé: she also needs some background on computer science.

There's a Reneé of sorts in the Facebook Amiga group.

Quote:

If compatibility is the focus then Vampire is still the wrong choice.

I've literally seen people buy Vampires and then run old Amiga games on them. But that is the A500 version which lacks AGA. So great RTG Workbench to run old ECS games!

Quote:

But, again, I don't want to start talking about it: I just don't share the project vision. That's it.

I think it's great idea for the most part. If we could party in 1999. Like Natami. But for me it came out too late. I mean, it's using DDR and all that, but it's still behind my AmigaOne XE with 800 Mhz G3 and slow Radeon 9200SE. So for me it just isn't powerful enough.

Quote:

Indeed. Software mixing audio channels wasn't realistic on a plain 7Mhz 68000 platform, because it took too much (raster) time.

I did it myself in PT when out of tracks. Wrote some code to mix samples together. Then my drums had more tracks, or my tracks had more drum sounds really. Same playback speed. So substituted one sound for two. Then "kick" and "hat" became "kick+hat".

Also, module replayer also use raster time as you would be aware, waiting for DMA to set in. I thought polling in an interrupt was bad practice and didn't see why the player couldn't start DMA in one interrupt and then set loops in next. I mean, how often will a sample finish before the next interrupt? The average PT song at 125 BPM runs the player at 50 FPS. Even at the slowest tempo and fastest sample rate with shortest sample there is surely enough time between ticks to set post DMA loops. Later players I've seen add a second CIA timer to set it which is better but still seems overkill.

Quote:

Bruce doesn't know it because, despite claiming to develop for the Amiga in assembly, he never developed a (commercial) game. So he doesn't know all challenges that it takes.

I haven't either but I immediately think of the CPU cost. Knowing what it needs to do. An action game; no way, an adventure game; sure maybe.

Also I've seen the OctaMED routine, with the integer decimal math tricks and all it needs to do to simulate the hardware channels, and there is a bit of work.

Quote:

BTW, I've developed a software mixer (albeit there were still some bugs to be fixed: cracks were popping-up from time to time), so I know how it "costed" in performance terms.

On a 68000 I bet even worse. Things like drums sounds or other non-melodic sounds are easy enough since there's no scaling needed and only need adding. But at that point might as well pre render samples like my simple mixer did. I've considered a hybrid solution that does that on the tracker side. That maps it all out, renders one shot sounds, and renders melodies together where needed. But, it needs more memory, as the the cost for full speed. So less practical on A500.

I already posted about this idea here:
https://amigaworld.net/modules/newbb/viewtopic.php?topic_id=42151&forum=2

Quote:

No, there's not so much space for it. Sprite's control data was already almost fully used.

I mean, not in the existing control words, but extra control words after with palette data. So there could have been control words, palette words, bitmap words and then terminator words instead. For attached sprites it is slightly more complicated as the entire upper palette would have been needed, but in that case a larger palette could have been set.

@Hypex

https://github.com/nonarkitten/amiga_replacement_project/tree/master/denise
Drop in Denise chip replacement project with AGA.


https://github.com/nonarkitten/amiga_replacement_project/wiki/Willoe-v0.5-(ReAgnus)
Drop in Agnus chip replacement project with AGA and higher performance Chip RAM. Alice's Blitter is still 16-bit.


Graffiti can display 256 colors with OCS/ECS 16-bit Chip RAM, and it's too bad Graffiti is not register compatible with AGA Lisa.

Nonarkitten is also targeting Vampire AGA.

Last edited by Hammer on 21-Sep-2022 at 04:21 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@cdimauro

Quote:

It's so long now which is difficult to recall all details. I roughly remember that when I've added the Kickstart 2.0 on my Amiga 2000 then some demo stopped working. And when I switched to my Amiga 1200 then it was bloodbath.

When I have my Amiga 3000/030 @ 25 Mhz with Kickstart 2.04 ROM in the early 1990s, I use the SoftKickstart to load Kickstart 1.3 into memory. http://aminet.net/package/util/misc/softboot331

Amiga 4000 has a shadow register feature that maps with 00C00000-00CFFFFF with the 1st 1MB Chip RAM range.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

Quote:

Drop in Denise chip replacement project with AGA.

That's interesting. The ReAmiga will need a ReDesign.

I tend to think they might as well drop OCS and use ECS as minimum. Who would want to use OCS still in a new chip? ECS is slightly incompatible with OCS but if you are upgrading or replacing you'd surely want the later features.

Quote:

Drop in Agnus chip replacement project with AGA and higher performance Chip RAM. Alice's Blitter is still 16-bit.

Speding up the blitter will the next task. But replacing AGA is harder without socketed chips. Faster CIA would be useful.

Quote:

Graffiti can display 256 colors with OCS/ECS 16-bit Chip RAM, and it's too bad Graffiti is not register compatible with AGA Lisa.

Using 16 colour hires of all things to achieve it. Somehow turning blocks of 16 pixels in 16 grey colours into blocks of 8 pixels in 256 palette colours. How is Graffiti is not register compatible with AGA Lisa? There is the external one. And the limited edition embedded in the Indivision ECS.

Quote:

Quote: kolla wrote: @cdimauro Any modern demo in particular that you find is breaking the guidelines? It's so long now which is difficult to recall all details. I roughly remember that when I've added the Kickstart 2.0 on my Amiga 2000 then some demo stopped working. And when I switched to my Amiga 1200 then it was bloodbath.

A longwinded way of saying you’re way outdated on the topic and don’t know anything about demos, really.

Quote:

Actually the one which I recall having problems was State of the art, because it required slow memory. So, not playable on my Amiga 1200 even with 2MB of memory available. This I remember only because it's one of the most famous demo on Amiga.

Works fine on my A600 with only 2MB. But that is beside the point, that demo is from 1992, pre-AGA, and perhaps most important - coded for a different era, by teen agers of the time.

Quote:

Quote: It’s typical a compo rule that demo must exit cleanly. Usually demos were like games: they booted from the floppy and killed the o.s.. So, no soft exit to the o.s. when they finished.

Were, a long time ago. Times changed, also a long time ago, but somehow you missed it.

Quote:

Quote: I find it much more annoying with productivity software that “plays dirty”, Absolutely. Quote: but I can understand why it was done, as differences in performance between “correct” and “dirty” can be formidable and a matter of whether the software is at all useful or not. I beg to differ: a software could be correct AND having very good performance. Good practices don't hurt performances even when directly banging the hardware.

Got any example? Using "custom routines" over OS routines has typically been the mantra for performance all along.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

kolla wrote: Quote: It's so long now which is difficult to recall all details. I roughly remember that when I've added the Kickstart 2.0 on my Amiga 2000 then some demo stopped working. And when I switched to my Amiga 1200 then it was bloodbath. A longwinded way of saying you’re way outdated on the topic

Well, it's since '96 that I've switched from Amiga to PC (forced because the video ports on my 1200 weren't functional anymore; seems to be a common problem with these machines) and I've stopped using Amiga software.

What do you pretend after a so stop long, that I recall all details?!?
Quote:

and don’t know anything about demos, really.

This is a logical fallacy, dear mystifier. It looks like that you and logic aren't friend, but we know it since long time, since this isn't the first occurrence.

Anyway we'll see below who has knowledge about demos.
Quote:

Quote: Actually the one which I recall having problems was State of the art, because it required slow memory. So, not playable on my Amiga 1200 even with 2MB of memory available. This I remember only because it's one of the most famous demo on Amiga. Works fine on my A600 with only 2MB.

Tested on WinUAE and I get this:



The good thing about science is that experiments should be reproducible. Here's how I got this result:
Quickstart / A500 / 1.3 ROM, OCS Agnus, 512KB Chip RAM
Hardware / Chipset / Collision Level / Full
Hardware / Floppy drives / DF0: / StateOfTheArt.adf
Hardware / RAM / Chip: / 1M or Z2 Fast: 512KB

But the same happens with:
Quickstart / A600 / Basic non-expanded configuration
Quickstart / A600 / 2MB Chip RAM expanded configuration

However it works even on the A4000 configuration by just adding 512KB of Slow RAM.

The only thing which is missing is the demo's image, but I can 7-zip and send you if you're unable to find it.

So, I was recalling perfectly: State of the Art worked ONLY with Slow RAM (at $C00000).

I don't know why it works on your A600. Maybe you've a fixed version.
Quote:

But that is beside the point, that demo is from 1992, pre-AGA, and perhaps most important - coded for a different era, by teen agers of the time.

A different era?!? It's since the Amiga was born that those bad practices were VERY common. So, it was 7 (SEVEN!) years and people still were used to make stupid things like assuming that you had Slow RAM.

I don't know where you were living during that period: on another world?!?
Quote:

Usually demos were like games: they booted from the floppy and killed the o.s.. So, no soft exit to the o.s. when they finished.

Were, a long time ago.[/quote]
And on a galaxy far away...
Quote:

Times changed, also a long time ago, but somehow you missed it.

Probably because I've abandoned the Amiga after that it wasn't a suitable platform anymore.

AND you arrived AFTER that.

This is the only reasonable explanation, because since I was on the Amiga land the things worked as I've stated. And it's very easy to verify it, taking the products of that time.
Quote:

Quote: I beg to differ: a software could be correct AND having very good performance. Good practices don't hurt performances even when directly banging the hardware. Got any example?

Fightin' Spirit is one. It worked on every configuration even if my code (this specific part was removed on the final version) was self-modifying.
Quote:

Using "custom routines" over OS routines has typically been the mantra for performance all along.

Well, do you know what's your problem? You're ignorant. You aren't a coder neither an Amiga programmer and of course you have no idea on how developing games or demos on that platform. But you don't stop to write complete bullsh*its on that topics.

Specifically, writing "custom routines" do NOT mean that those have to do dirty things. Even compared to the o.s. ones (IF there were equivalent).

As usual, what matters is following the Commodore's guidelines. Or NOT.

This is and should be the ONLY criterion.

And I reveal you a secret: it was/is possible to have high performances while respecting those guidelines.

I gave you the example above. Do you know any other game which is moving a similar quantity of graphic at 25FPS, with so many colours, and with such reachness (there is plenty of graphic for both background and characters)?

@kolla

Quote:

Works fine on my A600 with only 2MB. But that is beside the point, that demo is from 1992, pre-AGA, and perhaps most important - coded for a different era, by teen agers of the time.

I had trouble with State of the art when I tried it only A1200. IIRC it was because I had replaced the floppy drive Escom version and it wouldn't load. I'd need to check with my sources, since I made a patch for it, but I'm sure it was because it was missing the disk ready line.

@cdimauro

I did ask for *modern* examples and you come dragging with 30 year old example that you barely can recall, from what indeed was a different era of demo coding, both in general and most of all because of the age of those coding those demos.

Yes, maybe I have a fixed version… if so, why don’t you?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Hypex

Quote:

Hypex wrote: @kolla Quote: Works fine on my A600 with only 2MB. But that is beside the point, that demo is from 1992, pre-AGA, and perhaps most important - coded for a different era, by teen agers of the time. I had trouble with State of the art when I tried it only A1200. IIRC it was because I had replaced the floppy drive Escom version and it wouldn't load. I'd need to check with my sources, since I made a patch for it, but I'm sure it was because it was missing the disk ready line.

If you got the original version that you had troubles anyway, since it required Slow RAM(see above).


@kolla

Quote:

kolla wrote: @cdimauro I did ask for *modern* examples and you come dragging with 30 year old example that you barely can recall, from what indeed was a different era of demo coding, both in general and most of all because of the age of those coding those demos.

Please, do you understand that this doesn't make sense?

The vast majority of demos were produced when Amiga was alive! And that was when we (not you!) amigans played them. Which means that we experimented all the issues which I've reported... AT THE PRECISE TIME WHEN THEY WERE RELEASED!

Who cares if after some time someone produced a fixed version. IF any! And who knows WHEN!

AFTER that Commodore went in bankrupt the Amiga platform was dead as well and most of Amigans moved to different platforms (PC, Mac).

I've no doubt that demo coders might have improved writing code, since they started producing stuff for accelerated Amigas. But that's nothing compared to what happened when the Amiga was alive.
Quote:

Yes, maybe I have a fixed version… if so, why don’t you?

I've already written why:

it's since '96 that I've switched from Amiga to PC (forced because the video ports on my 1200 weren't functional anymore; seems to be a common problem with these machines) and I've stopped using Amiga software

Besides that, since I went back I prefer to use WHDLoad, which IMO is THE (final) solution to the dirty jobs which were made by a complete idiots that didn't followed Commodore's guidelines since the very first day.

Last edited by cdimauro on 23-Sep-2022 at 05:54 AM.

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: It's up to you. I prefer games and applications. Besides the MMU and FP80 issues, Amiga 68K software that can run on DraCo is easier to support.

Not that much, since it lacked the original chipset and RTG software wasn't wide-spread when Commodore went in bankrupt.
Quote:

Quote: It was normal on Amiga to copy all tracks from the game's discs, included the ones above the standard 80 ones. A protection relying only on this was too easy to con. Workbench 1.3's Disk Copy tool only copies 0 to 79 tracks. The end user needs something like 3rd party software such as XCopy/ XCopy Pro or Dcopy or Nibble copy.

The end user started using this 3rd party software since the beginning. Workbench's Disk Copy was the most UNUSED software (even because it's more complicated).
Quote:

Quote: I don't expect many modern cards to fully support VESA, since it's a too old standard. So, this might happen. Nevertheless, games used VESA because it was a standard and it was reliable. In fact, Duke Nukem 3D used it, as you can see... Refer to SciTech UniVBE e.g. http://www.sierrahelp.com/Utilities/DisplayUtilities/ScitechUniVBE.html https://www.vogons.org/viewtopic.php?t=15190 Topic: Useful utilities for shoring up your video card's VESA VBE support. For vesafx18.zip This little tool fixes some (not all!) bugs in the VESA VBE implementation of 3DFX Banshee based gfx cards. If you have problems with some old dos VESA games/utilities try it, maybe it will solve your problem. When installed, the program eats about 2kb of dos memory, so either run it before the game/tool you want to fix or put it into your autoexec.bat. I've written/tested it on Creative Labs 3D Blaster Banshee. 3dfx received buglist so maybe some future bios upgrade will make this program unnecessary but for now, it might help. I found several programs that will work properly after installing VESAFIX, for example: Flight Unlimited, ZSNES, Terranova, Midplay, Vbetest, etc.

Correct. There was this 3rd party software which provided alternative VESA implementations when the bundled one was bugged on incomplete.

That's why we had TONs of games using the VESA standard: it was the standard, whatever was implemented on INT 10h...

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @cdimauro Quote: So, same story: demos continued to be done slapdash even on post-Amiga systems... Yep.. I remember tried to generalize everything down to the pixel in PublicPaint. create function pointer table for etch graphic mode, worked ok, on Linux on dual core 1.8 Ghz athlon, then tried it on a lot slower AmigaONE-XE 800Mhz, wow that sucked. Now I think better approach is not to generalize too much, instead make complex routines supporting etch resolution, the other why just too wasteful.

Well, if you write a 2D game you cannot avoid setting the resolution, because you're assets are defined for it. You might different assets per resolution, but it makes the graphic artist life a nightmare...
Quote:

Anyhow, maybe with C++ templates I might able to pool it off, without having to duplicate major code sections. Anyhow this was before templates, so not an option, yeh macros existed. I’m coming from coding school of don’t repeat your code twice, as adds complexity and bugs, I guess that school never cared about speed.

Correct. But templates and macros creates more code...
Quote:

Every OS friendly game worth talking about will write directly to the bitmap memory, avoid the graphic library as much as possible, this RastPort based drawing commands are really slow. CGX and P96 has some functions, but really not a lot to play with.

You've to distinguish games and regular applications.

For the former it's better to directly access the framebuffer where you update the graphic at the maximum speed. Because the game is as it is, with its assets, and it should be reproduced exactly as expected.

Applications have different requirements and should rely on the o.s. APIs as much as possible. That's because the o.s. could change the GUI interface and your application will continue to work.


@Hammer

Quote:

Hammer wrote: Graffiti can display 256 colors with OCS/ECS 16-bit Chip RAM, and it's too bad Graffiti is not register compatible with AGA Lisa.

That's normal, because it required some extra registers for defining the CLUT.

AFAIR the Graffiti software used some raster lines BEFORE the visible screen area to "send" all CLUT entries (so that the hardware was ready to render the screen area when it had to display it).

But since the hardware is off from the system it wasn't impossible to be compatible with the regular chipset.
Quote:

Hammer wrote: @cdimauro Quote: It's so long now which is difficult to recall all details. I roughly remember that when I've added the Kickstart 2.0 on my Amiga 2000 then some demo stopped working. And when I switched to my Amiga 1200 then it was bloodbath. When I have my Amiga 3000/030 @ 25 Mhz with Kickstart 2.04 ROM in the early 1990s, I use the SoftKickstart to load Kickstart 1.3 into memory. http://aminet.net/package/util/misc/softboot331 Amiga 4000 has a shadow register feature that maps with 00C00000-00CFFFFF with the 1st 1MB Chip RAM range.

Lucky you: the vast majority of Amigans hadn't this possibility...


@Hypex

Quote:

Hypex wrote: @Hammer Quote: Drop in Denise chip replacement project with AGA. That's interesting. The ReAmiga will need a ReDesign. I tend to think they might as well drop OCS and use ECS as minimum. Who would want to use OCS still in a new chip? ECS is slightly incompatible with OCS but if you are upgrading or replacing you'd surely want the later features. Quote: Drop in Agnus chip replacement project with AGA and higher performance Chip RAM. Alice's Blitter is still 16-bit. Speding up the blitter will the next task. But replacing AGA is harder without socketed chips. Faster CIA would be useful.

Speeding up the Blitter or other components is NOT recommended if (full) compatibility is the goal of those projects).

@Hypex

Quote:

That's interesting. The ReAmiga will need a ReDesign. I tend to think they might as well drop OCS and use ECS as minimum. Who would want to use OCS still in a new chip? ECS is slightly incompatible with OCS but if you are upgrading or replacing you'd surely want the later features.

It depends on the Implementation.

Quote:

Speding up the blitter will the next task. But replacing AGA is harder without socketed chips. Faster CIA would be useful.

A500's chips are socketed. Offering drop-in AGA chip upgrades for the A500 targets has Amiga's largest user base group.


Quote:

Using 16 colour hires of all things to achieve it. Somehow turning blocks of 16 pixels in 16 grey colours into blocks of 8 pixels in 256 palette colours. How is Graffiti is not register compatible with AGA Lisa? There is the external one. And the limited edition embedded in the Indivision ECS.

Graffiti is based on a series of low-color pixels that convey an 8-bit pixel that is decoded via custom external raster hardware. Regardless of the format, 8 bits (256 colors) worth of data is transferred to the raster.

Graffiti does not run AGA games.

I have Indivision AGA Mk3 with Graffiti emulation for my A1200.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@cdimauro

Quote:

Lucky you: the vast majority of Amigans hadn't this possibility...

Being a minority is less fun. I preferred an improved baseline standard for everybody i.e. for masses, not classes.

A3000 purchase was a surprise from my Dad (Xbox sports-type gamer).

Personally, I would have waited for A1200 since it's semi-portable for school presentations.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@cdimauro

Quote:

I don't know why it works on your A600. Maybe you've a fixed version.

From https://www.pouet.net/prod.php?which=99

This "State of the Art" demo version works on Amiga 500 with ECS Agnus 1 MB Chip Ram config.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@cdimauro

Quote:

cdimauro wrote: @kolla Quote: kolla wrote: @cdimauro I did ask for *modern* examples and you come dragging with 30 year old example that you barely can recall, from what indeed was a different era of demo coding, both in general and most of all because of the age of those coding those demos. Please, do you understand that this doesn't make sense? The vast majority of demos were produced when Amiga was alive! And that was when we (not you!) amigans played them. Which means that we experimented all the issues which I've reported... AT THE PRECISE TIME WHEN THEY WERE RELEASED!

I am not so sure that you are correct about that - if you say Amiga "died" in 1995, that is 27 years (and counting) of demo production, that may very well have cought up with the numbers of demos made between 1985 and 1995.

Quote:

Who cares if after some time someone produced a fixed version. IF any! And who knows WHEN!

Is this your approach to software in general? If so... interesting.

Quote:

AFTER that Commodore went in bankrupt the Amiga platform was dead as well and most of Amigans moved to different platforms (PC, Mac).

Just because people "moved" to a different platform for daily tasks didn't mean they left Amiga behind as a target for creating demos.

Quote:

I've no doubt that demo coders might have improved writing code, since they started producing stuff for accelerated Amigas. But that's nothing compared to what happened when the Amiga was alive.

Good, and not just accelerated Amiga, also stock A500 and stock A1200. Demo coding is a bit like sports... think of Go-Karts - there are different categories or classes that people compete in, depending on for example engine size. Same with demo competitions, different categories for the different systems that are targeted. This is also why systems like Apollo/Vampire systems are frawned upon, they break the category rules.

Quote:

Quote: Yes, maybe I have a fixed version… if so, why don’t you? I've already written why: it's since '96 that I've switched from Amiga to PC (forced because the video ports on my 1200 weren't functional anymore; seems to be a common problem with these machines) and I've stopped using Amiga software

And since the world circles around you, all demo production since ´96 can just be ignored... even when I specifically asked for MODERN example. You could just have said "I don't know - haven't paid attention" instead of spinning this into this nonsense about "all REAL Amiga demos were made before I left!"

Quote:

Besides that, since I went back I prefer to use WHDLoad, which IMO is THE (final) solution to the dirty jobs which were made by a complete idiots that didn't followed Commodore's guidelines since the very first day.

All demo coders were and are complete idiots, based on anecdotal evidence of ONE example from 1992. Because you say so, duly noted!

You know who else didn't follow Commodore's guidelines?

Last edited by kolla on 24-Sep-2022 at 07:52 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: I don't know why it works on your A600. Maybe you've a fixed version. From https://www.pouet.net/prod.php?which=99 This "State of the Art" demo version works on Amiga 500 with ECS Agnus 1 MB Chip Ram config.

The page states only OCS/ECS: it says nothing about 1MB Chip RAM.

Which isn't working, anyway:



Whereas just adding 512kB of Slow RAM (like I did with the A4000) worked...


@kolla

Quote:

kolla wrote: @cdimauro Quote: cdimauro wrote: Please, do you understand that this doesn't make sense? The vast majority of demos were produced when Amiga was alive! And that was when we (not you!) amigans played them. Which means that we experimented all the issues which I've reported... AT THE PRECISE TIME WHEN THEY WERE RELEASED! I am not so sure that you are correct about that - if you say Amiga "died" in 1995, that is 27 years (and counting) of demo production,

28 years, because Amiga died on '94 (with Commodore).
Quote:

that may very well have cought up with the numbers of demos made between 1985 and 1995.

Unfortunately there's no demo database like for the Amiga games that I know that could be searched by year.
Quote:

Quote: Who cares if after some time someone produced a fixed version. IF any! And who knows WHEN! Is this your approach to software in general? If so... interesting.

Not in general: it's for a platform which died and became retro.

The point is that we, amigans, lived during that time and enjoyed what we got. Again, at the time.

And at the time it was rare or difficult to get some fixes for all the issues that I've mentioned.

You know, internet wasn't so widespread as nowadays and we had very slow modems to be used for downloading / uploading data.

That was our real life and that's what I've plainly reported.
Quote:

Quote: AFTER that Commodore went in bankrupt the Amiga platform was dead as well and most of Amigans moved to different platforms (PC, Mac). Just because people "moved" to a different platform for daily tasks didn't mean they left Amiga behind as a target for creating demos.

Care to prove where I've said something like that?

kolla, you still have big problems with elementary logic.
Quote:

Quote: I've no doubt that demo coders might have improved writing code, since they started producing stuff for accelerated Amigas. But that's nothing compared to what happened when the Amiga was alive. Good, and not just accelerated Amiga, also stock A500 and stock A1200. Demo coding is a bit like sports... think of Go-Karts - there are different categories or classes that people compete in, depending on for example engine size. Same with demo competitions, different categories for the different systems that are targeted. This is also why systems like Apollo/Vampire systems are frawned upon, they break the category rules.

And I've nothing to say about that. Right?
Quote:

Quote: I've already written why: it's since '96 that I've switched from Amiga to PC (forced because the video ports on my 1200 weren't functional anymore; seems to be a common problem with these machines) and I've stopped using Amiga software And since the world circles around you, all demo production since ´96 can just be ignored...

See above: WHERE I'VE SAID THAT?!?
Quote:

even when I specifically asked for MODERN example.

Which happened AFTER that the discussion was already on this particolar topic.

So, you tried to change the topic focusing on something different. Because what I've talked about 'til then was my real life / experience as amigan. As ALL amigans. Until the platform died.
Quote:

You could just have said "I don't know - haven't paid attention" instead of spinning this into this nonsense about "all REAL Amiga demos were made before I left!"

That I NEVER said, dear mystifier.

For the rest, see above the context reconstruction.
Quote:

Quote: Besides that, since I went back I prefer to use WHDLoad, which IMO is THE (final) solution to the dirty jobs which were made by a complete idiots that didn't followed Commodore's guidelines since the very first day. All demo coders were and are complete idiots,

Again, never said that, mystifier.

Specifically, it was/is only for developers that did NOT followed the guidelines. Do you have a different opinion about that?
Quote:

based on anecdotal evidence of ONE example from 1992. Because you say so, duly noted!

Again, never said that. You continue to mystify either because you're a liar / lacking arguments and/or because you don't know what's elementary logic (and continue to fall on logical fallacies).

Specifically and putting the right words and context, I've talked of demos which had issues due to bad coding. AND, by YOUR request, I just gave a name that I recalled.

Those are the FACTs, dear liar or elementary logic enemy.
Quote:

You know who else didn't follow Commodore's guidelines?

Well, many of my Amiga disks that I've thrown away last Saturday had notes reporting "- Kick 2.0" ("-" means that did NOT worked with Kickstart 2.0), "- Kick 3.0", "-ECS", "-AGA", "No caches", "Requires $C00000".

But currently I have no statistics about that.

If that's something where YOU are interested to know then you can pick the ORIGINAL demos released AT THE TIME (so, NOT your fixed versions) and try if they work on configs different from the usual A500 KS 1.2 OCS/ECS 512kB Chip + 512kB Slow RAM.