Archive for February 2015




This would be *VERY* difficult on the C64 (beginning)


This would be *VERY* difficult on the C64 (end)

In this series of articles, I plan to look at simple building blocks of games programming, leading to programming a simple game.

The title of these articles is a quote from the Commodore 64 Group Leader of the local computer club I attended in 1984.

First, I must clear up a misunderstanding about the course “Let’s Make a Retro Game”, which has now reached its third episode on the YouTube channel “Electric Adventures”.

I was amazed to hear about this programming series, but I didn’t know exactly how the game was going to be written, or implemented on SEVEN different platforms, each with a different BASIC, and two different processors. These are MSX1, Spectravideo 318/328, the Colecovision games console, the Sinclair ZX Spectrum, Amstrad CPC (all Z80 based), as well as the Atari XEGS (6502 based console version of the Atari 8 bit computer system), and even the dreaded (6502 compatible) Commodore 64!

There was a mention of Z80 Assembler, the Z80 and TI99XX video chipset, other Z80 based computers with different video chips, and even 6502 Assembler for the Atari and C64. It also mentioned that the Colecovision games console is based on the Spectravideo 318/328 design. One difference is that the sound chip is by Texas Instruments and the same as in the BBC Micro.

I’ve now found out that, although this course will be using Z80 Assembler and 6502 Assembler, it’s not really a case of learning to program in those languages, but how to use an extensive game template linked with another two files, where most of the code has been prepared. It could be a bit like a game making package, such as “Shoot ‘Em Up Construction Kit”, although in this course you actually type in or modify a few lines which represent a small percentage of the total code and you don’t have to learn many Z80 or 6502 instructions. I can’t actually say how much people will learn about programming from this course, or if it’s possible to use this knowledge to create anything else except a shoot ’em up game.

There’s one main file containing the template program, which just prints the word TEMPLATE on a hires screen, while a ball is bouncing round the screen off the borders and there’s a bat at the bottom of the screen, which can be moved to the left and right, but the ball doesn’t bounce off the bat if it hits it. The template includes the message TEMPLATE, a font definition, a sound effect, and sprite data. One file is a list of labels followed by EQU (i.e. equate, meaning equals) instructions saying what numbers or memory locations these represent. The other file is a list of definitions of various subroutines which can be called up by the Template program itself. This includes various occurrences of CALL followed by addresses in the ROM. MSX1 has an extensive set of ROM routines, unlike the C64. MSX2 has even more of these routines. Obviously, there were no such templates around in 1984-1985 when I was being driven slowly round the bend by Commodore BASIC V2 on the C64. I think that MSX represents the best work Microsoft has ever done! After MSX, it seems to have been downhill all the way with the very derivative and buggy Windows OS copying the MacIntosh, the Amiga, and the Acorn Archimedes, as well as Visual BASIC, which is more like C than BASIC! Here’s the link to the Electric Adventures course…

I had been struggling to program the Commodore 64 with its totally f*cked up BASIC for several months, but obviously I didn’t get far, because Jack Tramiel had already sabotaged the C64’s BASIC before it was released. I presented the Commodore 64 Group Leader at my local computer club with a short program I called “TARDISes in flight”. This was based on the hot air balloon sprite program from the Commodore 64 user guide. The original program displayed a sprite that looked like a hot air balloon with a C logo moving across the screen. I managed to change this so it displayed a sprite that looked like the Doctor’s 1950s-1960s Police Box shaped TARDIS from the TV series “Doctor Who”, as well as a second sprite that looked identical, then made them cross each others’ paths. This was still on the text screen, because that was what was used in the original example and just turning on and clearing a C64 graphics screen is so difficult, although other computers do this with commands such as MODE <n> , SCREEN <n> , or GRAPHICS <n>.

