@Hammer

I would also add that 5 FPS difference has to judged as a proportional increase. Compared to the original T17 release we are several times faster already. Factor into that that we've also increased the render area by 11% when we went from 288 to 320 pixels.

Here is the previous WHDL (includes TKG turbo patch) versus the last but one version of our build:

https://eab.abime.net/showpost.php?p=1718042&postcount=5117

~3fps to 11.6fps

Although that's under (interpreted, memory timing cycle exact) emulation, real hardware does show a similar difference.

Last edited by Karlos on 11-Dec-2024 at 10:31 AM.

_________________
Doing stupid things for fun...

@Karlos

Thanks for all your work on this. I had a previous version running on my PiStorm32/Pi4 A1200 at the Nottingham Kickstart event in Summer '24 and it attracted a lot of attention.

I've downloaded the karlos-tkg-misc-redesign zip from Github this evening. The RTG version runs perfectly with my pseudo-PAL LoRes screenmode of 320x256, at around 50 FPS. However the ASM version loads to the menu screen, and when I start the game I get the HUD but the play field is black, the Energy and Ammo meters stay at 000 (sometimes the Energy meter sets to 200), the FPS stays at 0.0, and the music starts. I have to reset to get out. Going back to the previous version works.

-double post-

Last edited by Karlos on 12-Dec-2024 at 08:57 AM.

_________________
Doing stupid things for fun...

@AndyFC

The ASM version is now retired. Also be aware the redesign branch is for all in progress work on the mod and there are no guarantees that any levels are even completable. I'm also not working on them in a very linear order because, as with all hobbies, you do what interests you most :D

Regarding the ASM black screen - there is a bug in the handling of gamma/brightness after running the regular version. Deleting the settings file should remedy it. Nevertheless, the ASM version won't be getting any further updates and we have removed it from the build process. Expect it to disappear from the mod soon.

_________________
Doing stupid things for fun...

Just an addendum, the naming of the builds may set the wrong expectations. The ASM only build is what we started with and as the name implies is 100% assembler. The C build should really be called "the build that lets us also use C to do various things.", but that's a bit long winded. So it became "the c build".

There's no speed advantage of the ASM version. In fact, the opposite is true. The C version has started adding high-level changes to improve the handling of visibility for drawing. All the drawing itself is handled by the same ASM code, there's just less of it to do per frame.

Last edited by Karlos on 12-Dec-2024 at 12:04 PM.

_________________
Doing stupid things for fun...

@Karlos

My comment is for https://eab.abime.net/showpost.php?p=1719230&postcount=5253

- PAL low res 15 / 20 fps
- RTG BVision 320 x 240 17 / 25 fps

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hammer

