Atirez

Thanks, that clears it all up very nicely!

Thanks for the pointer, however I think that is somewhat beyond me - just cant seem to get my head around what it is actually doing. That is, throwing away all of the superfluous stuff such as converting screen values in to BE and DC. What I am trying to find out is; fundamentally what portions of memory is it setting with what values to be able to set the small block on screen.

Hi, I am hoping someone can help me find out how to call these functions in assembly. With PSET in basic I can set a 2x3 grid per character position on screen, but all I have been able to do is set characters and backgrounds directly through screen memory. I tried to find the assembly code for the basic commands but seem to be struggling. Thanks

Hmm that is interesting, it must be getting optimised somewhere. I will look in to that.

Sounds like a plan, just need to find a cheap 4k cartidge . Thanks for the help.

Hi Martin, yeah it is all in the linker file. -mjwx -i out\final\application.ihx -b _CODE = 0xe000 -b _DATA = 0xf000 -k C:\RETRO\COMPILERS\SDCC\bin\..\lib\z80 -l z80 out\bootstrap.asm out\data.asm out\notmain.rel -e With this setup I feel a lot more in control of how my assembler/c code is working and it give me better listings in the output, since sdcc providers .rst files I do not seem to need to object dump them anymore. For example: extern char aletter; void notmain(void) { char *screen; screen = (char*)0x3028; aletter = 66; *screen = aletter; while(1) { } } Produces this code with the addresses updated after linking. E016 48 _notmain_start:: E016 49 _notmain: 50 ;source/notmain.c:8: aletter = 66; E016 21 15 E0 [10] 51 ld hl,#_aletter + 0 E019 36 42 [10] 52 ld (hl), #0x42 53 ;source/notmain.c:9: *screen = aletter; E01B 21 28 30 [10] 54 ld hl,#0x3028 E01E 36 42 [10] 55 ld (hl),#0x42 56 ;source/notmain.c:11: while(1) { E020 57 00102$: E020 18 FE [12] 58 jr 00102$ E022 59 _notmain_end:: 60 .area _CODE 61 .area _INITIALIZER 62 .area _CABS (ABS) The only problem I have now is that global variables do not seem to be getting initialised and I do not seem to be able to change their values in code.

Perhaps this is the wrong place to post this but you seem to have a lot of knowledge about creating cartridges/electronics stuff. I was wondering how would I go about creating a board that could plug in to the aquarius cartridge slot using home electronics equipment? I dont need to print PCBs or anything, I just wanted to get to know the system better so was going to try and hook up the aquarius to the raspberry pi (via GPIO) but need to build the connector to fit the aquarius.

Hi all, I am somewhat new to all of this. However I am having a few issues getting some things to work as expected. Basically if I define: char buffer[960] = {1}; I expect that all the elements of the array will be initialised as 1 in this global variable. However printing the contents on screen: char *screen; screen = (char*)0x3028; // character scren memory start address *screen = buffer[0]; It displays a black background at position zero on screen, this is on an aquarius, zero = black, 1 = red. It doesnt seem that the arrays or indeed any global variables are being initialised :/. Perhaps I am doing something wrong in compilation? I am building each file as a .rel (relocatable object) and linking them myself with: sdcc -mz80 --no-std-crt0 --compile-only -o out/ source/notmain.c sdld -m -u -f link.lk The link.lk contains: -mjwx -i out\final\hello.ihx -b _CODE = 0xe000 -b _DATA = 0xf000 -k C:\RETRO\COMPILERS\SDCC\bin\..\lib\z80 -l z80 out\notmain.rel -e Finally I noticed in the .rst file that the data initialisation code is being produced it just doens't seem be getting run... F3C2 70 __xinit__screen_map: F3C2 01 71 .db #0x01 ; 1 F3C3 00 72 .db 0x00 ...

