Hi Folks,
I seem to vagely remember a AA Type-In that enables characters to be drawn at 3 or 4 times normal size from basic, possibly even in 3 different colours (Mode 1)? Am I remembering falsely or can anyone else remember this, and if so, which AA might I find it.
I could use sucha routine for an M4 board program I am thinking of, but Ideally I don't want to reinvent the wheel if you know what I mean ;)
Craig
Quote from: CraigsBar on 23:43, 09 July 16
Hi Folks,
I seem to vagely remember a AA Type-In that enables characters to be drawn at 3 or 4 times normal size from basic, possibly even in 3 different colours (Mode 1)? Am I remembering falsely or can anyone else remember this, and if so, which AA might I find it.
I could use sucha routine for an M4 board program I am thinking of, but Ideally I don't want to reinvent the wheel if you know what I mean ;)
Craig
Unsure because AA had quite a few of these programs, the program I'm thinking of which offers 2 different colours is Bigprint from AA57, though that's double height print and works in BASIC as a RSX, so when you say BASIC, was the one you were after written in BASIC? The other program which offers different heights is the Variable Height program from AA17, which is on the wiki (http://www.cpcwiki.eu/index.php/Amstrad_Action_February_1987_Type-Ins) and is written in BASIC.
Either will do, I don't mind an RSX, I'll take a look at both of those and see where I get too. Thanks, watch this space!
Yup, there was a few of them. I remember having typed one in and I'm pretty sure I still have it on tape or disk. Will check when I have time.
Bryce.
OK, varheight is too slow for what I have in mind. I am gonna check the RSX one tomorrow... Need to type it in first!
I think that I have a routine for that as well in an ASM book, I will have a look! :)
Quote from: ||C|-|E|| on 11:40, 12 July 16
I think that I have a routine for that as well in an ASM book, I will have a look! :)
Interesting. Would be interesting to compare it to the BIGPRINT program from AA57. I notice it was converted using the Data Creator type-in from AA50, but it could well be original.
I'll get typing tonight. And attach it to the relevant wiki type-in page.
Typed it in. And it works, next problem...
Is there a way to send the output of a bar command (such as |dir) to a variable so it can be passed to |bigprint. I was sure this was possible without reading the output back in from the screen but I now cannot find out how!
If only this were valid..
A$=|dir,"*.bin"
Craig
I don't believe so. The "output" of an RSX is simply a side effect, it's not really "returned" in any meaningful sense.
It is possible to write an RSX such that it returns data into a variable, but it has to be specifically coded to do so.
Quote from: andycadley on 17:43, 13 July 16
I don't believe so. The "output" of an RSX is simply a side effect, it's not really "returned" in any meaningful sense.
It is possible to write an RSX such that it returns data into a variable, but it has to be specifically coded to do so.
Since I made the same request to @Duke (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1624) to add it to the |time command (My potential project needs both you see) woudl it be possible to provide some background as to how. He was hoping for insite in returning a variable from an RSX :)
Ideally I'd be perfect to have somethng like
|time,a$
which would populate a$ with the time and date string. Once there I can use left$, right$ etc to mainipulate to my needs.
Anything you can offer as assistance woudl be great
Made this for you. It pokes in a little assembler function, which you call, it'll store the timestamp at 0x908B, from there I think you can put it into a var using peek?
10 FOR a=&9000 TO &908A
20 READ b: POKE a,b
30 NEXT
40 CALL &9000
50 IF PEEK(&908A) = 255 THEN PRINT"M4 not found!":END
60 FOR c=&908B TO &90A1: PRINT CHR$(PEEK(c));:NEXT
70 DATA &F3,&1,&84,&7F,&ED,&49,&3A,&8A,&90,&FE,&FF,&CC,&4B,&90,&FE,&FF,&C4,&1F,&90,&1,&8C,&7F,&ED,&49,&1,&0,&DF,&ED,&49,&FB,&C9,&1,&0,&DF,&ED,&79,&3E,&2,&1,&0,&FE,&11,& 24,&43,&ED,&79,&ED,&59,&ED,&51,&1,&0,&FC,&ED,&49,&21,&2,&FF,&5E,&23,&56,&EB
80 DATA &1,&3,&0,&9,&11,&8B,&90,&1,&16,&0,&ED,&B0,&C9,&F3,&FD,&21,&82,&90,&16,&7F,&D5,&1,&0,&DF,&ED,&51,&3A,&0,&C0,&FE,&1,&20,&1C,&3A,&4,&C0,&6F,&3A,&5,&C0,&67,&FD,&E5,&D1,&1A,&AE,&20,&D,&1A,&23,&13,&E6,&80,&28,&F5,&D1,&7A,&32,&8A,&90,&C9
90 DATA &D1,&15,&20,&D3,&3E,&FF,&C9,&4D,&34,&20,&42,&4F,&41,&52,&C4,&FF
And here is the assembler source too, if its any help:
org &9000
nolist
di
ld bc,&7F84
out (c),c
ld a,(m4_rom_num)
cp &FF
call z,find_m4_rom
cp &FF
call nz,get_time
ld bc,&7F8C
out (c),c
ld bc,&DF00
out (c),c
ei
ret
get_time: ; a = rom number
ld bc,&DF00
out (c),a
ld a,2 ; out going size
ld bc,&FE00 ; data port
ld de,&4324 ; C_TIME command
out (c),a
out (c),e
out (c),d
ld bc,&FC00 ; ack port
out (c),c
ld hl,&FF02 ; get response buffer address
ld e,(hl)
inc hl
ld d,(hl)
ex de,hl
ld bc,#3 ; skip check bytes
add hl,bc
ld de,time_stamp
ld bc,22
ldir ; copy time stamp to ram
ret
find_m4_rom:
di
ld iy,m4_rom_name ; rom identification line
ld d,127 ; start looking for from (counting downwards)
romloop: push de
ld bc,&DF00
out (c),d ; select rom
ld a,(&C000)
cp 1
jr nz, not_this_rom
; get rsxcommand_table
ld a,(&C004)
ld l,a
ld a,(&C005)
ld h,a
push iy
pop de
cmp_loop:
ld a,(de)
xor (hl) ; hl points at rom name
jr nz, not_this_rom
ld a,(de)
inc hl
inc de
and &80
jr z,cmp_loop
; rom found, store the rom number
pop de ; rom number
ld a,d
ld (m4_rom_num),a
ret
not_this_rom:
pop de
dec d
jr nz,romloop
ld a,255 ; not found!
ret
m4_rom_name: db "M4 BOAR",&C4 ; D | &80
m4_rom_num: db &FF
time_stamp: ds 22
Quote from: Duke on 19:12, 13 July 16
ld bc,&7F0C
out (c),c
You set pen 12, why? :-X
Should have been 8C :)
Not even sure what state I should leave it in when returning back to basic, it doesn't crash eitherway it seems.
Quote from: Duke on 19:29, 13 July 16
Not even sure what state I should leave it in when returning back to basic, it doesn't crash eitherway it seems.
Well, I'm not so much in firmware since I mostly use another OS, but firmware should have a function like "ask RAM-ROM state", so you can save the RAM/ROM state and switch back to it later.
Better: use the firmware function to "enable upper ROM", so you don't even have to bother with RAM-ROM mapping. :)
That'd probably be the best way yes, someone less rusty than me are welcome to change it (and maybe cut the size down too) :)
Quote from: TFM on 19:36, 13 July 16
Well, I'm not so much in firmware since I mostly use another OS, but firmware should have a function like "ask RAM-ROM state", so you can save the RAM/ROM state and switch back to it later.
Better: use the firmware function to "enable upper ROM", so you don't even have to bother with RAM-ROM mapping. :)
The "correct" way to handle banking is to use a FAR CALL (Rst 3) instruction, with an appropriate far call address, which can be found using KL FIND COMMAND. Somebody who has done it more recently than I can probably remember it better (or point to a good web link!)
As for passing parameters back from RSX's, it relies on you manipulating the memory associated with a variable when it is passed using the @ syntax. Strings are more troublesome, since all you get is a pointer to a string description block (containing the length and address where the string is actually stored) and you aren't allowed to modify the descriptor. In essence, that means your string variable needs to already be set up with a long enough content to hold whatever you wish to pass back.
So for a command like |DoSomething,@a$ you'd get the address and length of a$ with something like:
LD L,(IX+0)
LD H,(IX+1) ; HL = address of string descriptor
LD A,(HL); A = length of string
INC HL
LD E, (HL)
INC HL
LD D,(HL) => DE = address of string contents
From there you can manipulate the memory pointed to by DE to return your results. You are responsible for not writing more than the length of the string though, if you do things will probably not got well....
Ok thanks @andycadley (http://www.cpcwiki.eu/forum/index.php?action=profile;u=327) .
@CraigsBar (http://www.cpcwiki.eu/forum/index.php?action=profile;u=482): I hope the call &9000 will do, as the other seems a bit of mess :)
I'll have a play in the coming days and let you know.
---
Quote from: AMSDOS on 10:46, 14 July 16
---
Damn I wish I knew what this said ;)
Quote from: CraigsBar on 12:23, 14 July 16
Damn I wish I knew what this said ;)
He renounced the CPC and devoted himself to the C64. Then he realised the error of his ways. The scary thing is it took him 14 minutes to come to that realisation.
Quote from: EgoTrip on 16:25, 14 July 16
He renounced the CPC and devoted himself to the C64. Then he realised the error of his ways. The scary thing is it took him 14 minutes to come to that realisation.
[emoji38]
Took 14 minutes? That's how long it takes for the C64 to load anything, isn't it? :P
Quote from: Zoe Robinson on 19:56, 14 July 16
Took 14 minutes? That's how long it takes for the C64 to load anything, isn't it? [emoji14]
ROFL ;)