Didn't it use the 80 column screen? It was my experience that the C128's 80 column screen was an absolute dog. I was pretty handy with 6502 assembly language but trying to get anything onto that screen was just disappointingly slow. Maybe I was doing it wrong, but it seemed like you had to put every last screen address into that display controller, and that controller itself required you to select register numbers before putting the values in.<p>So just to write one character onto the actual screen required six writes into the controller chip. Adress-low-register-number into D600, screen address LSB into D601. Then address-high-register-number into D600, then screen address MSB into D601. Now you're ready to write 'A' into the actual screen buffer! So, write-data-register-number into D600 and 0x41 into D601!<p>Do you want to put a 'B' on the screen right after that 'A'? Repeat the above - six more writes to get the 'B' showing! Why they didn't embed an auto-incrementing screen address counter in the controller is beyond reckoning. At least that way you'd only have need to set the address once, and could then leave the select register (D600) parked on the write-and-increment register, and merrily stuffed your display string into D601 with a relatively tight loop.<p>Presumably the Z80 had to put up with the same annoying 80 column controller. That can't have helped.
A good reply to the "we should write more efficient code today, like we used to do in the Good Ol' Days". Inefficient code is not a new phenomenon!
So I had a C128D (replacement for C64, which was replacement for VIC20). I had also used a few CP/M machines at this point. I know why they put the Z80 in the 128 but I always felt it was just a stupid thing that the PM/Marketing team should have been told, NO. It would have reduced cost, shipping date, etc. This is a prime example where marketing made the decision without having a real compelling business case for doing so. They could have said 100% C64 compatible with and * that said, sorry no CP/M cartridge support and it would have been just fine.
The whole slow IO library, was a problem in a lot of places and spawned the nansi.sys/etc utilities on dos too. That is because the DOS console output services were generally a lot slower than could be accomplished with a bit of hand spun assembly running out of RAM. So instead of going through ansi.sys + BIOS int 10 it was possible to hook the output int (21,2 IIRC) and dump right to the text framebuffer tracking little more than the current color and cursor position.<p>It was so easy I wrote my own at one point (before I discovered/got nansi.sys? I can't remember the sequence). It was IIRC faster than the later nansi sys replacements but didn't work 100% of the time either. Probably because I only implemented the common subset needed to run a couple programs I wanted faster text output from. I remember for a while switching back and forth between mine and a replacement driver depending on application before I got a 486+VLB which was so fast that I could no longer tell the difference between the two.
Ah the interrupt handling a bunch of unnecessary things... Z80 has IM 2, you set a page-aligned 256 byte buffer, point the I register, enter Interrupt Mode 2, then you have your own custom interrupt handler instead of the one provided by the ROM.
From top answer:<p>> <i>each character is compared to every possible control character before it is decided that it isn't one</i><p>That's crazy; ASCII was carefully designed to avoid this kind of shit.