หน้าแรก>การเขียนโปรแกรมที่เกี่ยวข้อง>ซอร์สโค้ดอื่น ๆ
ดาวน์โหลด

AgDev - พอร์ตของ CEdev C/C++ Toolchain ไปยังแพลตฟอร์ม Agon

ภาพรวม

Agon Light และการปรับปรุงแพลตฟอร์ม Agon อื่นๆ ใช้โปรเซสเซอร์ Zilog eZ80 eZ80 มีพื้นที่ที่อยู่ 24 บิต รองรับหน่วยความจำ 16 เมกะไบต์ เทียบกับ 64 กิโลไบต์ของ Z80 ดั้งเดิม eZ80 มีโหมดการทำงานสองโหมด: โหมด Z80 มาตรฐาน ซึ่งมีรีจิสเตอร์ 16 บิต ทำให้ง่ายต่อการระบุหน่วยความจำ 64k แต่ต้องใช้ "ธนาคาร" เพื่อเข้าถึงหน่วยความจำมากกว่า 64k; และโหมดการดำเนินการ ADL (address data long) ซึ่งขยายรีจิสเตอร์เป็น 24 บิต ทำให้สามารถเข้าถึงพื้นที่ที่อยู่ทั้งหมดได้อย่างง่ายดาย

เมื่อเราพิจารณาภาษาการเขียนโปรแกรมระดับสูง Z80 มีหลายภาษา แต่มีหน่วยความจำจำกัดอยู่ที่ 64k หรือมีวิธีการสลับช่องที่ยุ่งยากในการเข้าถึงหน่วยความจำที่มากขึ้น

เมื่อพิจารณาถึงภาษาการเขียนโปรแกรม C มีคอมไพเลอร์ Z80 C อยู่จำนวนหนึ่ง จนถึงปัจจุบัน ชุมชน Agon ได้มุ่งเน้นไปที่สองประเด็น:

  • สภาพแวดล้อมการพัฒนา Zilog ZDS II ซึ่งสามารถสร้างโค้ด eZ80 ADL ได้ นี่เป็นชุดเครื่องมือดั้งเดิมที่นักพัฒนาของ Agon ใช้ แต่เป็นซอร์สแบบปิด ทำงานบน Windows เท่านั้น และรองรับเฉพาะมาตรฐานข้อมูล C89 เท่านั้น

  • SDCC (คอมไพเลอร์ C ของอุปกรณ์ขนาดเล็ก) ตัวเลือกยอดนิยมสำหรับคอมพิวเตอร์ 8 บิต และการปรับสิ่งนี้สำหรับ Agon ได้รับความสนใจจากผู้คนจำนวนมากในคอมพิวเตอร์ Agon นี่เป็นคอมไพเลอร์ที่ดีสำหรับ Z80 แต่รองรับเฉพาะ Z80 เท่านั้นไม่ใช่โหมด ADL

อีกทางเลือกหนึ่ง ห่วงโซ่เครื่องมือ CEdev C/C++ เป็นคอมไพเลอร์โอเพ่นซอร์สที่สามารถสร้างโค้ด ADL ได้ โดยกำหนดเป้าหมายเป็นเครื่องคิดเลข TI-84 Plus CE (ใช้โปรเซสเซอร์ eZ80) และมีชุมชนที่มีขนาดเหมาะสม CEdev ขึ้นอยู่กับคอมไพเลอร์ LLVM และแอสเซมเบลอร์ fasmg เวอร์ชัน eZ80 มันสร้างโค้ด ADL ที่มีพอยน์เตอร์ 24 บิต, จำนวนเต็ม 24 บิต, ความยาว 32 บิต, กางเกงขาสั้น 16 บิต และโฟลต 32 บิต นอกจากนี้ยังมีไลบรารี่ที่กว้างขวางสำหรับโปรแกรม C และ C++ (แม้ว่าจะยังไม่เป็นไปตามมาตรฐาน ISO...)

