- Welcome to CPCWiki forum.
The ultimate Amstrad CPC community!
Recent posts
#1
Quote from: Cwiiis on 14:29, 02 December 22On the off-chance, I tried the 1.0 firmware given I based my circuit on the diagram of the PS/2 circuit, but no change in behaviour. I guess I should learn enough about PIC programming to just write a small debug program to check that the circuit is ok by flashing LED patterns... But I'll exhaust a few more easier, brute-force methods first.I've not read the complete thread - but when using a new MCU / IDE there's always a few issues that will catch you out...Have you configured the "hardware side" of the MCU correctly? normally you have to configure the oscillator type (such as external oscillator / Crystal or ceramic resonator etc), clock path / clock dividers / PLL, ADC, DAC, watchdog timers etc...
Not sure what's required for your MCU, but might be good to write a simple software routine to flash an LED etc. just to see that the MCU hardware configuration is OK (clock frequency etc).
#2
My mistake, sorry
#3
"Basically, that's all" 
#4
The PCB LK are properly set to address the 256K ROM?
#5
Quote from: tjohnson on 12:10, 23 December 20It will fit on a 1001... so I assumed some padding in the CPR file.
Nevertheless, I was using a 2 Mbit Flash and burned an untruncated 256 kB bin file obtained from the CPR file using CPR Tools. Maybe the problem was I used 39SF020 Flash instead of 27C020 / 27C2002 EPROM, but the pinout is compatible.
#6
#7
Music starts at 0:24 and finishes at 4:24
#8
There is no C.
It's pure assembly, but part of it is generated by a C# program (the GnG backoffice) which provides compilation results in assembly code (necessary to speed up the processing during the execution of the game in runtime). This generated code is optimized to the maximum of what I could do.
In this perspective, the hard and soft sprites are compiled in assembler by various engines within a complete backoffice that I wrote in C#.
The assets of the sprites and other images or animations are delivered in GIF files which are consumed by this backoffice which automatically clips them, and processes, arranges, arranges, as necessary.
All the processing of assets, level data, mapping, music and sfx, the management of the global assembly and the preparation of all this in the final CPR file (compression, distribution and addressing of the data in the roms) are done entirely via this backoffice, via a process that allows to assemble everything in a maximum of 10 seconds (if maximum compression) in 1 click.
The implementation of the levels is done via another software, the Level Designer, also written in C#, which proposes a visual interface allowing the graphic designer to deliver his work in the form of tilesets and XML files describing the palettes, the tile mapping, or other elements specific to the game that will be processed by the backoffice.
I write the Z80 code via a simple Notepad++, with which I manage the project and its file tree.
At the end, if I make any modification (code, image, any data or settings), in only one click, the backoffice software prepares everything without any intervention from me, and finally launches either WinAPE by automatically loading the cartridge, or sends the cartridge file to my 6128 PLUS via an M4 card in wifi and automatically starts the amstrad by booting on the game.
For the graphics part, I let Hwikaa explain how he works, if he wants.
The assembler used for the assembly is Edouard Bergé's RASM, which is consumed by the backoffice to assemble the various game elements.
The music and sfx are written by Ixien who works with Arkos Tracker 2.0 from Targhan (Windows). I wrote a custom player in asm Z80 to play the mods and manage the internal PSG and the TotO playcity card if present (which adds two extra PSGs, allowing to have uncut internal channels and spacialized SFX).
Finally, the compression algorithm used is ZX0 by Einar Saukas.
Basically, that's all.
It's pure assembly, but part of it is generated by a C# program (the GnG backoffice) which provides compilation results in assembly code (necessary to speed up the processing during the execution of the game in runtime). This generated code is optimized to the maximum of what I could do.
In this perspective, the hard and soft sprites are compiled in assembler by various engines within a complete backoffice that I wrote in C#.
The assets of the sprites and other images or animations are delivered in GIF files which are consumed by this backoffice which automatically clips them, and processes, arranges, arranges, as necessary.
All the processing of assets, level data, mapping, music and sfx, the management of the global assembly and the preparation of all this in the final CPR file (compression, distribution and addressing of the data in the roms) are done entirely via this backoffice, via a process that allows to assemble everything in a maximum of 10 seconds (if maximum compression) in 1 click.
The implementation of the levels is done via another software, the Level Designer, also written in C#, which proposes a visual interface allowing the graphic designer to deliver his work in the form of tilesets and XML files describing the palettes, the tile mapping, or other elements specific to the game that will be processed by the backoffice.
I write the Z80 code via a simple Notepad++, with which I manage the project and its file tree.
At the end, if I make any modification (code, image, any data or settings), in only one click, the backoffice software prepares everything without any intervention from me, and finally launches either WinAPE by automatically loading the cartridge, or sends the cartridge file to my 6128 PLUS via an M4 card in wifi and automatically starts the amstrad by booting on the game.
For the graphics part, I let Hwikaa explain how he works, if he wants.
The assembler used for the assembly is Edouard Bergé's RASM, which is consumed by the backoffice to assemble the various game elements.
The music and sfx are written by Ixien who works with Arkos Tracker 2.0 from Targhan (Windows). I wrote a custom player in asm Z80 to play the mods and manage the internal PSG and the TotO playcity card if present (which adds two extra PSGs, allowing to have uncut internal channels and spacialized SFX).
Finally, the compression algorithm used is ZX0 by Einar Saukas.
Basically, that's all.
#9
Quote from: Golem13 on 17:36, 18 May 21Impresionante, no podemos esperar más, me gustaría preguntarte, ¿con qué herramienta dibujas las escenas y los sprites? ¿Qué haces exactamente en C y Rasm?Quote from: Otto on 17:17, 18 May 21Muy impresionante, desde la perspectiva de la programación y desde la perspectiva gráfica.
¿Con qué lenguaje de computadora está escrito el juego? Ensamblador, C, Pascal, ...?
Es 100% ensamblador, escrito desde cero.
Todo el código está escrito por mí mismo, y parte de él es generado por un back office también escrito por mí. Se encarga de compilar, preparar, formatear los datos necesarios (gráficos como tablero, música y sonidos como mods ArkosTrackers). Está escrito en C# y se ejecuta bajo Windows.
Todo el código finalmente se ensambla con el potente ensamblador RASM de Roudoudou.
Solo importé tres rutinas externas, la compresión/descompresión ZX0 y LZ48, y el código del reproductor Arkos Tracker. Naturalmente, me encargué de modificar estos códigos, para que encajaran perfectamente y satisfagan exactamente las necesidades del juego.
Para la emulación, trabajo principalmente con WinAPE, que sigue siendo la mejor opción en términos de programación gracias a su interfaz de depuración y rastreo muy potente. Lo uso como una máquina de ejecución porque desarrollo con un simple NotePad++. Para probar en una máquina real, utilizo un Amstrad 6128 PLUS y una tarjeta M4.
El backoffice, sin intervención humana desde el principio hasta el final de la generación de la RCP final, se encarga de enviar el cartucho ya sea a WinAPE o a la máquina real en Wifi, automáticamente. El proceso totalmente industrializado tarda
Gracias por su trabajo, estamos deseando que llegue.
#10
Quote from: Golem13 on 17:36, 18 May 21Quote from: Otto on 17:17, 18 May 21Muy impresionante, desde la perspectiva de la programación y desde la perspectiva gráfica.
¿Con qué lenguaje de computadora está escrito el juego? Ensamblador, C, Pascal, ...?
Es 100% ensamblador, escrito desde cero.
Todo el código está escrito por mí mismo, y parte de él es generado por un back office también escrito por mí. Se encarga de compilar, preparar, formatear los datos necesarios (gráficos como tablero, música y sonidos como mods ArkosTrackers). Está escrito en C# y se ejecuta bajo Windows.
Todo el código finalmente se ensambla con el potente ensamblador RASM de Roudoudou.
Solo importé tres rutinas externas, la compresión/descompresión ZX0 y LZ48, y el código del reproductor Arkos Tracker. Naturalmente, me encargué de modificar estos códigos, para que encajaran perfectamente y satisfagan exactamente las necesidades del juego.
Para la emulación, trabajo principalmente con WinAPE, que sigue siendo la mejor opción en términos de programación gracias a su interfaz de depuración y rastreo muy potente. Lo uso como una máquina de ejecución porque desarrollo con un simple NotePad++. Para probar en una máquina real, utilizo un Amstrad 6128 PLUS y una tarjeta M4.
El backoffice, sin intervención humana desde el principio hasta el final de la generación de la RCP final, se encarga de enviar el cartucho ya sea a WinAPE o a la máquina real en Wifi, automáticamente. El proceso totalmente industrializado tarda de 10 a 15 segundos con un solo clic.
Impressive, we can't wait any longer, I would like to ask you, with what tool do you draw the scenes and sprites? what do you do in C and Rasm exactly?
Thank you for your work, we are looking forward to it.