Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

RETREAM

137
Posts
33
Topics
399
Followers
3
Following
A member registered Sep 07, 2016 · View creator page →

Creator of

Recent community posts

Sure!

A scanso di equivoci e nella speranza di tranquillizzarti, lasciami ribadire che in tutto ciò che ho scritto non c'era nulla di personale: ho solo fornito indicazioni e spiegazioni puramente tecniche; né c'entra alcunché il fatto che io sia l'autore della demo.

Detto ciò, il funzionamento di una CPU non è un punto di vista: è un fatto. Se vuoi saperne di più e capire perché emulare il 68060 non è la scelta migliore (in generale, non solo per la demo), prendi in considerazione le informazioni tecniche che ti ho passato ;)

(1 edit)

Toolkitman, per ragioni di praticità, rispondo con questa unica risposta a tutti i tuoi post.

Innanzitutto, niente di personale (non capisco nemmeno perché tu abbia pensato una cosa del genere): volevo solo darti delle dritte per ottenere l'emulazione più efficiente, spiegando le ragioni tecniche di quanto dicevo.

Per quanto riguarda il discorso tecnico, dalle tue risposte si evince che non hai strumenti sufficienti a comprendere quanto ho scritto. Pertanto, ti consiglio quanto segue:

  • leggi l'appendice D MC68060 INSTRUCTIONS del manuale ufficiale del 68060 (M68060 User's Manual - MC68060UM), che include una tabella riassuntiva di tutte le istruzioni della famiglia M68k e mostra, per ogni processore, quali istruzioni sono supportate, supportate parzialmente o non supportate; lo puoi scaricare da qui;
  • fai riferimento anche al manuale ufficiale del programmatore M68k (M68000 Family Programmer's Reference Manual - M68000PM), che puoi scaricare da qui;
  • studia almeno un pochino di programmazione assembly (non so consigliarti un libro, ma potrebbe esserti utile questa guida introduttiva alla programmazione a basso livello che ho scritto io stesso);
  • torna poi all'MC68060UM e dai un'occhiata alla sezione 8 EXCEPTION PROCESSING e, in particolare, alla sottosezione 8.2.4 Illegal Instruction and Unimplemented Instruction Exceptions;
  • se necessario, magari chiedi aiuto su qualche forum (questo non è il posto adatto e siamo andati già troppo OT).

No, intendevo proprio quello che ho scritto, e cioè: "il 68060 non ha tutte le istruzioni della famiglia M68k". Il 68060 non ha diverse istruzioni che sono invece presenti su 68020, 68030 e 68040 (in realtà, nessuna CPU ha tutte le istruzioni della famiglia M68k, ma in questo contesto mi riferisco alle operazioni intere in modalità utente - per questo ho suggerito delle impostazioni differenti per le operazioni in virgola mobile; non ho toccato il discorso MMU perché è ancora più complicato e l'MMU è raramente usata).

A parte quello, stai confondendo due cose diverse: la velocità dei processori reali e la velocità dei processori emulati. L'emulatore non emula la velocità reale delle CPU (tranne nel caso del 68000, con l'opzione di emulazione accurata), ma invece esegue le operazioni quanto più velocemente può. Perciò, impostare la CPU emulata a 68060 invece che 68020 non darà un'emulazione più veloce, ma al contrario, sarà controproducente per le istruzioni che il 68060 non ha - quando una di quelle istruzioni deve essere eseguita, ciò che accade è che parte un'eccezione e il gestore dell'eccezione (se definito) emula quell'istruzione; ciò non solo è un'operazione di per sé molto lenta (anche su CPU reale, sulla cache del quale ha pure un impatto negativo), ma costringe anche l'emulatore a eseguire molte più operazioni.

(2 edits)

Emulare il 68060 non ti dà maggiori prestazioni, anzi, te ne dà di peggiori perché il 68060 non ha tutte le istruzioni della famiglia M68k e quelle che non ha vengono emulate attraverso eccezioni (che sono molto pesanti computazionalmente).
In generale:
 * se il software non usa l'FPU (come tutte le mie produzioni) -> scegli 68020;
 * se il software usa l'FPU -> scegli 68020+68882 o, secondariamente, 68040.
Probabilmente avevi l'emulazione di CPU e chipset impostate ad "accurate", ma quella emula abbastanza accuratamente solo un A500 (e un po' meno un A1200).

