Jump to content

576XE

Members
  • Content Count

    780
  • Joined

  • Last visited

Community Reputation

142 Excellent

About 576XE

  • Rank
    Dragonstomper
  • Birthday 03/26/1959

Profile Information

  • Gender
    Male
  • Location
    Moscow, Russia
  1. Workaround to eliminate some quirks of InterLISP/65 in SDX. At first, I must say that InterLISP/65 has an unqtue ability on atari-8 !!! It's a pretty-printing ! No other lang has it! (IMHO) BUT! What we can do with 40 columns limit while LISP has no limit in it's logic line at all?!! (Only a RAM limitations.) So, we need 80 columns! - And it's a beginning of my investigations... Good old Konrad (Drak030), said me a secret word to familiarize LISP with SDX. POKE 02e4,$c0. And it works in COL 40 mode! Also, never working with LISP he has never meet it's real problems. Recently I've tried to run LISP in SDX in COL 80 and COL 64 (I prefere COL 64) environment with the purpose to get a real pretty-printing of some long-enough LISP program such as LISP's 'EDIT - structured-manner LISP-native EDITOR. No chance. May be 'Screen' or '80font' are destroyed while loading LISP, may be some other garbage come in to screen ... I report this screenshot: /Garbage Thus we have some data/drivers in operative area while working. So I decided to say 'Y' but 'N' while loading LISP 2.5 after the prompt: Reserve mem for graphic modes 6,7,8 And a screenshot: /Loaded And it's pretty-printing screenshot. /Success P.S. I really can not understand which part of SDX is under the siege. May be some relocation of standard SDX parts is a Panacea? All your suggestions about relocation of SDX data are very highly appreciated. Best wishes from Moscow zen
  2. Hello FRIENDS! This new code is working! It's demo of course BUT ... program vm; const CON=0; COF=1; NOP=255; ESC=28; RET=12; UP=14; cUP=142; DN=15; cDN=143; type sarT = array[1..6] of string; var CH: byte absolute $2fc; SAVMSC: word absolute $58; CRSINH: byte absolute $2f0; X,Y,W,H: byte; procedure invLine(x,y,len : byte); var _L: byte absolute $f0; _A: integer absolute $f2; begin _L := len; _A := SAVMSC + y*40 + x-1; inline($ac/_L/ (* ldy #_L *) $b1/$f2/ (* lda($f2),y *) $49/$80/ (* eor #$80 *) $91/$f2/ (* sta($f2),y *) $88/ (* dey *) $d0/$f5); (* bne -9 *) end; procedure putMenu; var strg: sarT; ndx: byte; begin strg[1] := 'Moscow '; strg[2] := 'Petersburg'; strg[3] := 'Evpatoria '; strg[4] := 'Feodosia '; strg[5] := 'Simeiz '; strg[6] := 'Konakovo '; for ndx := 1 to H do begin gotoxy(X,Y-1+ndx); writeln(strg[ndx]); end; end; var MINR,MAXR,sel,key: byte; dy: shortint; begin X := 5; Y := 5; W := 10; H := 6; MINR := 1; MAXR := 6; CRSINH := COF; putMenu; sel := 1; invLine(X,Y-1+sel,W); repeat CH := NOP; while CH=NOP do ; key := CH; dy := ord((key=DN) or (key=cDN)) - ord((key=UP) or (key=cUP)); if dy<>0 then begin invLine(X,Y-1+sel,W); sel := sel+dy; if sel<MINR then sel := MINR; if sel>MAXR then sel := MAXR; invLine(X,Y-1+sel,W); CH := NOP; end; if key=RET then begin gotoxy(14,20); writeln(sel,' selected'); CH := NOP; end; until key=ESC; CH := NOP; CRSINH := CON; end. And a screenshot: zen
  3. Hello FRIENDS! This code of CAS and LUCKYBUCK gently decides all problems ! program cas; const Esc=#27; var sMem : word absolute $58; procedure invLine(x,y,len : byte); var sAdr: integer absolute $f2; _l : byte absolute $f0; begin _l := len; sAdr := sMem + y*40 + x-1; inline($ac/_l/ (* ldy #_l *) $b1/$f2/ (* lda($f2),y *) $49/$80/ (* eor #$80 *) $91/$f2/ (* sta($f2),y *) $88/ (* dey *) $d0/$f5); (* bne -9 *) end; (*= Main Procedure =================*) (*- Locals -------------------------*) var _X,_Y,_L: byte; _C: char; begin writeln; writeln; writeln; _X := 0; _Y := 0; _L := 40; repeat _C := readkey; while _C='' do ; (* Wait... *) invLine(_X,_Y,_L); until _C=Esc; end. Simply ingenious. zen
  4. I think that every localized person say it in his local manner. In Russian It's much more simpler and faster to say... (Sixtyfive-Null-two.- In translation of course!) Then Six Five Zero Two. zen
  5. LSC is just another attempt to create it's own universe... By the way I love C and my own choice is CC8 based on ACEC (ie fast and compatible!). zen
  6. Hello, Alfred! You are right! Pascal being too serious teacher forbids some Atari related actions. FE Any pointer in CLSN Pascal sits in memory in 3 bytes! LSB, MSB and then BNK with the purpose to access all 13XE memory. I'm not being a programmer at all can not understand how it treats these data. I know some facts from manual. One of them says that absolute Atari(thus 2 bytes) address treats as bnkNum<$addr> ie 3 bytes ! ie $2000=$00,$2000 ! Another one says that when data goes from stack, then the operation of getting the address of this local variable (ie @) returns the offset to THE data of this variable from current stack pointer! It's not processor stack it's 16k CLSN program stack!!! I mean that only Pascal while compiling prevents successful ML operations. By the way, absolute addressing operations ie STA $2000,Y is unsuccessful too! We just can not represent to Pascal data perfectly! As far as it's concern < - It's not a big problem. Even if we send 2-bytes datum with the purpose of obtain < byte, we are successfully get it's byte because of Little Endian Atari notation of addressing. Our beloved Accu. gets only one LSB byte! While we are retreaving > byte we get 2 bytes value and then get the second datum from them. PS And... Many thanks from spring Moscow to you and family! zen
  7. hi baktra, It is a case of algorithm! No more. I just wanted to flip value but you said about inversion only. Where is an error? Just misunderstanding. zen
  8. Today is one of my best days. I've found the reasons of Pascal's bad understanding of assembly. At first while pointers in Assembler are two-bytes addresses with special addressing modes, pointers in Pascal are three-bytes values laying in memory in special order (LSB,MSB,BNK). Thus Pascal is awaiting the third byte while working with pointers. When it takes third value from code it just jam all program and not only break PC but Stack too! First picture shows Stack overflow situation. When I addes BRK code after address fields Pascal calmed down. The RTS really needed in inline insertions and not for inline procedures to clearly end up insertion but it may work the same role as BRK! Please look at the first working code of Pascal's screen access. program invl; type linT = array[0..39] of byte; ptrT = ^byte; adrT = word; var sMem: word absolute $58; lPtr: ptrT absolute $ca; (*longint: $ca=LSB,$cb=MSB,$cc=BNK*) lAdr: adrT absolute $ca; (* word: $ca=LSB,$cb=MSB *) lMar: byte absolute $cd; ch: char; begin writeln('Hello, World!'); writeln; lPtr := memptr($00,lAdr); lMar := 4; lAdr := sMem+lMar; inline($a0/$03/ (* LDY #$03 *) $b1/lAdr/ (* LOOP LDA (lAdr),Y *) $00/ (* BRK *) $49/$80/ (* EOR #$80 *) $91/lAdr/ (* STA (lAdr),Y *) $60); (* RTS *) write('lMar=',lMar,' '); writeln('lAdr=',lAdr); ch := readkey; end. zen
  9. Hello, baktra! If I can remember ORA just sets a bit in a byte while EOR effectively flips it back and forth. In my last post I just tried to pay attention on strange effects of using BRK and RTS in inline Pascal code. zen
  10. Hello, Friends! This CRAZY CLSN Pascal effectively blows up my brain!!! Please look at the codes... This code goes to cycle?!! and fills up 16k program stack of CLSN with Pascal's speed ignoring inversion... program tst10; var sMem: word absolute $58; (* Z-Page variables *) sPtr: pointer absolute $ca; (*longint: $ca=LSB,$cb=MSB,$cc=BKB*) sAdr: word absolute $ca; (* word: $ca=LSB,$cb=MSB *) lMar: byte absolute $cd; (* byte *) sLen: byte absolute $ce; (* byte *) ch: char; procedure invByte(a: word; m: byte); begin sAdr := a; lMar := m; inline($a4/lMar/ (* ldy lMar *) $b1/sAdr/ (* lda (sAdr),Y *) (* Intentionally Blanked *) $49/$80/ (* eor #$80 *) $91/sAdr); (* sta (sAdr),Y *) (* Intentionally Blanked *) end; begin writeln('Sample'); sPtr := memptr($00,sMem); invByte(sAdr,5); ch := readkey; end. This code successively supresses sycling but ignores inverting?!! program tst11; var sMem: word absolute $58; (* Z-Page variables *) sPtr: pointer absolute $ca; (*longint: $ca=LSB,$cb=MSB,$cc=BKB*) sAdr: word absolute $ca; (* word: $ca=LSB,$cb=MSB *) lMar: byte absolute $cd; (* byte *) sLen: byte absolute $ce; (* byte *) ch: char; procedure invByte(a: word; m: byte); begin sAdr := a; lMar := m; inline($a4/lMar/ (* ldy lMar *) $b1/sAdr/ (* lda (sAdr),Y *) (* Intentionally Blanked *) $49/$80/ (* eor #$80 *) $91/sAdr/ (* sta (sAdr),Y *) $60); (* rts *) end; begin writeln('Sample'); sPtr := memptr($00,sMem); invByte(sAdr,5); ch := readkey; end. This code adds inverting but... it's NOT inverting at all! program tst12; var sMem: word absolute $58; (* Z-Page variables *) sPtr: pointer absolute $ca; (*longint: $ca=LSB,$cb=MSB,$cc=BKB*) sAdr: word absolute $ca; (* word: $ca=LSB,$cb=MSB *) lMar: byte absolute $cd; (* byte *) sLen: byte absolute $ce; (* byte *) ch: char; procedure invByte(a: word; m: byte); begin sAdr := a; lMar := m; inline($a4/lMar/ (* ldy lMar *) $b1/sAdr/ (* lda (sAdr),Y *) $00/ (* brk *) $49/$80/ (* eor #$80 *) $91/sAdr/ (* sta (sAdr),Y *) $60); (* rts *) end; begin writeln('Sample'); sPtr := memptr($00,sMem); invByte(sAdr,5); ch := readkey; end. Where am I? I'm still lost! Please help! zen
  11. Many thanks! It simply works.
  12. Hello, there, dear Andreas! You are very responsive Man! Simply You are The MAN! Many thanks! I'm working now with CLSN Pascal. It's unbelievably interesting because of rare ability to work natively with all XE memory. While Compile Time it sits partially in XMS but while Runtime it is out - and almost all XE XMS is Heap . My problem is that I can not find A WAY to access screen memory in Pascal. It just locks all my attempts on compiling stage and I can not use ML Inline routines... Yes! It's just Pascal strong typing of course. But I'm still lost. Best wishes from Snowy Moscow. Warmest wishes from Cold Russia. zen (it's just my initials - no more ) P.S. Sorry,Sorry,Sorry... Is it possible to change screen color permanently? (I think it is but how to?)
  13. Is it possible to work with TurboDOS without 130XE RAMDISK? Too many interesting programs uses 4 banks.
  14. Hi, friends - Recently Alfred said It may be really essential, because of this fact: CLSN manual says that - The value returned by the @ operator is a longint with the highest byte representing the bank (0 = Main; 1 .. 4 = Banks) and the low word representing the absolute memory location. 1-st byte - Bank 2-nd, 3-rd bytes - Address (reasonably in Atari little endians notation) If i can understand it may be the reason of erroneus behavior of invLine procedure. zen P.S. Just now I've found Pascal memory vision. Location Area ----------------- ---------------- $00000-$0FFFF Main Memory $14000-$18000 Bank #1 $24000-$28000 Bank #2 $34000-$38000 Bank #3 $44000-$48000 Bank #4 And how to work with this structure? zen
  15. Hello, DMSC. Glad to see another answer! As far as it's concerned PL65 code I can imagine that in the case of waiting any key pressed it must be the PROC without returning res variable . I simply used some previously prepared FUNC to accomplish the task. It may be called as Wait for Esc etc. In the case of assembly routine I clearly understand that it's my foult. But all of my another attempts was erroneous! I just can not understand the way of communication of Pascal ML part with it's own. They say nothing about strike Pascal typification in the case of using ML codes. How to explain Pascal that var sAdr is really the pointer to byte value in assembly? In PL65 there is a absolute rule that any ZP value is a pointer! Thus I can access any RAM address. But for only programming purposes it's too low leveled! I really love CLSN IDE! After all my LISP, PL65, CC8, BasicXE investigations... I noticed that it gives me some another freedom of programming ideas. But it kills my programming manner . As I can understand Pascal's Pointers are - never tracked dynamic addresses which are/may be organized in HEAP and can NOT be calculated from Pascal itself. And thank you for your explaination of my error. As you can see PL65 variable is NOT ZP variable but I've used Pascal's as ZP in ML. I repared and no success... zen
×
×
  • Create New...