Obviously, the next stage or stages was to detect when the sprites collided, then make them bounce off each other, meaning to stop and travel off in different directions. The C64 Group Leader obviously added some PEEK and POKE commands to my program, because PEEK and POKE is how you do MOST THINGS on the C64, apart from just printing text. After this, a number was displayed in the top left hand corner of the screen. He pointed out that the number displayed changed when the two sprites collided, so the program was detecting collisions. Obviously, this wasn’t what I had in mind. I asked him how to make the sprites bounce off each other as well. His now legendary reply was “Oh, that would be VERY difficult!” and that was the end of this programming session. This was the point where I gave up on the C64, and decided to look around for a replacement which could also play polyphonic music.

We’ve already got a big building block for a simple game, which is the program I recently posted in a de debunk. My opponent, the C64 fanatic TMR, has criticised my program as being “cack handed”, and even refused point blank to convert this listing into Commodore BASIC V2 for the C64. I’m not sure why this is, but it’s probably for some really nasty and devious reason, such as gaining a feeling of superiority by actively trying to prevent other people from learning to program. I saved my MSX BASIC V2.0 program as VDIFF6.BAS, then posted it on YouTube, included in my last post on here. Here it is again…

This program needs a bit more work on it, though. First of all, the sprites could be redesigned from the 8×8 resolution sprites expanded to 16×16 to proper 16×16 resolution sprites. MSX 16×16 sprites are defined in four 8×8 blocks in the order top left, bottom left, top right, and bottom right, They can be designed on graph paper, or in a special sprite designer, like one I’ve typed in from the Dutch magazine “MSX Computer Magazine”. This saves the finished design as BASIC lines of DATA statements, which can be read into a SPRITE$(N) definition.

MSX BASIC, even V1.0, has some very advanced commands, such as SPRITE$(N), PUT SPRITE N,(X,Y),C , SPRITE ON, SPRITE OFF and ON SPRITE GOSUB. We should also look at how to program the same demo and simple game without using these commands, as in Tandy Color BASIC, or Dragon BASIC. There were listings for the Tandy Colour Computer/Dragon in the amazing British magazine INPUT. This magazine exposed the C64’s BASIC V2 as crap in Issue No. 3, then started using Simon’s BASIC, which wasn’t designed with an option to create stand alone programs, in spite of a third party obscure compiler released some time later which I never heard of in 1984-1985. INPUT magazine was teaching how to do BASIC programming on several computer platforms, but this was before MSX came out. Luckily, I recently found out that there was later a Spanish version called “INPUT MSX”, which included the same listings converted into MSX BASIC, but with a lot of other articles such as games reviews, book reviews, computer news, and ads. You can find and download copies of “INPUT MSX” on , type in the listings for MSX, then refer back to the original English language articles in INPUT, if you can’t make out the Spanish articles at all.

There are a few things to consider when converting Dragon/Tandy listings to MSX. The commands which cause the main problems are PMODE N,N, PCLS, PRINT @ N, PEEK and POKE. To deal with these, you just delete all references to PMODE N,N, which selects one of a few limited palettes, as well as PCLS which clears a graphics screen, because SCREEN <n> in MSX automatically clears the graphics screen. PRINT @,N causes some problems. This is because the Dragon/Tandy text screens are 32 columns by 16 lines, but these positions are each represented by one number, instead of seperated into columns and rows. This means dividing the number by 32 to get the row, then the remainder is the column. You’d have to use the commands SCREEN 1:WIDTH 32 for the nearest equivalent screen. You may be able to do the same in MSX BASIC by using LOCATE N, instead of LOCATE X,Y , each followed by a PRINT command. Of course, PEEK and POKE commands can’t be used with the same memory locations, or in the same way on MSX as on Tandy/Dragon. Even some of the numbers to PEEK and POKE are different on the Dragon and Tandy, which was to avoid legal problems because the Dragon was based on the Tandy Colour Computer. There’s also a technique in Tandy/Dragon BASIC of making a character for a game, by defining a sequence of CHR$(N) commands. I think this may not be the same technique as MSX BASIC, where SPRITE$(N) is followed by 8 or 16 CHR$(N) commands, meaning that each one of them is a bit pattern. The Dragon/Tandy may be making up a string of graphics characters instead.

