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.

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

Connecting Commodore floppy to Windows 8.1 laptop

CBMXfer, finished copying GEOS

Back at days, when I had last time a desktop PC at home (it was an AMD Athlon 2500+) in around 2000, it had a conventional parallel port. I was also able to boot it up in MSDOS 6.2, to make exclusive use of that mentioned parallel printer port to connect my Commodore 1541 floppy with StarCommander, and make file transfers back and forth. However, since than, I only had laptops, not having parallel or serial ports, but still wanted to connect my old floppy drives to PC somehow, to transfer those zillions of D64 images I collected from net, to test on actual hardware.

Laptop using Commodore 1571 drive

Now days, I need to say, the most comfortable way to command your Commodore IEC drives (Commodore 1540, 1541, 1570, 1571, 1581, etc...), is to get your hands on a ZoomFloppy device, also known as xum1541 cable. This is a micro controller based USB device, accompanied with drivers for Windows, and some command line utilities to do actual things with it. I also looked up the ebay to find some implementations, since I didn't want to bother making it myself.

I ended up buying 8_bit_fan's smaller implementation, not having IEEE-488 port. The product arrived without any software bundled with it, so I needed to look up, and download everything I needed to make it work. At least, it wasn't expensive. OpenCBM is compatible with this solution, however, the latest version didn't contain the support yet, so I needed to download a prepacked, xum1541 supporting OpenCBM verison, directly from ZoomFloppy's website. Installing the drivers wasn't smooth, since there is no official support for Windows 8.1. The problem is that the USB driver is not signed, so by default, Windows 8.1 won't allow you to install it. To workaround this problem, you can hit the restart while holding down the shift key, in the power drop down menu, on the start screen, to restart your computer in maintenance mode, and selecting the "Disable signed driver constraint" or similar by pressing F7, you can boot into an operating mode, where you can install the driver, even though it is not signed. Rebooting afterwards in normal mode/way, and you are done. Otherwise you just need to follow the steps in the manual you get.

I have found command line operation cumbersome, so I downloaded CBMXfer also. To make work properly, you'd better place it in the ZoomFloppy's version of OpenCBM bin directory, and run it from that location. To make it even more convenient, you should also download and install the latest VICE 6502 system emulator (C=64, C=128, PET, etc...), and copy c1541.exe from it's directory to the same directory where CBMXfer is.

This way I can access my Commodore 1541, 1570, 1571 drives with no hassle, and even brows files stored in the D64 disk images, brows the net, and display the screen of my C=64/128 simultaneously using AVerTV on my Windows 8.1 laptop. :)

LED világítótest, how-to

QCAD

A lakás világításáról volt már szó. Ott a felső világítást mutattam be. A technológia (LED, tápegység) semmit sem változott, csak a rögzítési mód. Most ugyanis a vályú alsó felén lévő kivágásokat kellett megtölteni fénnyel. Tanulva belőle,  hogy a felső világítósort milyen macerás volt kézzel elkészíteni, kicsit átgondoltam az alsó világítás mikéntjét.



Papír prototípus

Az alábbi elvárásoknak kellett megfelelni:

• A kivágásokat szabályosra terveztem, de leginkább olyan távolságokra kerültek egymástól, ahogy a festőnek sikerült. Nagy eltérések nincsenek, 1- max 3 cm.
• Könnyen és gyorsan szerelhetőnek kell lennie
• El kell takarnia a vályú belsejében futó kábeleket

Gyorsan csináltam is papírból egy proof-of-conceptet. Behelyezés: 5-ös! LED rögzítés... egyelőre elmélet. Az világosan látszott, hogy sima alumíniumból gyenge volna (túl könnyen deformálódik, hajlik). Tehát valami erősebb anyagra van szükség. Az is világossá vált, hogy ezt kézzel, lemezollóval nem fogom tudni kivágni, ígyhát keresgéltem a neten, mire megtaláltam a Tamás kft-t, akik lézer segítségével ki tudják vágni a kívánt mintát. Csak DXF-ben el kell nekik küldeni. Mint kiderült, ami működik egy papír kirigami esetében, azt lemezzel nem olyan egyszerű megcsinálni.



A fémlap és felette alakra hajtogatva.
Ugye mennyit egyszerűsödött a papír-
hoz képest? :)

