hi! I'm curious about coding stuff for gx4000, specially via Pasmo (assembly) or Boriel's ZX-Basic (basic, assembly or both - i have a special interest on this one, since i'm interested on help extending it to all z80 machines)
The situation is that i don't know what to start trying to compile as ready tutorial examples, or documentation that might be helpful.
From what i tried to run those few games available on Mess, it seems not having a rom bios, so the rom start needs interrupt vector routines like master system, sg1000 and gamegear does? And why they need to be 128kb large? (anyway, i guess that memory paging for allowing cartridges up to 2 or 4mb might be possible electronically, but there are no emulators supporting it since there are no games using such paging?)
And about the rom start, is that possible or simple that our developed code can start at 0x0069, as i were doing for sg1000, master system and gamegear?
And i heard somewhere that the roms has some kind of encription or checksum (that "acid" chip?), and perhaps there might be some way to bypass this and make more easier to create homebrew stuff?
Please let me know how simple and possible is to do this, because it is quite sad seeing gx4000 being so empty of available titles, so i guess would be great homebrew stuff might have a great presence there
Quote from: nitrofurano on 17:17, 12 August 14
hi! I'm curious about coding stuff for gx4000, specially via Pasmo (assembly) or Boriel's ZX-Basic (basic, assembly or both - i have a special interest on this one, since i'm interested on help extending it to all z80 machines)
cool!
Quote from: nitrofurano on 17:17, 12 August 14
The situation is that i don't know what to start trying to compile as ready tutorial examples, or documentation that might be helpful.
Go to Unofficial Amstrad WWW Resource (http://www.cpctech.org.uk/source.html)
look for "An example setup for an Amstrad Plus/GX4000 cartridge".
The way my website is setup, I can't give a direct link, the redirect puts frames and that gets in the way of me copying and pasting direct links :(
My website has quite a selection of code showing how to do scrolling, split screen etc.
Also look on the docs section for "Arnold V" documentation. Also here on the wiki with some updates.
Also I and others are happy to answer any programming questions.
Quote from: nitrofurano on 17:17, 12 August 14
From what i tried to run those few games available on Mess, it seems not having a rom bios, so the rom start needs interrupt vector routines like master system, sg1000 and gamegear does? And why they need to be 128kb large? (anyway, i guess that memory paging for allowing cartridges up to 2 or 4mb might be possible electronically, but there are no emulators supporting it since there are no games using such paging?)
Correct. No bios.
You need some basic code to setup the hardware then you're ready to go.
512KB is the max without any extra hardware. The cartridge port has very limited signals so it is much harder to expand. You would need to use reads of specific memory addresses if you wanted to make larger cartridges.
Quote from: nitrofurano on 17:17, 12 August 14
And about the rom start, is that possible or simple that our developed code can start at 0x0069, as i were doing for sg1000, master system and gamegear?
it calls 0x0000. There is no rom header. So you can do a "JP 0x0069" at the beginning?
Quote from: nitrofurano on 17:17, 12 August 14
And i heard somewhere that the roms has some kind of encription or checksum (that "acid" chip?), and perhaps there might be some way to bypass this and make more easier to create homebrew stuff?
no encryption and no checksum.
The cartridge requires the acid chip inside it, if the acid and asic don't communicate the asic feeds z80 bad data and the game crashes.
So yes, it is required in some form. There is a simple piece of hardware Nilquader made which can make the asic work without an acid, but it's not always reliable. The best is a CPLD implementation of the acid. Again this code is available on the wiki.
Quote from: nitrofurano on 17:17, 12 August 14
Please let me know how simple and possible is to do this, because it is quite sad seeing gx4000 being so empty of available titles, so i guess would be great homebrew stuff might have a great presence there
agreed.
It has been discussed before.
We need cartridge cases/shells (can be extracted from existing carts if you really want), pcbs and acid replacements/alternatives (again can be extracted from existing carts - if you do, please use burning rubber ;) ). So far there are some pcb designs, there is some acid replacement as cpld, but not put together and no cartridge cases either. There was talk of making them but nothing has materialised. It is sad :(
512K may still be quite more than enough to get huge games...
remember you can use some RAM to uncompress stuffs when needed.
Anyway I think such a big game should really include "drivers" so it can as well provide support for the PLUS (keyboards, Disk/Tape, Extra RAM) and be sure you also manage some extra peripherals (Mouse ? Analog port ? PlayCity ?) as well.
Quote from: arnoldemu on 17:43, 12 August 14
look for "An example setup for an Amstrad Plus/GX4000 cartridge".
The way my website is setup, I can't give a direct link, the redirect puts frames and that gets in the way of me copying and pasting direct links :(
Link (http://cpctech.cpc-live.com/source/cart.html) ;)
Quote from: arnoldemu on 17:43, 12 August 14
it calls 0x0000. There is no rom header. So you can do a "JP 0x0069" at the beginning?
what i have for Master System, Game Gear and SG1000 coded on Boriel's ZXBasic is this: (my concern is, since gx4000 is a z80, and the 0x00?8 (specially 0x0038 in the sega's 8bit consoles - i can't remember what 0x0066 is, perhaps start/pause button ) are interrupt vectors used from z80 by default, and the cartridge starts at 0x0000, it seems to have the same situation)./library/smsboot.bas
asm
org $0000
boot:
di
im 1
ld sp,$dff0
jp main
pause:
push af
ld a,$ff
ld ($C000),a
pop af
retn
org $0038
push af
in a,($bf)
pop af
ei
reti
org $0066
jp pause
org $0070
main:
defb 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
defb 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
defb 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
defb 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
end asm
(btw, the code there is actually starting at $0070, but it could be $0069, since "jp pause" takes 3 bytes starting from $0066 )
(the stuff i have for sega's 8bit consoles can be find at Homebrew - SMS Power! (http://www.smspower.org/Homebrew/Index?q=$:Platform=SG) from "nitrofurano", with sources - i imagine that can be somehow a good start for gx4000 )
so the idea is to code gx4000 stuff in this same process
QuoteWe need cartridge cases/shells (can be extracted from existing carts if you really want), pcbs and acid replacements/alternatives (again can be extracted from existing carts - if you do, please use burning rubber ). So far there are some pcb designs, there is some acid replacement as cpld, but not put together and no cartridge cases either. There was talk of making them but nothing has materialised. It is sad
btw, did some make, or can make, models from these cases/shells for 3d printing, like Nes Cartridge (incl. Freecad model) by deepthought - Thingiverse (http://www.thingiverse.com/thing:143434) ? would be amazing! :)
You can use similar code to this yes.
The NMI (0x0066) is not used on GX4000.
On GX4000 it becomes a little more complex because you can:
1. Disable the ROM so that you can use the ram in the area &0000-&3fff.
2. You can choose which of 8 cartridge pages (16KB each) is at &0000-&3fff, so you could have a interrupt handler in each cartridge page.
3. Some cartridge ROM is accessible in the range &c000-&ffff.
Quote from: nitrofurano on 13:50, 13 August 14
btw, did some make, or can make, models from these cases/shells for 3d printing, like Nes Cartridge (incl. Freecad model) by deepthought - Thingiverse (http://www.thingiverse.com/thing:143434) ? would be amazing! :)
Yes that would be great.
I did give the dimensions of the case in another forum post. I don't know if somebody made a freecad model or not, they are free to use my information to make one ;)
I downloaded one of your productions.
I see the asm code and the .bas code.
I see your makefile/batch file.
So you can do a similar thing for mess/winape.
assemble it, use buildcpr tool and you have your cartridge you can use in mess/winape. If you want to burn it onto a rom for a real cartridge use the original binary file.
You will need to use a different library because the graphic chips are different compared to sms, but that is ok and I expected this.
So I think you will have fun writing for gx4000 in this way.
btw, above, at 0x0038 what i have is related to "halt" for waitvbl - do gx4000 uses similar thing? (meaning, sorry for my ignorance about amstrad and gx4000, is it possible or should we add something for using "halt" as waitvbl, or we should only use delays with decrementing bc registers instead? )
a question: for example, how easy is to "convert" these 16kb cartridges into gx4000-compatible?
16k ROM game development competition – finished | The Amstrad CPC news portal (http://www.octoate.de/wp/2013/07/02/16k-rom-game-development-competition-finished/)
Quote from: arnoldemu on 13:58, 13 August 14
Yes that would be great.
I did give the dimensions of the case in another forum post. I don't know if somebody made a freecad model or not, they are free to use my information to make one ;)
where from can we find it? perhaps i can start to do something on Blender, and someone else can convert it to 3d printing files - i only don't know how accurate they will become
my first test (not working, perhaps i'm missing something...)
btw, via that .sh bash script, i'm finding that Mess emulator is opening rom files with the sizes 16kb, 32kb, 64kb, 128kb, 256kb and 512kb - 1024kb and above it shows segmentation error from terminal
so, what i wanted to do is to add some working example - the problem is that i'm a real newbie on coding on both amstrad and gx4000 this way! :D (and i'm struggling a lot to understand the examples available up to now - so if someone can help, please do, and thanks in advance! :) )
Are you referring to ROMs or cartridges? Carts can't really get bigger than 512kB.
Quote from: nitrofurano on 14:47, 13 August 14
my first test (not working, perhaps i'm missing something...)
first build a cpr file using buildcpr. On my website under download section.
Unofficial Amstrad WWW Resource (http://www.cpctech.org.uk/download.html)
http://www.cpctech.org.uk/download/buildcpr.zip (http://www.cpctech.org.uk/download/buildcpr.zip)
Quote from: mahlemiut on 00:14, 15 August 14Are you referring to ROMs or cartridges? Carts can't really get bigger than 512kB.
in this case would be roms (but i guess it would apply on cartridge as well.
i think that once, Eduardo Robsy (Pitpan at Karoshi's msx forum), theoretically, the paging access can be almost infinite if we use msx/sega paging system (poking on rom areas that a paging chip would detect) applied on the cartridges (like 4mb using 1 byte for paging 16kb areas, 1gb (!) if we use 2 bytes, etc. ), so i guess it seems electronically possible, but a bit out of conventions or having default support from emulators
Quote from: arnoldemu on 08:56, 15 August 14first build a cpr file using buildcpr. On my website under download section.Unofficial Amstrad WWW Resource (http://www.cpctech.org.uk/download.html)http://www.cpctech.org.uk/download/buildcpr.zip
thanks, i'll try this soon, still today! :) - btw, what is the difference between cpr and bin files, related to emulators? i saw that cpr has a header added on the bin file, but i don't know what is that used for
(this comment here was redundant and i erased it - how can we delete it?)
Quote from: arnoldemu on 08:56, 15 August 14
first build a cpr file using buildcpr. On my website under download section.
Unofficial Amstrad WWW Resource (http://www.cpctech.org.uk/download.html)
http://www.cpctech.org.uk/download/buildcpr.zip (http://www.cpctech.org.uk/download/buildcpr.zip)
thanks! i compiled and installed it fine with "make" and "sudo cp buildcpr /usr/bin/", and works fine on the script
the problem i think is on the example i tried to compile, the .cpr behaves just like the previous .bin , just a black screen appears (perhaps i'm missing something there, i just want to display a random display dump, or a "hello world", or something, for now)
Quote from: nitrofurano on 11:52, 15 August 14
thanks! i compiled and installed it fine with "make" and "sudo cp buildcpr /usr/bin/", and works fine on the script
the problem i think is on the example i tried to compile, the .cpr behaves just like the previous .bin , just a black screen appears (perhaps i'm missing something there, i just want to display a random display dump, or a "hello world", or something, for now)
In the generated asm:
__START_PROGRAM:
di
push ix
push iy
exx
push hl
exx
ld hl, 0
add hl, sp
ld (__CALL_BACK__), hl
ei <<<<<<<
there is an ei here to re-enable interrupts.
After boot is finished, cartridge rom is still active in range &0000-&3fff. So when interrupt happens it will execute interrupt handler at &0038.
You will get a crash because the gx4000boot is not setup for this.
2. Your code is sitting in rom. __CALL_BACK__ variable in the asm will be in rom. It's read-only. It's value will not change. This will not work!
3. I am confused by ZXBASIC_USER_DATA. Is it relocated into RAM? The loop in your basic program stores it's value in ZXBASIC_USER_DATA. But because it's in ROM it's value is read-only and will never change, it will never go past 0. This will fail.
4. Is gx4000boot.bas filled so it goes up to 128? Your code assumes it running from 128 and you are using cat to join them. gx4000boot binary must be 128 bytes exactly. If not, it will fail.
Other solutions:
Your code is copied to ram. (Example is attached)
Your program runs from ROM but uses variables in RAM.
Quote
In the generated asm:
__START_PROGRAM:
di
push ix
push iy
exx
push hl
exx
ld hl, 0
add hl, sp
ld (__CALL_BACK__), hl
ei <<<<<<<
there is an ei here to re-enable interrupts.
__START_PROGRAM is a kind of "garbage" generated by Boriel's ZX-Basic i'm struggling to remove, but it is mostly not affecting the roms i were generating for Sega 8bit consoles (Master System, SG1000 and Game Gear) - so i guess it wouldn't affect GX4000 as well
Quote
After boot is finished, cartridge rom is still active in range &0000-&3fff. So when interrupt happens it will execute interrupt handler at &0038.
You will get a crash because the gx4000boot is not setup for this.
yes, this is a question i have, actually.
at smsboot.bas that i have in my Sega 8bit examples ( like stuff at Homebrew - SMS Power! (http://www.smspower.org/Homebrew) , from "nitrofurano" ), what i have related to this is: (starting from "
org $0038")
asm
org $0000
boot:
di
im 1
ld sp,$dff0
jp main
pause:
push af
ld a,$ff
ld ($C000),a
pop af
retn
org $0038
push af
in a,($bf)
pop af
ei
reti
org $0066
jp pause
org $0070
main:
defb 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
defb 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
defb 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
defb 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
end asm
but i don't know what should be instead for GX4000, i imagine it needs to be very different
Quote
2. Your code is sitting in rom. __CALL_BACK__ variable in the asm will be in rom. It's read-only. It's value will not change. This will not work!
i don't know, for some reason it is working fine on Master System, Game Gear, SG1000, Colecovision, MSX, etc... (perhaps i'm bypassing somewhere)
Quote
3. I am confused by ZXBASIC_USER_DATA. Is it relocated into RAM? The loop in your basic program stores it's value in ZXBASIC_USER_DATA. But because it's in ROM it's value is read-only and will never change, it will never go past 0. This will fail.
me too, but it never caused problems on Master System, Game Gear, SG1000, Colecovision, MSX...
Quote4. Is gx4000boot.bas filled so it goes up to 128? Your code assumes it running from 128 and you are using cat to join them. gx4000boot binary must be 128 bytes exactly. If not, it will fail.
yes, on this i think i'm being careful enough...
Quote
Other solutions:
Your code is copied to ram. (Example is attached)
they also only display a black screen (all .cpr files)
(btw, all the code i compiled to rom files on these other hardware i were attempted, i used ram only for variables)
Quote
Your program runs from ROM but uses variables in RAM.
on SG1000 (as on Master System and Game Gear), i declare the variables first, like
dim oxsp as uinteger at $C000
and thanks! :)
At &0038 i'd probably just put:
Ei
Ret
For now. That'll stop interrupts from crashing the machine at least (later on you might want to instead jump to your own interrupt routine but that can wait). You don't need anything specific at the other restart points like &0066, because the machine doesn't use NMIs, so you can leave that entirely blank.
As for RAM, it's present in the entire address space, obviously at start up you will have the lower ROM enabled and thus READs will come from that instead. WRITEs to those addresses would go to RAM so you could just copy the first 16K over itself and then turn the lower ROM off and from then on you'll be working in a purely RAM environment.
Quote from: andycadley on 09:08, 16 August 14
At &0038 i'd probably just put:
Ei
Ret
For now. That'll stop interrupts from crashing the machine at least (later on you might want to instead jump to your own interrupt routine but that can wait). You don't need anything specific at the other restart points like &0066, because the machine doesn't use NMIs, so you can leave that entirely blank.
...
at Push'n'Pop | Amstrad CPC Demoscene | Faster wait for the VBL (http://www.pushnpop.net/topic-289-1.html) i found:
waitvs:
ld a,&F5
in a,(&DB)
rra
jr nc,waitvs
so, i guess having it somehow at &0038 (that above might miss a "org &0038" and "ei" above and a "ret" below?), we might be able to use halt for wait-vbl? (i mostly use halt for wait-vbl on all z80-based machines i can)
You wouldn't want that happening on an interrupt, there are 6 per frame (unless you switch to the PRI or use DMA interrupts) so it'd slow things down massively. Trying to use HALT for v-blank on the Amstrad isn't really a good idea. You could put it on one of the other restart points and call it with a RST instead (assuming that's accessible from Pismo/Boriel) if you really want a single instruction way of doing it.
Quote from: andycadley on 10:04, 16 August 14
You wouldn't want that happening on an interrupt, there are 6 per frame (unless you switch to the PRI or use DMA interrupts) so it'd slow things down massively. Trying to use HALT for v-blank on the Amstrad isn't really a good idea. You could put it on one of the other restart points and call it with a RST instead (assuming that's accessible from Pismo/Boriel) if you really want a single instruction way of doing it.
i didn't know that...
in the meanwhile i tried to fix/improve my Boriel's ZX-Basic example, still not working (only still that black display) - i added ei and ret at &0038 - and some questions related to how to access and page the ram (for now i'm looking for having 16kb or 32kb only (i guess we can have the ram starting at $C000 or $8000, display included?), for display and variables only, and all code at the rom, for now, just for attempting on simplifying my newbie-stage learning curve)
(for now, my first concern for now is having that feedback on being able to display something on the screen, and then starting to keep progressing after that)
about replacing halt for v-blank, i really have no idea how to do that, and where to start
If you absolutely have to use HALT, your best bet would be to switch on the Plus Programmable Raster Interrupt (PRI) since this will disable the normal 6 fixed raster interrupts and replace them with one on a single scanline. By setting that to go off at a suitable point, you'd end up with something akin to a v-blank interrupt.
would be that too hard to do?
Not particularly hard no. With the ASIC registers paged in, just load the PRI register at &6800 with a value just larger than the number of scanlines in the display, say 201. That will replace the default interrupts with a single one that's triggered just after the display has been drawn. It's not quite v-blank, but it's probably functionally equivalent for most purposes.
Looking at your code, I also can't see anywhere that sets up the colour palettes, which is probably another reason the display just looks black (I'd assume emulators default to an all zero palette, not sure that's true of real hardware). So you probably also want to set that up by loading the ASIC palette registers too.
Quote from: andycadley on 21:04, 16 August 14
Not particularly hard no. With the ASIC registers paged in, just load the PRI register at &6800 with a value just larger than the number of scanlines in the display, say 201. That will replace the default interrupts with a single one that's triggered just after the display has been drawn. It's not quite v-blank, but it's probably functionally equivalent for most purposes.
awesome! i'd like to see a snippet of it...
Quote
Looking at your code, I also can't see anywhere that sets up the colour palettes, which is probably another reason the display just looks black (I'd assume emulators default to an all zero palette, not sure that's true of real hardware). So you probably also want to set that up by loading the ASIC palette registers too.
perhaps a bunch of "out" instructions would do that, just for testing? how they would look like, as assembly code, in both cpc+ (4096 colours) and cpc (27 unique colours) modes?
No problem, I've attached a couple to this post.
The first, ASIC PRI Sample, sets up a PRI just after the screen and then alternates the border colour a few times when it fires (so you can see where it is)
The second, ASIC colours sample, draws a pattern of stripes on the screen in each INK colour and then resets the palette into a series of incrementing yellow/cyan colours. It dynamically sets the PRI to trigger at a couple of points on the screen as a way of getting more onscreen colours (and is why I wouldn't recommend think of HALT as a frame syncing mechanism)
Note that both the above examples leave the ASIC registers paged in at &4000 (the Plus hardware is memory mapped rather than IO mapped). In a real world piece of code, you're more likely going to want to switch the ASIC on/off so that you can use the RAM in that address space.
Setting colours the old-school way is just a matter of OUT-ing the correct values to port &7fxx (a PEN select then an INK set), although I really wouldn't recommend it if you're running from a cartridge, the Plus palette is just so much nicer. :-)
thanks! :)
Quote from: andycadley on 12:35, 17 August 14
No problem, I've attached a couple to this post.
The first, ASIC PRI Sample, sets up a PRI just after the screen and then alternates the border colour a few times when it fires (so you can see where it is)
The second, ASIC colours sample, draws a pattern of stripes on the screen in each INK colour and then resets the palette into a series of incrementing yellow/cyan colours. It dynamically sets the PRI to trigger at a couple of points on the screen as a way of getting more onscreen colours (and is why I wouldn't recommend think of HALT as a frame syncing mechanism)
Note that both the above examples leave the ASIC registers paged in at &4000 (the Plus hardware is memory mapped rather than IO mapped). In a real world piece of code, you're more likely going to want to switch the ASIC on/off so that you can use the RAM in that address space.
tried that - compiled, but it is also all black as well - i have no idea what could be wrong there (i'm attaching them back as well)
Quote
Setting colours the old-school way is just a matter of OUT-ing the correct values to port &7fxx (a PEN select then an INK set), although I really wouldn't recommend it if you're running from a cartridge, the Plus palette is just so much nicer. :-)
yes, since it's for GX4000 firstly (for lots of reasons: the resulting materials are rom only, there is a need to increase the titles for GX4000, from my humble attempts i want to humbly motivate more people creating stuff for GX4000, etc.), i want to focus on the Plus palette mostly - the fact is that i'm also curious about the "default" palette as well, since i'm curious about starting Amstrad CPC later, on Boriel's ZX-Basic Compiler
I didn't bother fully configuring the CRTC, so the screen wouldn't be enabled, because I was just calling it from BASIC. You'll need to include the CRTC setup code from your previous boot code if you want to put it in a cartridge.
Setting up colours the old school way is jut a matter of doing something like:
Ld bc, &7f00
Out (c), c ; Select Pen 0
Ld a, &40
Out (c), a ; Select White
The wiki details the bit combinations required to select functions when writing to the gate array.
EDIT: Also when I setup Mode 0, it's disabling the ROMs, you'll need to tweak that slightly if you're running it from cartridge too (otherwise the code will be paged out from under itself!). Probably also need to set the stack up somewhere sensible too, between &8000 and &bfff to avoid the ROM, ASIC and display area.
Quote from: andycadley on 14:18, 17 August 14
I didn't bother fully configuring the CRTC, so the screen wouldn't be enabled, because I was just calling it from BASIC. You'll need to include the CRTC setup code from your previous boot code if you want to put it in a cartridge.
i confess i'm a bit lost, i'm a newbie about CPC and GX4000! :D
Quote
Setting up colours the old school way is jut a matter of doing something like:
Ld bc, &7f00
Out (c), c ; Select Pen 0
Ld a, &40
Out (c), a ; Select White
yes, thanks, something is starting to appear on the zxbasic example (attached in this message) - but it seems that something there is all out of control... (the display is getting filled from the end to start and slowly, quite weird)about that asm examples for pasmo, i'm lost there, i don't know what to do with that then... :D (seems simple when we know exactly what each instruction exactly does, which is not my case yet...)QuoteThe wiki details the bit combinations required to select functions when writing to the gate array.
where? i think i only found about those colour palette index codes - Video modes - CPCWiki (http://cpcwiki.eu/index.php/Video_modes#3-level_RGB_of_the_CPC)
Quote
EDIT: Also when I setup Mode 0, it's disabling the ROMs, you'll need to tweak that slightly if you're running it from cartridge too (otherwise the code will be paged out from under itself!). Probably also need to set the stack up somewhere sensible too, between &8000 and &bfff to avoid the ROM, ASIC and display area.
somehow, in this example i'm attaching now, it seems to write between $C000 and $FFFF, when i imagined it would between $4000 and $7FFF - what do you think is going wrong there? (i'm actually trying to set the stack somewhere there as well)
i actually wanted to use the ram between $C000 and $FFFF, or between $8000 and $FFFF , and having the most possible for rom starting from $0000
No problem, I've not used Pasmo or ZXBasic (really must give them a go) as I tend to stick to pure asm using the built in assembler in WinAPE these days. But hopefully I can point you in the right direction.
Details on the Gate Array for colour manipulation the old way is at Gate Array - CPCWiki (http://cpcwiki.eu/index.php/Gate_Array) - the GA is also used for things like ROM/RAM banking and changing Mode, so it's worth a bit of a read.
For the stack pointer, your safest bet is to initialise it to &c000 (although you should probably put it in your boot code). The stack grows downwards in memory and doesn't use the byte at the address you first load so it'll go from &bfff down towards 0. That's probably the safest bit of memory as things stand since you have the Lower ROM enabled in 0-3fff, the ASIC enabled at 4000-7fff and the screen located at c000-ffff. :-)
I'm not sure what you're trying to do by writing to &d008 and &d009, that doesn't seem to accomplish anything at all.
What I really can't understand though is why the compiled code in the cpr file has placed a JP &00b8 at &00b8, right after you set SP. That just ends in an infinite loop, so the rest of your code is never getting run.
Quote from: andycadley on 23:29, 17 August 14
No problem, I've not used Pasmo or ZXBasic (really must give them a go) as I tend to stick to pure asm using the built in assembler in WinAPE these days. But hopefully I can point you in the right direction.
thanks! :)
Quote
Details on the Gate Array for colour manipulation the old way is at Gate Array - CPCWiki (http://cpcwiki.eu/index.php/Gate_Array) - the GA is also used for things like ROM/RAM banking and changing Mode, so it's worth a bit of a read.
yes, only now i'm figuring out better what is there
Quote
For the stack pointer, your safest bet is to initialise it to &c000 (although you should probably put it in your boot code). The stack grows downwards in memory and doesn't use the byte at the address you first load so it'll go from &bfff down towards 0. That's probably the safest bit of memory as things stand since you have the Lower ROM enabled in 0-3fff, the ASIC enabled at 4000-7fff and the screen located at c000-ffff. :-)
thanks! i guess it starts to work now (added in the attachment)(btw, the only situation i'm seeing now is that the colours looks shuffled, instead of "red, green, blue and yellow", it appears "blue, red, blue and yellow" )Quote
I'm not sure what you're trying to do by writing to &d008 and &d009, that doesn't seem to accomplish anything at all.
just a test, trying to poke something on the screen (actually something appeared there)
Quote
What I really can't understand though is why the compiled code in the cpr file has placed a JP &00b8 at &00b8, right after you set SP. That just ends in an infinite loop, so the rest of your code is never getting run.
i think that was "
loop02:goto loop02" on the basic part - the fact is that there is no difference having that there or not - for example, try replacing that with 3 "nop" operands, and the result will be the same... :Sand btw, how cpcplus palette works, from "out" operands? (in an example, just like that you did about the 27-colour cpc palette - i want to try it as well! :) )last edit: adding another example, using mode 0 - what i don't know is how sizes and locations works...
found it - i'm testing overscan there - the problem is that there are 16kb ram banks (the display appears repeated somehow), i imagine that we need 32kb ram for overscan - perhaps from $8000 to $FFFF (i don't know how to do that...)
You may find the colour thing is just down to the encoding of pixels in the screen ram, as it's not necessarily as obvious as you might first think.
Overscan is a tricky one, you have to put the CRTC in 32K mode and the memory arrangement gets a bit tricky. As it stands with the Lower ROM turned on and the ASIC paged in, you'll find it tricky to do. You kinda need to get used to the whole paging mechanism to be able to work effectively with such a large amount of the RAM dedicated to the display.
The Plus colour palette, along with all the other new functionality, isn't IO mapped so you can't access it via OUT instructions. Instead you have to page in the ASIC registers (your boot code already does this). The palette registers are then located between &6400 and &641f, two bytes per PEN. They're followed by the Border colour at &6420 and &6421. More details of the ASIC registers is at "Arnold V" Specification - Issue 1.5 - 10th April 1990 (http://cpctech.cpc-live.com/docs/arnold5a.html)
Quote from: andycadley on 20:51, 18 August 14
You may find the colour thing is just down to the encoding of pixels in the screen ram, as it's not necessarily as obvious as you might first think.
Overscan is a tricky one, you have to put the CRTC in 32K mode and the memory arrangement gets a bit tricky. As it stands with the Lower ROM turned on and the ASIC paged in, you'll find it tricky to do. You kinda need to get used to the whole paging mechanism to be able to work effectively with such a large amount of the RAM dedicated to the display.
yes, i'm afraid that will take a while (unless someone else might try to do that on ZXBasic as well! :D )
i imagined that this would be as simple as for example, having the display ram between $8000 and $FFFF, and since whole 32kb seems to be not completely used, we could use that for other stuff too (variables, stack, etc.)
Quote
The Plus colour palette, along with all the other new functionality, isn't IO mapped so you can't access it via OUT instructions. Instead you have to page in the ASIC registers (your boot code already does this). The palette registers are then located between &6400 and &641f, two bytes per PEN. They're followed by the Border colour at &6420 and &6421. More details of the ASIC registers is at "Arnold V" Specification - Issue 1.5 - 10th April 1990 (http://cpctech.cpc-live.com/docs/arnold5a.html)
thanks! :)
and i didn't know that - would this mean that, the situation i have now is that i only have between &0000 and &3FFF for rom and everything else for ram, or just the fact that i poke between &6400 and &6421, even on rom, the machine assumes it is for the palette, just like Sega Master System and some MSX rom pagers (like ascii8k and ascii16k) uses for cartridge rom paging? (btw, in theory, that would be how GX4000 could support over 512kb of cartridge roms (up to 4mb is 1 byte is used, and up to 1gb if 2 bytes are used ) - people here experienced in electronics would confirm it - the only problem of this is that it is not conventional to the GX4000 specifications, and no emulator is supporting it yet)
another question: is the GX4000 joystick using the keyboard connectors (as the feedback i got from Mess emulator)? - the code i found on the wiki here looks a bit tricky, wasn't that just setting and reading i/o ports? (on machines like ZX-Spectrum, MSX, Mattel Aquarius, and so on, doing this is extremely simple - i really wonder how complicated it is on CPC... )
Yeah, in theory you can use the unused bits of the display memory for other things, but because the display storage isn't entirely linear it's takes a bit of effort to figure out where the "holes" are. I'd stick to a 16K display to start with. No point overcomplicating things to begin with. ;)
As it stands, your memory map looks a bit like this:
&0000 - &3fff - ROM (writes will go to the underlying RAM page though)
&4000 - &7fff - ASIC registers
&8000 - &bfff - RAM (with the stack at the top end)
&c000 - &ffff - Screen RAM
So, as you can see any write to say &6400 will write into the ASIC and change the palette. Normally you'd not leave the ASIC paged in, so that the RAM there is usable to. And you just switch it in and out when you're actually making changes to the registers.
The Plus can support a maximum of 512k cartridge ROM, split into 16K chunks. The first 8 of which can paged in at &0000 or &c000, the rest can all be paged in at &c000. No existing cartridges are actually that large however.
Reading the keyboard/joystick is a bit of a pain on the CPC/GX, because it all involves a slightly convoluted mapping via the PPI. You should be able to get by with a generic routine though (I'm sure there is one around here). On the GX you only need worry about the joysticks and the P key, which is what the pause button maps to. :)
@nitrofurano (http://www.cpcwiki.eu/forum/index.php?action=profile;u=987):
I like what you are doing. I like that you are investigating the gx4000, cartridges and writing code using zxbasic. I think it's a good plan and I look forward to seeing the results of your work.
Keep going.
Myself I work with either assembler (I use pasmo) or C (I use sdcc).
As you can see from the forum we are all willing to help!
Quote from: andycadley on 22:29, 18 August 14
Yeah, in theory you can use the unused bits of the display memory for other things, but because the display storage isn't entirely linear it's takes a bit of effort to figure out where the "holes" are. I'd stick to a 16K display to start with. No point overcomplicating things to begin with.
that was mostly by curiousity! (and the excitement on seeing stuff working! )
and yes, it's quite interesting "gymnastic" to figure out how this whole paging system works!
Quote
As it stands, your memory map looks a bit like this:
&0000 - &3fff - ROM (writes will go to the underlying RAM page though)
&4000 - &7fff - ASIC registers
&8000 - &bfff - RAM (with the stack at the top end)
&c000 - &ffff - Screen RAM
thanks!
Quote
So, as you can see any write to say &6400 will write into the ASIC and change the palette. Normally you'd not leave the ASIC paged in, so that the RAM there is usable to. And you just switch it in and out when you're actually making changes to the registers.
my concern mostly was that i might need between &0000 and &7FFF for rom
Quote
The Plus can support a maximum of 512k cartridge ROM, split into 16K chunks. The first 8 of which can paged in at &0000 or &c000, the rest can all be paged in at &c000. No existing cartridges are actually that large however.
my first curiousity about "large" rom files was for testing stuff like ZX BASIC:Released Programs - MSX - BorielWiki - that is a slideshow (106kb each picture, 256x424 in yjk colour format, uncompressed) filling whole 4mb of a memory-paged rom using ascii16k paging system - this was a kind of previous level of a picture-based game ( a bit like ZX BASIC:Released Programs - BorielWiki ) that i want to have similar stuff for gx4000
Quote
Reading the keyboard/joystick is a bit of a pain on the CPC/GX, because it all involves a slightly convoluted mapping via the PPI. You should be able to get by with a generic routine though (I'm sure there is one around here). On the GX you only need worry about the joysticks and the P key, which is what the pause button maps to.
thanks for confirming how painful it is! - i actually will have to put some hands on it soon, try to transform what is available in the wiki in a kind of library (like those i started in the last attachment i added here in this thread)
Quote from: arnoldemu on 08:54, 19 August 14
@nitrofurano (http://www.cpcwiki.eu/forum/index.php?action=profile;u=987):
I like what you are doing. I like that you are investigating the gx4000, cartridges and writing code using zxbasic. I think it's a good plan and I look forward to seeing the results of your work.
Keep going.
thanks!
there are, mainly, for 2 purposes, that i'm attempting this:
- i want to help zxbasic becoming a far more popular tool that it is, try to extend it to the most wide range of z80-based existing hardware (even those most obscure from eastern Europe), and sharing the idea of how simple can be creating stuff with that.
- it is sad seeing a console like GX4000 almost abandoned in the scene because the lack of "classical" titles, when the homebrew scene can help a lot on "fixing" this situation, and from my humble part trying to contribute on it.
The next step will be CPC (the whole range besides GX4000), PCW, etc. - but i really wanted to focus on GX4000 first because of the second purpose i cited above
Quote
Myself I work with either assembler (I use pasmo) or C (I use sdcc).
As you can see from the forum we are all willing to help!
thanks!
Good stuff. :)
As a long time advocate of the Plus/GX4000 hardware it's always good to see someone trying new stuff out with it. Bit busy this week but I'm definitely going to have to install Pasmo/ZXBasic and see what it can do. Hopefully we can find ways of making some of this stuff a bit easier!
Anything that makes use of the extended features on my plus is good news. It seems such a waste to just use classic Cpc stuff on them.
thanks a lot for the feedback! 8)
btw, while adding new commands to the library (like setting the screen mode, entering cpc+ as hexcolour on the palette ( for example, #928E76 from Palette / Hard Mix :: COLOURlovers (http://www.colourlovers.com/palette/946114/Hard_Mix) becomes #987 in 12bit, and $987 as value for there), etc. ), i found that i'm struggling on setting the screen size and offset again and again (crtc stuff) - the idea is that the boot might have some default stuff for starting, and then we could change it via commands from these libraries like those i'm attempting on creating - i guess it is something wrong there?
Hi,
I wrote corrections in your sub cpcscreensize.
When you select crtc register, it's ok.
ld bc,$bcNN
out (c),c
But when you write the value, it must be on $bdNN...
sub cpcscreensize(txsz as uinteger,tysz as uinteger):
asm
ld bc,$bc01
out (c),c
ld a,(ix+4) // for the crtc register value it must be $bdxx not $bcxx
inc b // so inc b, or ld b,$bd
out (c),a
ld bc,$bc06
out (c),c
ld a,(ix+6) // same here
inc b
out (c),a
end asm
end sub
Quote from: Xifos on 20:26, 19 August 14
Hi,
I wrote corrections in your sub cpcscreensize.
When you select crtc register, it's ok.
ld bc,$bcNN
out (c),c
But when you write the value, it must be on $bdNN...
sub cpcscreensize(txsz as uinteger,tysz as uinteger):
asm
ld bc,$bc01
out (c),c
ld a,(ix+4) // for the crtc register value it must be $bdxx not $bcxx
inc b // so inc b, or ld b,$bd
out (c),a
ld bc,$bc06
out (c),c
ld a,(ix+6) // same here
inc b
out (c),a
end asm
end sub
thanks! working fine now! :)
testing the joystick, and writing some text (btw, i guess Mess doesn't emulate pause button from GX4000 hardware)
Quote from: nitrofurano on 11:05, 20 August 14
testing the joystick, and writing some text (btw, i guess Mess doesn't emulate pause button from GX4000 hardware)
the pause button is just mapped to "p" if I recall correctly.
yes, thanks for confirming! :) (i think it was mentioned in this thread before)
btw, i added the keymap line related to "p" key, in the case people might want to try it on other emulators (i don't know which good GX4000 emulator is there for GNU/Linux besides Mess)
about the ZX-Basic wiki page, i'm starting this one: ZX BASIC:Released Programs - AmstradCPC - BorielWiki (http://www.boriel.com/wiki/en/index.php/ZX_BASIC:Released_Programs_-_AmstradCPC) (all people are welcome on adding stuff there, as far as they are made by ZX-Basic Compiler! :) )