AgDev เป็นผลมาจากความพยายามในการปรับเปลี่ยน CEdev เพื่อรองรับชุดคุณลักษณะและการออกแบบฮาร์ดแวร์ของแพลตฟอร์ม Agon ผลลัพธ์ที่ได้คือ toolchain ที่ทรงพลังกว่าและมีความสามารถ C++ เมื่อเปรียบเทียบกับตัวเลือกอื่นๆ สำหรับ Agon

การติดตั้ง

ดาวน์โหลดรุ่นหรือรุ่นจากแหล่งที่มาด้วยตัวคุณเอง วาง build ไว้ในไดเร็กทอรีที่คุณเลือก

หลังจากนั้นตรวจสอบให้แน่ใจว่าโฟลเดอร์ /bin สามารถพบได้ใน PATH ; หากคุณใช้ Windows ให้ทำตามคำแนะนำนี้ หรือคุณสามารถเรียกใช้ cedev.bat และดำเนินการคำสั่งจากที่นั่นแทน บน Linux ให้รัน export PATH=/<insert path here>/bin:$PATH ในหน้าต่างเทอร์มินัล

การสร้างโปรแกรม

สิ่งนี้เป็นไปตามแนวทางเดียวกันกับ CE Toolchain ดั้งเดิม (ดูด้านล่างของหน้าเริ่มต้นใช้งาน CEdev) กระบวนการสร้างได้รับการแก้ไขเพื่อหยุดการสร้างไฟล์ .bin นี่คือไฟล์ปฏิบัติการ Agon Light

ฉันแนะนำให้ใช้:

 ทำให้สะอาด
ทำให้ V=1

คำสั่ง make clean สามารถใช้เพื่อลบผลลัพธ์ของการคอมไพล์ก่อนหน้านี้ และบังคับให้คอมไพล์ใหม่

กระบวนการสร้างต้องผ่านขั้นตอนต่อไปนี้:

  1. การรวบรวมไฟล์ต้นฉบับ .c เป็นบิตโค้ด LLVM (.bc) โดยใช้ ez80-clang

  2. การเชื่อมโยงบิตโค้ด LLVM โดยใช้ ez80-link ซึ่งรวมถึงการเพิ่มประสิทธิภาพเวลาลิงก์ด้วย

  3. การสร้างโค้ดแอสเซมบลี eZ80 (.src) สำหรับโปรแกรมต้นทางที่ใช้ ez80-clang

  4. การประกอบและการเชื่อมโยงโค้ดแอสเซมบลีที่สร้างขึ้น (จากขั้นตอนที่ 3) กับไลบรารีและรันไทม์คอมไพเลอร์โดยใช้ fasmg ซึ่งรวมถึงการสร้างไฟล์ปฏิบัติการที่กำหนดเป้าหมายไว้ที่ตำแหน่งหน่วยความจำเฉพาะ นี่เป็นส่วนหลักของกระบวนการสร้างที่ต้องปรับเปลี่ยน

C Calling Conventions (สำหรับการเชื่อมต่อกับแอปพลิเคชัน ASM)

ดูหมายเหตุการใช้งาน Zilog "การโทร C จาก asm.pdf"

เฉพาะรีจิสเตอร์ IX และสแต็กเท่านั้นที่ต้องถูกรักษาไว้โดยฟังก์ชันที่ถูกเรียก

ข้อโต้แย้ง

อาร์กิวเมนต์จะถูกผลักจากสุดท้ายไปแรกที่สอดคล้องกับต้นแบบ C ใน eZ80 นั้น 3 ไบต์จะถูกพุชไปที่สแต็กเสมอโดยไม่คำนึงถึงขนาดจริง อย่างไรก็ตาม ฟังก์ชันแอสเซมบลีต้องระมัดระวังในการใช้ไบต์ที่ถูกต้องที่ถูกพุชเท่านั้น ตัวอย่างเช่น หากใช้ประเภท แบบสั้น ไบต์ด้านบนของค่าที่พุชบนสแต็กจะมีข้อมูลที่กำหนดเอง ตารางนี้แสดงรายการตำแหน่งที่สัมพันธ์กับ sp จากภายในฟังก์ชันที่ถูกเรียก โปรดทราบว่า sp + [0,2] มีที่อยู่ผู้ส่ง