Eh, figurati se le televisioni danno retta a un signor nessuno che poi propone un video anti-sistema...

Si, lo so :)

Il video su YouTube già c'è:

Per quanto riguarda la TV... e come faccio a farcelo arrivare? :D
(1 edit)

Le librerie per 68030 non faranno alcuna differenza, né, in generale, la versione o la configurazione di AmigaOS: la demo lo spegne del tutto e usa l'hardware direttamente. Solo una cosa può influire: se hai l'MMU attiva, allora gli accessi alla RAM (di qualunque tipo) sono rallentati (la demo non va a disabilitare l'MMU).

Aumentare la CHIP RAM non ti servirà: la demo ne usa pochissima (circa 32 kB). Il problema della CHIP RAM è la velocità di accesso: già è lenta di per sé, e poi alcune schede acceleratrici vi accedono con qualche difficoltà. Ad esempio, la mia Blizzard 1230-IV ha un buon accesso alla CHIP RAM, per cui la demo non richiede mai più del 90% della potenza totale dell'intera macchina. Puoi vedere le prestazioni di varie macchine in fondo alla pagina stessa della demo qui su itch.io.

(1 edit)

Messaggio: mi sa che ci stiamo fraintendendo a vicenda :D Comunque, purtroppo il messaggio del video non è stato recepito affatto, e il mondo va sempre peggio.

Problema tecnico: 32 MB sono più che sufficienti; se la demo scattava, il problema era la CPU (o, meno probabilmente, l'accesso alla CHIP RAM). Che scheda di espansione hai? Hai almeno un 68030?

La demo richiede 15 MB di fast: se hai un'espansione da almeno 16 MB, la puoi far girare sull'Amiga reale (godendotela dunque appieno).

Grazie per i complimenti.

Solo una domanda: in che senso il messaggio è stato recepito?

Thank you!

Thanks!

I have now performed various tests under WinUAE (I don't have an A4000), but I can't get the game to crash. Could you provide a report as per my previous reply, please? Also, could you try to run the game after booting without startup-sequence, please?

(1 edit)

Thanks for the feedback. Could you provide a detailed report and your system specifications (hardware, OS, special software, etc.), please? You can write to contact@retream.com.

Sorry, it is not possible because the readme gives instructions precisely regarding the SkillGrid directory (and reflects the CD layout, which includes two directories).

In an AmigaOS environment, all that is needed to install the game is to extract the SkillGrid directory from SkillGrid-WM.lha and put it somewhere. If you don't have AmigaOS, there are tools for Windows and Linux (and most likely also other OSes) for .lha files. In particular, 7-Zip handles .lha files just like .zip files. I don't know how Amiberry works, so I can't give you instructions regarding that. 

Thanks a lot, your mindset is a great display of appreciation :)
Enjoy!

If you're referring to the music in the video, no, that's Man with The Gun by PRESS PLAY ON TAPE:


Sorry, what does "BOC" mean?

Thanks!

(2 edits)

NTSC machines can execute less operations per frame than PAL machines due to the shorter duration of frames (16.67 ms instead of 20 ms). Therefore, NTSC machines are not able to execute all the operations that the game requires each frame, thus causing a frame skip every other frame. The end result is that the game runs at 60/2 = 30 fps (and sprites flicker here and there due to the lost sync, and music gets slow down). On PAL machines, instead, the game never skips a frame, so it runs at 50 fps.

You're welcome!

They're both .lha. The extensions were indeed missing - weird!  Now the problem is fixed. Thanks for reporting.

By the way, if you haven't already, please download the .iso: it contains also those other files and, additionally, the documentation in PDF format (which is easier and more pleasant to read).

Hi, thanks for the proposal, but I have other projects to work on. Best luck with your game!

You're welcome! Glad you appreciate it :)

On NTSC the frame rate is halved (i.e. 30 fps, which means that the game is very slow) and sprites flicker. Unfortunately, NTSC machines are not suitable.

I definitely enjoyed it - that's the whole point of developing this kind of games ;)
Nike weekend to you, too!

Thanks a lot, both for the donations and the intention of buying my software. However, please do feel free to download ;)

As of today, all the RETREAM games are available for free download. No payment will be asked and it will not even be possible to make a donation to RETREAM. However, given the sad events that these days are devastating Ukraine (and the world), it would be nice if who downloads and likes the games also makes a donation (of any kind, in any way) for Ukraine.

Enjoy!

https://retream.itch.io

No, it has not been released yet. Still stuck due to the NVRAM issue, as I couldn't have tests done (see here for more details) :/
Also, unfortunately, in the past few months I couldn't dedicate time to software development - and the same will be in the foreseeable future.

Sorry, I didn't know I was proposing as a solution something that's basically affected by a similar problem!

Cool that you can play the game on other computers :) That said - this is something that occurred to me only once in bed - maybe you could still get it to run on your Mac with Wine (in the past, I did try the Windows version on various Linux machines at it ran just perfectly).

