ac.tomo

Thanks for that but I'm actually after enlarging gr.0 text horizontally as well as vertically in bitmap gr.8. I've seen it done scrolling but can't remember the names of the demo's I've seen it in. I could do it but would like to see the demo's, again, to see the popular method. I know it's all bit shifting like rybags mentioned in 16x16 bit blocks.

Can anyone name a couple of demo's for me that increase and decrease the size of Graphics 0 text, it's one of the programs that I intend to put in my book, but thinking off the top of my head there are a couple of ways of doing it, I just want to see the popular way most coders do it. Thanks.

Just thought I'd give you an update on the next new book on text and graphics for those who are interested, I actually had more than I thought I had left to do and the reason why it's taking so long is that I don't have a lot of time in the week to work on it, but rest assured that it is progressing but will be a number of months away from finishing at the mo.

Hi, I've had to restore my altirra emulator but can't setup a drive and folder to load/save my basic files, any help please.

Thankyou for having a look.

I'm hoping someone can help me find some .GAM files I made years ago, they're called "ACT01.GAM" to "ACT45.GAM", also "BTWO.GAM" files. I have some in BANDIT file format but I didn't convert them all (from CON.KIT .GAM files to BANDIT files) back in the day.

Interesting... I'm never used bpl/bmi this way but then I haven't read a 6502 manual from cover to cover. So, in this case #21 - #16 leaves a positive result and thus can branch thru bpl (correct?) or does the 128 bit still get involved?

You can actually get any type of branch you wish with the existing branches, as you know: BCS is => and BCC is only < but if you: BCC dest1 and BEQ dest1 then you now have branch if < or = too, also: BEQ dest1 BCS dest2 now gives you branch if equal to dest1 and branch if > (only) to dest2 You also have: BCC dest1 branch only if less than to dest1 BEQ dest2 branch if equal to dest2 BCS dest3 and branch if > to dest3

Many thanks for that guys, this above explanation will help me remember (a bit!)

I asked this question a while back but do you think I can find the thread!? Can someone please remind me with the correct BCC or BCS results to this: LDA $MEM_LOC CMP #50 BCC or BCS blah I can't remember which is 'less than' 'equal' or 'greater-than' if you know what I mean?

I won't say too much because the solution to this 'flickering problem' is detailed in my graphics book, but using this method can give a little flickering but if the luma's aint too far apart between the two modes then flickering would be at a minimum. If the luma's were the same there would only be a few graphics 0 character pixels that show flicker and that would be more minimal. EDIT: and if you shifted the Gr.0 & gr.12 font characters left one bit and redefined the gr.12 font slightly flicker really would be more minimal again. EDIT2: AND In fact, the odd Gr.0 bits that don't get covered by a gr.12 bit-pair pixel CAN be covered, so you'll get that tiny bit of colour outside of the gr.0 bits but I don't believe there'll be any flicker then at all with the slightly higher lum gr.0 bits.

@patjomki, it is actually possible to do what your trying to do, there's actually a couple of methods, basically, one way is to switch DL's between graphics 0 and graphics 12, you could use the same DM for both screens and change the character-set so that its fine for graphics 0 but altered a bit for the graphics 12 characters, you could also use different DM's which would give you more options.

I've just got back from getting the disk and trying it out, your correct DMSC, not that I thought you were wrong, I just felt adamant that it would work as it was (as this is how I remembered it), I don't remember the ",16" being in the original program, obviously by the look at it it was, somewhere along the line this ",16" has been overlooked, I could see that the USR argument required some bytes on the stack but I thought the OPEN operation done that, obviously not, but thanks for making me see the correct method, otherwise there would have been an error in my book. Thanks again.

To be honest I haven't "made sure" about this issue as my 65XE is down my mothers and not up my flat and I only have one DOS 2.5 disk and for some reason the disk is loading slow and troubled and there's obviously some problems there, actually I'm just going up my flat now to 'hopefully' find a working disk to try, I do understand completely what your all saying, I do know the PLA's are looking for what would be the ",16" lsb/msb's but for some reason I seem to remember it working as it is, it isn't actually my program, I got it from somewhere several years ago, I'll get back to you when I've tried a working disk.

yes, I wanted to ring bind it but I don't think AMAZON supports it.

lol, there's a couple of extra bits in the latest version.

mmm, puzzling. I did try the original program.

I tried the program (as it was) on the real hardware and it (as I remember) does work, obviously on the real hardware the OPEN function places the channel number on the stack whereas on ALTIRRA it does not. But thanks everyone for your help.

Many thanks for that DMSC, as I believe the program works fine on the real hardware, it's obviously a difference with ALTIRRA, although I'm not sure since it's been a long time since I tried it on the real ATARI, but thanks again, unfortuneatly your name will now appear in my book, unless ofcourse you don't want it too. thanks.

I wonder if someone can help me, I'm trying to load a standard 62 sector picture file in using ALTIRRA but ain't getting anywhere, here's what I got: 10 GRAPHICS 15+16:MEM=7680 20 DATA 104,104,104,170,76,86,228 30 FOR I=0 TO 6:READ D:POKE 1536+I,D:NEXT I 50 HI=INT(MEM/256):LO=MEM-HI*256 60 OPEN #1,4,0,"D:FILENAME.PIC" 70 POKE 849,1:POKE 850,7 75 POKE 852,PEEK(88):POKE 853,PEEK(89) 80 POKE 856,LO:POKE 857,HI 85 POKE 858,4 90 I=USR(1536) 95 CLOSE #1 It's actually for my book so if anyone can give me the answer then they will be credited, thanks.

Hi all, it might sound odd but I need an answer to a problem I've got concerning one of the topics in my graphics book: the topic is 'input/output' and although I have all the information I need for the real hardware I don't know how to load a font file in Altirra, the fast way, here's what I got: 10 DATA 104,104,104,170,76,86,228 20 FOR I=0 TO 6:READ D:POKE 1536+I,D:NEXT I 35 OPEN #1,8,0,"D:NAME.FNT" 40 POKE 849,1:POKE 850,11 50 POKE 852,0:POKE 853,PEEK(106) 60 POKE 856,0:POKE 857,4:POKE 858,8 70 X=USR(1536) 80 CLOSE #1 I do have the program to do it the slow way (printing byte by byte to the file) but not the fast way, any help much appreciated, whoever gives me the solution will be credited in the book (ofcourse).

Unfortuneatly, no it isn't ringbound, I would have liked to do that but as I understand AMAZON doesn't support that.

Ah, ok. I've read through the "addenda & errata" appendix and the XL one and put all of the information together in the main MAP to reduce jumping around trying to find the correct information. The "XL enhancements etc." appendix lists the XL locations & older 4/800 locations all together (so although everything has been eased and added for the XL/XE user, the older 4/800 systems are still fully covered).

I'm not sure what you mean Larry? Yes mutil8, a little while yet.

Thanks for all your comments, as far as I know the price you see on AMAZON is the price you pay, it's available on AMAZON.COM as well as AMAZON.CO.UK (and other AMAZON countries also), just search: "C&EM". I'll let the cat out of the bag, the 2nd book is all about text and graphics with LOTS of information never been released ever before, at the moment there are 3 chapters left to finish and 3 chapters yet to do. When I do finish it I will be posting it up on this forum and I will also be putting another message up which at the moment I'm not going to divulge, you'll just have to wait and see.