ประเภท C/C++ ขนาด ตำแหน่งกองซ้อน
ถ่าน 1 ไบต์ เอสพี + [3]
สั้น 2 ไบต์ เอสพี + [3,4]
ภายใน 3 ไบต์ เอสพี + [3,5]
ยาว 4 ไบต์ เอสพี + [3,6]
ยาวยาว 8 ไบต์ เอสพี + [3,10]
ลอย 4 ไบต์ เอสพี + [3,6]
สองเท่า 4 ไบต์ เอสพี + [3,6]
ตัวชี้ 3 ไบต์ เอสพี + [3,5]

โปรดทราบว่า eZ80 เป็น endian เพียงเล็กน้อย กล่าวคือ ไบต์ที่มีนัยสำคัญน้อยที่สุดจะถูกเก็บไว้ก่อน

การส่งคืน

ตารางนี้แสดงรายการรีจิสเตอร์ที่ใช้สำหรับคืนค่าจากฟังก์ชัน เครื่องหมายของประเภทไม่ส่งผลต่อรีจิสเตอร์ที่ใช้ แต่อาจส่งผลต่อค่าที่ส่งคืน LSB อยู่ในรีจิสเตอร์ทางด้านขวาสุดของนิพจน์ เช่น E:UHL หมายถึงรีจิสเตอร์ L เก็บ LSB

ประเภท C/C++ กลับทะเบียน
ถ่าน ก
สั้น เอชแอล
ภายใน เอ่อ.
ยาว อี:เอ่อ.
ยาวยาว BC:UDE:UHL
ลอย อี:เอ่อ.
สองเท่า อี:เอ่อ.
ตัวชี้ เอ่อ.

ไลบรารี IO มาตรฐาน

ไม่เป็นไปตามมาตรฐาน ISO!

ประกอบด้วยสิ่งต่อไปนี้:

ไฟล์ IO:

  • fopen() , freopen(), fclose()

  • fputc() , fputs()

  • fgetc() , ungetc() , fgets()

  • feof() , ferror() , fflush()

  • fread() , fwrite()

  • fseek() , rewind() , ftell()

  • clearerr()

  • remove()

มาตรฐาน STDIN / STDOUT IO:

  • putchar() , puts()

  • getchar() , gets_s()

เอาต์พุตที่จัดรูปแบบแล้ว

  • printf() (และ vprintf() )

  • sprintf() (และ vsprintf() )

  • snprintf() (และ vsnprintf() )

อินพุตที่จัดรูปแบบแล้ว

  • scanf()

  • sscanf()

มีสิ่งอื่นๆ ในที่นี้ เช่น stdint และอื่นๆ แต่ส่วนใหญ่ควรตรงกับความคาดหวังของไลบรารีมาตรฐานทั่วไป ส่วนใหญ่.

การเปลี่ยนเส้นทาง stdio

สามารถเปลี่ยนเส้นทางเอาต์พุตได้โดยใช้ freopen() บน stdout หรือ stderr :

  • putchar() - ส่งออกไปที่ outchar() เว้นแต่ว่าเอาต์พุตจะถูกเปลี่ยนเส้นทาง ซึ่งในกรณีนี้จะส่งออกไปที่ fputc()

  • puts() - เรียก putchar()

  • printf() (และ vprintf() ) - เรียก npf_putc_std() ซึ่งเรียก putchar() ใน nanoprintf.c

  • fputc() - เรียก mos_fputc() เว้นแต่ถูกเรียกบน stdout เมื่อเรียก outchar() - หลีกเลี่ยงการเรียก putchar() เพื่อไม่ให้เสี่ยงต่อการวนซ้ำการเรียกใช้ฟังก์ชัน