I’ve just done a redesigned version of the TARDIS sprite, using the very handy sprite editor created by Unfortunately, this sprite editor only runs under Windows and requires the .net framework, but no one’s perfect! The data for this sprite is as follows, output in Assembler hex format using the Assembler DB (Define Byte) directive, which translates easily into an MSX BASIC definition. However, with such a large sprite, made up of 32 bytes instead of 8 bytes, we have to first define a string of 32 bytes, let’s call it S$ before using SPRITE$(N)=S$. This is because even the amazing MSX BASIC V2.0 can’t fit all of that onto one program line, although it’s much better than Commodore BASIC V2, which can only manage 80 characters!

db 01h,02h,02h,0Fh,1Fh,11h,11h,11h
db 11h,1Fh,1Fh,1Fh,1Fh,1Fh,1Fh,3Fh
db 80h,40h,40h,F0h,F8h,88h,88h,88h
db 88h,F8h,F8h,F8h,F8h,F8h,F8h,FCh


My new improved program (part 1)


My new improved program (part 2)


My new improved program (part 3)

Following this, I decided to improve on my demo program, by doing a sound effect, changing the sprites’ colours, and improving the routine to make them bounce off each other. Here’s the video of the new improved version…

Unfortunately, the hires MSX2 SCREEN 7 mode (512×212) used here has resulted in the stars ending up more or less invisible in this video.

That’s all for now! Just try and take in the techniques I’ve revealed to you here, before the next installment in this exciting series.

Posted February 19, 2015 by C64hater in Uncategorized



This is a de debunk of the debunk on

Of course, MSX2, as well as MSX V1 is capable of creating programs with graphics and sprites quite simplly, such as the following.

VDIFF6aFirst screenful of what was too “VERY difficult” on the Commodore 64

VDIFF6bSecond screenful of what was too “VERY difficult” on the Commodore 64

I should point out that in MSX BASIC V1.0 it’s possible to write almost the identical program, but with a few small changes. There are only a couple of things that make it different from MSX BASIC V1.0. These are that in line 10 SCREEN 4,1 would have to be SCREEN 2,1 (a display mode with colour bleed, depending on where hires graphics of different colours are drawn) SET BEEP 3 which sets the sound for a standard BEEP would have to be deleted, and the whole of line 20, which changes the actual colour of the logical colour 5, would have to be deleted.

This is a demo of the very thing which made me give up trying to program on the Commodore 64. In other words, it’s two sprites colliding, then bouncing off each other in different directions. The C64 group leader of my computer club told me “Oh, that would be VERY difficult!” He was much older than me, very experienced and I thought he may have been using computers for years before the home computer boom.

Here’s a video of this demo.

I’d love to see a program in C64 BASIC V2 with an accompanying video from TMR or any C64 fanatic showing the same thing being done. I doubt they’ll do one. I think this proves conclusively that the Commodore 64 is crap!!

Moving on from this simple building block of games programming, we would do a flowchart about exactly what was supposed to happen in the game, design some more detailed sprites, add keyboard control with STICK(0) and STRIG(0) and joystick control with STICK(1) and STRIG(1).

TMR wrote…

There were Amstrad CPC fans who were satisfied with the same “blocky” resolution for their games from that era and Atari 8-bit users who were happy to live with the even coarser 4:1 ratio pixels their GTIA-specific modes required[1]; the “Commodore propaganda” is just in the author’s mind since it seems to extend to other, non-Commodore platforms.
And we do also need to remember that the MSX2 was released in 1985, the same year that the original Atari ST and Commodore Amiga were released, so the idea that a machine put out three years after the C64 has better graphics shouldn’t come as a surprise to anybody who isn’t terminally stupid. But at the same time

