Blatant Programming Question
-
Well, why don't you throw out those old CDP1802 processors and get some Pentiums? They're still old but are much better with C! :laugh:
- Life in the fast lane is only fun if you live in a country with no speed limits. - Of all the things I have lost, it is my mind that I miss the most. - I vaguely remember having a good memory...
-
... 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 : ; ===============================CDP1802 wrote:
it is no secret that 8 bit processors are generally not well suited for C.
True; C was written for 12-bit processors and performs poorly with any other word width. ;P
-
... 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 : ; ===============================Why in the world do you want to use a CDP1802? I gave away my Apple IIc because it used that heap of crap! No LONG CALL instruction (though a LONG JMP was implemented) made it messy to program anything useful. I moved to an Epson QX-16 instead, since it used a far more logical instruction set, with symmetric CALL and JMP instructions, and used a 2 bit register to enable 4 separate banks of RAM and extend my addressing capacity to 256k. The 8255 was a great I/O controller, by the way, as was the Signetics 2651 USART, which is what you want for a PS/2 serial port. IIRC, the PS/2 is a 4-pin interface that includes TxD, RxD, Signal Ground, and Frame Ground as a four-wire RS232 port, relying on software handshaking (Xon/Xoff) rather than the older hardware handshaking (RTS/CTS). Both will do the job, though the 8255 was designed to integrate nicely with the Z80 bus structure.
Will Rogers never met me.
-
Why in the world do you want to use a CDP1802? I gave away my Apple IIc because it used that heap of crap! No LONG CALL instruction (though a LONG JMP was implemented) made it messy to program anything useful. I moved to an Epson QX-16 instead, since it used a far more logical instruction set, with symmetric CALL and JMP instructions, and used a 2 bit register to enable 4 separate banks of RAM and extend my addressing capacity to 256k. The 8255 was a great I/O controller, by the way, as was the Signetics 2651 USART, which is what you want for a PS/2 serial port. IIRC, the PS/2 is a 4-pin interface that includes TxD, RxD, Signal Ground, and Frame Ground as a four-wire RS232 port, relying on software handshaking (Xon/Xoff) rather than the older hardware handshaking (RTS/CTS). Both will do the job, though the 8255 was designed to integrate nicely with the Z80 bus structure.
Will Rogers never met me.
Roger Wright wrote:
I gave away my Apple IIc because it used that heap of crap!
If you had not done that, you could now get a small bundle of cash for it from the fanboys. And the processor was a 6502, like in the 8 bit Ataris or C64s (their 6510 was a clone with minor modifications).
Roger Wright wrote:
Both will do the job, though the 8255 was designed to integrate nicely with the Z80 bus structure.
No wonder. The 8255 was designed for Intel processors, while the Z80 was intended to be an enhanced 8080 clone.
-
... 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 : ; =============================== -
Roger Wright wrote:
I gave away my Apple IIc because it used that heap of crap!
If you had not done that, you could now get a small bundle of cash for it from the fanboys. And the processor was a 6502, like in the 8 bit Ataris or C64s (their 6510 was a clone with minor modifications).
Roger Wright wrote:
Both will do the job, though the 8255 was designed to integrate nicely with the Z80 bus structure.
No wonder. The 8255 was designed for Intel processors, while the Z80 was intended to be an enhanced 8080 clone.
CDP1802 wrote:
6502
Yup, you're right - memories fade in time... :-D
Will Rogers never met me.
-
CDP1802 wrote:
6502
Yup, you're right - memories fade in time... :-D
Will Rogers never met me.
-
My own technique : push the registers, use the registers for anything you need them, pull the registers.
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus Do not feed the troll ! - Common proverb
Why not try compiling some C for a couple of subroutines that reflect your application for an alternative RISC machine ? I suggest you download a free toolchain such as CodeSourcery G++, find out how to select compilation for an earlier ARM CPU, switch on every optimisation possible and see what comes out in the mixed lising, maybe get some ideas ? If that is not to your taste maybe there is another RISC as resource-absent as the CPD1802 you could do something similar for ? Not sure how old the CPD1802 C compiler is...I could always hammer a compiler with a.n.other assembler for smaller chips but I wouldn't be so sanguine in the face of recent compiler advances... If that doesn't work maybe there is a fully static CPD1802 model in VHDL you could pop into a fast small FPGA and generate your own CPU running at warp speed and hence making your execution problems vanish - faster bus-interfacing problems aside, that is... What is your application anyway ? Is the CPD1802 the only non-Intel chip licensed for space flight ? What is wrong with an ARM Cortex-based microcontroller ? Was Rick Deckard really Nexus 6 ? Anyway, the best of luck with your project, I hope you have a lot of fun solving your puzzles and get a great result.
-
... 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 : ; =============================== -
... 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 : ; ===============================Have you tried liberal use of the "register" keyword? Its supposed to keep variables in registers, if possible. And I recall something about it passing parameters to functions in registers instead of on the stack if used in the function parameter delcaration. You can write some amazingly small code in C if you try.. like the main loop of a marching pattern memory test in 15 bytes (just small enough to completely fit in the 16 byte instruction cache of the 386 and scream). [has anybody noticed, if your VI fingers take over and you press esc twice in a row while typing in the message entry box, you loose your entire message with no warning and way to recover it? Guess we now know that codeproject coders have never used VI :)]
We can program with only 1's, but if all you've got are zeros, you've got nothing.