What will the Raspberry Pi bring to the C64?
Has anyone started anything yet?

You could couple it with a Keyrah and build it into the case of a C64 and have a real cool emulation computer for about $80 that runs VICE on the OS.

Iain
_________________

A fruity dessert?
_________________

Here's a neat article about the Raspberry Pi, drawing parallels between it and the Commodore 64.

http://www.thestar.com/busines...in-minutes


I'm planning on getting one after the furor dies down, but don't have any particular plans to integrate it with my C64 (or VIC for that matter).

Could there be any way to connect an x cable to it or something like that or nothing that isn't already just as cheap to do with existing hardware as it would require some of the more expensive c64 devices to connect to the Pi in the first place?

Hm it costs a fraction of the C-One. Then again, the comparison is silly because this is not a reconfigurable FPGA-based thingie.

I like the idea very much anyway. I'd also love to see more software built for modern devices people have anyway - mostly Macs and PCs - that reaches back to the philosophy of the "ready" prompt.

We have of course various interpreters, both professional like Matlab or Mathematica (shit expensive and real complex) and educational like various LOGO implementations (far too primitive)...
I'm thinking on the levels of a BASIC for the Mac that has an API included for the most important OS functions such as graphics, windowing, sound, etc.

Ironically the closest anyone got to this since Commodore went bankrupt was Microsoft with Visual Basic.

You know, it really pays to think about why certain good habits go out of fashion.

Like in the 1700s, a gentleman was EXPECTED to be able to play a musical instrument.
In the 1980s, a kid who liked computer games was expected to be able to code.

Some would say it's distraction.
Too many television and piped music around nowadays.
Too many computer games and FPSes and MMOs and shit around nowadays.

Bullcrap. There were plenty of great games back in the day as well. You could spend days at a time, skipping sleep playing c64 games.

Nah, it's ACCESSIBILITY. The c64 came with a book on BASIC programming. It was, in a way, a very esoteric thing, but people were interested in it and professionals were interested in sharing the knowledge. And of course, the computer started with a programming input.
And nowadays you don't explain programming to the 7 year old kid who is interested in how to use a computer. (I had a great mentor who did just that when I was 7. It worked.) You explain how to move the mouse to an icon and start Angry Birds.
Programming has become something reserved for engineers.

With music it was the same. Back then, it was normal to be able to play music. Lawyers could play music. Priests could play music. Mechants, shoemakers, doctors, all sorts of people could. Nowadays, many people feel that it's reserved for the pros, those who do it for a living. "Otherwise it's just not worth the effort" they say.

Many of us have become engineers because we loved to code. I guess today's kids will only start coding because they want to be computer engineers (because it pays well and it's easy to find a job).
(You become a pro musician because you love playing and are good at it - not the other way around, start playing because you want to be a pro...)

We need to tame our computers. Make them more user-friendly. As in, start with a label in large, friendly letters, saying "READY". Maybe we can also add "DON'T PANIC". It's good advice for coding as well.

@sigmoid. You make a very good point, what is expected behavior does change, (For some, I still open doors for ladies, and I still shave with a straight razor) I would have to disagree only slightly with the "in the 80's if you played games you were expected to be a coder", that is mostly true, because if you had a Computer to game you had to code, Accessibility was a part of it, but the majority of it is because we were forced to. There were not five million programs to accomplish the tasks we wanted or we knew we could do it better than the slap dash job someone who did not care about the program did. (I never became an engineer because I have always feared making what I love become a drudgery, something I MUST do to survive.) But I think it is best summed up by the quote attributed to Ronald Reagan: When a protesting student met with him and told him,"You do not know the stresses we grow up with, you did not have to grow up with computers and cell phones. With Microwave Ovens and VCR's" Mr. Reagan said, "You are right we did not have to grow up with them, we had to invent them." So I think back then it was more a matter of necessity that we coded rather than accessibility. But a good point all the same

Lite

In the end the thing to remember is that nobody is taking anything away, we're just adding to it.
So you can still build your PC from components, write your own kernel, tinker and experiment, hack and modify to your heart's content.
But in addition to that, normal people (i.e. your mom, grandma, etc.) can use a modern computer-like device and get something done, without having to understand the concept of hierarchical file systems.