In the cases of the Amstrad CPC and the Atari 8 bit, at least those computers had dialects of BASIC which supported their hardware and they were both more colourful than the Commodore 64. The Amstrad CPC MODE 0 was 160×200 with 16 colours, but these colours were from a palette of 27 colours, instead of just 16, and not only that, but each of the 16 colours could appear anywhere on the screen, not limited to 4 colours per 8×8 character cell, unlike the C64! As for Atari 8 bit display modes, there are so many of them that it’s hard to remember what they all are, but I’ll never forget that Atari computers can use Display Lists to generate a different mode on each line of the display, and have a 128 or 256 colour palette, totally outclassing the C64. You can view a list of the official Atari display modes on . Of course, MSX2 was released in 1985, following on and maintaining compatibility with the original MSX, released less than a year after the C64. The fact that an 8 bit Z80 based computer could display graphics better than the Atari ST and nearly as good as the Amiga was astounding! There was also the fact that there was such a thing as an MSX2 upgrade cartridge, as well as some MSX users upgrading their computers to the MSX2 standard by fitting the Yamaha 9938 graphics chip, a RAM upgrade, and an MSX2 sub ROM. There was no such upgrade available from Commodore for the C64.

TMR wrote…

The author has yet to use the software or hardware in question so cannot “practically guarantee” anything at all at this point. Putting the MSX2 with expansion hardware up against just a standard C64 would just be an almost childlike, pointless comparison that wastes the time of the author’s readers even further than usual and the author’s lack of experience with C64 music software means he can’t fairly judge that in comparison either”.

The sound and music hardware and software in question is similar to my old CX5M computer, so I already know what to expect. Apart from this, it has more software available than for the CX5M sound module. Another factor is that the FM PAC is a standard, supported sound upgrade for MSX computers.

TMR wrote…

No, that’s an outright lie on the author’s part since your correspondent has never made any such claim. Your correspondent’s view on flowcharts is that, once a certain level of complexity is reached, they are pretty much useless unless reduced to a level of simplicity that doesn’t help things along.
And just because something appears in print it isn’t a universal truth; if that were the case there wouldn’t be even a peep about the A-Z of Personal Computers from the author and, since Steven Levy’s book Hackers has a similar “revelation” that none of the programmers at seminal Apple II and Atari 8-bit software company Online Systems used flowcharts, we’d have a ridiculously large paradox

We’re talking here about TMR’s obsessive hatred of flowcharts to plan programs. Rodnay Zaks, the master of Assembly Language/Machine Code on several processors, has said this is wrong, so he should know. The fact that none of the programmers at one particular software house used flowcharts doesn’t prove anything.

TMR wrote…

We need to pause in order to appreciate the scale of the author’s hypocrisy here dear reader; in a comment on his blog that we’ll be dealing with in the next post the author has recently reiterated his belief that “people were supposed to learn how to do everything they could in BASIC, before learning how to do the same things in Assembler/Machine Code” but the programming course he’s essentially endorsing to his readers in the quoted paragraph is for beginners but starts with Z80 assembly language.
We’ll have to see if the author either apologises to his readers for previously misleading them about the actual importance of BASIC to beginners or renounces the Electric Adventures programming course for not teaching BASIC first

The Electric Adventures programming course on YouTube has got off to a very slow start. I’m still not sure how they’ll teach programming. In the first two episodes, all Tony Cruise has done is install and demonstrate the use of a sprite editor and an MSX emulator, both running on Windows. He claimed this was to make things as easy as possible. He said that even using graph paper and working out bit values would be too difficult for some people. He mentioned that he was planning to make the same game first on MSX, and Spectravideo computers, as well as the Colecovision games console, all using the Z80 CPU, and TI99XX video chip, before moving on to the Sinclair Spectrum and Amstrad CPC computers. It remains to be seen how he’s going to do this. Finally, he plans to make the same game for the Atari 8 bit and even the C64!

TMR wrote…

There’s no need for anyone try of course, because Metal Gear was released on the C64 in 1990. We have previously mentioned the author’s poor research, but now seems to be a good time to reiterate that”.

Of course, it doersn’t matter that Metal Gear was eventually released on the C64. All that matters is that this was using its by then roughly seven year old VIC-II graphics chip, in the usual blocky 160×200 mode with only 4 colours in each 8×8 character cell. A quick search online reveals something that doesn’t even look like the same game. Here’s a video comparing Metal Gear on MSX2, NES, C64, and PS2. I rest my case!

