Poszukiwana/poszukiwany; przykład utworu w Music Pro Tracker (by SoTe) z wykorzystaniem sampli. Jeśli to marzenie ściętej głowy, proszę o sprostowanie.
P.S Uparcie i skrycie poszukuje prostego, ugruntowanego, bezproblemowego ;) Zagrania synthu z POKEY w mixie z samplami.
Z uwagi na niską wiedzę techniczną nie skorzystam z opcji jak np. z REHARDEN, wspomniane w: ->link<- Dlatego upatruje szansy w Music Pro Tracker i dostępnym playerze w Mad Pascalu. ->link<-
Here are some polish texts regarding MPT, which I do not understand at all. (Google translate did not help much.) They were on the ATR image of MPT 2.4
CharlieChaplin: You can use most AI tools, such as DeepSeek.com to ask it to convert it from ATARI to ASCII and then ask for a translation from Polish to English. Also, to translate well, you could use DEEPL.com. Greetings!
Najbardziej pomocna paczka z linku od @tebe, repostuje; ->link<- ->link<-
Jest to obraz dysku, więc trzeba wydostać dokumentacje np używając... javascript ;) ->link<-
Mam z kolei problem z Altirrą: Uruchomiony Music Pro Tracker nie jest w stanie załadować utworu .mpt z dysku. Leci error "C10 Error 130"
Stworzyłem obraz .atr z muzyczkami .mpt (przy pomocy dir2atr), i podmontowałem go jako dysk D1 w Altirra.
MPT bootuje z pliku .xex W menu MPT wybieram File/Load i próbuje wpisywać: D:SONG123.MPT D1:SONG123.MPT SONG123.MPT
Nic z tego nie działa, leci wspomniany error. Przeglądam obraz .atr narzędziem z Altirry i widzę pliki utworów, niby wszystko jest na stole.
Ta sama operacja na stockowym a8 (65XE) działa ale robię trochę inaczej: z SIO2SD ładuje Music Pro Tracker (.xex), później montuje plik utworu .MPT na D1: i z menu File/Load: SONG123.MPT
Z tego co rozumiem na Altirra można montować tylko obrazy dysków, nie pliki (.mpt). Czy ktoś udrożnił ścieżkę ładowanie .mpt do Music Pro Tracker na Altirra?
żeby działały operacje I/O w pamięci Atari musi znajdować się DOS, czyli menadżer wszystkich operacji I/O związanych z dyskietką
potrzebujesz ATR-a z DOS-em, na którym masz MPT i pozostałe pliki, uruchamiasz takiego ATR-a, startuje DOS, z DOS-a uruchamiasz MPT
możemy podpiąć dyskietki ATR pod Altirrą i przy pomocy DOSu kopiować między nimi dane (warto pamiętać że Altirra umożliwia realne i wirtualne operacje na ATR, więc powinniśmy to odpowiednio skonfigurować inaczej nasze zmiany ulegną zapomnieniu po zamknięciu Altirry)
w załączniku zaincjowana dyskietka (ATR) w formacie D (180K) DOS-em II64, moja podręczna dyskietka
jak kasować takiego ATR-a pod DOSII64?
CL# kasuje całą zawartość IN# inicjuje dyskietkę DOS-em
Wykorzystałem gotowy obraz z ->link<- i dodałem do obrazu pliki BARTMAN.MPT i .SMP (załącznik Mpt24s_and_docs.ATR)
i teraz na 65XE z SD2SIO odpalam ten obraz i wszystko idzie legitnie: - najpierw odpala się DOS i UI - wpisuje MPT24.COM i ładuje się MPT - już w programie MPT używam "load" i wpisuje BARTMAN.MPT - utwór poprawnie się ładuje - z menu "Special" ładuje sampla BARTMAN.SMP
Tej samej operacji nie jestem w stanie zrobić na Altirra (z tym samym obrazem z załącznika). Obraz nie ładuje się - czarny ekran.
Proszę o test jeśli ktoś ma chwilę, ponieważ u mnie podejrzewam patologię i zwyrodnienia bo działam na wine (OSX, M2). Altirra jest na "fabrycznej" konfiguracji.
@Vidolczy masz url do źródeł takie playera mpt+sample ? @tebe czy jest możliwość pożenienia tego w Mad Pascalu korzystając z asm { } czy to w praktyce będzie droga przez mękę albo niewykonalne?
ogólnie sample zawsze zajmują większość czasu CPU, na Atari nie ma DMA jak w Amidze, gdzie podajemy adres sampla i chip go pobiera z pamięci, tutaj CPU musi odwalać całą robotę
hej, o ile dobrze pamiętam, to zrobiłem najpierw sap'a z tych plików pod mpt, a potem z sap'a zrobiłem xex'a. Nie umiem w kodowanie, po prostu używałem chyba ASAP + Altirra.
były oddzielne programy które dokonywały konwersji sampli z Amigi, ogólnie to nie problem stworzyć sampla 8Khz, 15Khz i zapisać go jako WAV, PCM bez kompresji, nawet jak program zapisze to jako 4bit, to będzie to tylko bajt z 4 bitami informacji
będzie trzeba sobie stworzyć program który dwa kolejne bajty z takiego PCM-a zapisze jako starszy i młodszy nibble, no i należy pamiętać aby długość sampla była wielokrotnością strony pamięci (256 bajtów)
nagłówek sampli D8, D15 to 32 bajty, 16 bajtów starszych adresów początku sampla i 16 bajtów starszych adresów końca sampla
dlatego załadowanie sampli do pamięci pod wybrany adres inny niż domyślne $9000 wymaga przeliczenia tych starszych bajtów adresów z nagłówka
Program do przygotowania sampla w formacie .D8, D15 jeszcze do ogarnięcia :), ale wykorzystanie playera w MP okazało się wypadkiem przy pracy.
Zachęcony możliwościami skompilowałem player do .obx podlinkowałem w .pas, zawołałem start ;) i.. wybuchło. KONIEC
Praca u podstaw. Zanim zorientowałem się jak despotyczny jest kod playera, wrzuciłem zadanie analityczne do "asystenta" i po wynikach widzę, że osadzenie tego w MP jest udręką przez piekło albo lepiej w ogóle o tym nie myśleć.
"wyświetlenie obrazka" podczas odgrywania .md1 na zadanie domowe, ale w .asm.
Raport "asystenta":
Zero-Page ($00-$FF):
Mad Pascal reserves zero-page for its runtime: EDX/ECX/EAX: 32-bit registers at zero-page (typically $80-$8B or similar; exact locations depend on compilation but often overlap $80-$FF user area). These are used for REGISTER parameters (first 3 params in procs). Software stack pointer: Tied to X-register usage. Other internals: Pointers, temps (e.g., $CB-$CE for pointers, but variable).
Player code uses $EC-$FF (e.g., addr=$EC, audzer=$F0, adrsmp=$FE). This is in the BASIC/user area ($80-$FF), which Mad Pascal also uses for globals/locals if ABSOLUTE or REGISTER. Collision Risk: High. $EC-$FF might overlap Mad Pascal's EDX/ECX/EAX or other temps. Atari OS reserves $00-$7F (cleared on warmstart), so player's usage is in "safe" user space but conflicts with Pascal runtime. Fix: Relocate player zero-page vars to a dedicated block, e.g., $CB-$DF (check Mad Pascal map via -t switch). Or make them non-zero-page (slower but safer). Use .public in ASM to expose as ABSOLUTE in Pascal (e.g., var addr: word absolute $EC; but remap to avoid overlap).
Main Memory:
Player originates at $2000, loads music at $5000 (msx), samples at $9000. Mad Pascal: User code starts ~$2000+ (after runtime), globals at $0600 or $A000. Screen/Display List often at $BC00+ (default GR.0). Extended RAM not used by default. VBI vector (548-549 = $0224-$0225, VVBLKD shadow). Collision Risk: Low for code/data if linked as .obx (relocatable). But VBI install overwrites OS vector—Mad Pascal may use VBI for its own (e.g., if ROMOFF or custom interrupts). Player pokes POKEY ($D200+), safe but ensure no concurrent access. Fix: Use relocatable .obx; Mad Pascal handles via {$LINK}. For VBI, make it an INTERRUPT proc in ASM (save A/X/Y, RTI end). Avoid $C000-$FFFF writes unless {$DEFINE ROMOFF} (player doesn't use, so safe). Samples at $9000 avoid screen mem.
Stack ($0100-$01FF):
Grows down from $01FF; Mad Pascal uses for calls (X-reg stack). Player VBI (vbl) calls play, jumps to $E462 (SYSVBV). Collision Risk: Medium. If VBI depth > stack space, overflow. Player doesn't push much, but combined with Pascal calls, risk. Fix: Keep VBI lean; save/restore stack explicitly if needed.
Register Conflicts:
X-Register: Mad Pascal reserves X for software stack (parameter passing, locals). MUST PRESERVE in all ASM code—push/pull if modified.
Player code: Heavily uses X (e.g., channel loops ldx #3; dex; bpl), modifies without save. Collision Risk: Critical—will crash Pascal stack if not preserved. Fix: In all procedures, txa; pha at start, pla; tax at end. Especially in play (VBI).
A/Y Registers: Free, but in INTERRUPT procs, save/restore all (A/X/Y) manually.
Player: Modifies freely. Fix: For VBI (play), wrap with save/restore.
Other: No flags/processor status issues noted.
Other Conflicts:
Interrupts: Player sets custom VBI, calls play. Mad Pascal INTERRUPT procs must end with RTI, not RTS/JMP.
Fix: Change play to RTI-end; declare as procedure Play; interrupt; assembler;.
Linking/Compilation: Player uses .org $2000, not relocatable by default.
Fix: Compile with mads mpt_player.asm -hm -o:mpt_player.obx -xi:<mad_pascal_base_path> for Mad Pascal headers (.hea). Use .proc/.endp for procedures, .public for exports.
ROMOFF: Player doesn't use, but if Pascal enables, watch DLI/VBI stability (player has no DLI). CPU Load: 15 kHz sample mode heavy; test in Pascal loop for slowdown.
General Rework Strategy:
Make code relocatable: Remove fixed .org, use labels. Expose procs/vars: .proc InitSong .endp, etc.; .public pozptr for position read. Preserve X everywhere. Compile to .obx, link in Pascal with {$LINK mpt_player.obx}, include .hea for declarations.
Step 2: Reorganized Assembly Code into Procedures I'll provide reworked ASM code snippets (not full; assume paste into original). Reorganize into:
InitSong: Combines original start inits (music/sample load, tables). StartSong: Sets VBI, starts playback (czygrc=1). PlaySong: The play routine, now a proc (for VBI call). Expose pozptr as .public byte for Pascal read. Add X-preserve wrappers. Relocate zero-page to $CB-$DF (example; verify no overlap via Pascal map).
Poukładanie w pamięci wydaje się mniejszym wysiłkiem, niż praca w rozczytaniu jakie zasoby zajmuje player - z czego korzysta podczas pracy (przerwanie, rejestry itd).
CommentTime21 Aug 2025 14:17 (2 godzin temu) zmieniony
@tebe
OMG (| - _ - |) ->link<- Dzięki! Pozostaje dłużnikiem.
@MaW wrzuć co masz na wyjściu ze swojego asystenta, porównamy robotę robocików. Generalnie to zapytałem w jakim elementach implementacja playera MD1 w .asm koliduje z MP (pamięć, runtime itd).
