Software Creation Golden Rules...

@stef thank you very much for the detailed answer! I hope someone in the future could run the forum for you, so that you don't get bombarded with questions (like mine...) that you'll have to answer :) The price point seems right which, I won't lie, is a nice surprise :)

@Drogon by mechanical keyboard I meant a standard off the shelf keyboard that I could hack into a self printed enclosure and solder internally XD I'm kinda old so I have weird requirements :p I once did a design for an ATX PC case that "pretends" to be a home micro-computer. Please don't laugh hard!

I completely get the implications in terms of cost and so forth. But I mean if you're going to buy a retro hobby computer anyway....

And I would fully expect the keyboard layout to be about the same as the standard PC keyboard layout that everyone is familiar with nowadays. I'd leave off the numeric keypad to save on cost and size since I seldom use it. The insert, home, page up/down, delete, and end keys could double as programmable function keys, with the regular function keys, print screen, scroll lock, and pause/break keys being omitted as well.

A suitable compromise might be to offer an all-in-one case and etched circuit board for the keyboard, and let the user worry about key caps and whatever color of switches he wants to use.

A built-in mechanical switch keyboard (not some mushy rubbery chiclet keyboard) would totally sell it!

Hi, new to the forum here and I just learnt about this project which seems like the ideal retro-computer!

Some thoughts/questions:

1. Are there plans for a C compiler?

2. The idea of booting into BASIC is vital imho. As hated as it is (which I find odd) it was the #1 reason for tons of people to get into programming and then move on to more "serious" languages. It's also a big plus for the vibe.

3. If it isn't too early to ask, how could someone get a hold of a board in the future? Any price approximation?

4. It's really nice of you having the case 3D-printed and not going for a moulded, set-in-stone design. That would allow anyone to have his own design. I, for example, would like to enclose a mechanical keyboard and the PCB in a single case.

P.S. anyone having difficulties navigating the forum? It's super slow on my end.

In 1987...

We had BBC Basic and the Acorn MOS (Machine operating system) in 1982 running on a 6502 with 32KB of RAM. BBC Basic was the fastest (interpreted) BASIC of it's time, supported some structured programming and named procedures and functions with local variables and recursion. (also 32-bit integers) It was a 16K BASIC, but on-top of that was the MOS which was another 12K. The MOS did the screen, keyboard and sound handling and defined the filesystem interface too. Everything went via a vector table, so any user code or another ROM (the BBC Micro stacked ROMs, switching one out and another in, as required) could take over a vector and provide e.g. a filing system with no changes to your programs.

So let's not hang back on an old fashioned BASIC just because "1987". That's 10 years after the Apple I, 9 after the Apple II, 8 after Visicalc, Apple Logo/Pascal and 5 years after the BBC Micro and a whole host of other languages - let 'er rip :-)

-Gordon