Finally, here’s a review pointing out just how crappy Metal Gear was on the C64!

Posted February 15, 2015 by C64hater in Uncategorized



jay-miner-1Jay Miner, the “Father” of the Amiga and Atari 8 bit computers

The Amiga was originally called the Lorraine, designed by a group of ex Atari engineers, led by Jay Miner, who was also involved in designing the Atari 2600 games console, as well as the Atari 400 and 800 computers. His team included RJ Mical, programmer of Intuition, Carl Sassenrath programmer of the Exec part, graphics programmer Dale Luck and hardware engineers, Glenn Keller, Dave Needle, and David Dean, as well as several others. Jay Miner wanted to design a new, more powerful computer, which could also play games, but Atari weren’t interested in doing this at the time, or at least not in the expenses of development. For this reason, Jay Miner left Atari and assembled a team which became Amiga Corp. Their plan was to get finance for the development themselves, then sell the completed product to Atari. In the meantime, Amiga Corp developed a strategy of producing software and joysticks to earn them some more development money, as well as cover up their real work from competitors. One of these was a “joyboard”, based on a surfboard. They named their custom chips Paula, Agnus (not Latin for lamb, but an alternative spelling to Agnes), and Denise, so that competitors who overheard them talking would think they were referring to their girlfriends. Only one chip, called Gary, had a male name.

The concepts behind the Amiga’s design were very similar to the earlier Atari 8 bit computers (i.e. the Atari 400 and 800). The idea was to push the hardware to the limit, this time based round a 68000 CPU, like the original monochrome Apple MacIntosh, but with more colours than any other computer generally available (except for expensive specialised workstations) and custom chips for graphics and sound, which took a lot of the workload off the CPU. The graphics chips in Amiga and Atari 8 bit computers have direct memory access (DMA) to the video RAM and the sound in both is four channel stereo. The Amiga graphics chip can even display custom screen modes, by using “Copper Lists”, similar to the Atari’s “Display Lists” and the sound chip has four channels, the same number as the Atari 8 bitters. They mixed this with concepts from mainframe computers such as UNIX OS, to produce a multitasking operating system, eventually based on TripOS, called Amiga Workbench, including components such as the graphic Intuition and the text command based AmigaDOS.

Early Amigas were supplied with ABasiC by Metacomco, which was influenced by Sinclair BASIC and Commodore BASIC 3.5, but this was changed later to AmigaBASIC, by Microsoft, similar to Microsoft BASIC for the Apple MacIntosh, descended from Microsoft extended BASIC for Tandy, Dragon, and MSX computers, as well as from GW-BASIC on early PCs. AmigaBASIC includes about 205 commands (as listed in ), including those for colour, graphics, music, speech, windows, and mouse input. Lots of books about programming in AmigaBASIC were written by Data Becker of Germany, then later translated and republished by Abacus of the USA.

Amiga1000KingTutThe Amiga running Deluxe Paint

The official Amiga debut presentation included artist Andy Warhol colouring in a digitised pic of the singer Debbie Harry, using a pre release version of a graphics package called by different sources “ProPaint” or “Graphicraft”, with its own custom PIC file format, instead of the later, truly amazing, killer application “Deluxe Paint” with the more common IFF ILBM format. IFF stands for Interchangeable File Format, allowing most programs to share data, while ILBM is the specific Interleaved Bit Format for graphics screens. Andy Warhol had been working with this software for about a year beforehand.

That’s all for this installment about the Amiga’s 30th anniversary! Another post on this topic will follow shortly.

Posted February 11, 2015 by C64hater in Uncategorized



AmigaA1000The original Amiga computer model (A1000) from 1985

I’ve now decided to make shorter posts and do them more frequently, like I used to do when I started this blog, so here goes!