Újabb keresgélés után találtam egy ingyenes 2D CAD programot, a QCAD-et, amit gyorsan (kb 1 óra) megtanultam annyira kezelni, hogy a mellékelt ábrán látható tervet össze tudjam állítani. Elküldtem a terveket, egy-két iteráció után jöttek a kivágott elemek, rozsdamentes acélból, amik túl kicsit voltak, hogy géppel hajtogassák meg őket a kívánt alakra. Cserébe viszont tized miliméter pontos rajzolatok. Maradt a saját kezű hajtogatás: satu + fémléc.

Teszt beépítés

Levágattam az üvegdarabokat is, most kezd minden összeállni. A hajtogatás sorrendje fontos. A kiálló "3 szálka" szolgál a LED rögzítésére: csak bele kell csúsztatni a füzért, majd a középső széles lemezt lehajtani. A kisebbek mellette rögzítik a helyére, a LED lábainál megfogva azt. Ahogy a teszt beépítésen is látszik, jó lesz nagyon! ...ha majd kész leszek az összessel...

Tanúság: az origami és kirigami jó, hasznos, de a fémiparban nem véletlenül nem terjedt el! Viszont soh'sem késő valami újat tanulni.

Cross platform development for C=64 - Part I

Lately I felt I need to develop something new to my old favorite for the Commodore 64. I decided that I will set up a cross development platform to be able to use my favorite modern tools.

I started with searching the internet for goods. I realized with pleasure that a lot of information can be found related this old computer but I was looking for specific things at first, namely a good emulator, a cross compiler for assembly language, and tools.

I was programming in assembly for C=64 back in time when I had enough of the slow BASIC on it, so I assumed I will have my development up and running in no time. I also got used to the (almost) perfect development tools I use now days, like Visual Studio, and also got used to the elegant object oriented languages like C#, Delphi, and source controls like Team Foundation Server or SVN.

First I need an emulator: I decided to use WinVICE 2.1 which is free, has built in machine code monitor, and good command line argument capabilities. It accurately emulates C=64, is fast, and friendly to developers (f.e.: it knows a lot of disk/tape/prg formats, lurking around in the C=64 emulation community).

I have also found a great compiler with even greater macro capabilities which was written in Java, and is a command line tool. I decided to use Kick Assembler 3.0 further on. For editing one can use any kind of editor, capable to save to ASCII/Win western code page. (yep, UTF-8 is not supported). Windows has a “great” built-in editor, named Notepad.

Setting up the development environment

Since everything can be accessed from command line the idea to use BAT files was quite straightforward. I created a BAT to actually build my application, “build.bat”:

@echo off
call settings.bat
echo ===================================
echo Build started for "%project%"...
echo -----------------------------------
echo.>"%target%.debug"
call compile.bat %project% %target%
echo break .%entryPoint%>>"%target%.debug"
echo.
echo Finished @
time /T
echo ===================================

Having the “setup.bat” SET the used cmd variables, like “target”, “entryPoint”, and so on… The “compile.bat” is even more simple:

@echo off
echo Compiling "%1.asm"....
echo -----------------------------------
"%kickass%" "%1.asm" -vicesymbols -o "%2.prg"
echo load_labels "%1.vs">>"%target%.debug"
echo ===================================

Note that the “kickass” cmd parameter is the path to the compiler, and the –vicesymbols parameter of it: machine code monitor in VICE can load a symbol file, which makes the reading of the code much easier! Also note the echo line with “load_labels” in it, which appends to the file with extension “.debug”. This file contains VICE MCM commands. Also note, that the build batch file appends the same debug file with a break . VICE command.

If build succeeds, you will have your “.prg” file, which is directly loadable into VICE from command line. Let’s see the “debug.bat”:

@echo off
call settings.bat
"%vice%" -autostart %target%.prg +confirmexit -moncommands %target%.debug

Isn’t it simple? It directs the emulator, to auto start our compiled prg file, and load and execute the commands in the debug file with the MCM (which in fact contains a break command with the program’s start address, so you are set up to debug your code from start!).

In part II I will show you how one can use Visual Studio without modifications, to build and run your program in emulator.

In part III you will learn how to add Kick Assembler color coding to Visual Studio.