Scratch that, I think I have got there - was mostly being stupid :/ Now I have: bootstrap.asm .module bootstrap .z80 .optsdcc -mz80 .globl _notmain _main: .db 98, 97, 114, 114 .db 121, 156, 106, 176 .db 111, 108, 110, 100 .db 101, 168, 199, 112 call _notmain hang: jr hang notmain.c unsigned int x(unsigned int x); extern void notmain(void) { unsigned int n = 0; n = x(1); while(1) { } } x.c unsigned int x(unsigned int x) { unsigned int y; unsigned int n = 5; y = x - n; return y + 2; } build.bat @echo off rem set the current working directory to the same location as the batch file pushd "%~dp0" cd ../ call sdcc_paths.bat rem set the current working directory to the same location as the batch file pushd "%~dp0" rem build stuff rem .rel are .o files sdasz80 -l -o -s out/bootstrap bootstrap sdcc -mz80 --no-std-crt0 --compile-only -o out/ notmain.c sdcc -mz80 --no-std-crt0 --compile-only -o out/ x.c sdld -u -i out/1 out/bootstrap.asm out/notmain.rel out/x.rel hex2bin -p 00 -l 4000 out/1.ihx Needed some extra options on the command line stuff and to use the linker. If at all possible though, could someone help me with the different sections that the z80asm expects/requires and help me understand the .org directive. I thought .org was used to tell the assembler to organise the data from that location, but my output in the final binary file seems to jam in to that location. So if I do have this eventually running on an aquarius it will load my file up to 0xE000 (from memory may be wrong) and find nothing there...

Hi all, first post so my apologies if this is covered else where but I could't find it. Having recieved my childhood Aquarius from my parents attic I would like to get in to programming some games/stuff for it but have been struggling to get a nice tool chain to compile, link, deploy anything. What I am trying to do. I would like to be able to do the following: Compile my assembler code with an assembler to an object file Compile my c code to an object file Use a linker to link the files together Finally produce a binary file from the resulting linker files Also I would like to dump the machine code the compiler has generated from my code for debugging/learning purposes. Something like objdump provided in gcc. What I have tried I have tried several compilers including sd88k, sdcc but (and this may be due to lack of knowledge) have been unable to get these to do that. The sdcc does have a seperate assembler and c compiler however the assembler is also a linker, it produces .lst files which I assume are the generated assembly instructions from the compiler after any optomisation but it doesn't look right - again could just be me. Finally I have the PDF from Zilog describing the instruction set but can not find out any information about the sections that the assembler should be producing the sdcc produces some but I can not find out any information about them. This is what I have been messing around with at the moment bootstrap.s .module bootstrap .optsdcc -mz80 .area HOME (abs) .org #0x8000 .globl _main .globl _notmain ;-------------------------------------------------------- ; Home ;-------------------------------------------------------- .area _HOME .area _HOME ;-------------------------------------------------------- ; code ;-------------------------------------------------------- .area _CODE _main: .db 98, 97, 114, 114 .db 121, 156, 106, 176 .db 111, 108, 110, 100 .db 101, 168, 199, 112 jr _notmain hang: jr hang notmain.c unsigned int x(unsigned int x); void notmain(void) { unsigned int n = 0; n = x(1); while(1) { } } x.c unsigned int x(unsigned int x) { unsigned int y; unsigned int n = 5; y = x - n; return y + 2; } Batch file for building @echo off rem set the current working directory to the same location as the batch file pushd "%~dp0" cd ../ call sdcc_paths.bat rem set the current working directory to the same location as the batch file pushd "%~dp0" rem build stuff rem .rel are .o files sdasz80 -l -o out/bootstrap.rel bootstrap.s sdcc -mz80 -c -o out/notmain.rel notmain.c sdcc -mz80 -c -o out/x.rel x.c sdcc -o out/helloworld.ihx out/bootstrap.rel out/notmain.rel out/x.rel packihx out/helloworld.ihx > out/helloworld.hex hex2bin -p 00 -l 4000 out/helloworld.ihx The reason I have random methods in different files was to test linking. Anyway, when trying to run that it doesn't work, it correctly jumps to main but then the address to jump to the method x is incorrect and it jumps to far in memory (using Z80 Simulator IDE)