In 1985, following a few years of secret development, the Amiga computer was revealed to the World! This computer introduced the concepts of multitasking to the general public. It also had higher quality graphics than any other system generally available. It could even lay screens on top of one another, then scroll the screens up and down in front of other screens, a feature never adopted by PC hardware companies or Apple.

When I first heard about the Amiga, I thought to myself that there was no way I would buy another computer made by the Commodore con artists. Once bitten, twice shy! However, I eventually heard enough about the Amiga to realise that it wasn’t anything like any previous Commodore computer, because it wasn’t developed by Commodore, so then I eventually decided to buy one.

The Amiga was supplied with a BASIC programming language which supported a lot of its hardware.

Here’s how the legendary Fred Harris, who was already the hero who presented the earlier computer programming series “Me and My Micro” introduced the Amiga on the BBC TV series “Micro Live”.

That’s all I want to say about the Amiga at the moment! Look forward to a continuation of this very soon!

Posted February 11, 2015 by C64hater in Uncategorized



My second steps with MSX2…

PhilipsMSX2mainA close up of my MSX2

Finally, after all the disruption of Christmas and New Year I’m back! I wish you all a happy 2015, which is pronounced TWENTY FIFTEEN!!!!

On Thursday, December 18 2014, I received a package from an eBay seller in the Netherlands. It was an MSX2 computer! A type of computer never released in Britain, where I have always lived. It seems this type of computer was never released in any English speaking country either! Some MSX fanatics in Australia had them specially imported, and I’m not 100% sure about the situation in Canada. There was also the Yamaha CX7M MSX2 computer (a later model from the CX5M) which was sold as a musical instrument in music shops, but I’m not sure in which countries it was available.

As I previously posted on here, the computer I’ve bought is an Philips VG8235 MSX2 computer, the same as or similar to a Philips MSX2 computer I used at the Philips stand at a show in London, which I think was in 1986. I actually wanted an MSX2 computer with a separate keyboard, which is called a “pizza box” configuration in MSX circles, but it seemed I couldn’t afford one, so I went for this more traditional doorstop style model instead. It cost me €99 plus €20 postage.

PhilipsMSX2driveMy MSX2 showing the refurbished, thinner floppy disk drive with a gap above it

Luckily for me, after I sent a question about whether or not some Philips software was built in on ROM, the eBay seller told me it wasn’t built in to this model, so then she had a look round for a copy of the Philips Video Graphics editor and sent this disk which also contains a Philips Home Office suite, as well as two other disks, so well done to her! I’ve given her some glowing feedback on eBay. The other disks contain a collection of 19 classic games, now abandonware, mainly ripped from cartridges, and the other disk contains just one game called Infinity, which is an MSX2 fruit machine simulation. The disk of 19 games contains such classics as Antarctic Adventure, Hyper Sports 1 & 2, Yie Ar Kung Fu, Road Fighter, and King’s Valley, which helped define MSX as a gaming platform.

Buying this MSX2 computer for me is like an alternative timeline of what might have been. During the time period early May 1985 to December 1988 I was mainly a fanatical Amstrad CPC user, having bought a CPC664 because of the 8912 sound chip with unprecedented software envelope control, the built in disk drive, and a colour monitor included with it. However, in about February to April 1986 I also got a Yamaha CX5M Music Computer, which was of course MSX version 1. I didn’t go for any other MSX1 computer, because the 8910 sound chip as used in MSX couldn’t play different instrumental sounds on each of its 3 channels. It seems Locomotive Software for Amstrad overcame this limitation in their BASIC and ROM system firmware using the 8912 chip, which I have recently read otherwise has the same limitations as the 8910 used in MSX1. I used my CX5M mainly for music, although I did some programming and some games playing on it. I read in the magazines “MSX Computing”, as well as “MSX User” about developments such as the MSX disk drives with MSX-DOS, the Quick Disk drives, and MSX2, but unfortunately, I never managed to upgrade to any of these facilities. I joined the independently run Yamaha DX Owners’ Club, which was for users of Yamaha DX synthesisers, as well as the Yamaha CX5M computer. The organiser of this club eventually gave up due to other commitments, then it was taken over by Yamaha Kemble Music (UK) Ltd. I did some work on the Yamaha Kemble Music (UK) Ltd stand at a music fair. My knowledge was superior to a Yamaha Kemble Music (UK) Ltd manager who answered a customer’s enquiry about if his Quick Disk drive was compatible with the new disk compatible Yamaha music cartridges with “Yes, so long as it uses MSX Disk BASIC”. I was able to point out that his Quick Disk drive wasn’t compatible with the new disk compatible software because it not only didn’t use MSX Disk BASIC, but was a sequential filing system, like tape, although it recorded a single track onto a disk like a groove on a vinyl record.

