Started by mr_lou, 17:38, 29 July 19
0 Members and 1 Guest are viewing this topic.
Quote from: mv on 13:50, 11 October 20That's tricky!Printing MODE 1 bitmaps in MODE 2 and view them in MODE 1.I tried to implement this feature in CPCBasic, but its internal pixel buffer does not use the screen memory architecture from the CPC (that's just a simulation for PEEK&POKE).And changing all the screen drawing routines...So I put in a compromize: CALL &BD1C,1 will convert the screen memory to MODE 1.Calling &BD1C again will convert the whole screen again, so we cannot use it for the moving man.
Quote from: AMSDOS on 10:29, 27 October 20I'm not liking these Firmware Calls from BASIC which use the extra parameters, especially after the Warzone game I converted to run on the 464 the other day won't work on a 664 because of statements like CALL &BC06,&C0 and CALL &BC06,&40.It's possible switching screens using OUT statements, so perhaps that would be the best course of action, though I'm unsure if &BD1C is available from an OUT statement.
Quote from: mv on 23:19, 27 October 20Good point! I never tried CALL &BC06 on a CPC 664... I see... not good to modify register SP.Hmm, we could memorize the byte at &BC06, set to e.g. zero, CALL it and restore. Or even better, use CALL &BC07! Who came up with &BC06?
QuoteCALL &BD1C is different. You can try to set the mode with OUT &7Fxx but this is not permanent. You have to modify register BC' as well. Luckily, the CALL is the same on all CPC 464/664/6128. And isn't it a nice trick to set register A with the number of arguments?
a$="3e00cd08bcc9":c=0:for p=1 to 11 step 2:poke &160+c,val("&"+mid$(a$,p,2)):c=c+1:nextpoke &161,&40:call &160poke &161,&C0:call &160
Page created in 0.066 seconds with 32 queries.