Thursday 11 January 2024

THE400 Mini - The Atari 400 platform recreated. My initial thoughts.

Retro Games Ltd (RGL) have partnered with PLAION to bring the wonderful world of the Atari 400, 800, 5200 and XE/XL range to life in a now famous mini form factor. THE400 Mini using modern days connections like HDMI and USB, will soon be available (and may be pre-ordered now) in "console" form.

The famous Atari 400, along with its "more serious" and compatible 800 model, were initially announced in December 1978 by Atari to follow up on its successful 2600 Video Computer System. It offered many advanced features for a personal computer of that era, and eventually launched to retail in October 1979. Until then, Commodore, Apple and Radio Shack had been slogging it out for dominance in this fast growing personal computer market. Atari entering this fight was significant, and the 400 model was pretty formidable, especially when it came to computer graphics.

Offering high resolution graphics of up to 320 x 192 pixels, utilising hardware sprites, and having a palette of 128 colours, all through a standard television set, meant that this computer was going to be good for playing video games. And its 40 x 24 character display made it equally good for the applications of the day. Being powered by the popular 6502 Central Processing Unit (CPU) at 1.8Mhz, which [in raw Mhz] was faster than both Commodore's and Apple's offerings (I won't compare this to the Radio Shack's TRS-80 as comparing a 6502-based processor to a Z80-based processor is folly). From 1980 through to around 1986, the Atari 8-bit computer range had some seriously good entertainment software produced for it, by then upcoming and staple video game developers like Activision, Epyx, Datasoft, and Atari itself.

From around 1986, the Atari 8-bit personal computer platform began to fade, even with improvements made to the compatible XE and XL range, which could display 256 colours and had a few more graphics modes. Commodore, with its C64, largely won the home computer war, and this model wouldn't die until around 1992. Remember that the C64 competed against (in many ways) more technically capable machines like the Commodore Amiga or Atari ST for over half of its commercial life. To still be a relevant in 1990 was quite a feat.

What I find most interesting about the announcement of THE400 Mini is its price point. And I'm taking nothing away from its perfect replica form factor.

THE400 Mini will be pre-loaded with 25 licensed games, and will provide a way to load your own legally purchased or public domain software by "side-loading" tape, disk or cartridge images. Knowing RGL as I do, I'm certain that it will support THE400 through firmware updates based on user feedback, so you will be able to buy with some confidence. I note that other "Mini" console producers do not offer this. Releasing a new firmware update is timely and costly, and provides RGL with no additional revenue.

I think the promised feature to "rewind" your gameplay by up to 40 seconds is interesting, and I guess this may be more convenient than the "saved game states" on THEC64 or THEA500 Mini. It is the price point of £99.99 that I think makes THEC64 Mini and even THEC64 Classic, or THEVIC20 (if you can find one) look very good value indeed.

THEC64 Mini launched at £69.99, and included 64 licensed games. It has since had several firmware updates, adding more games of varying quality to the carousel. Like THE400, THEC64 allows you to side-load any tape, disk, or cartridge images of software that you own. It includes one joystick and all the necessary cables to get you started. Although some will say that the joystick included with THEC64 Mini wasn't good quality, the joystick included with THE400 won't be worth £30 more. So, THE400 has more USB ports, but THEC64 Mini can use a cheap USB extender. One thing I don't know is if THE400 will include a decent USB power adapter, but looking at both THEC64 Mini and THEA500 Mini, it is likely that it will not, though it may require lower power consumption and/or not run so hot as some versions of THEC64 Mini.

THEC64 Classic and THEVIC20 launched at £119.99 (some sources say £109.99), which included an improved joystick (especially on THEVIC20), with a fully working and correctly mapped keyboard, more USB ports and a USB power adapter, and all of the necessary cables to get you started. All firmware updates to THEC64 Mini also work on THEC64 Classic, and THEVIC20. So, you legally have over 64 games if you have the latest firmware version, and many good features that some C64 fans will love, like being able to emulate the Commodore Ram Expansion Unit (REU), or the ability to play four-player adapter games, like Bomb Mania, from Protovision.

Aside from entertainment software, you have much more choice of other types of software too. I could write many pages just about the GEOS operating system, which by itself had all kinds of productivity, utilities and so on. The Commodore C64's library of games alone certainly exceeds the cumulative totals of all models of the Atari 8-bit personal computer range. And THEC64 Classic can also play VIC-20 games too. A lazy estimate is that owners or THEC64 Classic and THEVIC20 will have at least 10,000 software titles to pick from. As you might have guessed, these are not that difficult to find these days, and even after the commercial demise of the C64, there has still been lots of software released for it considering that it was a commercially dead platform for at least 15 years after 1992.

Could this therefore be a sign that THEC64 platform is about to be discontinued? Or will hard-nosed consumers simply make a cold decision that, because many games on the Atari 400/800/XE/XL had comparable versions on either the C64 or the VIC-20, or both, that THEC64 Classic or Mini is simply better value? If the latter is the case, this may mean that THEC64 has, at least, another year at retail in it.

All of this means, at least to me, that THE400's success is in the balance, although I'm sure that many people will be pre-ordering this right now. RGL already have a product that will fit many gamers who were around from ~1981 through to the early 1990s - or those people who don't want to mess around with a Raspberry Pi and spend time configuring it with this or that emulator. The Atari 400/800/XE/XL was only a significant player for about half the 1980s, with the 5200 model only really a footnote in all of this. The VIC-20 was significant from 1980-1984, and the C64 from 1982 through to the end of that decade. But is the Atari name enough to carry this new product? And will it at least sell as well as THEC64 Mini when you are paying more to get less? Time will tell.

A side note to this is that it kind of reminds me of when Commodore launched its Plus/4 model in 1984: the Plus/4 was too similar to the C64 in many ways but without a better sound chip, and although it could display more colours, it could not do hardware sprites like the C64, and did not use the most common joystick type. Okay, so the Plus/4 was meant for a different market, to compete at the low end with the Sinclair/Timex machines, but somehow it ended up launching at $299USD. By the time of its launch, the C64 was certainly no more expensive than this, and had already started to have a second user market, and had a vaster software library. It all sounds too familar.