PhilipsMSX2backThe rear view of my Philips VG8235 MSX2

Later on, in December 1988 I took the plunge and bought an Amiga A500 computer! This became my main computer for programming and most activities except composing music, although I did try that as well. I became a fanatical Amigan and an Atari ST and PC hater. I started programming in AmigaBASIC by Microsoft, which is similar to MSX BASIC, but has extra commands for windows, sub programs (like procedures), speech, the mouse, and pull down menus. I still hated the Commodore 64, because that computer had nothing in common with the Amiga except both of them were sold by Commodore. The Amiga doesn’t even have a Commodore style printer port. Eventually, Commodore killed the Amiga because they didn’t understand it. It was about 9 years ahead of the competition. They got rid of the original team who developed it. Apart from them, only ex Atari employees dismissed by Jack Tramiel, and Atari 8 bit enthusiasts understood the Amiga.

As for using my new MSX2 computer, after looking at the software provided on disk, I needed to get a blank disk, or at least reformat a spare one if I could find one. I picked up a disk with a not really brilliant classic game on it, which I had downloaded anyway, put it into the MSX2 internal drive, then typed the MSX Disk BASIC command CALL FORMAT. I was prompted to format drive A: or drive B: . I later checked that if you choose B: it then prompts you to insert a disk into the same drive for drive B: , like under CP/M on the Amstrad CPC. Next, I was asked whether I wanted to format a single sided or double sided disk! My Philips VG8235 has been upgraded from a single sided 360K disk drive to a double sided 720K one. I selected the double sided option and it started to format! All went well, then I had a newly formatted disk ready to save programs onto. Just from memory, I soon started to create a program in MSX BASIC V2.0 showing the background of the text based SCREEN 0 cycling through lots of colours using the command COLOR=(number, red, green, blue). I was surprised this worked on SCREEN 0, because this screen mode was also available under MSX1. However, this is definitely MSX2, not MSX1 and it finally surpassed the Atari 8 bitters for the maximum number of colours on an 8 bit computer!

I also tried out the Philips Video Graphics software which responds to joystick control. I recently posted a long video which showed someone using this software to generate lots of geometric patterns. Unfortunately, Philips decided to use lots of icons, without accompanying text in any language at all, so I found that I wasn’t able to work out how to draw anything using this software! I’ve searched online for a scanned manual in any language, but haven’t found one so far. I hear that the software AGE5 is better, but only works in SCREEN 5, although some enthusiasts have hacked it to produce versions that work in some other display modes. I hope to copy this onto floppy disk soon.

Here’s the details of MSX2 graphics screens.

Mode Resolution Colours Size Description
4 256×192 16 of 512 RGB 16kB Graphic Mode
5 256×212/424 16 of 512 RGB 32kB Graphic Mode
6 512×212/424 4 of 512 RGB 32kB Graphic Mode
7 512×212/424 16 of 512 RGB 64kB Graphic Mode
8 256×212/424 256 (no palette) 64kB Graphic Mode

When faced with the choice of this or the C64 320×200 hires with 16 colours and 8×8 attributes or colour bleed, or the 160×200 multicolour mode with only 4 colours in each 8×8 cell, surely only people totally brainwashed by Commodore propaganda or living somewhere MSX2 wasn’t available would have wanted to play blocky games or do rough, woodcut style graphic art on a Commodore 64!