(FWIW: I did write what I consider to by my "perfect" BASIC some 6-7 years ago and still update it from time to time, however it was written with Linux in-mind and all in C - I am considering a port/re-write to the 6502 but who knows. I do like BASIC it has to be said - if you want an example of what it looks like then: https://unicorn.drogon.net/wumpus.rtb )

The fact that BASIC is interpreted is what makes it more suitable to boot into than a monitor, actually. If you're not running a GUI, then you're booting into a command line shell. The BASIC environment served as the command shell for vintage home computers that weren't running a full OS.

Hi, new to this forum. Great project idea, I've been following for a while.

Re: system software it's worth pointing out that the source for a number of 6502 and 65816 operating systems is now out there. GEOS has been fully reverse engineered and is here: https://github.com/mist64/geos From my understanding GEOS was built to have a somewhat pluggable platform abstraction, and was ported to the Apple II back in the day. So it may not be a huge effort to port it to the C256. It could really take advantage of the C256's higher resolution graphics and speed.

There was also a Unix-like operating system for the Apple IIgs called GNO/ME that is open source. But it's written in C, which is not really a great language for the 02/816.

I might be interested in working on GEOS for the C256. Could be a fun project.

I'll be looking to implement a likely extended (full) ANSI 1977-1980 Fortran (Fortran 77). The slight extension for direct POKE and PEEK. Other than that.... it would be Fortran. Forth implementations were already around for C64 with CP/M cartridge. YES, we could have CP/M via cartridge. Nevada Fortran had an implementation of POKE and PEEK. I would probably approach it similarly but what is important on a C256 type system with the 65c816 is the addressing mode of the system. POKE and PEEK (and variants) for EACH addressing mode of the 65c816.

Let me remind people that the problem with BASIC being slow was because it was interpreted. By 1983, there was already a BASIC compiler which compiled BASIC programs into P-code or outright ML. P-code can be thought as being sort of equivalent to Java byte code. It was a little faster when it converted to ML but not as fast as if it compiled to ML. BASIC compilers existed by 1985 that allowed full BASIC to ML compiling. Even the ones that compiled to P-Code (Speedcode) could speed up BASIC programs on the order of a magnitude increase and then some. With a few hand crafted improvements to some of your routines in hand crafted ML, you could really kick it up some while still writing most of the game in high level language. We had Fortran and Pascal and other languages which your wrote a source code in a text editor (source code editor) and then compiled it.

My first programming was on TI-99/4A. I have the PEB and FOUR TI-99/4A computers. BASIC on TI was horribly SLOW. Even when the CPU was like 3.5 MHz or something like that. This was because BASIC was interpreting to this "GPL" which then had to be interpreted again to ML. Double interpreting slowed down BASIC a lot. ML ran quite fast especially if you learned the optimize the cache. TI-99/4A had this 256 byte 'cache' called scratch pad memory. The only real 16-bit SRAM memory accessible directly by the TMS9900 CPU. If we had somehow increased that to 16KB or even 64KB or even 128KB (64 K-Words), then have the 16KB to 64KB or more 8-bit DRAM.... the TI-99/4A would have really shined its capabilities especially up against the IBM PC.

My first computer and also where I got my first taste of programming was for the Texas Instruments TI/994A with the optional speech synthesizer. Good old Parsec was my favorite game I played followed by Hunt the Wumpus. I think the first program I wrote (well let's be honest here, I copied from my book, was a BASIC program to calculate my weight on the different planets of the Solar System. I missed the whole Commodore era (excepts for at my friends house) as I went from my TI to 8088 based computers. I'll have some catching up to do to learn the programming techniques of these older systems! Having a version of BASIC being supported upon boot wouldn't be a bad thing, plus it gives you an easy environment right there immediately. I don't plan on going back and writing much in BASIC, that's not what I want to learn from this project, but others might. Ok, well I'll probably write a program to calculate my weight on different planets in the Sol....... haha, anyways how BASIC is presented doesn't really matter to me in the scheme of things.

Nah, Tom. What you describe is not what I called patching with some pokes... for instance, to get a 2400 baud or more instead of 1200 baud is just patching a byte in an instruction of an *internal* function hopefully in RAM to change the delay, not to rewrite all the functions necessary to load a tape because you need to reroute that BIOS function. But, nevermind, I was just expressing my opinion that having a particular programming language set as *mandatory* in a ROM is not a good move. I had bought a C64 which has a faulty BASIC ROM and wasn't able to do anything, which I consider as something totally stupid. I can understand at the Comodore time, they considered BASIC in ROM like most manufacturers and because they have no fast storage to load a BASIC in RAM. But again, add your BASIC in ROM but don't make it mandatory to run when booting (what should be mandatory are KERNAL and IPL or DOS).

@hlide

All of the things you're describing are possible with the inclusion of a jump table in Direct page RAM. You can patch the operating system with additional functions or even replace existing functions by adding your own code in RAM, then modifying the jump table entry to point to your code.

There's also a standardized syntax for OS calls on CP/M and DOS that I'm considering how to include. In CP/M, OS calls all go through address 5, so you'd do something like this:

LDX #function

LDA #parameter

JSR 5

The code at 5 would actually jump to the OS call, so user programs don't need to know or care where the real OS routine lives. Since there's some setup needed to actually make the OS cal (storing the current program bank and data registers, for example), a technique like this, rather than the C64's jump tables, will be necessary.

** update: I'm considering a new system that would allow for dynamic linking, using symbols, rather than addresses. Stay tuned over in software development.

hlide,

Yes, the Boot ROM will be the Kernal(el) + Monitor + An Extended version of Basic with new commands that will use all the magnificent feature of the unit. ;o)

There will be an empty socket inside for anybody who wants to add and customize their boot experience.

As for the USB connectivity... Well, in the early planning, I mentioned that there would be a USB port (Serial Connectivity) for development. That idea still holds, what possibility could change is that I might implement it a bit differently.

Early on, my strategy is to enable developer by giving them the tools they will ease their work and this is the purpose of the USB(Serial) connectivity to the PC to connect with the tool-chain with a small app; but I also want to limit the usage of this link, because in reality... It is not suppose to be there...

Anyway, we will see...

Cheers

S

Well, it's true with 16 MB, there's enough place. My reasonning is BASIC was a poor and cheap solution for programming in basic way. I was constantly frustrated when trying to program a game because it was so slow. I prefer to start with a MONITOR ROM and enter BASIC *ONLY* if I want to do so: if BASIC ROM fails, it shouldn't prevent the C256 to work (it would even be great if we can replace by something else indiviually). At the time of MZ-80 series, a lot of languages were available and loadable through either tape or floppy-disk (there was also Quick-Disk - 8s to read all the 128 KB). Keep your BASIC but be smarter as not being totally dependent upon it. One example I had: tape loading/saving with BASIC was 1200 baud. It was easy to patch BASIC through some POKEs to allow loading/saving with BASIC in 2400 baud. There are numerous cases were the ability to patch the BASIC allowed some improvements. Recently, I made an Arduino-based tape player for my MZ-700 with a broken tape player: I was able to patch so it can read a tape program as four times as fast - and there is also an ultrafats version not relying on the standard SHARP PWM system to make the retro-computer to read at its full speed (using WRITE signal to handshake Arduino to send the next bit).

If your KERNAL ROM contains a BIOS *AND* a full monitor including assembler/disassembler, I guess it is a very good point.

By the way, I have a C64 Reloaded MK2. The ability to have several images for KERNAL, BASIC, CGROM or custom image (à la cardtridge?) and be able to upload them through USB Serial using a PC terminal is really great. Would it be something equivalent?

I learned to program with BASIC on a Commodore VIC-20. I don't think I would have become so interested in computers so quickly if my first PC had been something with nothing but a machine monitor and no built in programming language. Quite frankly, I think the biggest thing turning kids off from programming today is the lack of such a simple stepping stone.

If your only argument is that the BASIC ROM will use a few kilobytes of memory, please review the specifications. There's 16MB of address space available with the 85816 CPU, and there's plenty of room for a 64KB OS ROM, which would include BASIC and BIOS functions (also called the KERNAL on Commodore computers.)

hlide, I know where you are coming from. But keep in mind that assembly language is still to this day a skill that very few people master. Back in the 80s nobody knew how to program save few privileged one ( I am talking in general with any programming language). BASIC was the entry point for clueless people to get into programming, I mean LOGO could have a been a choice, but lets pretend that BASIC was a good way to get people interested.

Could you imagine the Commodore64 starting up with assembly language monitor instead of BASIC?

BASIC was never my forte either because it was so slow, but even if it is far from being the perfect choice, it is certainly still a good starting point considering that I want to keep the same feel and experience that of a C64 or C128.

The C256 will have its local assembly monitor and even more.

Besides, the memory size is not a problem anymore because the address space is bigger but also because the C816 can tell you if it is going to fetch data or code. That way you can have ROM and RAM at the same location and it is going to work fine, unless you are trying to fetch data from your ROM...

Cheers

S

My very first computer was a SHARP MZ-80 K (48KB RAM, 4KB MONITOR ROM, 1KB VRAM and 2KB CGROM) : there was no BASIC in ROM, only a MONITOR ROM. That's way, if you wanted to load a machine language file, you have all the RAM available. If you want BASIC, just load it (around 14KB). The good part is that you can improve the BASIC or use other languages (FORTH, FORTRAN, PASCAL or even ASSEMBLER) instead. There were even BASIC compilers. I don't understand why we need to place a BASIC in ROM (not a clean way to do so and less room for RAM in a 64KB max environment). Personnaly, I hate BASIC. I would prefer to use a C compiler. That said, why not put the BASIC somewhere else and let the machine load it in RAM *ONLY* if asked through the MONITOR ROM?

Tejekion, I am glad that things are moving along for you, maybe the enthusiasm for the project sent good vibration in the Universe! Who knows! I hope you can find sometime to do what you set out to do with the console when it is available. Keep me posted!

Well. Like Stef. I am fixing to have to move for a job I may be getting. Fed up with the homeless shelter I am volunteering at. I mean, I have a place to stay right now, but fortunately, the job I'm going to will give me my own apartment, AND decent pay. Not too much, but at least my apartment will only cost me $200, and that's with utilities included. So my learning to program for the C256, may become somewhat limited. However, since I started writing this, 5 jobs across 3 states have contacted me about interest in giving me a job. So I may not have to move nearly as far as I thought I would before. The first job that contacted me is 600 miles from my current location. The last one that contacted me is about 50 miles away. Then of course, the place where I'm volunteering at is going to hate losing their free IT support, customer service and transporter. Especially since they keep pissing me off, refusing to pay me for mileage while giving people rides, and being two faced in how they treat me, as opposed to the way I'm told I'm supposed to treat the women in the shelter.

The big thing was with the 128 was the microprocessor was a MOS 8502 with a 2mhZ option. Since the VIC-II chip was not designed to

handle 2mhZ speed, it was turned off when the fast command was used. Also when you turned on the 128 the Z80A chip was in

control for the boot process; once the process was completed it switched to the 8502 (explains the short delay when booting).\\

Fun Fact:

Bil Herd and his team designed and developed the C128 on a DEC PDP-10 mini computer!

Honestly, I don't know. I just had an extremely hard time with it. I bought, and briefly had my C128 for one reason, To do C128 things. I guess I suffered from a brain freeze or something. I should have done what I am doing now for this, learned 6502 programming.

Why was the 128 hard to learn? Everything that applied to the 64 also worked on the 128, just with bonus items (like DLOAD and CATALOG)

I would agree to this wholeheartedly, with one exception. The C128 was a pain in the rear for me to learn. It still is. GEOS 128 would have been a saving grace for me had a C128 been available for me to buy in 1992, when I bought my Amiga 500. Once I got a taste of Amiga Workbench, there was little looking back for me as far as CLI went. Sure I used it when necessary on the Amiga, but it just didn't make sense to go with CLI. Kinda the problem that Linux has now. For some reason though, CLI on the C64 is no problem for me. Of course I primarily used the C64 for 10+ years before going Amiga. I maybe had a C128 for 3 months since getting my first C64 in 1985. It was a lot easier to use than the C128 emulator is on WinVICE. I guess that's why I was wanting to get one. But since I'll have to learn something new anyway, I will wait and Learn Basic 10 on The C256.

Actually, Quick BASIC was first released in 1985. :) It was the second programming language I picked up on the DOS, right after Borland Turbo C++. (I had a C programming class at the time, which was why I bought an XT system.)

Since CBM BASIC was hideously slow, I'd like to think that some of Microsoft's advances in the BASIC programming language would have filtered back to a Commodore 16-bit machine. If I was writing a BASIC interpreter in 1987, with more than 8K of ROM to work with, I'd certainly have done some work to increase performance. :)

You're certainly right about CP/M. I want to say that the last commercially produced computer to run CP/M was the Kaypro 10, which was canceled in 1984. Past that point, anyone that wasn't doing some re-imagined Mac-style desktop was building DOS machines.

As to what Commodore would have sold in a 1987 machine, we can turn to what came with the 64C at that time: GEOS was the big attraction, with word processing, desktop publishing, and financial software being developed for the GEOS desktop. Unfortunatley, 64K of RAM just isn't enough for what GEOS was being asked to do, so we really never got the robust GEOS ecosystem people were hoping to see. Still, it's likely that if the Amiga hadn't come along, we'd have some sort of a GUI on any new CBM machines.

Still - I do agree that the good old fashioned BASIC boot screen is more attractive to 8-bit afficionados, and it's a staple of the era: if it didn't run CP/M or DOS, every 8-bit computer of the time had some similar sort of startup screen.