Just thought that such a routine might come in handy, I can already detect which version of CP/M is being used, though it would be handy to have something which can split the differences between a 464,664 & 6128 - mainly because the 464 has addresses which reside in different localities from the 664/6128! Is there something straightfoward which can split them apart? ::)
Hello,
An easy way to detect CPC model is based on vector addresses. Many are specific for each machine.
exemple :
BB4E
====
464 1078
664 1070
6128 1074
Just read memory value in the &BB4F.
T&J/GPA
You don't have to go that far, you can start more early in the ROM (in this case RAM equals ROM, but to look at the ROM is always more secure...):
Address &0006 contains:
&91 - in CPC6128
&7B - in CPC664
&80 - in CPC464
May you should also check if it is a Plus ;-)
Thanks Folks, main reason I was asking was because I was having a look as the Fast Plot Routine on CPCWiki (http://www.cpcwiki.eu/index.php/Programming:Fast_plot) which looks great, though it wants to know this ColourMask which is an address which is different on the 664/6128 compared to the 464. Good point - the Pluses should be included, unfortunately the code doesn't say if it's different or not, I'm guessing it could be the same, though won't know for sure. Guessing that's a question for Executioner since their responcible for that routine! :-[
But yeah I eventually try both of those out to see what works best! ;D
Actually you are not testing for the type of CPC but for what type of rom your CPC using... ;D
Differences in GA and banking mechanismes is not being tested!
/Ygdrazil
Quote from: TFM/FS on 21:47, 29 August 10
You don't have to go that far, you can start more early in the ROM (in this case RAM equals ROM, but to look at the ROM is always more secure...):
Address &0006 contains:
&91 - in CPC6128
&7B - in CPC664
&80 - in CPC464
May you should also check if it is a Plus ;-)
Quote from: CP/M User on 07:51, 30 August 10
Thanks Folks, main reason I was asking was because I was having a look as the Fast Plot Routine on CPCWiki (http://www.cpcwiki.eu/index.php/Programming:Fast_plot) which looks great, though it wants to know this ColourMask which is an address which is different on the 664/6128 compared to the 464. Good point - the Pluses should be included, unfortunately the code doesn't say if it's different or not, I'm guessing it could be the same, though won't know for sure. Guessing that's a question for Executioner since their responcible for that routine! :-[
But yeah I eventually try both of those out to see what works best! ;D
For 6128 an Plus it's the same :-)
Quote from: Ygdrazil on 10:26, 30 August 10
Actually you are not testing for the type of CPC but for what type of rom your CPC using... ;D
Differences in GA and banking mechanismes is not being tested!
/Ygdrazil
Absolutely right! Why make it more complex and _time comsuming_ than needed. Every microcycle counts! Ask Tron!
Hmm, I seem to have hit a few issues with this - probably because I'm trying to implement this in CP/M. Initally I thought the &BB4E was some kind of Firmware, but CP/M doesn't like it one bit (seems to enjoy crashing) and unfortunately obtaining a value from &0006 gives me a result of 6! Doesn't matter which Computer is being used in CP/M it's the same value! :( Primarily because CP/M is using that low area in memory! ???
Sorry I should of realised that I can't do that in CP/M because it's wired up all differently ???
With the Fast Plot (http://www.cpcwiki.eu/index.php/Programming:Fast_plot) the problem there is it's looking for a GRAPHICS PEN which resides in &B6A3 on a 664/6128 and at &B33A on a 464 these addresses though are AMSDOS based, just like the one which returns a value at &BB4F, though I'm not sure if that address is right or not cause I haven't seemed to get it to work. &BB4E in the Firmware Manual calls it a Text VDU Jumpblock.
What I maybe able to do with that Fast Plot in CP/M though is do a GRA GET PEN which returns the result in "A" and use that for the Fast Plot routine.
Okay what I found out is GRA GET PEN returns a different value - in the Accumulator is the Graphics Pen - so in Mode 1 it's 0,1,2,3. &B6A3/&B33A is different again - so in Mode 1 (and this varies from Mode to Mode), GRA PEN 1 is &F0, 2 is &0F, 3 is &FF and I'm guessing 0 is &00! From what I can tell - CP/M has kept the colour value @ &B6A3, though it doesn't utilise it.
I'm thinking the only way to substitute it is to read the array and based on the values used on the array, intergrate a separate variable (at an absolute address) and have it there - so 0 for 0, 1 as &F0, 2 as &0F and 3 as &FF.
Quote from: CP/M User on 12:19, 31 August 10
Hmm, I seem to have hit a few issues with this - probably because I'm trying to implement this in CP/M. Initally I thought the &BB4E was some kind of Firmware, but CP/M doesn't like it one bit (seems to enjoy crashing) and unfortunately obtaining a value from &0006 gives me a result of 6! Doesn't matter which Computer is being used in CP/M it's the same value! :( Primarily because CP/M is using that low area in memory! ???
http://www.cpctech.org.uk/source/cpmfirm3.html
Here is how you access cpc firmware functions from within cpm.
You have to detect which version of cpm you are using and then perform the appropiate method.
Question, do you have any pascal or asm code for accessing gsx?
I am especially interested in gsx code that works on cpc in mode 0,1,2 and also code that would work on pcw.
I have an idea ;)
Quote from: CP/M User on 04:08, 01 September 10
Sorry I should of realised that I can't do that in CP/M because it's wired up all differently ???
With the Fast Plot (http://www.cpcwiki.eu/index.php/Programming:Fast_plot) the problem there is it's looking for a GRAPHICS PEN which resides in &B6A3 on a 664/6128 and at &B33A on a 464 these addresses though are AMSDOS based, just like the one which returns a value at &BB4F, though I'm not sure if that address is right or not cause I haven't seemed to get it to work. &BB4E in the Firmware Manual calls it a Text VDU Jumpblock.
What I maybe able to do with that Fast Plot in CP/M though is do a GRA GET PEN which returns the result in "A" and use that for the Fast Plot routine.
Okay what I found out is GRA GET PEN returns a different value - in the Accumulator is the Graphics Pen - so in Mode 1 it's 0,1,2,3. &B6A3/&B33A is different again - so in Mode 1 (and this varies from Mode to Mode), GRA PEN 1 is &F0, 2 is &0F, 3 is &FF and I'm guessing 0 is &00! From what I can tell - CP/M has kept the colour value @ &B6A3, though it doesn't utilise it.
I'm thinking the only way to substitute it is to read the array and based on the values used on the array, intergrate a separate variable (at an absolute address) and have it there - so 0 for 0, 1 as &F0, 2 as &0F and 3 as &FF.
The &f0, &0f, &ff and &00 is the pen index encoded into the form that can be poked direct to the screen on cpc mode 1 I think.
&f0 is pen 1 for all pixels. etc
You then need to mask it as appropiate for the pixel you want &88, &44, &22, &11. But because it is different in each firmware, I would not actually use this.
I think the correct way is to use SCR ENCODE, and this gives a pixel and mask you can use for drawing to the screen.
Have a look through the firmware guide to find a better example that works the same on all firmwares.
arnoldemu wrote:
Here is how you access cpc firmware functions from within cpm.
You have to detect which version of cpm you are using and then perform the appropiate method.
Yep, I'm all up with that stuff mate! ;) Not sure if &BB4E is the correct code for detecting which CPC I'm using. Probably doesn't matter now since I was trying to incorporate that Fastplotting routine which uses different Graphics Pen Addresses between the 464 and 664/6128. I've tried GRA SET PEN to test and see if this changes that address @ B6A3 - it doesn't unless it's elsewhere, I had a look though by dumping the memory in DDT and varing the GRA SET PEN routine in places, though found nothing.
Question, do you have any pascal or asm code for accessing gsx?
No unfortunately, cause I'm more hung over using Firmware instead! ???
I am especially interested in gsx code that works on cpc in mode 0,1,2 and also code that would work on pcw.
I have an idea ;)
Maybe this site (http://www.z80.eu/gsx.html) maybe worth checking out - particularly the Graph128.zip (http://www.z80.eu/downloads/graph128.zip) file (it's Commodore based, so I'm not sure how compatable it maybe - though GSX is suppose to be Universal). I vagerally recall a Turtle Graphics program which was written in Turbo Pascal which might have been done with GSX - it was so long ago though. Otherwise I can have a look and see if there's some GSX stuff on NVG. The stuff which is in the Graph128 file is fairly routine library like.
arnoldemu wrote:
The &f0, &0f, &ff and &00 is the pen index encoded into the form that can be poked direct to the screen on cpc mode 1 I think.
&f0 is pen 1 for all pixels. etc
You then need to mask it as appropiate for the pixel you want &88, &44, &22, &11. But because it is different in each firmware, I would not actually use this.
I think the correct way is to use SCR ENCODE, and this gives a pixel and mask you can use for drawing to the screen.
Have a look through the firmware guide to find a better example that works the same on all firmwares.
Yes SCR INK ENCODE (&BC2C) sounds promising because what I'm trying to do is take a PEN Number and convert it into a Code for that Fast Plot to work. It works totally different from a GRA PLOT ABSOLUTE and it doesn't seem to have that issue of calculating every 2 or 4 pixel that MODE 1 or 0 does, and the Y Co-ordinate 0 is positioned at the top of the screen (&C000).
Quote from: CP/M User on 12:19, 31 August 10
Hmm, I seem to have hit a few issues with this - probably because I'm trying to implement this in CP/M. Initally I thought the &BB4E was some kind of Firmware, but CP/M doesn't like it one bit (seems to enjoy crashing) and unfortunately obtaining a value from &0006 gives me a result of 6! Doesn't matter which Computer is being used in CP/M it's the same value! :( Primarily because CP/M is using that low area in memory! ???
Under CP/M you just make it the following way...
DI
LD BC,&7F82
OUT (C),C
LD A,(&0006)
LD C,&86
OUT (C),C
EI
CP A,&xx...
JR Z,cpcxxxx
But be careful, this code must be located between &4000 an &FFFF. NOT below &4000!
arnoldemu wrote:
The &f0, &0f, &ff and &00 is the pen index encoded into the form that can be poked direct to the screen on cpc mode 1 I think.
&f0 is pen 1 for all pixels. etc
You then need to mask it as appropiate for the pixel you want &88, &44, &22, &11. But because it is different in each firmware, I would not actually use this.
I think the correct way is to use SCR ENCODE, and this gives a pixel and mask you can use for drawing to the screen.
Have a look through the firmware guide to find a better example that works the same on all firmwares.
Seem to be running out of ideas as to why this won't work in CP/M! He's my program I quickly generated:
ORG &0100 ; CP/M v2.2 COM File
write'fasplot2.com'
myprog call &be9b
defw &bc02
LD a,1
call &be9b
defw &bc0e
LD a,2
call &be9b
defw &bc2c
ld (myval),a
ld de,100
ld hl,100
call fplot
ld a,3
call &be9b
defw &bc2c
ld (myval),a
ld de,101
ld hl,100
call fplot
ld a,1
call &be9b
defw &bc2c
ld (myval),a
ld de,102
ld hl,100
call fplot
ret
FPLOT LD A, L ;A = Lowbyte Y
AND %00000111 ;isolate Bit 0..2
LD H, A ;= y MOD 8 to H
XOR L ;A = Bit 3..7 of Y
LD L, A ;= (Y\8)*8 to L
LD C, A ;store in C
LD B, &60 ;B = &C0\2 = Highbyte Screenstart\2
ADD HL, HL ;HL * 2
ADD HL, HL ;HL * 4
ADD HL, BC ;+ BC = Startaddress
ADD HL, HL ;of the raster line
LD A, E ;Lowbyte X to A
SRL D ;calculate X\4, because
RR E ;4 pixel per byte
SRL E
ADD HL, DE ;+ HL = Screenaddress
LD C, %10001000 ;Bitmask for MODE 1
AND %00000011 ;A = X MOD 4
JR Z, NSHIFT ;-> = 0, no shift
SHIFT SRL C ;move bitmask to pixel
DEC A ;loop counter
JR NZ,SHIFT ;-position
NSHIFT LD A, (myval) ;get color mask
XOR (HL) ;XOR screenbyte
AND C ;AND bitmask
XOR (HL) ;XOR screenbyte
LD (HL), A ;new screenbyte
RET ;done
myval defb 0
From what I can tell the Firmware is working perfectly fine (SCR INK ENCODE is returning the right values), though for Fastplot routine, it simply doesn't display draw the pixel at 100 followed by 101 or 102, was working fine in AMSDOS. In AMSDOS I had the program running just fine simularly to this one where I return the SCR INK ENCODE value into my own little area and have the fastplot routine obtaining it from there! ???
TFM/FS wrote:
Under CP/M you just make it the following way...
DI
LD BC,&7F82
OUT (C),C
LD A,(&0006)
LD C,&86
OUT (C),C
EI
CP A,&xx...
JR Z,cpcxxxx
But be careful, this code must be located between &4000 an &FFFF. NOT below &4000!
Looks good, for the most part I'm guessing that the main routine which Disables Interrupts and then Enables Interrupts will store a result into "A", so perhaps if I need to use something like that one day if I could return that result into a place in Memory (a variable I defined for example) that would be good!
Quote from: CP/M User on 10:46, 02 September 10
TFM/FS wrote:
Under CP/M you just make it the following way...
DI
LD BC,&7F82
OUT (C),C
LD A,(&0006)
LD C,&86
OUT (C),C
EI
CP A,&xx...
JR Z,cpcxxxx
But be careful, this code must be located between &4000 an &FFFF. NOT below &4000!
Looks good, for the most part I'm guessing that the main routine which Disables Interrupts and then Enables Interrupts will store a result into "A", so perhaps if I need to use something like that one day if I could return that result into a place in Memory (a variable I defined for example) that would be good!
To store the result in a varialble just code: LD (VARIABLE),A
you can later on access it by: LD A,(VARIABLE)
Great thanks! ;D