25.06 20:21
[#1]
Command & Conquer na Amigę 500?
Ciekawe czy dałoby się zaadoptować na nasze podwórko
https://indyjo.itch.io/commandconquer
https://indyjo.itch.io/commandconquer
25.06 20:46
[#3]
Re: Command & Conquer na Amigę 500?
@Norbert, post #2
Tylko, ze port na Atari STE dziala z 10MB RAM i 68000 8 MHz.
A port Arcziego ma duzo wyzsze wymagania.
Jesli to rzeczywiscie dziala OK, na takim Atari STE, to byc moze port na Amiga 500/600 2MB chip i 8 MB fast jest mozliwy.
Choc nie wiem jak tam jest z blitterem, bo Amigowy tylko 2MB chip max obsluguje, a moze potrzebne byc wiecej.
No i swiadczyloby to tez o dobrym wykorzystania AI przez autora portu.
No i nazwa jest wlasciwa, nie jakas tam VanillaConquer , ktora sie kojarzy ze zdobywaniem przypraw do pieczenia.
Ostatnia aktualizacja: 25.06.2026 20:49:12 przez Don_Adan
A port Arcziego ma duzo wyzsze wymagania.
Jesli to rzeczywiscie dziala OK, na takim Atari STE, to byc moze port na Amiga 500/600 2MB chip i 8 MB fast jest mozliwy.
Choc nie wiem jak tam jest z blitterem, bo Amigowy tylko 2MB chip max obsluguje, a moze potrzebne byc wiecej.
No i swiadczyloby to tez o dobrym wykorzystania AI przez autora portu.
No i nazwa jest wlasciwa, nie jakas tam VanillaConquer , ktora sie kojarzy ze zdobywaniem przypraw do pieczenia.
Ostatnia aktualizacja: 25.06.2026 20:49:12 przez Don_Adan
26.06 04:20
[#9]
Re: Command & Conquer na Amigę 500?
@dynx, post #4
Tego to nie wiem, bo nie widzialem tego portu w akcji, byc moze to jest kwestia samej logiki gry, ze jest za ciezka dla 68000 8MHz.
A byc moze ilosci blitowanej grafiki.
Przy dobrze zrobionej grafice to 16 kolorow wystarcza dla A500, przyklad to chocby Grind.
A jest wtedy szybciej i mniej chipu potrzeba.
Dune 2 dziala na A500 calkiem dobrze i calkiem niezle wyglada.
A to jest gra tego samego Westwood Studio.
Oczywiscie to musi byc port w Low Res czyli 320x200 (320x240 max), o ile gra ma mozliwosc ustawienia takiej rozdzielczosci.
Zadnego AHI, tylko Protracker i SFX, lub same SFX.
Ale konfig z 10MB pamieci i HD w A500 (bez karty turbo) to jednak duza nisza jest, moze z 0.01% albo i mniej.
A byc moze ilosci blitowanej grafiki.
Przy dobrze zrobionej grafice to 16 kolorow wystarcza dla A500, przyklad to chocby Grind.
A jest wtedy szybciej i mniej chipu potrzeba.
Dune 2 dziala na A500 calkiem dobrze i calkiem niezle wyglada.
A to jest gra tego samego Westwood Studio.
Oczywiscie to musi byc port w Low Res czyli 320x200 (320x240 max), o ile gra ma mozliwosc ustawienia takiej rozdzielczosci.
Zadnego AHI, tylko Protracker i SFX, lub same SFX.
Ale konfig z 10MB pamieci i HD w A500 (bez karty turbo) to jednak duza nisza jest, moze z 0.01% albo i mniej.
27.06 00:21
[#18]
Re: Command & Conquer na Amigę 500?
@Katarzyna, post #17
Ciekawe, wygląda na to, że z włożonym fastramem na płycie gra z niego korzysta zamiast korzystać z pamięci na karcie akceleratora. A fastram na płycie jest dużo wolniejszy. Ktoś potrafi wyjaśnić dlaczego gra wybiera wolniejszą pamięć?
Robiłem kiedyś takie testy ale musiałem wtedy zapchać cały fastram akceleratora i doom zaczynał chodzić jak ślimak kiedy został mu sam fastram na płycie.
Robiłem kiedyś takie testy ale musiałem wtedy zapchać cały fastram akceleratora i doom zaczynał chodzić jak ślimak kiedy został mu sam fastram na płycie.
27.06 01:44
[#19]
Re: Command & Conquer na Amigę 500?
@bfgmatik, post #18
Trzeba by sprawdzić jakie priorytety mają poszczególne pamięci, bo może tej na płycie system przydzielił wyższy. Zasada, że szybsza pamięć dostaje wyższy priorytet chyba nie zawsze działa. Kiedyś już się spotkałem z podobną sytuacja na mojej A4000, nie pamiętam o jaki program lub grę chodziło. Komenda "Setmempri" z Aminet'u rozwiązywała problem.
27.06 09:33
[#21]
Re: Command & Conquer na Amigę 500?
@bfgmatik, post #18
Najprawdopodobniej bledny/zbedny atrybut uzywany przez autora portu do alokacji pamieci fast.
Ten sam problem jest z portem MK3.
Alokuje sie ANY memory, a nie jakis specyficzny fast.
Tylko MEMF_CHIP powinno byc ustawione, o ile potrzebny jest zaalokowany chip.
Trzeba by zobaczyc jakich atrybutow, uzywa autor portu przy alokacji pamieci fast.
Ten sam problem jest z portem MK3.
Alokuje sie ANY memory, a nie jakis specyficzny fast.
attributes -
requirements
If no flags are set, the system will return the best
available memory block. For expanded systems, the fast
memory pool is searched first.
MEMF_CHIP: If the requested memory will be used by
the Amiga custom chips, this flag *must*
be set.
Only certain parts of memory are reachable
by the special chip sets' DMA circuitry.
Chip DMA includes screen memory, images that
are blitted, audio data, copper lists, sprites
and Pre-V36 trackdisk.device buffers.
MEMF_FAST: This is non-chip memory. If no flag is set
MEMF_FAST is taken as the default.
DO NOT SPECIFY MEMF_FAST unless you know
exactly what you are doing! If MEMF_FAST is
set, AllocMem() will fail on machines that
only have chip memory! This flag may not
be set when MEMF_CHIP is set.
MEMF_PUBLIC: Memory that must not be mapped, swapped,
or otherwise made non-addressable. ALL
MEMORY THAT IS REFERENCED VIA INTERRUPTS
AND/OR BY OTHER TASKS MUST BE EITHER PUBLIC
OR LOCKED INTO MEMORY! This includes both
code and data.
MEMF_LOCAL: This is memory that will not go away
after the CPU RESET instruction. Normally,
autoconfig memory boards become unavailable
after RESET while motherboard memory
may still be available. This memory type
is now automatically set in V36. Pre-V36
systems may not have this memory type
and AllocMem() will then fail.
MEMF_24BITDMA: This is memory that is within the address
range of 24-bit DMA devices. (Zorro-II)
This is required if you run a Zorro-II
DMA device on a machine that has memory
beyond the 24-bit addressing limit of
Zorro-II. This memory type
is now automatically set in V36. Pre-V36
systems may not have this memory type
and AllocMem() will then fail.Tylko MEMF_CHIP powinno byc ustawione, o ile potrzebny jest zaalokowany chip.
Trzeba by zobaczyc jakich atrybutow, uzywa autor portu przy alokacji pamieci fast.
27.06 11:57
[#23]
Re: Command & Conquer na Amigę 500?
@Artur Jarosik, post #22
Skoro tak, i D1=0, to moze D1=1 jednak musi byc ustawione?
Chyba, ze jakis blad w kompilatorze jest, i co innego generuje?
Edycja
Bo to powinno dzialac tak jak jest tutaj napisane.
Ostatnia aktualizacja: 27.06.2026 12:02:05 przez Don_Adan
Chyba, ze jakis blad w kompilatorze jest, i co innego generuje?
Edycja
MEMF_ANY to flaga alokacji pamięci w systemie AmigaOS (używana m.in. w funkcjach AllocMem i AllocVec), która oznacza brak specjalnych wymagań co do typu pamięci. System przydziela najszybszą dostępną pamięć (zazwyczaj Fast RAM), a jeśli jest niedostępna – przydzieli wolniejszą (Chip RAM).
Bo to powinno dzialac tak jak jest tutaj napisane.
Ostatnia aktualizacja: 27.06.2026 12:02:05 przez Don_Adan
27.06 12:24
[#26]
Re: Command & Conquer na Amigę 500?
@Don_Adan, post #23
EXAMPLES
AllocMem(64,0L) - Allocate the best available memory
AllocMem(25,MEMF_CLEAR) - Allocate the best available memory, and
clear it before returning.Jednak to musi byc 0, czyli dobrze pamietalem.
Tylko, ze ja nigdy bitow nie ustawialem, a dawalem po prostu w asemblerze.
moveq #0,D1
Bo jezeli to jest np BSET na D1, to juz wynik moze byc inny.
Zreszta jak mozna ustawic 0 jako bit, zeby D1=0?
NIe da sie.
Moze daj tam moveq#0,D1 zamiast tego MEMF_ANY ?
27.06 12:39
[#28]
Re: Command & Conquer na Amigę 500?
@Artur Jarosik, post #25
Nie trzeba,samemu ustawiac, bo przeciez Buli uzywa wielu innych programow, i mu dzialaja bez problemu, z ta jego pamiecia.
Przeczytaj:
link
Wiec problem jest w procedurze alokujacej pamiec.
Edycja.
Albo exec gry ladujesz do fast, czyli $40 zamiast $00 w stworzonym exeku.
Bledne parametry kompilacji.
Ostatnia aktualizacja: 27.06.2026 12:42:38 przez Don_Adan
Przeczytaj:
link
Wiec problem jest w procedurze alokujacej pamiec.
Edycja.
Albo exec gry ladujesz do fast, czyli $40 zamiast $00 w stworzonym exeku.
Bledne parametry kompilacji.
Ostatnia aktualizacja: 27.06.2026 12:42:38 przez Don_Adan
27.06 17:33
[#30]
Re: Command & Conquer na Amigę 500?
@Don_Adan, post #28
Przeczytalem jeszcze raz co pisal Buli, i o ile dobrze zrozumialem, to nie jest to problem alokacji pamieci przez exec library, ale problem z alokowaniem pamieci przez dos library dla exeka gry.
I tutaj exek gry sie laduje do tej pamieci.
Exek (jego poszczegolne hunki) na Amidze moga sie ladowac:
do kazdej pamieci (pierwszy bajt danego hunka jest wtedy $00),
do chipu (pierwszy bajt danego hunka jest wtedy $40),
do fastu (pierwszy bajt danego hunka jest wtedy $80).
Hunki zaczynajace sie od $80 to sa bardzo rzadkie przypadki, ja moze parenascie razy taki hunk widzialem w grze/demie.
Ogolnie powinno byc wtedy $00, a nie $80 uzywane.
Jesli to o to chodzi, to zamiast CODE_F/DATA_F/BSS_F, trzeba uzywac CODE/DATA/BSS.
Wiec to kwestia ustawien kompilatora/assemblera lub linkera.
I tutaj exek gry sie laduje do tej pamieci.
Exek (jego poszczegolne hunki) na Amidze moga sie ladowac:
do kazdej pamieci (pierwszy bajt danego hunka jest wtedy $00),
do chipu (pierwszy bajt danego hunka jest wtedy $40),
do fastu (pierwszy bajt danego hunka jest wtedy $80).
Hunki zaczynajace sie od $80 to sa bardzo rzadkie przypadki, ja moze parenascie razy taki hunk widzialem w grze/demie.
Ogolnie powinno byc wtedy $00, a nie $80 uzywane.
Jesli to o to chodzi, to zamiast CODE_F/DATA_F/BSS_F, trzeba uzywac CODE/DATA/BSS.
Wiec to kwestia ustawien kompilatora/assemblera lub linkera.