Jag har också en MPF-II, men den står lågt prioriterad på att-göra-listan att ordna adapter för att använda något nätaggregat som jag faktiskt har, eftersom originalnätagget saknas. Det i sin tur innebär att jag måste kolla upp pinout, vilket verkar kräva ohm:ande mot t.ex. kretsar i datorn eller expansionsbussen. Vilket år som helstASEA skrev: ↑7 oktober 2024, 07:12:26 Antar det var smidigast att göra så utan behöva ändra i nåt i ROM. Verkar som de inte var färg från början i europaversionerna av Apple II, bara monokrom signal.
Jag har en Multitech Microprofessor MPF-ii, som till viss mån ska vara Apple II kompatibel. Det är PAL och färggrafiken funkar riktigt bra i denna, hårdvarumässigt så är den superenkelt uppbyggd. Inga specifika grafikkretsar el dyl. Tänkte att jag nån dag skulle sätta mej in i hur de löst det där.
Allmänt så behöver pixelklockan vara dubbla PAL-färgbärvågsfrekvensen istället för dubbla NTSC-färgbärvågsfrekvensen, men sen behöver varannan linje flippa fas för att det ska bli korrekt PAL-färg. Inte säker på hur MPF-II gjorde, men gissar att den har dubbla skiftregister för högupplösningsläget där de används växelvis på udda/jämna rader, och där det ena har databitarna växlade för att färgerna ska fungera, eller nåt sånt.
Apple II har om jag fattat rätt 7 pixlar breda tecken, för att dubbla 3.58MHz NTSC delat med sju blir strax över 1MHz. Jämför för övrigt att PAL VIC 20 går på 1,1Mhz (4,43 delat på 4 (eller egentligen dubbla 4,43 delat på åtta). C64 har separata klockor för färgbärvågen (fyrdubbla 4,43 eller 3,58) och pixelklockan (8MHz) och delar därför ner pixelklockan med åtta för att få processor/bussklockan. En PLL-krets ser till att man slipper dot crawl.
Det verkar finnas en hel del användare av MPF-II i Brasilien. En video om den, med lite referenser till användarna i Brasilien:
Ja, Apple II var väl den vanligaste datorn med kortplatser på ett moderkort. Det vanliga före Apple II var ju ett mer eller mindre passivt bakplan (i vissa fall med enklare adressavkodning - tror att I/O-portarna på SWTPC 6800 är avkodade i bakplanet).
Det är säkert en smaksak/vanesak, men jag har alltid genuint hatat editorn i ABC 80. Ett tecken felskrivet och man är tvungen att skriva om hela raden. Med de begränsade resurser en 8-bit-dator från den eran har så tycker jag att Commodore löste det smidigast. Har inte 100% koll på hur Apple och TRS-80 gjorde, men det fanns ju fler burkar som gjorde som Commodore, t.ex. Atari 8-bit (som kom lite senare). Till och med den knöliga editorn hos Sinclair är hästlängder bättre än ABC 80.
Det smarta var väl mest att använda en befintlig ROM-krets som åtminstone var på gång att massproduceras för text-TV-dekoders i TV, och sannolikt en krets som Luxor ändå räknade med att köpa till sin TV-produktion. Commodore/MOS hade ju fördelen att de tillverkade kretsarna själva, inkl ROM, så de kunde välja vilka tecken de ville. Det är väl lite smaksak om man har 4x4 eller 6x4 för blockgrafik. Med 6x4 så går det åt 64 positioner, med 4x4 endast 16. Commodore har ju tecken för att göra t.ex. stapeldiagram med valfri höjd eller bredd i 1-pixel-steg, tecken för att göra raka och rundade hörn och streck (lite som "textgrafiken" på PC) osv.ASEA skrev: ↑7 oktober 2024, 07:12:26Smart att göra den kompatibel med texttvgrafik, kanske inte så hippt några år senare i jämförelse med tex C64. Men enkelt att lära ut och förstå för förstagångsanvändare, minneseffektivt också. Riktig ljudkrets också, även om något begränsade möjligheter i ABC80 att kunna utnyttja kretsen fullt ut så måste det vara en av de första datorerna att ha en dedikerad sådan.
Måste säga att det är lite förvånande att endast Apple II dels använder samma RAM för video som till resten av datorn, och dels har ett grafikläge. Grafikläget må vara en plåga jämfört med alla nyare burkar, men ändå överlägset vad samtida burkar hade. RAM-kretsarna som MOS/Commodore tillverkade var ju uppenbart snabba nog eftersom dessa kretsar används både för vanligt RAM och bildminne.
