1571 cleaning, and power supply repaires

I have bought already ages ago the new capacitors for the power supply of my 1571 drive, and Commodore 128. Those electrolyte capacitors tend to spill, and fail over time, that's why I decided to prevent damage, and exchange those early. Other than that, my C=128 power supply unit was buzzing loud, and wanted also to investigate that problem too.

Opening up the C128 PS, I found the small bracers on the lower case supporting the transformer broken, so the screws holding it couldn't hold on to anything. This way, the 50Hz freq made the plate on top of it to vibrate, making the annoying sound. First, I experimented with super glue, without success. The glue itself stuck to everything, besides the broke off parts of the stands. I even made the situation worse, by ripping off some of the still somewhat attached parts. However, my second choice, what all the times worked for me so far, worked: the two component epoxy plasticine.

After the curing time, I just needed to carve it to it's final shape, and ready to drive in the screws. On the picture, the two tall, black capacitors are the new ones. Measuring the old ones, I have found them capacitance wide above rating, however the new ones have lower ESR values. After putting all the things together again, and cleaning the wires as well, I have got a reasonable looking, and fully functional C128 PS.

On the 1571, last time I opened it up, I have discovered a suspicious capacitor (the blue one, having sign of excess heat exposure). It was high time to swap it for a new one. Unfortunately, these days the inline version of capacitors are not in fashion anymore, so I could get parallel legged ones with the same ratings. This made me facing a new problem: how will I plant in those new caps., with drilled holes so much stretched apart of each other? Well, fortunately, the PCB traces are wide, and runs next to the other hole as well. Only needed to do is to drill a new hole on the track, next to the other, and plant in the capacitor, lying down. I also exchanged those small ones, which 1uF 63V, and 47uF 16V, with new, surprisingly smaller ones, without problems. Assembling the PSU together again, I have noticed, that before, the mains input was plugged into the 220V line of the transformer. Since in Hungary we have 230V, I have decided to use 240V instead. Also retrofitted those two three legged regulator ICs screwed against the aluminum case, with thermo paste, to help prolong their lifetime.

Turning the PSU on, measured the voltages across different components. 5V output pin: 4.96V, perfect! 12V output pin: 11.98V, perfect! Voltage on the biggest capacitor: 32V. Since it is the puffer capacitor before the 12V regulator, and it is rated 40V, it is considered OK. The new, exchanged capacitor experienced 17.4V! Not good! Since it is rated 16V as it was before the case, with the older, blue cap. Switching the mains input to 220V (as it was the configuration before), made the story even worse, measuring 19.2V on the very same capacitor. This explains, why it showed excess heat wear. I will need to get a higher rated one, any time soon.

Since my 1571 was apart, I took the opportunity to clear the casing thoroughly. It became less yellowish, and gained back a nice grey-brown color. The only surprise I faced: the front label stating "Commodore 1571 Disk Drive" faded as well and didn't stop until it became fully white. I will need to replace it. Other than that, its almost perfect now.

How I sped up CP/M display

As I have mentioned on my earlier post, I wasn't satisfied with the speed of character display speeds in Commodore 128 CP/M. So, I have investigated the source codes on me, related to Z80 ROM, and CP/M BIOS. In the meantime, I have learned the 8080 derived Z80 mnemonic syntax (bleh, ouch, very inconsistent compared to the Z80 syntax), and begin to code... well, not really, first I needed to establish a development environment.

VICE 2.4 C=128 emulator proved to be buggy on emulating C128+1571 drive in CP/M mode, making all write attempts to disk a failure. So, I also installed VICE 2.3. I have tried to use MyZ80 as was advised for speed reasons, but failed to get a CP/M 3 version of it, so I decided to compile and test also on VICE, C128 emulator, and write the source on my laptop in Windows 8.1. To transfer single files to D71, D64 images, a DOS tool-set can be used: ctools. So, I also needed to install DosBox 0.74 to make that happen.

In VICE, running C128 I configured 3 disk drives: 8: 1571 as boot, 9: 1571 as temp/transfer, 10: 1581 to have more space for the sources and compile. The workflow was as following:
- Modify source in Notepad++
- Use ctools to copy modified source to temp.D71, under DosBox
- Boot up VICE C128, copy sources from temp.D71 to development.d81
- Compile in VICE
- Update CPM+.SYS on boot
- Reboot and test, and restore the boot.d71 on failure

But getting down to business, and modifications a made to the BIOS. Making a long story short: I have implemented a buffered, and burst output to directly to the VDC chip, leaving out the built-in ROM when needed.

Why did this speed up the display process at all? And how could I convert a char-by-char display to a buffered one? It's not that obvious as it sounds for the first time, if someone doesn't know the inner workings of the BIOS, so let's have a look at that first.

The BIOS provides only a single "chout" procedure for the BDOS, to make a single char displayed on the next cursor position. Sounds simple? Ehh, not. Since this BIOS call is redirectable, depending on the active device (a disk, printer, console, etc...), and the handling of the special chars on the console (screen), like "go to top left corner" expressed with a single car, or "go to X column and Y row", expressed by 4 chars after each other, using the proper escape sequence. The original BIOS handles those special char sequences by storing callback, continue addresses pointing to further char checks on next BIOS call. Also, the BIOS checks every time the active devices, where most of the times only the screen is active as char out device.