I don't think people get interested in programming by being exposed to programming languages at the user interface level of a computer.
At least for me, I wanted to program computers long before I knew exactly what that was, and being to exposed to BASIC on the C64 didn't really help, for all I know it made me a worse programmer.

To get people interested in programming, all you have to do is make awesome software.

I've been on the Raspberry Pi forum a few times complaining that they need to come up with some sort of easy programming interface. I told them it didn't have to be BASIC (although that would be nice) but it needed to have a simple user interface that would keep people from having to learn how to use a complex IDE, included libraries, compilers, linkers, OS-specific functions, or API calls. Even if the language were C, Pascal, Basic, or Python, the idea should be that you open some programming screen where you can simply start entering code, then press a button to execute that code. It should be as simple as that. I think we'd get a huge rush of new programmers if it were that easy.

I think SDL BASIC could probably fit that need, but I think it hasn't been updated in quite some time. I wrote some games in it a few years back and it only took me a few minutes to learn how to code in it and write some games that actually worked pretty darned fast even on a 400 Mhz PII.

I actually found something that really goes along these lines.

The BASIC! app for iOS. It's lovely. It provides a similar, hands-on terminal interface as the c64, and instead of just being a closed playground, it provides access to the most important iOS api calls!
Lovely! You can see how much work went into it.

http://itunes.apple.com/us/app/basic!/id362411238?mt=8

As for becoming a worse programmer from learning BASIC, come on, that is clearly not true. Yes, as an engineer I hate coders with a passion who do not understand OO and structure. I wouldn't vouch for a new hire who didn't have his design patterns down solid.

But under all that, the CPU does in fact work with bloody GOTOs. If someone wants to get into ASM, then I can't think of a reason why NOT to learn BASIC.
And even if the Neumannian model gets obsoleted with time, it is a very simple concept that a 6 year old can learn at the same time as he learns to read, write and count. Structured programming and OOP requires a more mature approach, I wouldn't start teaching a kid under 12-13 about them.

Cool. I am sure there are plenty of these home made things for a quicker path into programming. I really wanted to experiment with a C64 alike setting where the programming didnt require a compile and all, where you could experiment to results much like the C64 Basic, but at the same time have some of the powers of a modern computer.

So I set out some simple requirements/limitations, both to get started with a specification of some "virtual machine" and limit it somewhat just because I wanted a retro feel to it. Perhaps silly for some but I didnt plan to use this to make fancy 3d shooters or anything. I wanted a plain and simple 2d graphics programming / playground based on java, a language I have been using for the past 10 years and love. So here are some of the specs:

- 800x480 resolution wide screen format
- Tile based monospaced 16x16 pixel font by default (50x30 char screen)
- Layers of these tile screens, each with individual scrolling abilities
- Colored painting, simple to set text color, but also direct color copy
- Alpha channel - PNG based tilesets
- Sprites also based from these tilesets for simplicity
- Background color, gradient or image
- Direct pixel access to layers if needed
- Simple scrolling using an extra row/column of tiles on the sides
- No API objects - yes, all available methods are available as core commands
- Simple built in file system for saving, loading and quicklaunching
- Code Java directly in console without line numbers!
- Trimmed down Java a bit to reduce clutter
- Simple sound API, multiple channels, waveform editor

These are just some of the points I had in mind. I really wanted to keep it down to earth, plain and simple, and named the project after a term I often like to use - its called jKiss - Java Keep It Simple and Stupid.

Its not meant for programming a bank infrastructure, its meant for making quick games or whatever other fun you can have with it. Immediately available and allows for experimentation.

Moreover I'd like to be able to make a Linux boot memory stick where it boots directly into this and you have a "new retro computer".

Here is a sample screenshot also showing an optional grid overlay and some commands:



This image demonstrates a number of small things. You can write any command on the fly as the JKAPI is always available. You can write programs by starting lines with a colon and omit curly braces to indicate scope as the scope is automatically created for you depending on indentation (each space = 1 indentation/scope). So the println is in the scope under the for loop. Additionally semicolon is optional unless you want to put several instructions on the same line. It also stops at any coding error when you run it and shows you the line for quick editing. All JKAPI methods are lower case as well for simplicity.

