[ASM] Commodore64 Utility

Salve.

Anche se la fotteseganza scorrerà potente in voi, io godo nello scrivere in ASM.

Sto finendo, manca poco oramai, un tool per C=64 che aggiunge una RAMDISK.
Cos'ha di diverso rispetto ai millemila tool già esistenti per C=64?

1. Sfrutta la RAM-under-ROM ($A000-$BFFF) ($C700-$FFFF) per un totale di 24K
2. Oltre a poter salvare file .PRG (BASIC) si possono salvare zone di memoria (.BYT) e programmi basic con autorun protetti da password (.cry)
3. Con un unico comando si può salvare l'intera RAMDISK su disco/nastro
4. Aggiunta dei comandi al BASIC2.0 (RLOAD/RSAVE/RVERIFY/RFORMAT/RDIR/...) con token dedicati (e conseguenti forme -abbreviate-)
5. Rimangono disponibili i soliti 38911bytes
6. Si può caricare/salvare in modalità asincrona,ma solo i file .byt

Poi che ne farò una volta completo? Lo donerò all'umanità, cosicchè possa apprezzare il mio genio. Ed il mio nome diventerà immortale.



RIDETE, STRONZI

bravo,
ma invece perchè non impari qualcosa di utile ?

che ne so ... c# almeno con unity puoi fare il gioco di jas in 3d?

Citazione:

---

Originariamente Scritto da Mastro Razza

bravo,
ma invece perchè non impari qualcosa di utile ?

---

:asd:

Plaudo comunque alla sua voglia di smanettare sul "ferro" alla buona vecchia maniera :snob:.

In realtà le cose sono diventate leggermente più semplici.
All'epoca, inserivo i codici direttamente.
Ora, invece, con Relaunch scrivi il codice in asm (con macro e tutte le cose belle che la tecnologia ci porta) ed il debug su VICE real-time...
All'epoca invece sbagliavi qualcosa e ZOT... crash... tutto perso. Bestemmie e Joystick volanti.

Citazione:

---

Originariamente Scritto da KymyA

In realtà le cose sono diventate leggermente più semplici.
All'epoca, inserivo i codici direttamente.
Ora, invece, con Relaunch scrivi il codice in asm (con macro e tutte le cose belle che la tecnologia ci porta) ed il debug su VICE real-time...
All'epoca invece sbagliavi qualcosa e ZOT... crash... tutto perso. Bestemmie e Joystick volanti.

---

All'epoca esisteva gia' il macro-assembler o alla peggio programmavi inserendo il tuo codice tramite un mini programmino basic che caricava in memoria (le buone vecchie istruzioni "data" ).
E in tutti i casi si salvava prima di provare :sisi:

bravo,
ma invece fare un app mobile che almeno hai la prospettiva di fare bei soldi invece di ste stronzate che non servono a niente?

invece servono.
se sai programmare con un assembly così "povero" quando passi ad utilizzare istruzioni complesse come le SSE4.1 puoi solo godere duro.
Oltretutto predispone la forma-mentis giusta per l'ottimizzazione delle risorse, del codice, etc..etc..
Quando i byte erano pochi, si ottimizzava duro. Ora che i programmatori hanno miliardi di bytes, scrivono codice poco ottimizzato.
Cmq fa nulla...