Making those shortcut on device checks were already introduced in '93, with the speed bios verison 6.2. I have just added a buffer, to store chars on BIOS call, and only flush to display when it is full. The "flush" procedure has the trick. It reads up all the chars stored in the buffer one after the other, and if they are normal characters meant to be displayed ordinary, it uses the feature of the VDC chip, to auto increment memory addresses where the next character is to be stored. Since most of the time the buffer contains only normal chars, it has the following consequences: 2*char-num-in-a-row+14 output instructions, compared to the contant 16 output instructions per char in the original implementation, using the BIOS. Since IO is potentially slow to communicate with the VDC chip, it is a big gain, having 92 outs for 40 char string, instead of the 640 outs in the old implementation.

Also, this way, there is no need to store multi-char-decoding continue addresses, since the algorithm simply can fetch the next byte as needed. Except if it reaches the end of the buffer, when it simply copies the 1-3 unprocessed chars to the front, and finishes running, and the system waits for an other buffer flush.

The only drawback of this approach is that, you won't see anything while you are typing, since the buffer is not full yet (most probably). However, most of the programs are spending their time waiting user input, by calling "chin" procedure in the BIOS. If no key is pressed, so the input buffer is empty, the BIOS is waiting in a loop for a new char. This loop can be used to flush the buffer, at any filled up state. This was almost good, so far, however the clever programs used instead the "chstat" procedure call, to check if there are chars waiting to input, so, no flush again... until I have added a countdown to that procedure as well, which when reached 0, called the flush. OK! Now you see "instantly" what you are typing. But the fe in compile time, when the programs do some work, and don't expect any input, never checks the input line, so even if they update the screen with information on their status, since no flush occurs, you will not see it. Or, even worse, you will see some half rows, ended in the middle of a word. That's why the disk status indicator proc also got the countdown, to be able to flush the buffer.

The results? VDO (which is a memory only text editor), displays screens, and pages of text noticeable faster! What about games? I guess action games will not work... Contact me, if you are interested in testing.

Commodore 64 tisztítás

Ez a C64-es annyira olcsón kellette magát, hogy nem tudtam ellenállni, meg kellett vennem. Ugyan látszott a hirdetés képein, hogy itt-ott hozzányúltak, de ha más nem, alkatrésznek jó lesz! Az előző tulaja szentimentális búcsút intett neki, gondolva ez a gép itt fejezte be a pályafutását. A géphez még tartozott egy rébbi 1541-es drive, illetve egy C-Lab Midi interface kártya.

Haza vittem, bekapcsoltam, és működik. A táp rendes 5.2V feszültséget ad, a képe szép, hangja van. Mi kell ennél több? Csak a hátulján az a ronda plusz csatlakozó ne lenne! Meg a felirat az elején! Az 1541-es is működik, bár időnként éktelen hangja van. A gép házán már kívülről is látszott, hogy jó poros közegben tárolták (pedig a vásárlásra letörölgették kívülről), az alján még valami friss festékszerű is volt. Az 1541-es szintén moddolt egység: egy kapcsoló és egy plusz LED éktelenkedik az elején. Arra nem kaptam választ, hogy mire való, az előző tulaj sem tudta (így vette). A meghajtó háza pedig koszos, és festékmaszatos helyenként.

Innen indultunk

Nagyon érdekelt, hogy az a LED + kapcsoló mire való, így gyorsan felnyitottam. Mint kiderült, egy csavar hiányzott a házból, egynek meg körbeszaladt a menete, amikor legutóbb valaki erővel próbálta meghúzni azt. Így gyakorlatilag csak 2 csavar tartotta össze a gépet. Felnyitva óriási por és dzsuva fogadott odabent, amit gyorsan kicsit lelegyeztem róla. Az oda nem illő vezetékeket végigkövetve, azt találtam, hogy a LED-et közvetlenül kapcsolja, illetve egy másik ág rövidre zárja a P6 csatlakozón található írásvédelem érzékelő két lábát: ebbe a meghajtóba olyan floppyt is bele lehet rakni, aminek nem vágják ki a szélét, és lehet vele írni, hogyha ég a piros LED. Zseniális! :)

Van kosz! :)

A kivitelezés házi megoldásnak elmegy, de nem különösebben szép megoldás. Ezzel a floppyt össze is szereltem, és félreraktam máskorra (a pucolása, és a mechanika tisztítása, zsírozása igen időigényes).

Töprengtem, hogy mi legyen a C64-essel. Végül eszembe jutott, hogy tök szerencsére a donor gép alja ugyan ilyen típusú, és az nincs kivágva, csak koszos, és lehet hogy kicsit karcos. A tetejéről pedig talán lekaparható és lesikálható az a "Home computer" felirat. Neki is estem sebtiben.

WTF??