สามารถเปลี่ยนเส้นทางอินพุตได้โดยใช้ freopen() บน stdin :

  • getchar() - เรียก inchar() เพื่อรับอักขระและ outchar() เพื่อสะท้อนอักขระ (แม้ว่าเอาต์พุตจะถูกเปลี่ยนเส้นทางก็ตาม) หากเอาต์พุตไม่ได้รับการเปลี่ยนทิศทางให้เรียก fgetc() และไม่สะท้อนอักขระ

  • gets_s() - เรียก getchar() หากอินพุตไม่ได้ถูกเปลี่ยนเส้นทาง (บรรทัดถูกยกเลิกด้วย CR) การเรียก fgets() ของอินพุตถูกเปลี่ยนเส้นทาง (บรรทัดถูกยกเลิกด้วยคู่ CR/LF)

  • scanf() - เรียก getchar() ใน uscan.c (ไม่จำเป็นต้องอัปเดต)

  • fgetc() - เรียก mos_fgetc() เว้นแต่ถูกเรียกบน stdin เมื่อเรียก inchar() และ echos ด้วย outchar() - หลีกเลี่ยงการเรียก getchar() เพื่อไม่ให้เสี่ยงต่อการเรียกใช้ฟังก์ชันวนซ้ำ

ต้องใช้ FILE * ซึ่งเป็นตัวชี้ไปยังตัวจัดการไฟล์ที่ส่งคืนโดย fopen และส่งผ่านไปยังรูทีน IO ของไฟล์เพื่อระบุไฟล์ที่จะดำเนินการ

ไฟล์อื่นๆ ที่เกี่ยวข้อง:

stdio.h - ไฟล์ส่วนหัวปกติ ซึ่งกำหนดฟังก์ชันต่างๆ และ typedef สำหรับ FILE

files.c - สร้างอินสแตนซ์ที่เก็บข้อมูลสำหรับตัวจัดการไฟล์รวมถึง: stdout, stderr, stdin

มีการกำหนดตัวจัดการไฟล์มาตรฐานต่อไปนี้:

  • stdout - เอาต์พุตเริ่มต้น

  • stderr - เอาต์พุตเริ่มต้นสำหรับข้อความแสดงข้อผิดพลาด

  • stdin - อินพุตเริ่มต้น

MOS ไม่ได้ใช้การเปลี่ยนเส้นทางอินพุต / เอาท์พุต ดังนั้นตามค่าเริ่มต้นสิ่งเหล่านี้ทั้งหมดจะใช้คอนโซล

การประมวลผลบรรทัดคำสั่งและการเปลี่ยนเส้นทางอินพุต / เอาท์พุต

มีสองตัวเลือกสำหรับการประมวลผลบรรทัดคำสั่ง

การประมวลผลบรรทัดคำสั่งอย่างง่าย

ซึ่งจะถูกรวมไว้โดยอัตโนมัติหากมีการกำหนดฟังก์ชันหลักเป็น

 int main( int argc, ถ่าน* argv[] )

แยกบรรทัดคำสั่งโดยใช้ช่องว่างเป็นตัวคั่น ตัวเลือกบรรทัดคำสั่งมีอยู่ในอาร์เรย์ argv[] ตามปกติ

การประมวลผลบรรทัดคำสั่งที่ซับซ้อน - สำหรับการเปลี่ยนเส้นทางและการอ้างอิง

สิ่งนี้จะถูกรวมไว้เป็นทางเลือกหากแอปพลิเคชัน makefile ประกอบด้วย:

 LDHAS_ARG_การประมวลผล = 1

สิ่งนี้รองรับ

  • การอ้างอิงด้วยเครื่องหมายคำพูดคู่

  • การเปลี่ยนเส้นทางอินพุต / เอาท์พุต

    • >out_file.txt - เปลี่ยนเส้นทาง stdout ไปที่ out_file.txt สร้างไฟล์ใหม่

    • >>out_file.txt - เปลี่ยนเส้นทาง stdout ไปที่ out_file.txt ต่อท้ายไฟล์

    • <in_file.txt - เปลี่ยนเส้นทาง stdin ให้มาจาก in_file.txt