Two days later after receiving my MSX2 computer, I went away for Christmas. I didn’t want to take my amazing new, refurbished MSX2 computer with me in case it got damaged, so this means I was unable to use it over a period of 9 days.

PhilipsMSX2256barsprgA short MSX BASIC V2.0 program to produce vertical bars in 256 colours

I’ve also started programming in MSX BASIC again. This is a totally amazing and user friendly language compared with Commodore BASIC V2, Visual BASIC, C, or C#. I’m trying to familiarise myself with the additional screen modes 4-8. It was fairly easy for me to display bars in 256 colours out of the 512 available. Try simulating that on a Commodore 64 which only has 16 colours!

PhilipsMSX2256bars1The output of the 256 colour bar program above

I’ve started programming a demo of a game using SCREEN 4, which has no colour bleed attributes, using 16×16 sprites and some simple music using the PLAY command. The music slowed down the program, because I forgot how to use MSX interrupts from MSX BASIC, but have now found out from the excellent “Complete MSX Programmers’ Guide” (Melbourne House) that the relevant commands are ON INTERVAL= GOSUB , accompanied by INTERVAL ON. Of course, this would require God knows how many POKEs on the C64! I’ve also been having some more fun typing in some listings from the Dutch “MSX Computer Magazine”, such as “Escape”, a platform game which mixes MSX BASIC with a lot of Machine Code routines.

My next step will be downloading some MSX2 software from the Internet, then transferring it onto floppy disk, using some kind of floppy disk drive. This could be either a built in floppy drive or a USB floppy drive. My first attempts to do this with a USB floppy drive have failed. After that, I plan to buy a sound upgrade cartridge called FM PAQ. This is a new reproduction of the classic MSX FM PAC cartridge by Eric Boez, an MSX enthusiast in France on . This module isn’t compatible with Yamaha’s SFG-01 or SFG-05 FM synthesiser modules in their CX5M and similar computers, but I hear it’s got more software support. I think the software and the music cartridge could both be totally amazing, but whatever it is, I can practically guarantee it will be a lot better than software for the Commodore 64! You can look forward to reading about it on here!

I have been encouraged by my new/old MSX2 computer to study Z80 Assembly Language/Machine Code again, this time from the book “Programming the Z80” by Rodnay Zaks. I haven’t got very far. However, in this book Rodnay Zaks makes the revelation that about 10% of people can write programs without making flowcharts first, but about 90% of people think they’re members of this 10%, so the programs they write crash, and as for the 10% who can write programs without making flowcharts, other people can’t understand how their programs work. I think this sums up TMR of the website . In other words he thinks “Flowcharts are for wimps!”

BTW, some recent news about programming MSX1 and similar systems with the Z80 CPU and TI99XX VDP video chip is on the YouTube channel Electric Adventures. A series started on 22-12-14 which is called “Let’s Make a Retro Game”. In this series Tony Cruise, a former writer on “Micro’s Gazette”, a fanatical Australian MSX/Spectravideo 318 and 328 magazine is using development software running on Microsoft Windows, such as a sprite editor (which combines two sprites into a single two colour sprite), and the BlueMSX emulator to develop a game to run on MSX1, Spectravideo 318/328, and the Colecovision console (which all use the Z80 CPU and TI99XX VDP), in Z80 Assembly Language, then show how to port it across to the Sinclair ZX Spectrum and Amstrad CPC, which also use the Z80 CPU, but have different graphics chips. Finally, he plans to port the game to the 6502 based Atari 8 bitter, and even the crappy 6510 based Commodore 64! Warning: watching this final stage could blow your mind! Of course, once someone has understood this lesson, they could enhance the game to MSX2 standards by using a different display mode, multicoloured sprites, and even some FM music, or SCC music.

Finally, here’s a video clip showing a well known game that was first released on MSX2. This game is called “Metal Gear”! Try doing this on a C64 with its blocky 160×200 16 colour graphics!

Look forward to another post from me very soon now!

Posted February 6, 2015 by C64hater in Uncategorized