I'm glad you still have the original personal code. If one day you want/need to get the corresponding download link here on itch.io, just go to https://www.retream.com/BOH/get_key.php (BOH landed on itch.io only several years after its initial release, so the original codes need to be "converted" first).

I can't thank you enough for your kind words. It's a great satisfaction to read that you enjoy unusual and complex games like SkillGrid and MAH, and, of course, that you like my games in general :)

I can't wait myself to release the SkillGrid update, but that one last technical hurdle mentioned in the update details is really hard to overcome.

(1 edit)

Thanks a lot for the kind words and the re-purchase! I'm really happy that you like BOH to the point of returning to it even after so many years - and buying it again, even! I hope you'll manage to enjoy the latest version, which, being the result of 10 years of free updates, is much better and richer than the 2009 edition.

Regarding the technical problem: BOH is a 32-bit application and, as far as I know, Apple dropped 32-bit applications support with MacOS 10.15 (see here); I guess that it's what the issue boils down to. Unfortunately, I can't afford to support also platforms that break compatibility (on top of that, after those 10 years of continued development, BOH is now really a closed project). Maybe there's a way to run old applications (I'm not a MacOS user, so I don't know)? Like, for example, DOSBox to run MS-DOS applications on modern Windows systems.

Out of curiosity: given that you had already bought the game, you were entitled to download it from here as well; didn't you get a key code with the original purchase?

Thanks :)

You're welcome, and I hope to release it soon. But that last showstopper mentioned in the post is really hard to overcome...

(4 edits)

If you have an AMIGA CD³², maybe you can help me release SkillGrid v1.1, which is a massively updated version of the game (check out the details in this devlog post).

Apart from the new package artwork (which is being worked on), the only thing that is holding up the release is the new Amiga CD³² NVRAM custom routines: they work under WinUAE, but I have no idea of what happens on real machines. Therefore, I have prepared a proper test suite to have the routines tested... by anyone who feels like giving it a go ;) Not having one of those machines, the fact that they mount different EEPROMs and the lack of official documentation makes developing this stuff quite difficult. Any feedback will be much appreciated.

Click here to download the suite.

This short video shows what the suite does:

(The operations will be surely slower on real machines.)

Technical details below.


--------------------------------------------------------------------------------
OVERVIEW
This is a test suite that purposes to verify whether my custom routines for
direct access to the Amiga CD³² NVRAM work.
Developing them is quite challenging because:
 · I do not have an Amiga CD³², so I have to rely on emulation, which is not
   100% exact;
 · different machines mount different EEPROM chips, which behave differently;
 · there is no official documentation (my references are the documentation that
   has been thankfully produced by who studied the behaviour of Akiko and the
   EEPROM datasheet from ATMEL, the maker of the EEPROM).