But all of this said, I'll probably be purchasing THE400 Mini myself because it looks like a lovingly created Mini console with a beautiful aesthetic. Because I guess a fool and his money really is easily parted.

Edited by Mike Mee. Many thanks for your help Mike.

Monday 13 March 2023

Learning Assembly and Hello World.

Hello World takes 30 lines of assembly?

Recently, I saw a programming meme on the BookFace so-called Social Media platform. It read "Ok ima Learn Assembly [sic] Damn Hello World is 30 lines" with an accompanying boxer first ready to fight, and then the said boxer taking a break with a water bottle.

Cards on the table, I am not a professional in any assembly language. I would say that I am most knowledgeable in Z80, and know enough in 6502 and MIPs to get by. And because I've not done any Z80 for a while (nor any other assembly for that matter), I'm a bit rusty with it. But I couldn't think how in Z80, or in 6502, or in MIPs, a Hello World program would take 30 lines of assembly. It may take 30 bytes, or words, but that's not the same. If you were learning assembly, you wouldn't be entering a program byte by byte (or word by word). That wasn't even a good idea 35 years ago.

So sure was I about this that I posted an example in 6502 with the target platform being the Commodore C64. My first try, although flawed, was 7 lines of assembly and 12 bytes of data. Whilst it worked fine to output 'HELLO WORLD' to the C64 screen (at 1024), it had a flaw that I didn't realise (as I didn't test the code before I posted it). It was only after testing that I realised the mistake, and posted a follow up which corrected my initial bug.

Some notes before I continue. For this example, I am using an online assembler found at nurpax.github.io/c64jasm-browser but other assemblers are available; if you want to try these examples on real hardware then I would recommend Turbo Macro Pro - some examples of how to use this are shown on Robin Harbron's excellent 8 Bit Show and Tell Youtube channel here. I recommend Robin's tutorials as he goes in to way more depth than I will be here.

Let's start from the dumbest example and work through it. In doing so, we may discover the elusive 30 lines of code issue highlighted by the meme.

* = $c000 ; Start address, call with
          ; SYS 49152 from C64 BASIC
    lda #$48 ; 'H'
    jsr $ffd2 ; Kernal CHROUT call
    lda #$45 ; 'E'
    jsr $ffd2
    lda #$4c ; 'L'
    jsr $ffd3
    lda #$4c ; 'L'
    jsr $ffd2
    lda #$4f ; 'O'
    jsr $ffd2
    lda #$20 ; ' '
    jsr $ffd2
    lda #$57 ; 'W'
    jsr $ffd2
    lda #$4f ; 'O'
    jsr $ffd2
    lda #$52 ; 'R'
    jsr $ffd2
    lda #$4c ; 'L'
    jsr $ffd2
    lda #$44 ; 'D'
    jsr $ffd2
    rts
  

As already stated, this is a dumb example, and we get to 24 lines.

It is using the C64 Kernal to output each character to the screen, so whilst this has some advantages, in that when you call this with SYS 49152 it will output from the next cursor position, and your code returns you back to BASIC cleanly on the rts instruction, it isn't necessarily the best way to do things. As an aside, this will also work on other Commodore machines, certainly the VIC-20 and C128 in native mode, and probably all other Commodore 8-bits including the PET as long as you relocate the code to somewhere where there is free memory available to store it.

Using the Kernal may be slower than handling things yourself, and using the CHROUT in particular means that you cannot easily write to the whole screen, as when you get to the last screen position (on the C64 this is 2023, or $07e7 in hexadecimal) and output there with a jsr $ffd2, your screen will scroll either one or two lines, and therefore the top one or two lines will disappear. If you limited your text to 999 characters maximum, or outputted to a specific screen area then this might be useful, but you'd also have to use the Kernal to position the cursor correctly before writing to the screen, which again may be cumbersome in some instances.

A more pertinent point here is that if you were actually going to learn assembly, you would not write any assembly like this. Aside from the relative slowness of calling to the Kernal CHROUT, you also have repeating code as almost every other line is a jsr $ffd2, and one of the lda instructions is not necessary at all. In the above example, it loads the 'L' character in HELLO twice before calling the CHROUT routine twice; a small efficiency here is to simply load the L character value once and call the CHROUT routine twice. But even then, doing things this way isn't how you would learn assembly. In assembly, you would set up a conditional loop to read from an area in memory where each byte of the data is stored with your message (HELLO WORLD), and then iterate the loop until your condition to terminate it is met, and output each byte to your display. Based on the CHROUT example above, let's have a look how one might do this.

* = $c000
    lda #$00 ; Set Accumulator to zero
    ldx #$00 ; Set the X register to zero
    lda $c01b,x ; Start of loop, reads the
                ;data to the Xth byte
    cmp #$00 ; Have we hit our terminator yet?
    beq *+9 ; If so, branch ahead 9 bytes
    jsr $ffd2 ; CHROUT
    inx ; Increment the X index
    jmp $c004 ; Jump back to the start of our loop
    rts ; Return to BASIC
* = $c01b ; Data at $c01b
    ; The data is split into multiple lines as
    ; putting it on a single line does not work
    ; well on the Blogger platform as the text
    ; overflows the design boundary and looks ugly
    !byte $48, $45, $4c, $4c
    !byte $4f, $20, $57, $4f
    !byte $52, $4c, $44, 0
  

Now that looks better, and we're definitely not near the 30 lines supposed in the meme, more like 12 if the data bytes are written on a single line.

A few cautionary notes here. Firstly, whilst I am not using labels, they are very useful and make your development easier to manage, and allows any assembly program room to grow, as the labels will move as your code gets longer or shorter. I don't use them as the online assembler linked above gives me an instant disassembly of the program as I type it, so I am able to correct my assembly code as necessary. But for convenience, I have set the start of the code to $c000 (SYS 49152 as already mentioned), and the data to be stored from $c01b.