คำสั่งมอส

สำหรับเอกสารประกอบปัจจุบันเกี่ยวกับคำสั่ง MOS โปรดดูเอกสาร Agon Console8

MOS (ระบบปฏิบัติการของเครื่องจักร) มีส่วนต่อประสานกับระบบไฟล์ Agon และอุปกรณ์ต่อพ่วงฮาร์ดแวร์บางอย่าง เช่น เมาส์ โดยจะเก็บข้อมูลเกี่ยวกับตัวแปรของระบบไว้ในโครงสร้าง SYSVAR ขนาดใหญ่ที่สามารถเข้าถึงได้จากฝั่ง Z80 โดยทั่วไปโค้ด C ของคุณจะประกาศตัวชี้ไปยังโครงสร้างนี้ โดยเริ่มต้นดังนี้:

 ความผันผวนคงที่ SYSVAR* sv;
 sv = vdp_vdu_init();

สำหรับข้อมูลเพิ่มเติม โปรดดูที่ <mos_api.h>

คำสั่ง VDP / VDU

สำหรับเอกสารประกอบปัจจุบันเกี่ยวกับคำสั่ง VDU โปรดดูเอกสาร Agon Console8

VDP (โปรเซสเซอร์แสดงผลวิดีโอ) ยอมรับสตรีมข้อความจาก MOS ซึ่งทำหน้าที่เหมือนเทอร์มินัลข้อความ / กราฟิก สตรีมข้อความสามารถประกอบด้วย:

  • ข้อความปกติ

  • หลีกเลี่ยงลำดับ / คำสั่งเพื่อควบคุมการแสดงผลและส่งคำสั่งกราฟิก / เสียง / ฯลฯ

เมื่อ MOS ส่งคืนผลลัพธ์อันเป็นผลมาจากการส่งคำสั่ง ผลลัพธ์เหล่านี้จะถูกจัดเก็บไว้ใน SYSVAR และจะไม่ส่งคืนโดยตรงเพื่อตอบสนองต่อคำสั่ง การตอบสนองเป็นแบบอะซิงโครนัส - เพื่อตรวจสอบว่าผลลัพธ์ถูกส่งกลับแล้ว:

  • ตั้งค่า vdp_pflags ใน SYSVAR ให้เป็นศูนย์

  • ออกคำสั่ง VDU

  • รอให้ตั้งค่าบิตที่เกี่ยวข้องใน vdp_pflags - ดู <mos_api.h> สำหรับบิตมาสก์

คำสั่งสามารถส่งโดย:

  • putch() - อักขระตัวเดียว (นี่ไม่ใช่ส่วนหนึ่งของไลบรารีมาตรฐาน C)

  • mos_puts() - สตริงหลายอักขระ

เอาต์พุตทั้งสองนี้โดยตรงไปยัง MOS/VDP - โปรดทราบว่าไม่ได้เป็นส่วนหนึ่งของไลบรารี STDIO และไม่อยู่ภายใต้การแปลหรือการเปลี่ยนเส้นทาง CR/LF

ฟังก์ชันอำนวยความสะดวกสำหรับคำสั่ง VDU หลายคำสั่งมีให้ใน AgDev ตัวอย่างเช่น หากต้องการเปลี่ยนหน้าจอ MODE เป็น 3 ให้เรียก C vdp_mode(3); จะส่ง 22,3 เป็นไบต์เดี่ยวไปยังเอาต์พุต เทียบเท่ากับ putch(22); putch(3); ดูรายการฟังก์ชันเหล่านี้ได้ที่ <vdp_vdu.h> ฟังก์ชั่นเพิ่มเติมที่เกี่ยวข้องกับการจัดการแป้นพิมพ์มีอยู่ใน <vdp_key.h>

ขยาย
ข้อมูลเพิ่มเติม
แอปที่เกี่ยวข้อง
แนะนำสำหรับคุณ
ข้อมูลที่เกี่ยวข้อง ทั้งหมด