(tengo a dire che ho scritto l'engine per un gioco platform sulla piattaforma GAMEBOY ADVANCE; gioco italiano poi uscito. Lo scrissi in C++)

lo so
ma ti ripeto
lascia stare sti bagordi che non hanno mai creduto in te

tu puoi fare tanti più sordi però ok sei frocio

si vedono tanti froci con la crana.
Sono due termini che non godono della mutua-esclusione

Cosa vuoi che faccia per fare la crana?
Comincio ad installare l'AndroidStudio? Tempo fa iniziai a vedere gli intent, etc..etc..

Citazione:

---

Originariamente Scritto da KymyA

invece servono.
se sai programmare con un assembly così "povero" quando passi ad utilizzare istruzioni complesse come le SSE4.1 puoi solo godere duro.

---

Bof, forse ti puo' dare una infarinatura (obsoleta) per l'assembly, ma non di piu'

Citazione:

---

Originariamente Scritto da KymyA

Oltretutto predispone la forma-mentis giusta per l'ottimizzazione delle risorse, del codice, etc..etc..

---

Anche no: le risorse che oggidie si devono gestire im maniera oculata sono a un livello un pelino piu' alto del codice macchina.

Citazione:

---

Originariamente Scritto da KymyA

Quando i byte erano pochi, si ottimizzava duro. Ora che i programmatori hanno miliardi di bytes, scrivono codice poco ottimizzato.

---

Anche no 2: il lavoro di ottimizzazione del codice e' fatto dal compilatore, che per poterlo fare al meglio deve poterlo capire. Se inizi a ascrivere in C++ con cicli al contrario, goto a cazzo di cane e giochini strani coi puntatori (cose che ai tempi "eroici" della programmazione di facevano per spremere ogni sigolo ciclo macchina) poi il compilatore non capisce una ricca sega e ti tira fuori codice di merda.

- - - Aggiornato - - -

Citazione:

---

Originariamente Scritto da KymyA

Cosa vuoi che faccia per fare la crana?
Comincio ad installare l'AndroidStudio?

---

Ese, e' tardi oramai: recluta 20 giovini cinesi in gamba (da pagare due piatti di riso al giorno) e fagli fare il lavoro per te mentre tu scialaqui la crana a escort :snob:

scia kymya ma tu cellai ancora il commodore 64? e se si, cellai con quali espanzioni?

Citazione:

---

Originariamente Scritto da KymyA

Salve.

Anche se la fotteseganza scorrerà potente in voi, io godo nello scrivere in ASM.

Sto finendo, manca poco oramai, un tool per C=64 che aggiunge una RAMDISK.
Cos'ha di diverso rispetto ai millemila tool già esistenti per C=64?

1. Sfrutta la RAM-under-ROM ($A000-$BFFF) ($C700-$FFFF) per un totale di 24K
2. Oltre a poter salvare file .PRG (BASIC) si possono salvare zone di memoria (.BYT) e programmi basic con autorun protetti da password (.cry)
3. Con un unico comando si può salvare l'intera RAMDISK su disco/nastro
4. Aggiunta dei comandi al BASIC2.0 (RLOAD/RSAVE/RVERIFY/RFORMAT/RDIR/...) con token dedicati (e conseguenti forme -abbreviate-)
5. Rimangono disponibili i soliti 38911bytes
6. Si può caricare/salvare in modalità asincrona,ma solo i file .byt

Poi che ne farò una volta completo? Lo donerò all'umanità, cosicchè possa apprezzare il mio genio. Ed il mio nome diventerà immortale.



RIDETE, STRONZI

---

Interessantissimo. L'utilità di questa cosa è solo in ritardo di circa 30 anni :asd:

Uno dei fottesega maggiori degli ultimi 5 anni

Citazione:

---

Originariamente Scritto da Pierluigi

scia kymya ma tu cellai ancora il commodore 64? e se si, cellai con quali espanzioni?

---

con monitor, stampante, cose :smug:

Citazione:

---

Originariamente Scritto da Pierluigi

scia kymya ma tu cellai ancora il commodore 64? e se si, cellai con quali espanzioni?

---

Io ne ho 4 tra cui quello che mi hanno comprato a 7 anni (cuoricini). Vorrei pigliare pure un ALDI e un Silver ma per qualche motivo strano il C64 è tornato di moda e i prezzi sulla baia si stanno impennando a vista d'occhio.

Comunque Kymya devo ammettere che ti ho sempre inquadrato male. Se ti spippoli sui biscottoni non sei lo stronzone che sembri.
Io sto scrivendo per il C64 un engine per avventure narrative stile jrpg ma senza l'rpg, quelle robe gender alla to the moon per intenderci.
Vorrei postare qualche screen ma per ora tutte le stringhe che compaiono a schermo sono cariche di madonne e insulti ai santi e non c'ho voglia di toglierle.

Fra qualche giorno se mi gira faccio il devlog thread che non seguirà (giustamente) nessuno.

Citazione:

---

Originariamente Scritto da LordOrion

Bof, forse ti puo' dare una infarinatura (obsoleta) per l'assembly, ma non di piu'

Anche no: le risorse che oggidie si devono gestire im maniera oculata sono a un livello un pelino piu' alto del codice macchina.

Anche no 2: il lavoro di ottimizzazione del codice e' fatto dal compilatore, che per poterlo fare al meglio deve poterlo capire. Se inizi a ascrivere in C++ con cicli al contrario, goto a cazzo di cane e giochini strani coi puntatori (cose che ai tempi "eroici" della programmazione di facevano per spremere ogni sigolo ciclo macchina) poi il compilatore non capisce una ricca sega e ti tira fuori codice di merda.

- - - Aggiornato - - -

Ese, e' tardi oramai: recluta 20 giovini cinesi in gamba (da pagare due piatti di riso al giorno) e fagli fare il lavoro per te mentre tu scialaqui la crana a escort :snob:

---

Tutto verissimo. Può essere un buon esercizio di allenamento mentale, un tuffo nella storia dell'IT ma la conoscenza dell'asm del 6502-6510-8500 e affini ormai non serve a un cazzo di niente negli scenari moderni.

tutti che sanno programmare per c64 e nessuno che faccia qualche bel gioco utile..tipo un match of the day2 ma che non vada al rallenty

Ah, kymyuccio, già che hai fatto coming out sul c64 (aspetto sempre quello sull'altra cosa ma ognuno ha i suoi tempi), ti sottopongo una questione che mi sta mandando ai matti.

In pratica ho messo su una catena di interrupt per cui al vblank imposto lo schermo su un banco del VIC e disegno la grafica in anticipo sul raster attraverso un sistema di tile 4x4 con color-per-char, dopodichè arrivato alla 20esima riga di caratteri switcho su un altro banco per disegnare icone, dialoghi e salcazzo.
Va tutto bene finchè non arriva quell'occasionale frame maledetto in cui il rastertime non basta per fare tutto in quelle 20 righe di caratteri ma sforo di quattro o cinque linee di raster.
Non ci sarebbe problema, pure i due Turrican avevano lo stesso problema e l'universo mondo se ne è fottuto degli occasionali flicker al pannello di stato.
Ma nel mio caso quando succede ciò, e da quel momento in avanti, il primo interrupt comincia a triggerarsi alla fine del rastertime impegnato dal secondo anticipando la sua esecuzione di un frame e sputtanando tutto (perchè a quel punto lo switch dei banchi del VIC si sfasa rispetto a quello che voglio io) nonostante io gli dica espressamente di aspettare il vblank. Che cosa devo fare? Dove sto sbagliando? Devo tagliarmi il cazzo e offrirlo agli dei?

Se non riesci a disegnare tutto prima del prossimo refresh finisce che la parte mancante viene disegnata quando il refresh è già avvenuto e poi inizia a disegnare il frame successivo. Così continui ad accumulare ritardo.
Non sarebbe meglio fare in modo che se il programma non riesce a disegnare tutto il frame corrente prima del refresh interrompa il disegno e cominci a disegnare il frame successivo? Così ci sarebbero dei frame incompleti ogni tanto, ma almeno non accumuli ritardo.

Massima stima Cento, disagio over9000000, ma massima stima

Citazione:

---

Originariamente Scritto da frank_one

Se non riesci a disegnare tutto prima del prossimo refresh finisce che la parte mancante viene disegnata quando il refresh è già avvenuto e poi inizia a disegnare il frame successivo. Così continui ad accumulare ritardo.
Non sarebbe meglio fare in modo che se il programma non riesce a disegnare tutto il frame corrente prima del refresh interrompa il disegno e cominci a disegnare il frame successivo? Così ci sarebbero dei frame incompleti ogni tanto, ma almeno non accumuli ritardo.

---

forse sta parlando di bad-lines... lo smadonnamento di ogni programmatore che ha cercato di tirare su qualche demoscene

Cmq, per chi ha chiesto (non mi va di replyare) ho 3 C64, classico nelle due versioni e nuovo bianco. Un 128, 1541, datassette, stampante C803, EasyFlash, SD2iec, Final Cartridge3 ...


x Cento... Ma programmi su PC? Cosa usi per il debug? perché se usi il C64 65XE debugger ti semplifica la vita... https://sourceforge.net/projects/c64-debugger/

Riguardo il fatto che l'assembly 65xx non serva ad un cazzo, permettetemi di dirvi (EDUCATAMENTE) che siete delle grandissime teste di minchia. Io l'ho trovato utile per riprogrammare dei lettori di barcode oppure dei PLC qui in azienda. Se una persona qualsiasi che non avesse mai visto codice assembly avesse visto il listato del firmware del lettore avrebbe pensato "CHE CAZZO E' QUESTA MASSA DI CARATTERI SCRAUSI??"