We have a much nicer example now, but there are still some things to improve: firstly, we have at least one line of unnecessary assembly: cmp #$00. This means we want to compare an absolute value (zero) with the current value in the Accumulator (A). Before this comparison we have loaded a value into A with lda $c01b,x. This is taking a byte from memory location $c01b offset by the current value of X. On our first iteration, this takes in the value $48, as the X register is zero, and therefore so is the offset. Our comparison is false, and the beq *+9 (branch if equals +9 bytes) does not happen. We then increment the X register with inx and jump back to the start of the loop with jmp $c004. And so the next iteration will load A from memory location $c01b offset by 1, and so on until X is 11 and our zero terminator condition is met. And once the condition is met, it branches 9 bytes ahead to the rts instruction, returning back to BASIC.

You may add more PETSCII bytes to the data block from $c01b as long as you don't have more than 255 bytes of data in the block including the zero terminator. For reference, the C64 character codes are here.

We are explicitly comparing the current memory contents to a zero value; in 6502 we don't need to do this. This is because when loading a value into the Accumulator, either directly, or by reading a memory address, it will set the zero flag if A happens to be zero. As the zero flag is set, we may do a $beq *+9 without the preceding cmp #$00 because a branch instruction will test against the zero flag unless you explicitly tell it not to. If our terminator had a value of 255 ($ff in hexadecimal), we would need to do a cmp #$ff statement before the branch instruction. By using an absolute value of zero as a terminator, we have saved one line of assembly, and two bytes.

This isn't the only improvement that we may make here; at the start of our example above, we load the Accumulator with an absolute value of zero (lda #$00), and then do the same with the X register. But to save another two bytes, we don't need to initialise A to zero; we only need to initialise the X register to zero as that is being used as our offset. As we have saved two byte, the jmp $c004 needs repointing as the start of the loop has moved up in memory by two byte. With these improvements, let's have a look at our new assembly listing.

* = $c000
    ldx #$00
    lda $c01b,x
    beq *+9
    jsr $ffd2
    inx
    jmp $c002
    rts
* = $c01b 
    !byte $48, $45, $4c, $4c
    !byte $4f, $20, $57, $4f
    !byte $52, $4c, $44, 0
  

Surely now we're done. The code itself is now pretty efficient. But we can still save one byte in our main loop. Remember that the zero flag is set if you write something to the Accumulator that equates to zero? The same principle applies to the X and Y registers. After we call the CHROUT routine with jsr $ffd2, we then increment the value in X with inx. The first time this happens, X will of course hold a value of 1, and we know that X will never be zero as we only have 12 data bytes including the terminator. This means that the zero flag is never set by the X register in our example, so we may use the branch instruction again instead of jmp $c002. It is only possible to branch 127 bytes back in your code, or 128 bytes forward in your code. Our code is small, and the loop beginning at $c002 will only be 9 bytes back from a branch if not equals instruction that we're adding. This saves one more byte from our code! Therefore, our rts line, to get us back to BASIC, is one byte lower in memory and the beq *+9 needs repointing too. Let's have a look at our final version with this optimisation:

* = $c000
    ldx #$00
    lda $c01b,x
    beq *+8
    jsr $ffd2
    inx
    bne *-9 ; We know that the zero flag
            ; is not set as we have incremented
            ; the X register by 1 and also we
            ; are not reading in 256 bytes of data.
            ; When the X register is 255 ($ff) and
            ; is incremented, it wraps around to
            ; zero. This same rules apply to
            ; the Y register.
    rts
* = $c01b 
    !byte $48, $45, $4c, $4c
    !byte $4f, $20, $57, $4f
    !byte $52, $4c, $44, 0
  

So there you go, we have a small and efficient hello world example in assembly, starting from a dumb example. I was going to go onto writing this to screen RAM at $0400 hexadecimal, or 1024 decimal, but this blog post is already long enough just covering the points that I wanted to, so I'll leave writing directly to the screen RAM for my next blogger update.

Thanks to Robin of 8 Bit Show and Tell mentioned above, and the other feedback I got from Mastodon. I received some very helpful comments about this blog post which has improved it. Note that we are able to make small and tight loops like this on the C64 with the CHROUT Kernal routine because this call preserves the Accumulator, X and Y values for us. Other Kernal calls may not do this, and will therefore require additional logic to track these values. But this is for a future blog. I've enjoyed re-acquainting myself with some 6502 again, and I'm glad it makes more sense now than it did the last time I looked at it.

If you don't want to wait for the next update, a really good C64 resource is available here, and there are plenty of 6502 resources just a few clicks away.

Sunday 4 December 2022

What advice would I give newer and junior developers?

Over 10 years ago, I began a career transfer from an adult support worker (or whatever that role is called now, a care assistant in old money) to one in Computer Science. I knew on beginning my Degree in Enterprise Computing, a programme that I attended thanks to Manchester Metropolitan University (MMU), that what I wanted to do with the rest of my life was software development. Through the course, I discovered that my two best classes were Programming, and Business Studies and management. My least favourite and consistently poor results fell into the Database and Structured Query Language (SQL) side of things.