Az új elektronika megálmodása

A december hónap munka szempontjából ütős volt, nem is nagyon maradt időm Jánossal fizikailag foglalkozni. Ezen kívül az elmúlt időszak hideg időjárása is akadályozó tényező volt (amikor már szabadságon voltam), lévén hogy a garázs nem fűtött, így ott sem volt 0 foknál melegebb...

Ígyhát maradt az egyéb polskis elfoglaltság: interneten felfrissítettem tudásom elektronikából, utána olvastam a különböző villanymotoroknak, működésüknek, tulajdonságaiknak, vezérlési technikáinak, konkrét példányok beszerezhetőségének, stb...

Kezdem is az első legérdekesebbel. Találtam egy ingyenes áramkör tervező programot, a neve KiCAD. Tanulás végett meg is terveztem az első kipróbálandó dolgot: egy 555-ös IC-vel irányított index vezérlőt (ez látható a képen). A program igen jópofa. Az ember a kapcsolási rajzzal kezdi, majd kiválasztja hogy melyik alkatrész milyen formájú, és végül összeállítja a nyákrajzot. Ha akarja, automatikusan elhelyezi számára a program az alkatrészeket, és automatikusan meg is rajzolja az összekötéseket. Lehet hogy én nem ismerem még eléggé, de az automatizmusa itt-ott hagy némi kívánnivalót magaután. Viszont a kipofozott változatot akár már 3D-ben is meg lehet forgatni, és tekinteni.

Közben pedig nekiestem kigondolni, hogyan is fog pontosan működni az autó új elektronikája és vezérlése. A cél a kábelrengeteg megszűntetése, illetve új kapcsolók és fogyasztók beiktatási folyamatának leegyszerűsítése. Ennek megvalósítására egy hiper olcsó, software nélküli digitális vezérlő rendszert gondoltam ki. Programozható azért lesz! Program kártyák segítségével. Moduláris is lesz: az egyes fogyasztó csoportok környezetében alaplapok lesznek, amikbe egységes jelfeldolgozókat lehet dugni, amik csak a vezérlésért lesznek felelősek. A teljesítmény fokozatok egyesével lesznek az alaplapra illeszthetők, amiket a vezérlő modul vezérel. A programkártyák pedig szintén az alaplapra kerülnek, amik pedig a vezérlőt állítja be, illetve a ki és bemeneteket köti össze (gyakorlatilag egy egyszerű kapcsolati ábra az egyes kivezetett érintkezők között). Az alaplap is csak csatlakozókat tartalmaz. Így bármi ami tönkremehet, az az autó más részeiben fellelhető ugyan olyan alkatrésszel helyettesíthető lesz. Tehát például a motor gyújtását vezérlő végfok kiég, fel lehet áldozni pl a jobb hátsó helyzetjelzőt ideiglenesen, hogy az ember hazaérjen.

Hogy a két ünnep között véletlenül se unatkozzak, bevásároltam tegnap a LOMEX-ben (ugyanis már csak januárban nyitnak ki). Mindent vettem, ami jól jöhet egy kis POC készítéshez. A LED-es világításokat is szem előtt tartottam. A képen jobb oldalt látható sok apró zöld izé, kicsi LED-ek, amik majd a működést (vagy nem működést, ez itt a kérdés...) fogják demonstrálni a demo vezérlő esetében. Tőle jobbra és balra találhatóak a filmdarabra emlékeztető csomagolásban a nagyteljesítményű LED-ek, 4-4 db piros és fehér színben. Ezekhez majd 12V-os jó hatásfokú LED vezérlőt kell csinálnom, hogy kipróbálhassam, amihez a bal oldalon látható ellenállások közül 1db és a középen alul látható LM338-as programozható feszültség szabályozót fogom használni, áram generátor konfigurációban. A 7 nagy IC torony decimális számlálók, ÉS kapuk, 8 bites shift&store regiszterek, inverter-bufferek. Középen 4 db nagyobb teljesítményű NPN tranzisztor, 10 db pici kapcsoló, 555-ös IC-k, potméterek. Az A4-es lap az valójában NyÁK lap, lakk filctollak, és egy rahedli IC foglalat. Majd csak kisül belőlük valami... :)