The routines work perfectly under emulation, but that is no guarantee that they
work also on real machines. Indeed, previous versions worked under emulation and
on a couple of machines, but failed on another machine.
--------------------------------------------------------------------------------
WHAT DOES THIS DO?
This suite will perform several read/write operations from/to the NVRAM, whose
DATA WILL THUS BE ALTERED (unless the routines fail to access the NVRAM
altogether). At the end, it will attempt to restore the NVRAM data exactly as it
was at the beginning.
Given that the routines are experimental, though, first it will check if a
backup of the NVRAM items exists and ask you whether to make a (new) backup, so
that the NVRAM items can be restored after the tests if the custom restore does
not succeed or execute at all (only OS-compliant NVRAM items will be backed up;
the backup and restore operations are done by means of the OS-legal, reliable,
third-party tools DumpNVRAM and RestoreNVRAM - check out NVRAM_Tools.doc).
You will be informed about the backup status and asked what to do and whether to
continue.
--------------------------------------------------------------------------------
REQUIREMENTS
· An Amiga CD³² with a writable media drive (DO NOT TRY ON OTHER MACHINES)
· The AmigaDOS Delete and Execute commands in the commands path.
--------------------------------------------------------------------------------
INSTRUCTIONS
To perform the tests:
 1. copy the NVRAMRTS directory from the archive to anywhere on the drive;
 2. from shell, enter the NVRAMRTS directory;
 3. run the "test" script and follow the on-screen instructions.
At the end of the tests or if the tests hung:
 1. reboot the machine;
 2. if the NVRAM data is not restored correctly or you are not sure, and a
    backup exists:
     2.1. from shell, enter the NVRAMRTS directory;
     2.2. run the "restore" script;
 3. pack the NVRAMRTS directory into an archive;
 4. send your Amiga CD³²'s specifications(*), the archive and, if the tests
    hung, the color of the screen at that point to postmaster@retream.com.
(*)The marking on the EEPROM would be particularly helpful, but, since that
requires opening the machine, do not worry if you do not feel like going that
far.
Thank you!
--------------------------------------------------------------------------------
THE CORE TOOL
The tests are performed by means of a tool called WriteReadNVRAM. It is a shell
program that allows to access any arbitrary chunk of the Amiga CD³² NVRAM.
It works as follows:
 1. if requested, it writes some data from an input file to the NVRAM;
 2. if requested, it saves some data from NVRAM to an output file.
The shell arguments are:
 · INPUTFILE=IF/K     : input file (unspecified = do not write data to NVRAM)
 · WRITEADDRESS=WA/K/N: NVRAM address in [0, 1023] to start writing from
 · WRITESIZE=WS/K/N   : number of bytes in [1, 1024-WRITEADDRESS] to write
 · OUTPUTFILE=OF/K    : output file (unspecified = do not read data from NVRAM)
 · READADDRESS=RA/K/N : NVRAM address in [0, 1023] to start reading from
 · READSIZE=RS/K/N    : number of bytes in [1, 1024-READADDRESS] to read
 · QUIET/S            : do not print any information to the standard output
These values are used for unspecified arguments:
 · WRITEADDRESS: 0
 · WRITESIZE   : 1024
 · READADDRESS : 0
 · READSIZE    : 1024
These values are used for invalid arguments:
 · WRITEADDRESS: 0
 · WRITESIZE   : 1024-WRITEADDRESS
 · READADDRESS : 0
 · READSIZE    : 1024-READADDRESS
If QUIET is not specified, the following information gets printed:
 · input file   : <input file path, if specified>
 · write address: <(corrected) NVRAM address for writing>
 · write size   : <(corrected) number of bytes for writing>
 · load result  : <result code (see below)>
 · output file  : <output file path, if specified>
 · read address : <(corrected) NVRAM address for reading>
 · read size    : <(corrected) number of bytes for reading>
 · save result  : <result code (see below)>
 · elapsed time : <elapsed time expressed in color clocks>
Result code:
 :| = no load/save
 :( = load/save failed
 :) = load/save succeeded
No data is written to the NVRAM if loading fails.
During execution, AmigaOS is disabled entirely. Also, the screen gets blanked
and repainted dynamically as follows:
 · green: writing;
 · cyan : preparing to read;
 · blue : reading;
 · red  : starting an operation.
THIS TOOL IS BASED ON THE CUSTOM ROUTINES WHOSE VALIDITY IS TO BE VERIFIED WITH
THIS SUITE, SO IT IS BY NO MEANS RELIABLE.

Thank you for letting me know about your kid: it's a joy to hear that :)

Follix community · Posted in Video

Thank you, much appreciated! I'm glad you like it to the point of making a video :)

Thanks you so much! Such words are very meaningful to me :)