Whilst I kept writing through University and beyond (exclusively through the pages of Micro Mart at that point), it became very obvious that in order to progress as a developer, [software development] had to be the main focus in my life, so writing became much less important to me. I had a good technical grounding in programming languages thanks to MMU but especially due to an unexpected almost full year at the University of Derby Games Programming course (this was due to Government funding cuts thanks to a certain coalition of chaos that I won't mention further).

At Derby I had covered a lot of C and Visual C++, some MIPs, Java for Android and some other languages. Being focused on entertainment rather than application software meant a whole lot more programming but no database theory, management or SQL. I did make the point that SQL will become more important even in the games programming world, something that at least one of my lecturers acknowledged. How else are you going to store all of that data for all of those online games?

Anyway, I started as an web application developer thanks to an Internship. After about one year, I had my first job proper at a company in Wolverhampton. I was taken on as a Junior Developer and as a content writer. Our primary technology was a LAMP sort of stack; that being Linux, Apache, MySql (or MariaDB) and PHP. We were running a version of Magento version 1.7.1, and had some front-end CSS compilers that apparently made front-end development more easier, though I've always thought that the benefits of something like SASS has very marginal benefits over straight CSS. That aside, in each new role I undertook from there, I learnt a lot. So what sort of advice would I give now to junior developers? Or someone inspiring to change career to become a developer?

The first thing I'd say is that there is never a bad time to learn something new. Although not everyone is suited for a role as a software developer, like not everyone can be a Nurse, nor a Doctor, if you have a logical mind and you are able to break down problems to small manageable chunks, and you don't mind learning how to debug then this could be for you.

But as a developer, what issues might you come across? I've found that being a developer is often quite different than programming alone. As a developer, you usually need to work collaboratively, and conform to certain standards and expectations. And whilst you should be given some slack as a junior, your work will still need to be maintainable and scale as necessary.

In my first job proper, the so-called senior developer made two critical mistakes that were even apparent to me after just over one year in the industry; firstly, the version of Magento that we were using was core hacked, meaning that we couldn't easily upgrade it.

My senior colleague developed a service that would produce JSON for pricing data; this data could move up and down every second based on current market prices. Whilst his service was perfectly good, and served the website well, I had developed an iPhone and Android application that was dependent on it.

Shortly after this application was released, he decided to change the API to deliver a different JSON structure. That would have been fine in other circumstances, but he made these changes without consulting anyone else, and whilst he was able to fix the website JavaScript charts that consumed it, he didn't inform me of the changes and therefore my application had been rendered useless. This happened during the last few weeks of my time there, and I had no way to update the application quickly or easily, and he didn't understand the application to fix it as some of it was Objective C and he refused to work outside of his conform zone which rapidly became the PHP framework Laravel.

As a developer, no matter how senior you think you are, or you become, do not make unilateral changes by yourself. Consult others first, especially those people in your team. And if you make a mistake, admit it. The sooner you do, the sooner it can be fixed. Other developers making unilateral changes has caught me out on other occasions too. One server change cost me well over 1 week of debugging because this change wasn't announced to anyone. This change was unnecessary and on a development server, although making such a change without agreement on a production server might have caused even more headaches!

My final piece of advice is to never assume that you know everything, and do not assume that just because you know something that everyone else in your team has that same knowledge. I've done presentations that I never expected to; one was why computers do not divide by zero, and another was about the difference between scalar values and objects. I have a small advantage over many of my younger colleagues in that I grew up programming, and many of the computer magazines that I'd buy growing up would be aimed at teaching children like myself computer programming too. So concepts like Integers and Boolean values, loops, branches and conditionals are kind of second nature to me even if the terminology may have changed. But even good people with good degrees may not have such a good grounding in programming principles even if they're perfectly good developers otherwise.

I've learnt a lot from my colleagues over the years too. As one of my lecturers once said to me, if you're not learning as a developer, you'll soon be obsolete.

Saturday 26 November 2022

BMC64 is free, so how much does it cost?

This sounds like a bit of a stupid question. How can something free cost any money? The reason that I ask this is because I was speaking on a Discord chat group recently and a common statement that people make is that the Bare Metal Commodore 64 (BMC64) emulator is a better thing than THEC64 and THEC64 Mini. Of course, such a solution that one could build oneself would be better in many ways. One could presumably customise all of the settings to enhance the user experience, including I assume choosing which SID chip to emulate, or even have two SID chips emulated, and so on. On THEC64 platform, one doesn't have nearly as much control, not without hacking anyway.

Another reason for BMC64 being better [than THEC64 platform] is that it is free. I was specifically thinking of BMC64 kits that one may purchase when I made the point that THEC64 has likely sold a lot more units than these kits. The counter argument was that BMC64 is just software that one could install on a Raspberry Pi, so it's free like a Linux operating system is free. But how much would one need to spend to use BMC64?

If you're reading this and you've already made an investment in a Raspberry Pi then you may stop reading here; BMC64 isn't going to cost you any more money than you've already spent. But what if you don't already own a Raspberry Pi, and want a dedicated piece of kit just for Commodore C64 software? Is THEC64 or Mini a good solution compared to something for free?

Well let's look at costings for a BMC64 solution first. Assuming that BMC64 will run on any Raspberry Pi currently available, you're probably looking at spending around £30 - £40 GBP for the cheapest Pi, which I assume has the lowest specification. So we'll say £30 with postage. And then of course you'll want a keyboard, so there's another £10 - £15. And if you don't mind playing games with a keyboard rather than a controller or joystick, that's it. It's then just the time it takes to set up. So, you're looking at spending between £40 and £55 for this option, and that's if you don't already have a spare USB keyboard lying around. That's good value, but it's certainly not costing £0.

Like for like, THEC64 Mini is currently for sale here in the UK via Game outlets for around £40, at least in my local store in the West Midlands. Okay, so you don't have a keyboard included with the Mini, but do have a controller. I know THEC64 Mini joystick isn't the best version, but it's still a fair comparison for the cheapest BMC64 option. Set up time for THEC64 Mini is usually no more than a few minutes, whereas BMC64 may vary depending on how much one wants to configure. THEC64 Mini does include 64 games to get started with, and all of these are licensed games. THEC64 Mini has a custom housing, fewer USB ports and no included PSU. It requires a 5V 1amp USB charger, which will be another £5 - £10. Both solutions allow you to add your own software, but THEC64 platform is limited to USB 2 flash drives formatted to FAT32, though this is more than adequate for C64 games.

THEC64 Mini is nicely packaged. I genuinely had a warm fuzzy feeling when I initially opened my first THEC64 Mini. The guys at Retro Games Ltd did a really good job with the industrial design and packaging. I won't have that same feeling opening the packaging for a Raspberry Pi, but this may be different for you.

The suggestion in the chat wasn't for this cheap option, but to consider a Raspberry Pi 4000, as that includes a keyboard and a mouse. This is currently around £100 in the UK. How does that compare to THEC64 Classic?

THEC64 is currently retailing in the UK for around £120, it is housed in a stylist casing which matches the size of the most common C64 casing in the UK, and includes a fully functioning and properly mapped keyboard with a joystick controller. Again, everything on THEC64 is fully licensed, and the bundled joystick is much better than the THEC64 Mini joystick. At £120, this isn't costing significantly more than a Pi 4000 solution.

So whilst one may save some money with a Raspberry Pi, is BMC64 a better solution? Well that depends on what you mean by better. THEC64 and Mini work out of the box, and THEC64 has a fully mapped keyboard with a pretty accurate casing, and both run at 50 or 60FPS like the original hardware (depending on your region or what you're used to), and with no sound drift nor frame skipping like on some emulators especially running on lower specification hardware. There is an issue on some modern displays if you specifically want a 50Hz refresh rate, but I assume that this will be the case for a Pi anyway.

Whilst THEC64 emulation is more limited than with a BMC64, those things that are missing [from THEC64] are very marginal use cases. For most people who just want to play games, THEC64 is pretty good. If you are a more serious user and more invested in the C64 platform then BMC64 is very likely a more suitable option. It isn't for everyone though, like Linux isn't for everyone either.

This reminds me of the arguments that people used to have (maybe still do) between Microsoft Windows and Linux.

Linux is free, and yet you still need to spend about the same money as a Windows-installed PC to run it. Also, I've never known anyone to actually pay for a copy of Windows by itself as this cost is usually included with the computer, and that cost isn't necessarily significantly cheaper without a Windows installation. And more serious computer users probably want to build their own system anyway, and make their own choices of operating systems and other software installations.

So I don't own a BMC64 (or any bare metal emulator) solution, and at this point spending some money to get one isn't for me. I have got to an age now were I want things to work out of the box, rather than using my time with various customisations and setting, and wasting my time with any trouble shooting for when things go wrong. I already did that in the 1990s and early to mid 2000s with my Commodore C64 and C128 and all of the Creative Micro Designs hardware that I was using.

THEC64, regardless of what faults that it may or may not have, works. It's actually well supported and has seen regular updates for it, though I suspect that v1.6.1 will be the last firmware update for THEC64 as the remaining missing features, such as using a custom Kernal or emulating more than one drive, are very marginal use cases that most people who want to play classic games won't care that much about. Again, your experiences may differ here. Maybe it's essential that you have a custom Kernal installed, or have two SID chips emulated, for instance.

On that note, I'm off to play a few games of the absolute classic Wizball, and ponder the meaning of life, the universe, and everything.

Sunday 20 November 2022

Noel's Retro Lab bench mark test - we have a new leader

Noel's Retro Lab is a popular YouTube Channel that discusses many computers and related hardware. One thing I like about this channel is the detail Noel goes in to especially when repairing 8 and 16-bit personal computers. He gives a good overview of the hardware, and usually runs a BASIC bench mark as a way to compare one machine to another. This bench mark program is as follows:


10 FOR i=1 TO 10
20 s=0
30 FOR j=1 TO 1000
40 s=s+j
50 NEXT j
60 PRINT ".";
70 NEXT i
80 PRINT s

Noel has been adding the results (in seconds) for each machine that he has run this program on, and many of his friends and followers have contributed to this. You may see system-by-system comparisons in a Google Sheet here.

Until today, the fastest system has been the ZX Specrum Next, though it needs to be running at 28Mhz, and use Integers rather than floating point variables. It completes in 5 seconds, and for a BASIC interpreter on a Z80 computer that is pretty quick.

As I'd set up my Commodore C128D-Cr again yesterday, which has a CMD SuperCPU, RAMLink, FD2000, a Commodore 1581 and an Ultimate 1541 II attached to it (or the U1541 II alternates with the RAMLink due to compatibility issues with the two devices) I decided to try the aforementioned bench mark symbolic listing to see the results on my power system. I first tried it in C128 80 columns mode, and found that it was faster than 5 seconds (at least with BASIC or FULL optimisation enabled) - so I'd need a reliable way to time it accurately.

All variants of Commodore 8-bit BASIC have a TI$ system variable. This will tell you the number of seconds since you switched your computer on (by default) and may be set to the current time in HHMMSS format. Related to this is the TI system variable, which counts the 60ths of a second since the computer was switched on (by default), and is reset if the TI$ system variable is set to midnight. So I did a typical thing for Commodore BASIC bench marking by adding the following BASIC lines:


0 TI$="000000"
80 PRINT S:PRINT"SECONDS"TI/60,"JIFFIES"TI

At its fastest, and in C128 BASIC 7 and 80 columns mode, the bench mark completed in about 3.2 seconds with either BASIC or FULL optimisation mode set. I therefore knew that C64 BASIC 2 would be faster than this.

You may see the results on my official Twitter feed, but a heads up: in C64 mode the fastest result is under 2 seconds.

I'm now going to try this same bench marking on my Ultimate 64 at 48Mhz. I expect that the results to be under 1 second. I may optimise the U64 further to see if I can get this bench mark to run in under half a second without optimising the BASIC listing.

One thing to note about bench marking is that you may get misleading results that may or may not fit your personal agenda. I saw a YouTube video on how the Turbo Chameleon [TC] is faster than the SuperCPU. And yet, at the time of writing at least, the TC doesn't have a Doom port. Not in its C64 emulation anyway.

Saturday 12 November 2022

Do younger video game enthusiasts get the Commodore C64?

One thing that has become apparent to me over the years is that Commodore C64 games, and entertainment software on other 8-bit home computer systems like the Sinclair ZX Spectrum, are often abstract and usually quite difficult. At least the ones worth playing fall into this category.

I first realised this some time when I started my University Degree in Enterprise Computing. I was in my early 30s and it was around 2009 or 2010. At the time, I was still writing my weekly column for Micro Mart magazine (published here in the UK by Dennis Publishing Ltd I think, and previously under the Trinity Mirror group). I was one of the oldest people on the course, though not the oldest, and my friend Peter, who is interested in media and a part-time radio host on a local station, had something of a curiosity in 1980s technologies. Though he was probably interested because of Nintendo's enduring name, and was also an avid Apple user then (probably still is), with the latter monolith tech company rumoured to have "invented the personal computer", which we all know is false. The first real personal computer, at least at a consumer level, was the Commodore PET, being by far the most usuable, stable and complete machine of 1977. Right?

Anyway, it was around this time that a truly great ZX Spectrum programmer Jonathan Smith aka Joffa Smiff, passed away. I had met Joffa and even somehow got an interview out of him for Micro Mart. He was an extreme introvert, and I found him to be a complete genius, and thoroughly nice chap. Unfortunately, he had suffered with his mental health and this, along with other factors, lead to his passing at just 43 years old (RIP Joffa). I spoke with his sister shortly after his passing to offer my condolences whilst writing his obituary.

I already knew of some of Joffa's work as he was developing a Spectrum game before his passing, and I had played some of his games in the 1980s and early 1990s. But I'd never played all of his games until then. I can honestly say that I've never seen such consistent quality from a single 1980s games developer. I don't think there was one game that I didn't like, and I still play Hyper Active to this day. But it was his first game, Pud Pud that got me thinking about this question: "how would I explain this game to my daughter?"

For those who don't know Pud Pud, you take control of a flying Christmas Pudding-alike creature which must eat other creatures (which ones you have to figure out yourself) and find 10 other puddings whilst avoid being kissed by the evil Mrs Pud. It's fair to say that this game is a little out there and pretty abstract though not to the level of some Jeff Minter games. I got the feeling that younger game players wouldn't get it; those who have been born into a digitally saturated world, with if not instant but pretty quick on demand digital assets at your fingertips. Many of today's games, especially for younger players, have tutorial modes and on-screen prompts. And waiting to load for more than a few seconds in this world is unusual and may often lead to younger people to grow quickly impatient. In fact a recent television advert has people destroying their wifi routers because everything has to be now, and that's okay in the 2020s. It also shows the throw-away society that we have become in my view.

Those of us who grew up with machines like the C64, we generally didn't have games in an instant. Games consoles would load in seconds, but most people in the 1980s - at least most people in the UK - opted for a home computer for their main entertainment system even if we conned our parents into the myth that "it'll help with School homework" - well in the long run it helped anyway.

Home computers might have been as expensive as an equivalent video games console, but games were usually much cheaper for computers. Doing a quick search the Internet tells me that Atari VCS-2600 games would cost around $30 USD or more, so if we assume that those same games wouldn't have been cheaper than £20 GPB, you could have purchased 10 individual C64 games on cassette for that, thanks to budget publishers like Mastertronics. Also, cassette games were much easier to copy, you only needed a blank cassette tape and a tape-to-tape hifi system.

Anyway, C64 games were limited by the times and technology. Very few games had the luxury of having explainers, so if you didn't read the manual first (and very few of us did) nor the game reviews in various popular publications of the day, you wouldn't necessarily know what you were supposed to do on your first few plays. Magazines would have hints and tips to games, but those were generally published monthly. So if you were stuck on a new game and none of your friends had worked it out either, you'd have to hope that the next issue of your favourite printed periodical would have some hints for you, in the form of hand-drawn maps, or even cheats such as POKEs that would modify the game code to provide for infinite lives, time or other cheats.

Why do I mention all of this? Well, after my recent overview THEC64 Collection 1 for the Evercade I found a video from an upcoming YouTube channel which had some pretty pejorative and I think unfair veiws on the collection. The reviewer starts out by stating that he never had a Commodore C64 and all of the games on the collection were new to him. Fair enough, but in this particular review, he ranked the game "Lee", which is actually "Bruce Lee" as 13th out of the 14 games, in other words one of the worst on the collection. More on this later.

To be fair, this guy is of a younger generation. For various reasons, even games that I wasn't good at back in the 1980s (which was most of them), I'd still replay again several times after my first try. Maybe there was something that I'd missed as I hardly ever read the manual for any software. Each binary game world was an exploration and sometimes I'd actually progress a little further. Even if that didn't happen, I could listen to the music, or wonder how the programmer made that happen inside a television screen. As I was a programmer first (albeit BASIC), seeing different game ideas was as fun to me as playing them. Also, I didn't have games on tap, I might only get one new game a month. Something less frequently. And loading times would be at least three minutes, or ages as I thought back then. So if I was going to wait for something to load, I wouldn't want to switch it off after my first go, would I?

All of this nuance, this exploration, having patience and so on, something that is in my gaming DNA if you like, tends to be lost on younger game players. This lack of patience likely started in the 1990s, when machines like the Amiga started to become more common, with its pretty fast disk loading and relatively good amount of storage per disk, and powerful processor with pre-emptive multi-tasking capabilities. But more so with consoles. Cartridges could not only allow for more instant loading, but meant the game could be as big as the developer or publisher wanted it to be. Activision was one of the first to make a game seemingly exceed the capabilities of the host hardware with Pitfall II for the Atari VCS-2600, and this certainly happened with many Nintendo titles on both the Famicom/NES and Super Famicom/SNES.

So back to Lee, how could this be the second worst game on this Evercade collection? Well, the reviewer in question made some assumptions because it isn't instantly obvious that this isn't just a beat-em up with some platforms to navigate, and some lanterns to collect. A lack of patience, lack of exploration, and no background reading, meant that he abandoned this game before even opening the trapdoor on the second screen in. He didn't see the expanding gameplay elements, increasing difficulty and puzzle elements to the plaforms and so on. The review doesn't get much better from there, and again I see the same issue repeated in each subsequent overview of each of the titles included. Things aren't always instantly obvious especially to someone with nearly no experience with the C64 or its entertainment software. Although it's not all bad, some extra play time and a bit of background research would have helped ranking the games more accurately, especially if you're not going to persist with exploration.

As the YouTube reviewer in question has a negative feeling towards THEC64 Collection 1 for the Evercade, it turned into a bit of a pile-on by either people who don't like the C64 platform, or (I suspect) those who don't have anything good to say about Retro Games Ltd, because in some parts, you are one of the Kool Kids if you hate RGL. Because reasons.

One of the commenters in the YouTube comments section even went as far to suggest that the 1988 release of Impossible Mission for the Sega Master System was better because it was made by a "professional software development house" that "streamlined" the gameplay. I don't have a problem with the suggestion that a Master System game is better than the C64 version that it is based upon. It's the implication that Epyx in 1984 wasn't a professional software development house. Epyx probably had some of the very best video games designers and developers in the whole world in 1984. By the end of 1984, Epyx had published around 20 games including Impossible Mission, Gateway to Apshai, Pitstop and Pitstop II. I can vouch for how good these games are, and I'm sure many people will agree with me on those four titles. Its not just that these are great titles, but in 1984, each game would have been amazing. Add in that the video games industry wasn't yet 10 years old if you count from the launch of the VCS-2600, and that the C64 was only just 2 years old with many of its secrets yet to be discovered. This guy may be a Sega fanboy, but possibly also one of the RGL haters.

Anyway, that's my rant over. But it's worth noting that if the C64 platform, or for that matter any other 8-bit platform, is unfamiliar to you then often the games worth playing are difficult, sometimes abstract and many times unforgiving. Some games are limited by the way that the tile mapping works, for instance, or the limitations of sprite multiplexing, and there are other quirks that you'll get used to. But if you have a bit of patience, and maybe do some exploration, or some background reading, it'll all be worth it. Probably.

Tuesday 8 November 2022

THEC64 Collection 1 for the Evercade

C64 gaming on the Evercade, finally...

I purchased an Evercade Handheld shortly after release, and whilst this console is pretty good, there hasn't been much for me personally. I do like the Atari 2600 and Lynx collections, though many of the 2600 games have been repackaged in various iterations over the years, and all of the good games still worth playing are available on several devices I own already. The only other enticing cartridge was the Oliver Twins collection, however the games featured seem to be from the Nintendo Entertainment System, a console that I never really owned nor have much time for. I would have preferred original ZX Spectrum games especially for those Dizzy titles, but I guess the graphics wouldn't have looked as good as those from Nintendo versions. An issue with games from 8-bit computers being played on consoles is that some of those will require reworking to accommodate the lack of a keyboard on the host hardware, which is why THEC64 Mini has a way of mapping keyboard inputs to a multi-button joystick, and an on-screen keyboard. These features have persisted though to later THEC64 classic models even though the classic edition has a properly mapped keyboard.

It perked my interest when I heard about THEC64 collection 1 pending release for the Evercade Handheld. This was announced just after the 40th anniversary of the original Commodore C64's launch to retail (it was launched in January 1982 in the same sense that the ZX Spectrum was launched in April 1982, though no one could buy either 8-bit computer at that time). At least it's retail launch in North America; most European consumers had to wait until 1983 to get their hands on Commodore's mainstay 8-bit machine.

Included in the 14 titles of this release are some well remembered classics, although when you have a back catalogue of at least 5,000 commercial titles, and many thousands of public domain releases, you'll never please everybody. And of course, with the C64 lasting so long commercially - 10 years in the UK if you count it's [UK] launch date - there are, to my mind, several eras for the technology during the 1980s and 1990s and people will remember those games by the releases around the time they first owned the C64. No one would forget their first game on such a machine, even if it wasn't very good.

Briefly, the games included on THEC64 Collection 1 for the Evercade are as follows:

  1. Alleykey, by Hewson, published in 1986;
  2. Battle Valley, by Rack It/Hewson in 1988;
  3. "Lee", by Datasoft, 1984 (more on this later);
  4. Gateway to Apshai, by Epyx, 1983;
  5. Impossible Mission, by Expy, 1984;
  6. Iridis Alpha, by Llamasoft, 1986;
  7. Jumpman, by Expy, 1983;
  8. Marauder, by Hewson, 1988;
  9. The Monster Movie Game, by Epyx, 1986;
  10. Street Sports Baseball, by Epyx, 1987;
  11. Stormlord, by Hewson, 1989;
  12. Subterranea, by Hewson, 1988;
  13. Summer Games, by Epyx, 1984, and
  14. Winter Games, by Epyx, 1985.

It's fair to say then that there's a good mix of early and mid-era C64 games from its first commercial era, before 16-bit platforms like the Commodore Amiga became established (at least in the UK and Germany anyway, North American users may have a different experience), and way before everyone wanted a games console for their main home entertainment system (again, this may differ for North American readers) rather than a personal or home computer. Early adopters of the C64 may well be drawn to Jumpman, or Lee (Bruce Lee), and even those who first got their Commodore later in the 1980s will recognise either Winter or Summer games. Hewson made its name with Paradroid, Uridium and Nebulus though sadly none of these classics are included. And Lee is interesting. Whilst this is version 2 of Bruce Lee, the rights to use the Bruce Lee name would have been either not possible, or prohibitively expensive, and may have made this sub-£20 cartridge well over £25, so it's credited to Psytronik Software and Code Digital, at least on the game art on the Evercade's carousel. It's definitely version 2 of Bruce Lee by Datasoft, something that you can discover by using the onscreen keyboard during play. I suspect Code Digital own the game code, and Psytronik Software did the cover art, and maybe made some code changes to the title screen so it reads "Lee" rather than "Bruce Lee™" - this, along with Impossible Mission and Gateway to Apshai are my favourites of the collection.

I mentioned the onscreen keyboard, this is available in any of the included games by pressing the Select button in game. And although the keyboard covers the game screen, it's not too distracting as it is either semi-opaque or completely opaque at your control. But it does mean that any future releases in this range will need to be carefully chosen, or require work to map any in-game key presses to the various buttons on the Evercade. But that does make me wonder what's happening in terms of the emulation. Is it using the same bespoke version of Vice that THEC64 range uses? If so, mapping the controller buttons is as easy as a simple text file - or a "Commodore Joystick Map" (CJM) in THEC64 speak.

The games in breif

Alleykat is a pacey vertically scrolling racer and shoot-em up which oozes Andrew Braybrook's class and pedigree, although I do find this game quite difficult and can never get very far into it. I'm sure with practise it can be beaten, and it's not a bad addition. My score: 7/10. Lemon 64 rating: 7.3/10

Alleykat Trivia: when run on the Commodore C128 in C64 mode, the game utilises some of the additional processing power available during the screen blanking, making for a faster game (it's difficult enough already though).

Battle Valley is a horizontally scrolling shoot-em up in which you take control of either an all-terrain tank or helicopter to destroy all enemy military installations and stop the launch of intermediate range nuclear missiles. It has some very nice graphics and excellent parallax scrolling effects. My score: 6.5/10. Lemon 64 rating: 7.1/10

"Lee" (Bruce Lee) is a game in which you must guide our hero through multiple locations in a screen-by-screen platformer with elements of a beat-em up, as you face two protagonists, the Green Yamo and a nifty Ninja. Collecting lanterns unlocks other areas of the game, which leads to a secret fortress protected by a powerful wizard. Once complete, the game loops and becomes more difficult, but it never becomes tiresome. A true classic in every sense. My score: 9/10. Lemon 64 rating: 8.7/10

Gateway to Aphsai is a multi-directional dungeon exploration game in which you must guide our hero to riches, find armaments and eliminate any roaming nasties found in those dank and eerie caverns, and if you get stuck, you may simply move onto the next level though sometimes at a cost, although the exploration of this game really is engrossing and skipping to the next level should generally be a last resort (for instance, when you have run out of keys to unlock other parts of the map). My score: 9.5/10. Lemon 64 rating: 8.2/10

If the C64 ever had a killer app then Impossible Mission would be a strong candidate. The infamous speech "Another visitor... stay a while. STAY FOREVER!" greets you, and from there, you must stop the Professor Elvin Atombender from obtaining US military secrets by infiltrating Atombender's underground silo in a screen-by-screen platform and puzzle game. There are multiple rooms to access and search, all connected by various elevators. Crack the puzzle and stop Atombenders malevolent plot for world annihilation! My score: 9.5/10. Lemon 64 rating: 8.7/10

Impossible Mission Trivia: In a review from a popular Commodore magazine, issue May 1987, it is stated that this game was originally released in 1983, whilst most sources state 1984. Side note: I always wondered why an evil genius would have candy machines in a secret underground bunker populated by robots.

Iridis Alpha is a well presented and somewhat psychedelic horizontally scrolling shoot-em up with two playing areas as each level has a mirror world. This game takes a while to learn and appreciate, so it's one where I recommend reading the game instructions, something that I never did as a child C64 owner. It may be off-putting to a new player, at least initially. But don't dismiss this too quickly, as some patients and a bit of background reading will help. My score: 7/10. Lemon 64 rating: 7.3/10

Another early C64 favourite is Jumpman which is a multi-level platform game with each level contained in a single screen. Simply traverse the ladders, platforms and ropes to collect tokens which affect certain aspects of the level as you go. To make things interesting, there are projectiles and other in-game objects such as robots to avoid. A note that this game requires the onscreen keyboard to start and to enter your name into the high score table. My score: 7/10. Lemon 64 rating: 8.4/10

Marauder is a well presented scrolling arcade shoot-em up in which you may fire lethal projectiles from your mobile battle car in one of eight directions. Your task is to infiltrate enemy territories, each well protected by various armaments and other leethal defences. My score: 7/10. Lemon 64 rating: 7.3/10

The Monster Movie Game does exactly what it says on the tin: you play an on-screen Monster in one of six Cities and various scenarios to enact for the viewing pleasure of the cinema audience. My score: 6.5/10. Lemon 64 rating: 7.3/10

Street Sport Baseball is a binary version of one of the most popular sports in North America, although it's simple enough for a non-Baseball fan to understand the rules of play, the computer player doesn't necessarily always provide the strongest of opponents. My score: 7/10. Lemon 64 rating: 7.3/10

Another polished and fun platform game in this collection is Stormlord, although I find this game very difficult. Explore the levels, find the keys, use the teleports and save the fairies. My score: 7.5/10. Lemon 64 rating: 7.3/10

Subterranea is a horizontally scrolling blaster with detailed graphics and silky smooth scrolling, though this is probably the weakest game of the collection. My rating: 5.5/10. Lemon 64 rating: 6.1/10

Summer Games is a mutliplayer sports simulator with a total of up to eight events to compete in, or each event may be practised until perfected. Although these events by themselves aren't at all bad, I find that the D-Pad controller on the Evercade does not allow for fluid play, especially on the joystick-busting events like the 100m Dash, although there's a mix of events where a D-Pad is just as well suited as a joystick. All events not being playable does reflect on my rating. My score: 6.5/10. Lemon 64 rating: 7.7/10

Unlike Summer Games, some of the events in Winter Games requires more precise and rhythmical joystick waggling, and the D-Pad is perfectly good for that. There are seven events to compete in, or to practise, my favourite being the Biathlon which has some beautiful Nordic-esque backdrops. My score: 7/10. Lemon 64 rating: 7.3/10

Overall, I think this first THEC64 cartridge is a very good value package with three real gems in the collection. Hopefully, this won't be the only release with C64 games for the Evercade, and with it being branded THEC64, and as I mentioned to earlier, I do wonder if this is running the bespoke Vice version found in THEC64 and Mini. I also hope that there will be a "THEVIC20" collection too? If there is to be a second release (no doubt Retro Games Ltd and those people paid royalties for their wares being included in this package will be keeping a keen eye on sales) then I hope it will include at least one or more recent C64 game such as anything from the Metal Warrior series. Now that would be awesome!