What happens behind the scenes is actually that when you type run, the code is converted into a valid Java program based on the simple rules of indentation for scope, and compiled on the fly using the JDK. Then a class loader is instanciated that will load the newly compiled class and run it with access to the "core desktop". So it runs at full speed as well!

Atm the code runs in an immediate mode, and it inserts some test in loops to see if you want to break it, absolutely essential as you can easily create endless loops here that locks up the whole system. - I also have a framework that is typical for games, an update and paint where you place code into these, reading the current input state (which keys are pressed and mouse position and clicks) updating your game model, and then a paint method for going over your model for painting. But generally you can do that in the update too as the system has state info for all sprites etc much like the C64. Using the update system the program will get 60 frames per second vblank synched to avoid tearing (but I still have to profile performance to make sure its possible, maybe dropping to 30 fps if necessary).

An important choice I still think about is the in place editor. You can list a program and edit lines like the C64, pressing enter to commit. I am considering that its auto commited as you edit and that an enter works like a break to new line just like a normal text editor as that is what most people are more used to now. It would also simplify the process of inserting code lines as well. When functions are supported you will be able to do a flist to list the functions and expand any you want by standing on the function and press enter (you can also close a function like that). Or you can list an individual funciton by giving its name behind list. I also plan on adding a number of autocomplete features so you can press TAB to expand for e.g. load and list. It is important that its very accessible to edit any part of the code.

Here is another sample using another charset that is 32x32:



This one shows the creation of another screen layer (1, layer zero is the bottom where the "OS" output is). It clears the screen using character 0 which is a blank in this case. After the init, the "current screen output" is set to this one, so any operation is done on that layer. So we position the cursor and print out some floor board characters. We then create a sprite which we get an id for that is used for the commands later, position it and show it. After that we just move it across the screen with some 5ms waits between frames (remember this is immediate mode, no update framework function used here).

After this I have pressed Alt-1 which enables me to switch to layer 1 and type on that layer just as I can on the "OS" layer. But here I have a different charset so I draw characters (parts of a wall). The cursor is also bigger here since its a 32x32 layer. (I will later swap the grid layer to show the grid of the layer you are currently on). Its very fun and immediate - you can prototype your graphics on-screen like this and I can very easily make e.g. charscreen dumps that can be loaded as needed with a single command.

The system also has convenience methods for drawing vertical strips (used for e.g. smooth scrolling) as well as tiled blocks (when you e.g. want to draw 2x2 chars blocks). I wanted to make it simple and stupid really, having these things accessible using the same "patterns" as we all know.

So there it is. In its current state. I still have some work to do on the editor as well as the function system and update framework. I would love to see this run on something like a R-Pi platform as it would be cool to have a community of people making games and sharing them using a simple programming "OS" like this one.
_________________

I just want to use it as a disk drive.

Which is exactly why I went with plain Java as the language for my little project, no line numbers or goto's. Java functions does the trick. But at the same time I want to keep it simple so no multiple files with classes all over the place. Its meant for the programmer to contain it all in one "program". Inheritance, encapsulation, interfaces, public/private, and all that is nice if you are writing a banking application, but for the typical hobby "pacman clone" I dont want to encourage that kind of programming in jKiss.

As for the editor, the idea was that when you wrote list it worked a bit like the old more pipe in dos where it stops when you reaches the end of the screen and you can advance the listing by a page at a time or even one line steps using the arrow keys. I thought perhaps even to have some smart behaviour where if it senses a line of code on the bottom line a scroll down using the arrow keys will pop up the next line in the code. Likewise I can do it the other way too, upwards, so in essence it becomes a full editor inplace in the same area as the console. I really want to keep it simple and stupid.

My main challenge is how to get graphical assets into it, I will need to make a charmap editor command that lets a user handpaint the sprite and charactersets. Hopefully integrated with the console as well in some way. But I guess I could also support importing images from a USB stick as I would like the whole thing to work completely as the "OS" of a Linux box. Naturally when running it in Windows or any other window manager (like I do now) you have full access to add whatever assets you want (which is what I do now with free graphics found on the web).

Anyway, its just a fun little project. I guess my next step would be to make e.g. a pacman clone with it.
_________________