Recent Updates Page 3 Toggle Comment Threads | Keyboard Shortcuts

  • Jay Versluis 3:44 pm on April 18, 2018 Permalink | Reply
    Tags: , ,   

    Categories: Commodore ( 41 )   

    Flashing Border Colors on the Commodore 128 in Machine Language 

    In this screencast I’ll show you how to create the iconic flashing borders on Commodore machines. Back in the day, when the system was loading, this was a nice way to indicate that the computer is busy doing something rather than being dead. I’ll show you the principle both in BASIC and in Machine Language on the C128. The VIC-II chip is the same on the C64 though, so this will also work on the Commodore 64.

    The same approach can be used on the Plus/4, however the addresses for the border and background colours are different (decimal 65305, or hex $FF19).

    The VIC-20 is another story, as the border and background colour are changed using the same address (decimal 36879, or hex $900F). This link may help though: http://www.sleepingelephant.com/ipw-web/bulletin/bb/viewtopic.php?t=5905

    As always, enjoy 🙂

     
  • Jay Versluis 3:42 pm on April 17, 2018 Permalink | Reply
    Tags: , , ,   

    Categories: Commodore ( 41 )   

    Programmatic Loops in Commodore BASIC 

    In this screencast I’ll demonstrate how to use programmatic loops in Commodore BASIC.

    I’ll show you how to use the FOR/NEXT loop (available in all versions of Commodore BASIC), as well as the DO/WHILE loops (available on the Plus/4 and C128).

    Enjoy!

     
  • Jay Versluis 3:29 pm on April 16, 2018 Permalink | Reply
    Tags: , , ,   

    Categories: Commodore ( 41 )   

    Flow Control in Commodore BASIC 

    In this screencast I’ll explain the concept of Flow Control in Commodore BASIC. It’s kind of a video update of a post I did a while ago.

    In essence, it means that we can tell the programme to take a different route in the code depending on a condition that’s met. We’ll explore the IF/THEN and ON… GOTO/GOSUB statements (available on all versions of Commodore BASIC), as well as the expanded IF/THEN/ELSE version (available on the C128 and Plus/4 only).

    In addition, I’ll also show you how to use the BEGIN and BEND clauses that were introduced with the C128.

     
  • Jay Versluis 3:26 pm on April 16, 2018 Permalink | Reply
    Tags:   

    Categories: Commodore ( 41 ), Linux ( 101 ), Mac OS X ( 35 ), Screencast ( 87 )   

    How to run Commodore BASIC as a Scripting Language on macOS 

    Did you know you can run Commodore BASIC v2 on your Mac and Linux systems as a scripting language? It’s true – thanks to the marvellous efforts of Michael Steil and James Abbatiello. They’ve adapted the original BASIC v2 as featured on the VIC-20 and C64 with additional routines so that it works natively on modern machines. It’s ingenious!

    You can get the full source code on GitHub – it works a treat!

    For those who don’t quite know what to do with it, here are some instructions that’ll help you get CBM BASIC up and running on macOS.

    Download

    GitHub provides a convenient way to either clone a repository on your local machine if you have GitHub for Desktop installed, or you can download a ZIP file and unZIP it somewhere on your system. Once done, you should see a directory structure that looks exactly like the repo on GitHub.

    Compile

    You need a few utilities installed your your Mac to be able to compile files. Downloading Xcode will ptovide you with an excellent (and free) IDE as well as the command line tools needed to do that (gcc, make and several other goodies). You might be able to bring those components in using the Homebrew package manager.

    Using your Terminal app, navigate to your unZIPped folder. It includes a MAKEFILE so there’s no need to mess with any parameters. Enter “make” at the command prompt, and after a few moments you should have a file called “cbmbasic” without an extension in the same directory. That’s the binary for your Mac.

    To make it executable, we’ll have to tweak the file permissions – otherwise our operating system won’t be able to run it. We’ll do it using the chmod command:

    chmod +x ./cbmbasic

    You can test if it works by calling the binary without any parameters like this:

    ./cbmbasic

    If all goes well you should see something like this:

    For easy access, copy the binary over to your /usr/bin directory. That’s where common command line utilities are installed on Mac and Linux systems. The added benefit is that the path to that folder is already in your local $PATH variable, and as such you can simply type “cbmbasic” from any location when you’re on the command line.

    Here’s how to copy the binary over (this will ask for your administrator password):

    sudo cp ./cbmbasic /usr/bin

    Using Direct Mode

    When you run the binary it will bring up something like the standard BASIC command prompt we’re used to seeing on the Commodore 64. There are however a few important differences between a C64 emulator and this implementation:

    • this is NOT an emulator
    • cursor keys DO NOT work
    • all commands typed in must be CAPITALISED

    Other than that, you can start typing like on a real machine. Be careful with certain POKE commands though as those may call system routines that might not be implemented.

    LOAD and SAVE commands have been tweaked to reference the command line structure. They work just fine, but will load and save files in Commodore file format (which is not clear text ASCII – more on that later). For example:

    LOAD"$"
    
    LIST
    
    0 "/Users/versluis/Desktop/cbmbasic" 00 2A
    4    "."                PRG  
    2    ".."               PRG  
    2    ".git"             PRG  
    567  "cbmbasic"         PRG  
    7350 "cbmbasic.c"       PRG  
    593  "cbmbasic.o"       PRG  
    19   "cbmbasic.vcproj"  PRG  
    20   "console.c"        PRG  
    3    "console.h"        PRG  
    8    "console.o"        PRG  
    4    "glue.h"           PRG   
    1    "Makefile"         PRG  
    2    "Makefile.sun32"   PRG  
    3    "Makefile.win32"   PRG  
    27   "plugin.c"         PRG  
    
    ...
    
    READY.

    The above displays the directory of the current folder, much like it was an attached floppy drive. How cool is that? You can reference folders using both LOAD and SAVE just as if you were on the command line.

    You can also type in programmes and run them – however the cursor keys won’t work, so there’s no screen editing options. Programmes SAVEd from direct mode cannot be loaded from the command line, only from direct mode (i.e. when launching the binary without parameters).

    To quit direct mode, hit CTRL+C.

    Running Programmes from the Command Line

    The real power of this implementation can be seen when we run files from the command line. Those files must not be SAVEd from direct mode, but instead are simple clear text files. The extension doesn’t matter, but for good practice, let’s store them as .BAS files (much like shell scripts are stored with the.SH extension, or PHP files would be stored with the .PHP extension… you get the idea).

    You can write standard BASIC programmes use your favourite text editor (like vi from the command line), or try one from the “test” directory that’s provided with the repository.

    Imagine we had a file called “hello.bas” that we’ve created with vi, looking like this:

    10 PRINT "Hello World!"

    To run our file, we can simply define it behind the binary like this:

    cbmbasic hello.bas

    This will greet us with the “Hello World” message on the command line.

    Running Script Files

    Alternatively, we can specify the full path to cbmbasic at the beginning of a file (she-bang notation) and run it just like any other script file. Observe please:

    #!/usr/bin/cbmbasic
    10 PRINT “Hello World”
    20 PRINT “from CBM BASIC :-)”

    If the file was called “hello”, we’d need to change the permissions again so that the file can be executed:

    chmod +x ./hello

    Now we can run it like this:

     ./hello
    
    Hello World
    from CBM BASIC :-)

    Sweet – but I can’t work out how to compile this on macOS…

    Fear not – I’ve got a macOS binary that was compiled on 10.12 “Sierra”. You can find it in my fork of the project. Check out the “binaries” folder.

    Does it work on Windows? Or on Linux?

    I’ve tested compiling and running this puppy on CentOS 6 and 7 with roaring success. The above steps worked fine for it, so I’m assuming it’ll work on other Linux flavours just as well (the beauty of portable C code).

    According to the author, it works fine on Windows too – however I have no idea how to compile source code on Windows, so you’ll have to figure that out for yourself. I hear good things about Visual Studio  – if I work out how to do it, I’ll add it to the “binaries” folder on my GitHub Fork.

    Can I write my own extensions to BASIC?

    Apparently so – check our Michael’s site and repo for details:

    Right now, if you run SYS 1 from direct mode first, you can use the SYSTEM command (followed by anything you’d like to execute on the command line in “double quotes”) as well as LOCATE (followed by an x and y coordinate to place the text cursor) and WAIT.

    Have fun hacking BASIC and letting it run with the blistering speed of modern CPUs 🙂

     
  • Jay Versluis 7:22 pm on April 13, 2018 Permalink | Reply
    Tags: ,   

    Categories: Commodore ( 41 ), Screencast ( 87 )   

    Writing HELLO WORLD in Machine Language on the Commodore 128 

    The Commodore 128 has a built-in machine language monitor which makes it ideal for ML development. However, most (or pretty much all) documentation on this subject is geared towards the Commodore 64, making it slightly difficult to get a head start in writing ML code for the 128.

    Before I forget how to do it, here are a few pointers – courtesy of Jim Butterfield’s book “Machine Language – Expanded Edition”.

    Getting Started

    Let’s begin by typing MONITOR in C128 mode. It’ll take us to the machine language monitor. We’ll start our programme at $0B00. To begin assembling our code, we’ll type A 0B00 (A for Assemble), followed by these lines:

    LDX #$00
    LDA $0C10,X
    JSR $FFD2
    INX
    CPX #$2B
    BNE $0B02
    RTS

    The MONITOR will turn this text into the output you’ll see in the screenshot above (the lines starting with a . dot). Here’s what this code will do when called:

    First we’ll load the X register with a value of zero. We’ll use this register as a counter. In the next line we’ll load the accumulator with whatever is stored in address $0C10 plus whatever is stored in the X register. So if X has a value of zero, then the contents of $0C10 will be loaded. If X was 1, then the value in $0C11 would be loaded, and so forth.

    We’re using this as ASCII representation of our text (Hello World in a box in this case). With JSR $FFD2 we’ll call a Kernal routine that prints a single character onto the screen. Now we’re incrementing X by one and ask if it’s 45 yet (CPX #$2D). This would indicate that we’ve printed all the characters we need. If that’s not the case, we’ll return to line 2 and keep printing. Otherwise, we’ll stop the programme.

    Storing ASCII characters

    You’d think it was possible to simply type in text in the MONITOR. But of course that would be too easy. Instead we need to grab one of those massive tables and hack in each character’s ASCII code in hex. How convenient!

    Type M 0C10 (or whichever location in memory you’d like to store your text string at) and overtype the numbers at the start of the line, each one representing a single byte of our ASCII text. At the end of each line you’ll see what those characters look like when converted.

    In my case it’s a total of 45 characters, beginning with a return, followed by the top of the box, HELLO WORLD, and the bottom of the box.

    Running from the MONITOR

    To start the programme from the monitor, we’ll type G F0B00. We’ll end up with a SYNTAX ERROR and back on the BASIC screen though due to the RTS command at the end of the listing. If we replace it with a BRK command instead, we’ll end up back in the MONITOR.

    The important thing to remember is the five digit addressing mode on the C128 (i.e. G for GO, followed by F0B00). Our programme starts at $0B00 in memory, but to make it run properly we’ll have to specify which BANK it should be called from. Anything other than BANK 0 or BANK 1 is fine, otherwise we won’t reach the print routine at $FFD2. In my example I’m choosing F, but E would work fine too (as we’ll see in a moment).

    Running from BASIC

    Type X to exit the monitor and go back into the land of BASIC. First we’ll need to choose a BANK. We’ll have 16 to choose from (0 to 15), so perhaps let’s try BANK 15. Now we’ll need to type the start of our programme in decimal:

    BANK 15
    SYS 2816

    or we can use the DEC command to convert hex to decimal on the fly:

    BANK 15
    SYS DEC("0B00")

    Saving the programme

    From the MONITOR, we can save the programme using the S command. It needs to be followed by a name (in double quotes), followed by the drive number, memory start and memory end plus one byte – all separated by a comma. It’s probably easier to show than to write:

    S "HELLO WORLD",8,0B00,0C40

    We’re saving more bytes than strictly necessary here due to the large gap between our code and the beginning of the ASCII string. Our string could go up to $0C3F. The last byte in $0C40 is NOT saved to disk (or tape).

    We can do the same from BASIC using the BSAVE command (for Binary SAVE). The syntax is BSAVE “FILE NAME”, P1234 TO P5678. Sadly the DEC command doesn’t work inline with this command, which would make it extremely useful. We’ll have to convert the values into decimal manually instead.

    BSAVE "HELLO WORLD", P2816 TO P3136

    Loading the programme

    To bring our masterpiece back into the computer from the MONITOR, the L command works a treat:

    L "HELLO WORLD",8

    From BASIC we can load the programme the usual way, making sure we load it with ,DEVICE,1 at the end. This is to make sure it is loaded into the same memory it was saved from, rather than the start of BASIC:

    LOAD "HELLO WORLD",8,1

    Happy Assembling!

     
    • Iain 12:43 am on May 1, 2018 Permalink | Reply

      I always thought writing “hello world” would be that easy…

  • Jay Versluis 11:55 am on April 9, 2018 Permalink | Reply
    Tags:   

    Categories: Windows ( 22 )   

    Thoughts on Windows 10 Upgrade Error 0xc190020e 

    My first generation Surface Pro only has 64GB of space, roughly 20 of which I’m allowed to use (the rest of it is kind of forever “lost in cyberspace” – or so it seems). It’s been running all Windows 10 updates fine until a few months ago, when Windows kept bugging me that the latest security patches needed to be installed.

    I was happily running Version 1703 up to that point and never had an issue with space limitations or deferring updates. Until early 2018, when Microsoft started  aggressively forcing the Fall Creator’s Update down my throat.  (More …)

     
  • Jay Versluis 3:12 pm on April 5, 2018 Permalink | Reply
    Tags:   

    Categories: Commodore ( 41 )   

    Thoughts about the C64 Mini by Retro Games Ltd 

    In Europe, the brand new C64 Mini has just been released. Although I don’t have one myself, I’ve been following the Indiegogo campaign and have watched several “unboxing reviews” on YouTube. I must admit it’s a neat little machine, and I like the idea of somebody making the Commodore days available to a new generation of users.

    However, I can’t stop thinking “what’s the point of this exercise?”

    Don’t get me wrong, it’s not that I dislike the idea of Commodore BASIC making a re-appearence, or of new Commodore “herdware” being developed. Quite the opposite in fact.

    What I can’t understand is why the hardware needs to be built on an emulator rather than real hardware. Because we HAVE that already, and completely FREE at that. We therefore do not need exotic hardware that’ll quite probably be off the shelf in a matter years.

    I feel that it was different with the C64DTV project, with which Jeri Ellswoth reverse engineered the whole system using a new and combined chipset, basically building a new C64 wit modern components.

    The Mini on the other hand – at least as far as I know – is a down-stripped Linux box which runs a software emulator. It could emulate anything. I might as well run VICE on my modern (and replaceable when broken) laptop, plug in a USB controller and get the same result. For free.

    Why Mini?

    If a company goes through all the trouble to recreate the C64 with modern components, I feel they should recreate the whole thing rather than something we already have access to. If it’s all about “some output on the screen”, then an emulator output or dedicated hardware output are arguably the same. And I guess that’s what the Mini project is all about: plug-and-play screen output.

    But what I’d be more interested in is a fully reproduced piece of hardware, something to which I could solder homebrew stuff on the user port, or something I can plug in real floppy drives. I guess a fully recreated system is what I’m asking for, one that looks AND behaves exactly like the old breadbin. A system that lets me POKE a value and set a line on the cartridge port on high. That sort of thing.

    With that in mind, I can’t help but wonder who the target audience of the Mini is. Total geek enthusiasts (like me and thousands of others around the globe) won’t be happy with a compromise. So perhaps it’s newcomers who hadn’t been born when the real Commodore devices were around? I wager that they might not care about pixelated slow and way-too-hard-to-enjoy retro games. Who then is the Mini aimed at?

    Full-sized and Hand-held versions

    A full-sized authentic recreation, as announced in the original crowdfunding campaign, definitely YES. I’m looking forward to that. Likewise, I can see the appeal of a handheld pocket sized version that plays old-school C64 games. Love both of those ideas. Both of these were annouced in the campaign

    But the Mini? I just can’t see the point. If I want to play C64 games like back in the days, I might as well just play them on an emulator, or on authentic nostaliga hardware – with a fully working keyboard all.

    Another question I have is, how did it go from these two models to the Mini in the first place? Whose idea was it, and what was the reasoning behind it?

    Conclusion

    I’m not bemoaning the project, not at all. I just don’t quite understand why we have it, that’s all.

    I give Retro Games 10 out of 10 for the idea, and for seeing it through to release. But I can’t understand the concept of the Mini, or why it was produced at all (since it wasn’t part of the original idea behind this campaign). So only 5 out of 10 for that.

    I’m interested to see the full size version as well as the handheld version. But I can’t see myself buying a Mini at this point.

    Sorry 🙁

     
    • Mark Wilson 6:03 pm on April 5, 2018 Permalink | Reply

      “But what I’d be more interested in is a fully reproduced piece of hardware, something to which I could solder homebrew stuff on the user port, or something I can plug in real floppy drives. I guess a fully recreated system is what I’m asking for, one that looks AND behaves exactly like the old breadbin. A system that lets me POKE a value and set a line on the cartridge port on high. That sort of thing.”

      Sounds like you want the Ultimate 64, FPGA re-implementation of the C64 from the guy behind the awesome 1541 Ultimate 2… http://www.ultimate64.com

      However, the C64 Mini does look cute, and if they ever fix the god-awful joystick, I’ll probably buy one on that basis alone… ?

      • Jay Versluis 7:52 pm on April 5, 2018 Permalink | Reply

        Mark! Yowser! That is EXACTLY what I’m looking for – thank you so much for bringing this to my attention! And it’s described on Gideon’s FAQ section so much better than I could put it into words: it’s an implementation rather than an emulation, which is what attracted me to the C64DTV back then.

        Besides, I really like the price point of the Ultimate 64. I bought a couple of (sadly not working) original 64’s on eBay a few years ago, for about $40 each. Today people are asking close to $200 for an old C64 – that’s almost ludicrous. But at the same time it shows the demand that’s out there.

        Thank you so much for the tip – I’ll keep my eye on the Ultimate 64 🙂

  • Jay Versluis 12:10 am on April 2, 2018 Permalink | Reply
    Tags: , , ,   

    Categories: Commodore ( 41 )   

    How to print Numbers as Columns in Commodore BASIC 

    In this video I’m demonstrating how to print numbers in evenly spaced columns in Commodore BASIC.

    On the C128 and the Plus/4 we can use a nifty little function called PRINT USING for this, with which we can format the output of any printed text or variable.

    On the C64 and VIC-20 that function doesn’t exist, so we’ll have to convert a numeric value into a string (using the STR$ function), and then determine how long our string is. Following that we’ll have to manually pad our string value with as many spaces as are required. (More …)

     
  • Jay Versluis 10:17 am on April 1, 2018 Permalink | Reply
    Tags: , , ,   

    Categories: Commodore ( 41 )   

    Sorting an Array on the Commodore 64 

    In this video I’ll demonstrate how to sort a numeric array on the Commodore 64. The same principle works for string arrays, and of course on all other Commodore BASIC computers.

    The technique I’m using here is called Bubble Sort: in effect we’re comparing the first two items in the array, and if the left one is larger than the right one, the values are swapped around. This loop continues until all items in the array have been compared and sorted (hence the smallest items “bubble” to the front of the array, much like the smallest bubbles in a soda float to the top first).

    Here’s the full code I’m building, including the lottery portion. The Bubble Sort code starts in line 200.

    10 x=rnd(-ti)
    20 for i=1 to 6
    30 rn=int(rnd(1)*49)+1
    40 for j=1 to i
    50 if n(j)=rn then 30
    60 next j
    70 n(i)=rn
    80 next i
    100 print:gosub 200
    110 for i=1 to 6
    120 print n(i);
    130 next
    140 print
    199 goto 20
    200 rem bubble sort
    210 for i=5 to 1 step -1
    220 for j=1 to i
    230 x=n(j):y=n(j+1)
    240 if x>y then n(j)=y:n(j+1)=x
    250 next:next
    299 return

    I’ve explained how to build the lottery generator in this code here: https://wpguru.co.uk/2018/03/how-to-generate-lottery-numbers-on-the-commodore-64/

    Happy retro hacking!

     
  • Jay Versluis 12:39 pm on March 31, 2018 Permalink | Reply
    Tags: , ,   

    Categories: Commodore ( 41 ), Screencast ( 87 )   

    How to generate Lottery Numbers on the Commodore 64 

    In this video I’ll demonstrate how to draw random lottery numbers on a Commodore 64. The secret sauce here is not only the RND function to generate random numbers, but also two loops inside each other that prevent the same number from coming up more than once.

    Here’s the lottery generator code:

    10 x=rnd(-ti)
    20 for i=1 to 6
    30 rn=int(rnd(1)*49)+1
    40 for j=1 to i
    50 if n(j)=rn then 30
    60 next j
    70 n(i)=rn
    80 next i
    100 print
    110 for i=1 to 6
    120 print n(i);
    130 next
    140 print
    199 end

    To adapt this listing to match your local lottery, change line 20 to the amount of numbers to be drawn from your pool (6 in my example), and change the value in line 30 to match the size of your pool (49 in my example).

    Any questions, please let me know below.

    Happy retro hacking!

     
c
Compose new post
j
Next post/Next comment
k
Previous post/Previous comment
r
Reply
e
Edit
o
Show/Hide comments
t
Go to top
l
Go to login
h
Show/Hide help
shift + esc
Cancel