Szétszedve itt is hatalmas por-oroszlánok fogadtak, de semmi vészes, az itt-ott felszíni rozsdafoltokat leszámítva. És, amivel még nem találkoztam C64C-ben: fémlemez volt az RF árnyékoló/hűtő a NYÁK felett, mint a C128-asokban. Ezeken vannak nyúlványok, amik egy-egy melegedésre hajlamosabb IC-t érintenek (nem túl nagy felülettel, így nem valami hatékony). De, még mindig jobb, mint az alufóliával bevont kartonlap, ami az elterjedt megoldás volt.

Nincs kosz! :)

A sikálás Domestosos dörzsi szivaccsal a koszt pikk-pakk eltávolította. A feliratot már korántsem ilyen könnyen: azt egy éles bicskával kellett végül óvatosan lekapirgálnom. A donor gép alja jobb állapotban volt mint a teteje szerencsére, és a két gép színárnyalatában sincs nagy különbség, mint kiderült. Összeszerelésnél még a hűtött IC-k kaptak friss hőpasztát, az RF árnyékoló lemez hűtő karmantyúit nagy gonddal ráigazgattam (érsd: addig hajligattam, míg megfelelően felfeküdt) az IC-kre, és kész is volt!

Nincs módosítás!

Vagyis még nem! Hiszen az alsó borításnak a cseréjével a rajta lévő matrica, is kicserélődött, és nem az a gép van benne, amire a matrica utal! Így még ezeket is felcseréltem (elég jól, egyben lejöttek, miután a sarkukat felpiszkáltam), hogy ténylegesen az eredeti gépet kapjam. Elvégre egy Commodore többek között ettől is Commodore... hogy a hátulján is a saját logója szerepel, a saját születési anyakönyvi kivonatával.

CP/M on Commodore 128

CP/M modified by ME, booted up

I have downloaded the original release of CP/M for Commodore 128, and also tested Microsoft Multiplan on it, which is the predecessor for Excel. The speed was more than unsatisfying. You can imagine the situation sitting in front of your computer, waiting the initial screen to appear, and watch the screen displayed line by line, character by character following the movement of the cursor with your eyes. It is sloooow. Not just comparing to today's computing experience, but I would have been upset back at those days as well. The C64 version of Multiplan was lightning fast compared to what CP/M produced.

But before we deep dive into things, let's take a look at what that "seepeeperem" is. Originally developed by Digital Research Ltd for Intel's 8080 CPU in 1973, it was a console based operating system, much like the DOS, or the Linux. In fact, it was the predecessor of Microsoft DOS in some way, since Microsoft wanted to provide some functional compatibility for CP/M on the x86 systems. The Zilog Z80 CPU is an Intel 8080 binary compatible CPU, extended with several instructions, and some registers. This Z80 CPU is also part of the C128. Yes! The Commodore 128 has two different CPUs: MOS 8502 (which is an enhanced 6510, which is developed for the C64), and a Z80. The Z80 is only used for running CP/M.

Compiling CP/M in C128 VICE

When CP/M boots up from floppy, it provides a command prompt, much like DOS did later, with some familiar commands, like DIR, ERASE, etc... However there are differences as well, the COPY command in CP/M is called PIP. Also, CP/M didn't supported directories yet, it instead used some kind of user partitioning of directory entries from USER 0 to USER 15 (no passwords, or anything, so it is much like numbered directories of some kind).

CP/M run on a lot of 8080 and Z80 CPU based computers of it's time, having very different hardware architectures. Digital Research designed the OS that way, to make it possible. The basic concept was, to have a hardware specific BIOS (also loaded from disk), which is some kind of an hardware abstraction layer, on top of it sits the BDOS, which is invariant, and these two loads CCP.COM which is the COMMAND.COM for CP/M, handling the command prompt, user inputs, command and program execution, etc. Under the BIOS, there are the ROM based routines to handle screen, disk IO, and booting CP/M from disk.

Fortunately enough, Commodore made open source their BIOS version, to allow anyone to modify it's source according to their need. I readily found a so called Fast BIOS R6.2 on the net, which eliminated a good portion of unnecessary code from the BIOS, and made some shortcuts on the display parts to make screen handling faster. This code is dated back to 1993. However, it wasn't fast enough for me. So, I decided to speed it up even more. I also managed to get the source of the ROM functions found in the C128, so everything were at hand to make C128 CP/M a better world to live. But this will be an other post.

MS Multiplan, predecessor of Excel

I finally managed to introduce some tricks in the BIOS, which made a nice speed up in display times (by a factor of at least 50%), which is getting closer to acceptable speed.

I wonder, what is the reason of this slow CP/M functionality on Commodore 128. Probably the problems are manyfold:
- Z80 and 6502 assembly developers that time hated each others' architecture like hell (comparable to the Linux vs Windows flames experienced in the early 2000's)
- The star of CP/M already started to diminish the time, when Commodore came up with the C128
- The new OS for IBM XT was MSDOS, instead of CP/M
- Good, knowledgeable developers were rare that time
- The user base of C128 CP/M was too small, which made the developers to turn away from C128 CP/M development
- The Z80 CPU run at an effective speed of 2MHz, instead of 4MHz, which would have been comparable to the 1MHz mode of 8502 CPU, or to other CP/M running HW that time