By Andrew Braybrook
Wednesday 28th January
Been thinking about yesterdayís sprite combining system. Itís important to think through the limitations of a system before writing it, in case it wonít do what you want. It also gives me an opportunity to expand on the idea to explore what the system will do. Iíll have to resurrect my sprite reversal routine from Paradroid which produces the large robot pictures. Reflecting multi-coloured images is not as straightforward as reflecting hi-res sprites.
ST and I battled with some parallel communications this afternoon to get the Opus talking to the C64. We had a rare collection of errors, including the C64 missing out bytes because it wasnít fast enough, the C64 duplicating bytes because it was too fast, total lock-outs where both machines were waiting for each other, and the C64 only receiving one byte per millenium. With the aid of a mega-soldering iron, pliers and our frustration brick we cracked it. We can transfer data at about one and a half kilobytes per second, which is the fastest the Opus will currently do. We should get it faster with our own dedicated routine, if ST wants to learn 8086, I donít.
Apparently on the Opus you can print in foreground (ie everything stops until itís finished) or in background, that is you can carry on as normal and the interrupts routines just get on with it. MSDOS takes the January Mickey Mouse award for its idea of background printing, it accepts keyboard input at a magnificent rate of one character every three seconds while background printing. Not what Iíd call user transparent.
Thursday 29th January
Wrote a utility to read data from the Opus in ASCII format and convert it to machine-code as it reads it. Since it keeps getting checksum errors because it is missing bytes, I can only assume that Iím not getting back to read the next byte quickly enough. The Opus is like a machine gun and I donít have time to catch each bullet, polish it and place it neatly, Iíll have to catch them all in a bucket and tidy them up while itís reloading. Most frustrating because it very nearly works.
Friday 30th January
". . . Further investigations reveal that a certain C64 operating system delights in polling the keyboard every 60th of a second, despite being told not to by me. . . "
Monday 2nd February
Re-arranged my Centronics receive code to read a series of bytes at a time, stop transmission and decode them. It still occasionally Ďmissesí six or seven bytes. It either works perfectly or misses a whole lot, nothing in between - this is suspicious. Further investigations reveal that a certain C64 operating system delights in polling the keyboard every 60th of a second, despite being told not to by me. This has only started since Iíve been calling the write character to screen kernal routine, CHROUT, which must be enabling the interrupts again. How good of it to take this decision all by itself! Thus my receiving success or failure depends on whether I get interrupted while reading data. The interrupt lasts for so long that I lose about six bytes. With a very small test file it seems about an evens chance, but a larger file would never get across intact. I can soon fix this, just tell the timer chip (the CIA) to stop screaming blue murder every 60th of a second, rather than just sticking cheese in the systemís ears to stop it hearing and responding.
Now that it appears to be working it also explains why it didnít work last Thursday, which was a better system. Now Iíve changed it Iím not going back. Just like my macro assembler loaders, itíll type out full-stops as it loads, except mine will allow loading in RAM under the ROMs and protect against overwriting Certain delicate areas in the machine.
The Opus is now playing up, it refuses to link some Z80 code for my test file: it just crashes the whole machine. Perhaps it knows that the C64 wouldnít know what to do with it anyway. Thatís it, the Opus is emulating the C64 perfectly, it crashes! I only wanted to use Z80 because ST has already keyed in some Spectrum routines.
Tuesday 3rd February
Completed work on my parallel data receiving program and tested it out by passing a test file down from the Opus. All appears good. Right, time to take the plunge, retire the old C64, to be replaced by the new Opus PC, (Iíve been using STís Opus thus far), and connect it to the C128. The MPS801 printer will have to go as well since there just isnít room, Opae are big beasties indeed. The 1570 disk drive can sit on top of the Opus, connect it all together, light the blue touch paper and bingo, a Graftgold Development System.
Got a quick tutorial from ST on using the text editor and MSDOS in general. So begins the task of rekeying all that Iíve done on Morpheus so far into the Opus. Itís nice talking to a manís computer where software is written with no space constraints -a mere 492K spare for editing files, another 392K on the RAM disk, two disk drives with about 360K each, and an operating system that does what you want, when you want - with no fuss! Brings back memories of the old IBM mainframe (when it was running full tilt after five oíclock with decent IBM terminals and CMS).
Three problems have since reared their ugly heads, Easyscript wonít load, so I canít see what Iím going to type in on the Opus, and the old 1541 wonít read any disks at all. It knows itís being retired to the great disk drive home in the sky, to become just another ordinary breeze-block. The third problem is the most serious though, the fanheaterís bust so itís blowing cold air all round the room, just like the Opae! Anything they can do. . . .
" .. .if God had intended us to use serial data, heíd have only put one bit in every byte . . . "
Wednesday 4th February
One quick amendment to the receiver system, donít allow it to load data over itself and crash, Iíve done that with my C64 assembler loaders a few times this week.
Some people may he saying -How can it take these people so long just to connect two computers together? "Whilst appreciating that itís not exactly on the forefront of technology and one of the selling points of computers is the ability to interface them to anything - just you try and find someone whoíll stand up and admit that theyíve connected two different computers together in parallel. Many people Ďin the businessí seem to use serial links, but if God had intended us to use serial data, heíd have only put one bit in every byte. As weíve already discovered, serial linkage is no easier than parallel, is slower, and has a worse-defined standard. We have connected an Opus PC-II to a C128 in parallel using only information in the Programmers Reference Guide, some timing and circuit diagrams of a Centronics printer and applied logic. Weíve now probably got one of the more advanced development kits in the country for micro software.
Thursday 5th February
Continued keying in my source code to the new assembler. Itís mostly much more versatile then the CBM one, but it does have one or two inefficiencies. Whereas I used to type < or> signs for low or high bytes, I now have to key Ďlowí or ĎHighí in full, not even ĎLoí or ĎHií will do. Iím also learning to use the new proper fullscreen editor. Imagine a delete key that actually deletes the character under the cursor, not the one before it: how revolutionary, itíll never catch on! I remember the IBM mainframe that I used to work on did that - a real home from home this is. Finally got my utilities all keyed in and my variables and macros. I made some improvements to some tacky bits of code whilst rekeying it so I wouldnít be able to check it against the original version when itís done, very clever I donít think. If anything goes wrong itíll be harder to find the errors. Itís great being able to put huge comments in the code - on an 80 column screen it still looks tidy. It was impractical to get carried away on the C64 as it hampered loading time and took up too much space. All the source for one game used to take over 500 blocks on a disk, or about 120K.
Initial timing tests show that to assemble and download my utilifies takes about half a minute, not fast by any means, but compared to about five minutes on the C64 itís great. Itíll be interesting to see how long it takes on a finished program, which used to take the best part of half an hour on the C64. If itís still ten times faster itíll only take three minutes.
One thing about the assembler is that it really goes to town if it finds an error. It usually manages to find at least five things wrong on the line, just from one letter being mis-keyed. If it only printed four error messages itíd probably print a fifth moaning that it could only find four things wrong!
A final piece of good news, the fan heater is working again.
" . . . due to a certain wire not being connected at the Spectrum end, the Opus thought that the Spectrum had run out of paper. . . "
Friday 6th February
Feeling rather ill today, but it only hurts when I move. Struggled in to work and keyed in all the remaining source code to the Opus, assembled it, corrected all the typing errors, assembled it again and booted it down to the C128. It all ticks over very nicely.
Spent much of the afternoon looking for the bug that caused the sprites to flicker horrend ously. Finally found it, Iíd just mis-read one character from one screen while typing on the other.
ST found out why the Spectrum wonít listen to the Opus whereas the C128 will, itís a good one this. Since the Opus thinks it is printing to a printer, and our micros are impersonating printers, due to a certain wire not being connected at the Spectrum end, the Opus thought that the Spectrum had run out of paper! Thus it wasnít sending data across. A simple soldering job cured that and the two are now happily communicating.
Hopefully by now some of you will have played the Competition Edition of Paradroid in the Christmas double pack. Being 50% faster than the standard edition, it certainly plays a lot more furiously. I discovered how to make Paradroid run fast after I finished Alleykat. I was experimenting with the double-speed CPU in the C128 which is an adaptation of the 6510, called the 8510. It can run at a clock speed of 2MHZ if required, but normally it runs at 1MHz for C64 compatibility.
Upon further investigation, I realised that the 6510 present in all C64s could also be encouraged to run at this higher speed by use of software. I have produced a BASIC listing to allow you to apply this discovery to your own software. Just key in the program and save it to tape or disk. . RUN it, and then NEW it. Finally load in any game from cassette. Once loaded, it will run at up to double normal speed, prepare for a mega-fast game! Since the 6510 Accelerator upsets disk loading speeds, it cannot be used to speed up disk-based software yet, but I am working on a solution to this.
By the way, line 90 contains some cursor commands in quotes. The PRINTed line is 3 cursor downs, then NEW, then three cursor ups to put the word NEW on the CURRENT line just to remind you to NEW the program. All you do is press ENTER.
Monday 9th February
Itís been a slow day. Began by writing some more notes on the sprite combining system. I suppose the idea came from reading about ĎBlitterí chips, the way you just point them at up to three sources of data, one destination for the finished data and tell it what logical operations to perform, and it does it. It can do anything from simple data
copies to complex object plotting. Wish there was a blitter in the CM.
Now that I have a game name I can begin thinking about title screens. Iíve re-arranged some of my large character set to allow it to be used with my moving background system.! shall also need a snazzy high-score table of some kind.
Tuesday 10th February
Got to grips with the multi-layered grid that moves at different speeds, done with characters. Sadly it doesnít have CPU time to build and dis play it in real time, and not even at half-speed, doing half of the grid on each cycle. It is a nice effect though, so Iíll have to work out another way of displaying it. Itís a lot faster to debug with the source code in front of you on one screen and the game running on another.
Redrew the small-lettered character set and the game logo that will appear on-screen during the game to make them easier to read. Itís the first multi-colour resolution character set that Iíve ever done, Alleykat was in hi-res but with a fancy Atari-emulation system to make it look like more colours.
" . . . I hate line numbers! They were only invented for punch cards so that if some body shuffled them you could sort them out again. . . "
Wednesday 11th February
Re-organised yesterdayís grid-drawing routine so that it calculates all the animation frames in advance and can then display them at any speed. Thus it takes very little CPU time to display and gives me time to run the moving blobfleld and thirty-two sprites. Of course it does take an extra 4K of memory - you donít get something for nothing. The constant battle is always time against memory; you can write a routine thatís fast but takes a lot of memory, or write it to take less memory but it executes a lot slower.
Re-arranged the character set (again) to group together all the pieces that are similar in what they will do. This is so that anything such as col lision detection needs only to check a range of codes, not a series of individual codes dotted around all over the place.
Tried to think of a neat way of dematerialising the character set that hasnít been used . . . failed. I could switch in a new charac ter set,or a new screen, or both. Maybe a Uridium dreadnought dissolve would look nice.
One thing about our new Opae, the editor has no line numbers. Great. I hate line numbers! They were only invented for punch cards so that if somebody shuffled them you could sort them out again. This is the 1980s, and we donít use punch cards on the C64, so why do we have to suffer line numbers? Mickey Mouse award for the Thirteenth Century goes to the inventor of line numbers, especially in BASIC programs.
Thursday 12th February
Wrote (on paper) and keyed in an object block plotter, which plots blocks of characters on screen with which I shall build a sort of minidreadnought. This is the ship that the player will fly. At biggest it could be twenty-seven characters wide by n-n-n-nineteen high! Should give the player a feeling of superiority. Iíve got the íPlayer Xí words and the game logo put on screen using this block plotter, as well. Looking at it now I reckon I should put the moving grids up using the same plotter, which will save on code. However it can only handle the first 128 characters, because I use the top bit as an end-of-column flag. The grid uses higher character codes.
Took some screen shots this week, but the processor always takes at least a week to do black and white so Iíll send them to ZZAP! next month.
Since our printer has been disconnected for taking up too much room on the desk, this diary will have to go home for printing.
To be continued...
6510 ACCELERATOR LISTING
20 FOR X=49152 TO 49463
30 READ C
50 POKE X,C
60 NEXT X
70 IF B<>44878 THEN PRINT "ERROR": END
80 SYS 49152
90 PRINT "<CD> <CD> <CD> NEW <CU> <CU> <CU>"
200 DATA 174,48,3,172,49,3,142,46
210 DATA 3, 140,47,3, 162, 74, 160, 192
220 DATA 142, 48,3, 140,49,3, 162, 245
230 DATA 160, 192,32, 188, 192, 162,6, 160
240 DATA 193, 32, 188, 192, 169, 128, 141,225
250 DATA 192, 160,3,202,208,253, 136, 208
260 DATA 250, 206,32,208,173, 225, 192, 56
270 DATA 233, 1,72,238,32, 208, 104, 141
280 DATA 225, 192,208,229,169,37,141,5
290 DATA 220, 96,201, 0,208, 8, 165, 186
300 DATA 2O1, 1,240,5,169,0,108,46
310 DATA 3,32,23,248, 162,26, 160,193
320 DATA 32, 188,192,169,11,141,17,208
330 DATA 169,48, 141,225, 192, 160,0,202
340 DATA 208, 253, 136,208,250, 206, 225, 192
350 DATA 208,245, 169, 34, 133, 192, 169,55
360 DATA 133,1,169,27,141,17,208,173
370 DATA 134, 2, 41, 15,168,172,134,2
380 DATA 185, 36, 193,141,243,192,162,226
390 DATA 160, 192,32, 188, 192, 165, 197,201
400 DATA 64, 240, 250, 174,46, 3, 172,47
410 DATA 3, 142,48,3, 140,49,3, 169
420 DATA 27, 141,17,208,169, 64,141,5
430 DATA 220, 76,116, 164,142,203,192,140
440 DATA 204, 192,160,0,140,225,192,172
450 DATA 225, 192, 185,226, 192, 73,255, 72
460 DATA 238, 225, 192,240,11,32,210,255
470 DATA 104,201, 13, 240,3, 76, 199,192
480 DATA 96, 19,185,176,170,177,187,223
490 DATA 250, 190, 175, 173, 182, 179,223, 185
500 DATA 176, 176, 179, 101,242,201,202,206
510 DATA 2O7, 223, 190,188,188, 186,179,186
520 DATA 173,190,171,176,173,242,189, 166
530 DATA 223,190,177,187,173, 186, 168,223
540 DATA 189, 173,190, 166,189,173,176,176
550 DATA 180,242,172,186,190,173,188, 183
560 DATA 182, 177, 184, 242, 111, 250, 227, 96
570 DATA 99, 225,224,97, 126, 106, 105, 104
580 DATA 103, 102, 101, 100,0,0,0,0