C128 VIC-II raster interrupt is pretty stable, without jitter, with Z80 cpu when used with HALT state. And it seems fast enough to do many such programming tricks. Despite being somewhat slow, on C128, Z80 has capabilities when used wisely.
wow amazing ! Would it be possible to have stuff running on both cpu's concurrenlty and communicate ? Like using the z80 as 80's "graphic accelerator" for the 6502 ?
The two CPU's share the bus, so best you can do is to ping-pong quickly between them, with only one operating at any moment. This C128 design being more about greater "flexibility", not greater performance.
@@keyboard_gWell, you could of course always use the Z80 and the 6502 ping pong wise. That the demo scene never did much with it probably is also caused by the fact that, as you cannot use it at the same time, using the Z80 does not give much added benefit performance wise. But see for example also: th-cam.com/video/mbpPosev1OI/w-d-xo.htmlsi=-OgwK99u1T_rTx-c This uses the Z80 under CP/M, which is of course the main use case for using the Z80 on the C128. So not performance, but compatibility. You could very well also compile this to run native Z80 though. See also the C128 target of the Z88dk cross compiler. Actually now making my own CP/M software with it.
Maybe if you give the Z80 tasks that take lots of cycles, it would only need the bus 5% of the time. Or use the Z80 as the main processor if you prefer, and the 8502 as the GPU.
I would use my Commodore more if it had a “keyboard” mode. That is, if it could be used part-time as a USB keyboard. (I don’t have enough space on my desk for more than one keyboard, and C128 looks good enough to me!) Note: there is a program you can do this with Raspberry Pi 400.
Me too. idun-cart has a feature to use the C128 keyboard and send keys directly to the Pi. Idea is to use with a second touch screen to control e.g. a web browser. I'll demo this at some point.
is there some way to make use of a ESP32-S3 for example? (or some other low cost MCU that supports serial, and usb-hid mode). Then you could make a software that writes data to the serial of esp32 (by reading keyboard input on the Commodore), that converts it to USB.
What you are describing should already be possible with the idun-cart, just using software. I even created a GitHub issue describing this. Feel free to comment further here: github.com/idun-project/idun-cartridge/issues/11
Z80 has a better implementation of CPU stack and relatively fast stack access, so for compiled languages which depend heavily on stack, Z80 may even be preferable over 8502.
When running on the emulator I noticed the Idun shell showed as a 640k RAM system with 444k free. Where exactly does that memory live? Asking because I've populated banks 2 and 3 in my 128 for a total of 256k and I'm wondering if I can make this extra memory available to Idun?
Hi. An REU is supported, but not required. The emulator was configured with a 512k REU, so that is why it had 640k. The kernel memory manager only supports Banks 1 & 2 currently, but I'd be keen to get it working with 256k. Which memory hack do you have in your C128? Maybe I'll build one...
@@fr_schmidlin It's not as big a problem as you may think. Sprites and hardware scrolling would offload a lot of burden from the CPU, as would the sound generation.
hmm 🤔so in theory with the z80 allowed to run alongside the 6502 and the memory configuration (64k each) could a 48k zx specrum and maybe amstrad 464 emulator be possible (colour pallette aside)?
It sounds good, but you still have to account for all the I/O peripheral differences. I'm afraid it would be too slow at emulation. However, much easier porting of many programs from those Z80 systems is a definite. What to port?
Can you please tell me a bit about that monitor? Looks like you switched it between 40 and 80 column mode much like a Commodore 1084. What input ports does it have to support 80-column mode in particular?
Your video in 720p has this odd appearance with more than one shade of grey as the background colour. You said this output was direct from a emulator correct?
Yeah. It's some weird artifact not there in the emulation window's output, maybe caused by the video encoding process of either my editing software or TH-cam. I'd like to know how to eliminate it too.
Using a Z80 on the C128 is almost useless. The problem lies in the fact that the C64 and then C128 hardware were built around the 6502 CPU family, which differs significantly in terms of architecture from a Z80. To achieve optimal performance, hardware designers should have taken into account the specifics of a Z80 CPU, such as its ability to perform DRAM refresh independently, certain clock periods when the CPU doesn't use the bus, and the variable-length instruction set. Matching all these considerations with a 'bus hog' VIC-II proved challenging. Commodore (CBM) hardware designers added the Z80 to the C128 as a last-minute addition, with their primary goal being functionality rather than performance. The result is a Z80 running at 4 MHz, stopping half the time as a quick and dirty way to emulate the workings of the 6502 CPU. However, this falls short of the ideal. A similar approach was taken with the Amstrad CPC, originally designed for the 6510 and later adapted for the Z80. Due to the lower bus pressure of the Amstrad CPC video system, they achieved a real speed of 3.3 MHz, compared to the nominal 4 MHz clock, which is a decent result. (Every machine with a shared VRAM architecture has to pause due to video accesses; this even happens on a plain C64 with the 6510 CPU, referred to in jargon as 'bad lines.'). However a 2Mhz z80 is somewhat slow, rarely used even on native z80 hw solutions.
Well, neither is 1 MHz 8502 exactly a fast CPU, nor is fastness of code execution the appeal of retro computing. :) Yet, Z80 wins in simple memory copy loop (Z80 - n * 10,5 1MHz cycles; 8502 - n * 13 1MHz cycles). I think that for the most part the difference in speed is not that decisive in favour of either, but Z80 offers a wealth of registers, including shadow registers which can be rapidly flipped in and out, 16-bit arithmetic and a variety of rotate instructions for number-crunching. So it is the tools which Z80 offers to the programmer which should also be noted and not speed alone. The strong point of Z80 is that it allows keeping things in registers for faster access. - Back in the old days, it was admittedly quite difficult to develop code for Z80+C128, but I think that 39 years after the introduction of C128 it is high time to reconsider the case.
I'm sure Bill Herd and the rest of the C128 guys would love this.
C128 VIC-II raster interrupt is pretty stable, without jitter, with Z80 cpu when used with HALT state. And it seems fast enough to do many such programming tricks. Despite being somewhat slow, on C128, Z80 has capabilities when used wisely.
New Sub: Dryden, Mich.
Well done Sir, Cool Project
wow amazing ! Would it be possible to have stuff running on both cpu's concurrenlty and communicate ? Like using the z80 as 80's "graphic accelerator" for the 6502 ?
The two CPU's share the bus, so best you can do is to ping-pong quickly between them, with only one operating at any moment. This C128 design being more about greater "flexibility", not greater performance.
I am sure a demoscener could do something impressive.
@@keyboard_gWell, you could of course always use the Z80 and the 6502 ping pong wise. That the demo scene never did much with it probably is also caused by the fact that, as you cannot use it at the same time, using the Z80 does not give much added benefit performance wise.
But see for example also:
th-cam.com/video/mbpPosev1OI/w-d-xo.htmlsi=-OgwK99u1T_rTx-c
This uses the Z80 under CP/M, which is of course the main use case for using the Z80 on the C128. So not performance, but compatibility.
You could very well also compile this to run native Z80 though.
See also the C128 target of the Z88dk cross compiler. Actually now making my own CP/M software with it.
Maybe if you give the Z80 tasks that take lots of cycles, it would only need the bus 5% of the time. Or use the Z80 as the main processor if you prefer, and the 8502 as the GPU.
Very informative thanks
I gotta get me one of these carts
Technically, though, the Z80 is used every time the C128 is turned on, as it's the CPU used to set things up before giving the 8502 control.
I would use my Commodore more if it had a “keyboard” mode. That is, if it could be used part-time as a USB keyboard.
(I don’t have enough space on my desk for more than one keyboard, and C128 looks good enough to me!)
Note: there is a program you can do this with Raspberry Pi 400.
Me too. idun-cart has a feature to use the C128 keyboard and send keys directly to the Pi. Idea is to use with a second touch screen to control e.g. a web browser. I'll demo this at some point.
is there some way to make use of a ESP32-S3 for example? (or some other low cost MCU that supports serial, and usb-hid mode). Then you could make a software that writes data to the serial of esp32 (by reading keyboard input on the Commodore), that converts it to USB.
What you are describing should already be possible with the idun-cart, just using software. I even created a GitHub issue describing this. Feel free to comment further here: github.com/idun-project/idun-cartridge/issues/11
I like the name: IDUN.
Are you related to the Idun supercomputer?
Didnt expect to hear Brian Blessed hahaha
Z80 has a better implementation of CPU stack and relatively fast stack access, so for compiled languages which depend heavily on stack, Z80 may even be preferable over 8502.
You're right. I included the C compiler for Z80 coding. Have not done the same for the 8502.
What would be awesome is to have a ZX Spectrum emulator that uses the Z80 CPU 😁
When running on the emulator I noticed the Idun shell showed as a 640k RAM system with 444k free. Where exactly does that memory live? Asking because I've populated banks 2 and 3 in my 128 for a total of 256k and I'm wondering if I can make this extra memory available to Idun?
Hi. An REU is supported, but not required. The emulator was configured with a 512k REU, so that is why it had 640k. The kernel memory manager only supports Banks 1 & 2 currently, but I'd be keen to get it working with 256k. Which memory hack do you have in your C128? Maybe I'll build one...
That is very nice! I'm wondering if you could use the z80 beyond cp/m and port for example zx spectrum software.
Should be easy to port ZX spectrum code. Of course, any games would need to be modified for choice of VIC-II or VDC + SID chip.
@@idunproject But the Z80 runs at 2MHz in the C128, doesn't it? Much slower than de 3.5MHz of the speccy.
@@fr_schmidlin It's not as big a problem as you may think. Sprites and hardware scrolling would offload a lot of burden from the CPU, as would the sound generation.
hmm 🤔so in theory with the z80 allowed to run alongside the 6502 and the memory configuration (64k each) could a 48k zx specrum and maybe amstrad 464 emulator be possible (colour pallette aside)?
It sounds good, but you still have to account for all the I/O peripheral differences. I'm afraid it would be too slow at emulation. However, much easier porting of many programs from those Z80 systems is a definite. What to port?
Can you please tell me a bit about that monitor? Looks like you switched it between 40 and 80 column mode much like a Commodore 1084. What input ports does it have to support 80-column mode in particular?
It's a Sony PVM studio monitor. Not easy to find these days. Has 5 inputs: 2x composite, S-video, RGB digital, and RGB analog.
But what does the assembler code for switching to Z80 look like???
Not bad. You can find the 6502 asm source on the Github project page in cbm/cmd/zload.asm.
❤
Your video in 720p has this odd appearance with more than one shade of grey as the background colour. You said this output was direct from a emulator correct?
Yeah. It's some weird artifact not there in the emulation window's output, maybe caused by the video encoding process of either my editing software or TH-cam. I'd like to know how to eliminate it too.
CPM?
Using a Z80 on the C128 is almost useless. The problem lies in the fact that the C64 and then C128 hardware were built around the 6502 CPU family, which differs significantly in terms of architecture from a Z80. To achieve optimal performance, hardware designers should have taken into account the specifics of a Z80 CPU, such as its ability to perform DRAM refresh independently, certain clock periods when the CPU doesn't use the bus, and the variable-length instruction set. Matching all these considerations with a 'bus hog' VIC-II proved challenging.
Commodore (CBM) hardware designers added the Z80 to the C128 as a last-minute addition, with their primary goal being functionality rather than performance. The result is a Z80 running at 4 MHz, stopping half the time as a quick and dirty way to emulate the workings of the 6502 CPU. However, this falls short of the ideal. A similar approach was taken with the Amstrad CPC, originally designed for the 6510 and later adapted for the Z80. Due to the lower bus pressure of the Amstrad CPC video system, they achieved a real speed of 3.3 MHz, compared to the nominal 4 MHz clock, which is a decent result. (Every machine with a shared VRAM architecture has to pause due to video accesses; this even happens on a plain C64 with the 6510 CPU, referred to in jargon as 'bad lines.'). However a 2Mhz z80 is somewhat slow, rarely used even on native z80 hw solutions.
Well, neither is 1 MHz 8502 exactly a fast CPU, nor is fastness of code execution the appeal of retro computing. :) Yet, Z80 wins in simple memory copy loop (Z80 - n * 10,5 1MHz cycles; 8502 - n * 13 1MHz cycles). I think that for the most part the difference in speed is not that decisive in favour of either, but Z80 offers a wealth of registers, including shadow registers which can be rapidly flipped in and out, 16-bit arithmetic and a variety of rotate instructions for number-crunching. So it is the tools which Z80 offers to the programmer which should also be noted and not speed alone. The strong point of Z80 is that it allows keeping things in registers for faster access. - Back in the old days, it was admittedly quite difficult to develop code for Z80+C128, but I think that 39 years after the introduction of C128 it is high time to reconsider the case.
CP/M ?