address/data bus issue

Address/Data bus 설계

Big Mess O'Wire의 경우 data bus는 8 bit, address bus는 24bit를 사용하고 있습니다.
Magic1은 역시 address bus 24 bit (device select를 위해 2bit 사용, 한 device는 4M) data bus 8bit를 사용하고 있지요.

broneri cpu는 어드레스 버스는 적어도 24bit 이상은 만들어야 할 것 같군요. data bus는 8bit를 사용하는게 wiring을 줄이는 (wiring == pain ㅎㅎ; ) 방법이 될듯 합니다.

CISC or RISC 설계

BMOW의 경우 EEPROM에 BMOW microcode 실행 루틴이 들어 있습니다. 이렇게 함으로써 타 instruction set을 쉽게 포팅할 수 있게 설계되어 있습니다.

Magic1  역시 마이크로 코드 방식으로 동작하며 아래와 같은 블럭 다이어그램을 갖습니다.

저의 경우 RISC 방식 (사실 어떻게 보면 native microcode set)을 사용하기만 하면 될듯하군요. 향후 software 컴파일러 설계 시 risc 컴파일러를 만들게 되면 그만큼 cpu isa는 간단하지만 컴파일러의 컴파일 최적화 복잡도가 올라갈 수 있습니다. 그때 쯤 가면 기존의 micro code와 유사한 risc cpu에 cisc isa 해석기를 두면 될것 같다는 생각도 드네요.

CPU speed

BMOW는 2MHz로 동작하고 있습니다. 다소 느린편이지요. 또한 Magic1 역시 4.09MHz로 동작하고 있습니다. Magic1의 경우 MMU라고 할 수 있는 hardware page table을 지원하고 있어서 보다 소프트웨어에 대한 지원을 한다고 볼 수 있겠네요. 각 소프트웨어는 독립적인 주소 공간을 갖을 수 있으므로 보다 multi-tasking OS나 software flatform을 작성하기 용이 할 것 같습니다.

 저의 경우 VGA화면에서 게임이 동작되길 바라고 있기 때문에 최소 25.175MHz (for Video system)이상이어야 원활한 화면 재생이 될 것 같은데요. 문제는 사용하고 있는 74LS TTL 시리즈는 20MHz이상에 대해서는 동작이 제대로 되지 않기 때문에 cpu speed가 20MHz 이하로 결정된다는데 문제가 있습니다. 특히 ALU 부분은 74LS181N을 사용하고자 하고 있기에 이 speed constraint는 고정이라고 할 수 있겠네요.

만일 정말 제대로 된 화면 전환을 위해서는 video system을 따로 만들어서 accelerator 방식의 가속기 API를 제공함으로써 cpu system의 속도 제약에 대한 보상을 해줄 수 있을것 같습니다. 일단은 간단한 tile API와 sprite API를 제공하면 될것 같은데 뭐 아직 먼 얘기니까 ^^; 그때 가서 한번 해봐야겠지요

요 며칠동안 써든어택을 하면서 --; 놀기만 했네요. 어차피 개인적인 프로젝트니까, 쉬엄쉬엄 필 꽂힐때 천천히 진행해야 겠습니다. ^^