Welcome to the Lounge
For lazing about and discussing anything in a software developer's life that takes your fancy.
The Lounge is rated PG. If you're about to post something you wouldn't want your kid sister to read then don't post it. No flame wars, no abusive conduct and please don't post ads.
Technical discussions are welcome, but if you need specific help please use the programming forums
|... for which there will certainly be no more adequate place to post it. And I don't really expect more than some moral support.
So here we go: I'm planing to build a computer again, with up to 8 CPUs (CDP1802, what else?), up to 8 Mb RAM, Graphics based on the old MC6847 graphics chip (with one of the CPUs dedicated as graphics processor). An 8 bit machine with processors from 1976, which would have outperformed typical 16 bit Amigas or Atari STs from 1990.
I also want PS/2 ports for the keyboard and a mouse, but don't want to use microcontrollers. I have read, that in IBM's first AT models the Intel 8255 parallel port was used in bit mode for that purpose. Does anybody have more information about that?
The old computers based on the CDP1802 worked quite well without any OS, but this will obviously not be the case here. So I fired up both the assembler and the C compiler and started coding.
The code generated by the C compiler was more than eight times longer than that produced by the assembler. So much for compilers generating much better code than you possibly could manually. But, to be fair, it is no secret that 8 bit processors are generally not well suited for C.
Looking at the machine code confirmed that. The C compiler needed all that extra code to pass parameters to functions and keep local variables on the stack. The oldschool assembly techniques relied far more on global variables or holding values in the CDP1802's large register set.
Before I really can get to work now, I will need to work out some kind of calling convention which does not bloat the code too much, does not bog down the CPU by doing actually more work to pass parameters and variables than anything else, while trying to at least reduce the need for globals. Still, it now seems very strange that even the processor's handbook saw no need to discuss any techniques beyond global data. For recursive calls they worried about keeping the return address on the stack, but that's all. Who cares about parameters or local variables?
Edit: Just for fun: A small part of the assembler's listing:
(1) 118/ 34 : ; =========================================================================================
(1) 119/ 34 : ; Interrupt and DMA service routine for the CDP1861 to display an effective resolution
(1) 120/ 34 : ; of 64 x 64 pixels, using a display buffer of 512 bytes.
(1) 121/ 34 : ; =========================================================================================
(1) 122/ 34 :
(1) 123/ 34 : =>TRUE IF Resolution == 40H
(1) 124/ 34 :
(1) 125/ 34 : 72 ExitInterrupt: LDXA
(1) 126/ 35 : 70 RET
(1) 127/ 36 : C4 DisplayInt: NOP
(1) 128/ 37 : 22 DEC R2
(1) 129/ 38 : 78 SAV
(1) 130/ 39 : 22 DEC R2
(1) 131/ 3A : 52 STR R2
(1) 132/ 3B : F8 01 LDI DisplayBuffer >> 8
(1) 133/ 3D : B0 PHI R0
(1) 134/ 3E : F8 00 LDI 00H
(1) 135/ 40 : A0 PLO R0
(1) 136/ 41 : C4 NOP
(1) 137/ 42 : C4 NOP
(1) 138/ 43 : E2 SEX R2
(1) 139/ 44 : 80 DisplayLoop: GLO R0
(1) 140/ 45 : E2 SEX R2
(1) 141/ 46 : 20 DEC R0
(1) 142/ 47 : A0 PLO R0
(1) 143/ 48 : E2 SEX R2
(1) 144/ 49 : 3C 44 BN1 DisplayLoop
(1) 145/ 4B : 80 Rest: GLO R0
(1) 146/ 4C : E2 SEX R2
(1) 147/ 4D : 20 DEC R0
(1) 148/ 4E : A0 PLO R0
(1) 149/ 4F : 34 4B B1 Rest
(1) 150/ 51 : 30 34 BR ExitInterrupt
(1) 151/ 53 :
(1) 152/ 53 :  ENDIF
modified 18-Nov-12 4:59am.
General News Suggestion Question Bug Answer Joke Rant Admin