If we entertain the notion for a moment that the C2P is copyspeed and the RTG version is (the game is rendered in a fast buffer then copied to the frame), the C2P is limited to about 7MB/s write speed and the BVision is about 15-20MB/s write speed (I recall it was about 15 on my 040/25, on 060/50 it was faster but I don't remember exactly how much).

Rendering direct to VRAM isn't an option because you'd have to hold the lock for the entire render pass and many effects, eg transparency, also involve reading back from it. It's also all pixel by pixel, typically columnar rendering.

_________________
Doing stupid things for fun...

@Karlos

For the given 68060 CPU, BVision (3DLabs Premedia 2 PCI) has superior efficiency when compared to C2P+AGA+Amibus. The difference is not major.

PiStorm32-Emu68 with AGA's AB3D2 is +50 fps. My A1200's DELL LCD monitor can't exceed 60 hz.

Last edited by Hammer on 17-Dec-2024 at 02:33 AM.
Last edited by Hammer on 17-Dec-2024 at 02:32 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hammer

It's more nuanced than that. Yes, it's much faster to copy to VRAM on the BVision than to C2P into chip ram. However, there are other factors that affect the fluidity of the game.

The biggest is "tick rate". All the game logic runs on an interrupt which in the original is sourced from the screen blank. This is a very reliable 50Hz rate that literally everything in the game relies on. It's also why the game speed is off if you use Euro36 or 72 or whatever.

For RTG, we had to use a software interrupt at 50Hz. It may be better on real HW, but my experience on UAE where there's literally no limit to either copy or C2P before you hit the refresh rate, is that in the limit, the AGA blank delivers a rock solid 50fps (oddly it's 52.1 on my machine but either way, it's unwavering), whereas the RTG version which is dependent on the software interrupt is always fluctuating around the 50fps rate. This still happens if I frame cap to a lower rate.

It's something I do want to better understand it maybe it's not an issue. But if it is, I expect a PiStorm to show similar behaviour.

_________________
Doing stupid things for fun...

@Karlos

Quote:

or RTG, we had to use a software interrupt at 50Hz. It may be better on real HW, but my experience on UAE where there's literally no limit to either copy or C2P before you hit the refresh rate, is that in the limit, the AGA blank delivers a rock solid 50fps (oddly it's 52.1 on my machine but either way, it's unwavering), whereas the RTG version which is dependent on the software interrupt is always fluctuating around the 50fps rate. This still happens if I frame cap to a lower rate.

I'm aware of game logic processing within certain intervals e.g. 16.67ms for 60Hz.

PiStorm32 has access to AGA. Original PiStorm and PiStorm16 for 16-bit Amigas must use RTG.

Fast C2P software solution wasn't part of Commodore's documentation, hence many 3rd party companies factored in Commodore's slow C2P API warnings. Only a few 3rd party developers have disobeyed Commodore documentation's slow C2P API warnings and programmed a fast C2P software solution.

Last edited by Hammer on 18-Dec-2024 at 01:21 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hammer

I have to admit, I'm just not sure what point you are trying to make.

The official C2P solution was bad, especially if you used it via the software write chunky pixels mechanism, which IIRC involves allocating a temporary bitmap just to hamper things further.

When devs used Akiko, it was pretty much directly. And many didn't use it at all because aside from being too slow to not working at all if you had an 030 accelerator in your CD32 (unless you mess with MMU/CACR regs), they wanted their software to work on AGA generally. So they all rolled their own solutions from chunky copper screen to software C2P.

_________________
Doing stupid things for fun...

@BigD

I'm afraid the last round of improvements have introduced a two player mode regression.

_________________
Doing stupid things for fun...

@Karlos

Quote:

And many didn't use it at all because aside from being too slow to not working at all if you had an 030 accelerator in your CD32 (unless you mess with MMU/CACR regs), they wanted their software to work on AGA generally.

One would think that when so many devs complained about piracy, Akiko might be the definitive dongle, in a time where there was not that many CDRs

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@pixie

It's an interesting idea. You could imagine just writing to Akiko and reading back from the address as per normal direct C2P operation. If you don't get the expected converted result (which would probably render your SX32 030 card unworkable without care), your title would know you aren't on a real CD32 and no dice.

_________________
Doing stupid things for fun...

@Karlos

Without 68030's MMU and data cache issues, a faster 25 Mhz 68EC020 or 28 Mhz 68020 would be the easy pathway.

https://archive.computerhistory.org/resources/access/text/2013/04/102723262-05-01-acc.pdf
Page 119 of 981

For 1992
68000-12 = $5.5
68EC020-16 PQFP = $16.06, it's $15 in 1993 Q1.
68EC020-25 PQFP = $19.99, it's $18 in 1993 Q1.
Commodore has about $8 price discount for 68EC020.

68EC030-25 PQFP = $35.94
68030-25 CQFP = $108.75
From the A3000Plus price estimate document, Commodore doesn't have a discount for the 68030-25. Later A4000/030s used cheaper MMU-less 68EC030-25 instead of 68030-25.

68040-25 = $418.52
68EC040-25 = $112.50
----------------------------------------
Competition

AM386-40 = $102.50
386DX-25 PQFP = $103.00

486SX-20 PQFP = $157.75
486DX-33 = $376.75
486DX2-50 = $502.75

Without the 1 million A600 units related debt load mistake and with A1200's higher profit margin over CD32, A1200 could have 68EC020-25 and Fast RAM. $20 extra for 8 MB CD32 config. Motorola's 68K solution is not price vs performance competitive.

One of the early configs for Amiga Hombre's custom PA-RISC 3D accelerator is for the existing Amiga AGA. Refer to Namco's System 22 example with 68020 @ 24.5Mhz with two Texas Instruments TMS32025 DSP @ 49.152 MHz (3D geometry) and Evans & Sutherland TR3 (texture mapper, T&L and etc).

1 million A600 units production run should been A1200 units and out-of-the-box enhanced A1200 (with 68EC020 @ 25Mhz, 2MB Fast RAM) is not a guaranteed survival for Commodore since PS1 has strong specs for the money and strong launch titles.

For A4000/030's $1500 USD price, Commodore Canada/Amitech has a big box A2200-2 with 68030 @ 40Mhz and CD32 SBC. The production scale is about 65,000 units.

Amiga is not Mac or PC since Amiga's weak business market can't sustain Commodore's Amiga platform. The Amiga platform mostly acts like a game console Amiga. Newtek's niche can't sustain Commodore.

A semi-healthy Commodore's A1200 could have 68EC020 @ 25 and 2MB of Fast RAM.

Last edited by Hammer on 19-Dec-2024 at 12:44 AM.
Last edited by Hammer on 19-Dec-2024 at 12:40 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hammer

It's amazing. It took you that much text to say the A1200 would have been better if it has shipped with some Fast RAM and maybe a faster CPU. Everyone knows this.

Commodore wouldn't have released a 25MHz 020 A1200 with 2MB anyway, since they were trying to sell the 4000 030 at the same time.

I still don't see what this has to do with C2P v Akiko.

_________________
Doing stupid things for fun...

In more relevant news, the zone rendering bugs in two player mode are now fixed. Fortunately it wasn't necessary to just disable the optimisation.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @Hammer It's amazing. It took you that much text to say the A1200 would have been better if it has shipped with some Fast RAM and maybe a faster CPU. Everyone knows this.

A better "What IF" is based on real costings, not just must have Fast RAM without real cost reasons.

I usually add background information to my posts e.g. the small price difference between Jeff Frank's A1200 vs What IF enhanced A1200.

Commodore had a volume discount for 8 MB FP DRAM at similar performance to A1200's 140 ns read/write cycle types.

Quote:

@Karlos Commodore wouldn't have released a 25MHz 020 A1200 with 2MB anyway, since they were trying to sell the 4000 030 at the same time.

Psygnosis and David Pleasance argued for improved A1200/CD32.

Jeff Porter argued for 8 MB RAM equipped CD32. Alice's address lines are not designed for 8 MB Chip RAM, hence 6 MB Fast and 2 MB Chip RAM config for extra $20.

Jeff Porter's multimedia group can only tinker around the edges e.g. faster CPU, hardware C2P, DMA CD-ROM controller and 'etc'.

From June 1991, Bill Sydnes' Jeff Frank has Amiga chipset governance before Lew Eggebrecht's Amiga chipset governance.

Quote:

@Karlos I still don't see what this has to do with C2P v Akiko.

A real life costed "What IF" enhanced A1200 or CD32 with a minor price increase.

A stock CD32 is not 3D capable as per 1993 MPC Level 2's 4MB RAM PC game ports.

Stock CD32's config roughly targeted 1991 MPC Level 1's 386SX and 2MB RAM level.

Last edited by Hammer on 22-Dec-2024 at 01:36 AM.
Last edited by Hammer on 22-Dec-2024 at 01:30 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hammer

There are many what-if type threads. The only what-if I care about here is, what if AB3D2 had ran at acceptable* speed on 030/50 when released? After all, that was the original sale pitch.


*Remember, acceptable by the standards of existing Amiga FPS games in the mid 90's.

_________________
Doing stupid things for fun...

@Karlos

It’s not un-reasonable to have different rendering paths for graphics, or different output methods for audio. I do agree that supporting things that make it slower is not a good use of time and energy, however.

Last edited by NutsAboutAmiga on 22-Dec-2024 at 12:03 PM.

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