Early Specifications: (March 10th, 2019 Update)

Interesting project. It's nice to ask everyone's opinion about technical choices, but don't listen to them too much. Some people are just crazy here, they'd want 16 MB of RAM on a 16 bit CPU, they have no idea how ridiculous it is. 2MB is already huge, it's the size of a whole game of the 16-bit era accounting all assets, those machines had only 256K of RAM or something like that, and still could do wonders.

Less is more. Personnally, if I had to buy a retro computer, I would like it simple. No tons of IO, no upgradable parts, just a set of well documented specs/features that'd allow me to make software for it without the hassle of modern development (tons of different hardware, different OS, different browsers, tons of libs...). Also I think BASIC sucks (as much as floppy disks) and doesn't deserve your time making it better or faster, it's a beginner language and using it on CPUs with only a few Mhz doesn't make much sense...

I saw the 8-bit guy and some other people have dreams like yours, It's a pity that everyone keeps their personal projects instead of building something together. Everyone seems to have too much of a precise idea about what the device should be, ending up with disagreements with others, making the collaboration impossible.

Will we have a user definable TIMER INTERRUPT?

Dan

At least if we have a good memory map, and a few docs, we will have a good place to start. LDA $C5 is a lot easier for keyboard scanning than having to power up individually and scan each row....for an example.....and I never got involved with each line of the raster either.

Dan

Any KERNEL in this thing yet ?

No, I would not expect RR-Net or any other cartridge to work. You'd need to use a serial device plugged into the User port or the RS-232 port. The Foenix does have an industry-standard 9-pin RS-232 port and a User port that's mostly pin compatible with the Commodore User port. So you should be able to use things like WiFi or Ethernet modems in those two ports.

I anticipate that hardware designers will also eventually build devices for the Foenix's expansion port, potentially including adapters for C64 or C128 cartridges, but a 44 pin cartridge isn't going to work out of the box.

No Ethernet!? Will RR-Net cartridge work?

Based on the updated features, I think it will be very interesting if we can do something like pallette switching. I know we can handle 256 colors out of 16.7 Million color at any given time frame. Now, if we had not only 8bpp "color RAM" plus 1 KB of "screen RAM" that has 16 LUT (color Look Up Table) and 16 screen planes that can be called upon on a per character cell basis. This would actually give us 4096 possible screen colors. Each LUT would have 256 entries of 24-bit RGB values.

This is an idea... that's all. This way, we are hard-locked to 256 colors. We need efficient hardware approach to apply more colors that the 256 colors without having to modify the color look up table.

Regarding the SID, have the SID sockets like the C-One but design the C-256 mode to not depend on it as you have a new sound chip for people to exploit but SID can be something people can implement real ones for authentic C64 SID but you can also provide an option for EMULATED SID (FPGA SID implementation) while you have real ones that you can use like a stereo SID cartridge (with the real SID output feeding out to some audio connector. Have sockets with configuration ability to be fully compatible with BOTH 6581 and the 8580 chips. As in each socket can be independently configured for 6581 or 8580 via jumpers. The C-One had that in mind. It would be work on your part but technically doable.

BTW: The 65c816 is a 16 bit processor but it works in 8 bit data words for backward compatibility to 65c02/6502. This also made it more memory efficient because 8 bit data was not forced padded to 16 bit words. The TMS9900 was a 16 bit processor that actually used 16-bit data word. That's a different kind of beast, of course.

To the project developer, One suggestion for the extended cartridge port is to key a space between the 44-pin connector and an additional (in-line) connector for extended capabilities. The 'keyed' space would be to allow room for original C= cartridges to connect and special C256 cartridges being wider (kind of like the Vic-20 cartridges were). This wider cartridge form factor can have it's own benefits but the idea is so you don't need an adapter. Engineer the PCB layout so you can plugin either type of cartridges. Remember the long ISA slots that also had the separate VESA Local Bus. You can do something somewhat similar. All normal features in a 44-pin slot and you can add a 16-bit ISA-type (62+36) connector which would not need to be pin-compatible to old ISA because you can reverse the 62+36 connector so it would be inconvenient to people using actual ISA cards. We wouldn't want to use it for x86 ISA cards. Custom pinout design for C256 devices with backward compatibility to original C64/128 cartridges. This is an idea. Adapt, modify, or reject if you like but the idea is there for you to ponder about.

Thanks hlide, this is super intersting...

Speaking about SID, there is a new contender: armSID.

http://kompjut0r.blogspot.com/2018/04/sid-8580-vs-armsid-vs-swinsid-ultimate.html

http://kompjut0r.blogspot.com/2018/04/sid-8580-vs-armsid-vs-swinsid-ultimate_12.html

Hi Stef, all,

Great to see the interest, and the various suggestions from folks. As some others have said, this is your project, and you have the freedom, joy and burden of making it go exactly how you think is best. A few semi-random comments from what I have read:

1. You may be able to license the BASIC ROMs from, I think it is Cloantro.

2. I recommend using 800x600 video modes, as there are 50 and 60Hz versions, so you can do PAL and NTSC compatible modes, and they give you some border if you want it.

3. Let me know if you need an open-source floppy controller, as we already have one working on the MEGA65.

4. The memory size is really up to you, based on how you want the machine to feel. The MEGA65 has only 256KB of main memory (running at the 50MHz CPU clock), but has 8MB of expansion memory, and after that it is either cartridges or SD card. My personal feeling is that that is plenty, but of course with a 16-bit CPU and regular C compilers etc, it is all a bit different, and you might want to go for big memory, like on the SuperCPU.

5. Let me know if you want to make use of any of the VIC-IV implementation to kickstart progress on your VICKY.

6. For mouse, you can have ordinary C64 joystick ports, as there are plenty of USB mouse to Amiga (and thus C64) adapaters.

Anyway, keep having fun,

Paul.

@Stef: ok. Now I'm getting a little scared! :D

Hey Guys, if you could keep the conversation of software development in the Software section it would be great.

I don't have much time to really moderate the forum, but this thread begins to be very long.

So, try to post in the appropriate section. If a new section is needed, please advise!

Cheers

Well, I would not go as far as to say that it is a real 16bits, but close enough I guess...

Oh. So the 65816 is actually a 16Bit Processor? Hrmmm. :)

Yeah, I am in favor of a clean room implementation. With a little more room to work, I think it’s possible to significantly improve BASIC performance, especially with the inclusion of things like block I/O, block memory tranfer, and better variable handling.

As to 6502 assembly, check out Jim Butterfield’s “Machine Langage For The Commodore”. Since 65816 asm is derived from 6502, that is a place to start. And with a 128, you can enter assembly directly with MONITOR, but I recommend getting a real assembler, or using something like CBM PRG Studio on Windows.

The whole BASIC thing is a big can of worms... On one hand, I think it needs to be there in order to keep the same vibe that the other had before. On the other hand, I can't simply go on and use and improve the previous version because of copyrights Infrigment. Which means, that in reality we will have to come up with our own clean room version. The good thing about it, is that we will be able to make it use the full capacity of the C816 and add a ton of commands to support the hardware. The bad side is that it will take time to program it...

Oh and admin. I LOVE your Robin Hood-Like personality! Not wanting to rob a poor man like me of the pleasure of the torture of learning to program myself. >:\ :D

Ha! Went to 6502.org and found several web pages on programming the 6502. Now what about programming for Basic 10.xxx?

Took me a moment to navigate my way through to find the download but I got the Tool chain kit. This is kinda cool because I feel like I am catching the next wave of a computer industry. What's funny is...That you've given me a new lease on life. I'm 48, and have been disabled for a few years now. I have been unable to work and am now homeless because of it. I'd even started going through the anxiety of the midlife crisis in the last couple of weeks, not know where I was going to do in the future. Then while meandering around, desiring to do something with the Commodore 128, I happened upon this project from an ad about Stef being the 100,000th person on the site, and being interviewed.

Now, at the very early stages of this project, I am giving the chance to be involved with it. At the ground level. So I plan on taking this chance to help build the foundation for what should have been to begin with. The continued rise of Commodore!

Good morning tejekion,

I must admit, I really admire your enthusiasm.

Okay, I will give you my take this, maybe Wilson will come around and give its 2 cents.

I for one, I am all about getting in trouble and learn something. So, there is a gazillion books, examples on how to program the 6502. If you plan on writing a lot for the C256, I would suggest to download the WDC tool chain kit for the w65c816. Inside, there are examples, there is the compiler, simulator and something else I don't remember. On the web site they are also talking about a book for the c816 that was written by the creator(s).

Now, after you will have mastered the art of writing assembly you will have to write the IP stack for your wifi, which is he insane part here... I hope you have the low level registers definition for the chipset.

But, I would love to see that!

Let me know, if I can do more beside writing it myself... Although, I wouldn't want to rob you of that pleasure.

Cheers

@Stef: A ain't skurred. U play 2 Much! But there ain't nuttin wrong with that either! :D Now about this 6502 programming, are there any free books I can get to learn about it? I think a lot of things that I wanted to do with hardware, could possibly be done with software. For one the CMD-FD floppy drives can be emulated, as they are in most of the C64 emulators. And two, If I learn to make my own programs I will making a ton of it for this. I had started to learn programming, or at least software development for Amiga via the Icaros Desktop. But then got annoyed by the fact that I couldn't get the thing on the internet due to lack of drivers for my wifi adapter. with this, there ARE no wifi adapters, so I will get started on making drivers for some. Like I said before, I have a ton of ideas. It's just that now I have to start learning how to implement them.

Thanks. I'm looking at the toolchain now.

Yes, they have a simulator/debugger. So that's a place to start.

Oh crud. Now I need to learn 65816 assembler. O.O
Actually, that would be a good project. I could probably start by using the Commodore 64 Super CPU emulation in VICE. 
Do you have a 65816 virtual machine that you plan to use for firmware development? 

I am not quite sure what way should be the best for you to get going on this without having the real hardware. But, I feel that you will find what you need to achieve the goal, as far as I am concerned for the 65C816, I think you could get the Toolchain on the western design center website.

http://www.westerndesigncenter.com/wdc/tools.cfm

By the way, you have time, it doesn't have to be finished for tomorrow... You have till August! ;o)

Oh crud. Now I need to learn 65816 assembler. O.O

Actually, that would be a good project. I could probably start by using the Commodore 64 Super CPU emulation in VICE.

Do you have a 65816 virtual machine that you plan to use for firmware development?

Are you scared now tejekion? I am not going to poke you...

Listen, I believe that the C256 will have the necessary hardware for anybody who want to spend the time to get the machine to be like a C64. FPGA would need to be reprogrammed and code changed, but if somebody wants to get a C256 and do all these changes in the comfort of their own home and share with the entire community, I think it would be great. The funny part, is that I will put in place everything I can to make it happen. However, I for one, doesn't want to get involved in it, my deal is really to create a new computer with its own feature in hope that people will want to create software for it and maybe... Maybe, and it is far fetched, but I would like to think that at some point a new era of games could be created for it. Even, if it was just to get old games ported to it, it would be awesome!

Hey Stef. C64 emulation on this should be a snap. In fact, doesn't basic 10.0 support basic 2.0 commands?? Don't POKE me...I know nothing about programming OR design, just repair and operation. :\

Thanks wilsontp, I really appreciate the mention. I want to respect people's opinion, but I do expect people to understand that this is my vision...

By the way, did you mention that you are going to write a monitor for it? We will have to talk in private at some point, in a couple of weeks... Because, if you want, I will have a mission for you! If you so desire! ;o)

Thanks again for your support!

Cheers

S

Stef, it's your dream, and you're the one building this. Don't let anyone make you feel bad for sticking to your vision. :)

The 128's memory architecture is completely different; it uses bank switching to swap RAM and ROM in and out, and it's not actually possible to access all 128K of memory at the same time.

This design uses a 16-bit proccessor with a 24-bit memory bus, so it can access 16MB of memory without bank switching or other tricks. While the 6502 and 65816 instruction sets are related, and the 65816 can pretend to be a 6502, you're not going to ever run C128 software on this system without all of the C128 hardware that supports bank switching... and then there's the C128's awkward 80-colum video support....

As much as I loved my 128 at the time, I look at it now and think "what an awkward design." It never lived up to its potential, precisely because it was burdened with also being a C64. Personally, I'd rather see a new system be truly new, not be bogged down with legacy emulation.

It's diificult to say, if it is a text only and the software write directly to screen, but then do we go about collecting the keyboard's key input?

Do you have the source code for those BBS software, if you did you could modify them to work.

Yes, in theory it's going to be 80 columns.

S

No. No. No. I was just wondering if the C128 software would work on this. There are a lot of very good C128 BBSs out there that with the right system would do wonders. Not interested in Z80 or C64 compatibility. I think that will take care of itself. Just want to make sure that C128 software could take adavantage of the new platform, especially since this sounds like it's going to be more of an 80 column capable screen mode.

No plan for C128 compatibility support. There will be no Z80 in the system aside of you deciding to design a cartridge or expansion card for it. I am not trying to belittle the C128, but it was mainly used in C64 mode (I believe), and the C128 was a C64 on steroid which aside of his Z80 mode, leads us back to a C64. There are a gazillion ways to have a C64 these days. So, I doubt that having another version would help anything. I believe that the C64 compatibility is a double edge sword and honestly I am still on the fence about supporting any of it. Either the C256 stands on its own or it will crash and burn! ;o)

GUI would certainly be great for certain person I am sure. If someone wants to step in to program one, I will be more than happy to provide appropriate tools for them to succeed.

Listen, I would like to take that opportunity to mention, that I am not trying to be "douchy" when I oppose any type of improvement on the machine. I am only trying to stay on course with my initial mission and to stay true to the original vision.

Alright, enough said! Back to work!

Cheers

S

What about C128 compatibility. I very much would like to run C128 BBSs on this. Also will there be hard drive capability? Because a GUI desktop environment would be nice. And would also lend to my ability to run a nice BBS. There is also a guy on ebay that goes by Commander Kang. He is making clones for the CMD FD-2000 and FD-4000 floppy drives, as well as the CMD and Rear Admiral HDs. Would be nice if those worked with the C256. That would take care of the hard drive capability quicker as well.

If you build it, they will come... :)

It would be interesting to see something like the SPC700, in the SNES, where SID emulation could be a program ran on the chip. There is a SNES demo that played SID music.

Okay Guys, chill out about the memory... I hear you.

I will reconsider the basic amount in the system as I understand it could undermine the possibilities of creating interesting pieces of software. I get it.

Besides, there will be an expansion connector inside, so for anybody who wants to put a Gazillions Megs in it. They will be able to, as well as other devices, like a 2.5" IDE HD or Ethernet card if anybody bothers designing the hardware and software that goes along with it.

BTW, right now, I am just a single person and I can only do so much and honestly, I would rather release something sooner than later...

Cheers!

S

I'd honestly say that 512KB w/ a 1MB maximum expansion is a serious low-ball for 1987 spec. The IBM PC/AT (which launched in 1984) could do up to 16 MB; the Macintosh Plus (released in 1986) could do up to 4 MB; the Amiga 500 could do up to 9-- et al. With the processor chosen, I would seriously say allow for higher RAM amounts, even if you only put 512K by default.

If the GPU has dedicated memory, then fhe CPU doesn’t have to stop to let the GPU refresh the screen. The trick, for programmers, is to make sure you dont’t do video updates while the screen is being drawn. Raster interrupts, like fhe C64 had, can notify the programmer when the frame buffer is available for writing. Of course, this also gives the programmer the chance to do per-raster line tricks.

A system designed at the end of eighties would have:

* Dual playfield (two transparent overlapping screens). These would probably both be 16 colors each to save memory bandwidth.

* 320x240x256 graphics mode as well, more DMA time for sprites and blitter

* Some type of DMA driven sample playback capability

There should also be interrupts for screen raster line (and registers for reading current raster beam x and y coordinates) and a way to achieve clock cycle accurate synchronization with the raster beam.

It'd be very nice if there's also 8x8 character cell based screen modes. Those were useful for better performance in 2D-games.

It's your project and your itch to scratch but please reconsider the memory limits. The 65C816 is a full 16 bit CPU and I don't believe the designers of the time would have purposely limited the hardware like you're suggesting. In fact it's clear that they wouldn't have because they didn't do it with the Amiga 500 which released in 1987. The C128 dropped in '85 so a theoretical C256 would have been released somewhere around the time of the Amiga 500 and by then memory expansion was well established as thing.

More importantly if you want programmers, especially game programmers, to hop onto a proto 16 bit project you've got to give them some room to breath when creating code. From a games perspective I see the C256 as slotting in as not quite an Amiga 500 but much more than a C64.

I think you're essentially trying to build the Apple IIGS of the Commodore world which is very cool but if you unnecessarily restrict the system too much it will not take off as it should.

Thanks for including MIDI support!

Personally, I am not married to the SID. I could go either way on that, but adding a socket shouldn't be a huge burden. Since the SwinSID is out there, I don't see a reason not to included it. True, real SIDs will eventually be unobtainable, but we've got FGPA versions now, so that socket should still be useful. Including a YM chip will add a lot of 90's feel to the soundscape, and even a general MIDI synth should be easy enough to add in to the mix.

I'm also thinking about memory... I'd like to see this system just start with 16MB. I understand the whole "limitations are the soul of creativity" argument, but let's be honest - this system also needs to be capable of doing real work, and I don't see artificial limitations as exciting, just as frustrating. This system is, basically, a C64 with a SuperCPU... and the SuperCPU can handle up to 16MB of RAM. Let's use the full capabilities of the CPU rather than throttle developers needlessly.

Moving on - I like the idea of an IEC port for legacy data transfer, but I also definitely think we need USB host support - as well as USB device support. USB device support? I think this system should have a type B port that emulates two serial ports with an 11Mbps baud rate (equal to USB 1.1); this would allow direct communication with a PC or other system. Virtual Port 1 would be used for debugging and run the same monitor as from the console's MONITOR command, and the Virtual Port 2 would be a data channel to allow a PC or Raspberry Pi to act as a print and file server. This would allow the Feonix to send a standard set of print commands, and the connected PC would translate those commands to whatever printer is connected.

Keyboard and mouse - I think USB is really the only option these days. You can't buy a new PS2 anything anymore, so the system should support USB devices from the get-go.

Character set: Like the C128 VDU, the system should be able to display PETSCII graphics characters and lower case letters at the same time. Further, Code Page 437 ASCII (aka IBM Extended ASCII) should be supported. In PET ASCII, code 14 switches to text mode and 142 to Graphic mode. Add in 15 and 143 to switch to APETSCII and CP437 ASCII.

In APETSCII mode, character codes 32-127 represent the ASCII character set, including the _, |, \, `, ~, {, and } symbols. 128-255 contains the PETSCII glyphs. (I have worked up a chart that shows how the two can co-exist.) In APETSCII mode, it's even possible to add several missing glyphs: right and down arrows, top-half-shaded and right-half-shaded boxes, and the half and diagonal solid boxes that currently require reverse printing.

On that note, ditch reverse printing and use per-cell foreground and background colors. To reverse print, the user would simply select opposite colors. This also allows for the character generator ROM to cut the number of required symbols in half, allowing for upper-case, lower-case, and ASCII compatible symbols on the screen at the same time. A second set of glyphs should be provided for CP437 support.

Why support Code Page 437? This would allow easier porting of DOS games and applications.

Finally, disk and file access. I think the Feonix should stick with the CBM standard of LOAD "filename", [device], [location] convention, but with a twist: the internal hard drive should start out as the default device (ie: device 1), and if a different device number is used (eg: 8 or 9), then that should become the default until a reboot. This would allow programs to easily load overlays and data from the device used to launch the program. The use of hardcoded device IDs or path names in software should be discouraged.

I like the uIEC standard for accessing the file system and mounting images on FAT devices. Stick with that for simplicity and compatibility. Include the JiffyDOS DOS wedge commands in BASIC and the machine monitor, and it will be very easy to navigate disks. So with JiffyDOS and IEC syntax combined, we get:

@ gets the device status or issues a DOS command

@CD changes directories and mounts disk images.

@$ reads the directory

/ loads a BASIC program

% loads a machine language program

The SID has always been a point of contention because of its fandom. From my perspective I am only trying to recreate something that could have existed at the time. Back then there was a lot 6581 going around, so it is only natural that a C256 would have them.

Now, that being said, I would like to think that with a different environment and with more time, they would have improved upon it. Which will lead me Inoxarobly to replace the real SID with a more evolve version of them at some point...

The SID purists will probably have a fit if it does not have sockets for real SID chips but honestly they are expensive now and falling like flies. The 8580 was in fact closer to the original design spec than the 6581 was (but then folks learned to exploit the 'unintended' 6581 'features'.)

The original SwinSID was open source I believe but not the SwinSID ultimate. I also recently came across an open source Propeller SID, which is really a SID player but I don't think it would take much to actually use I/O pins similar to the real McCoy. They only used one cog for the SID so one could do stereo easily. The source is well commented and was easy to get an idea of what they were doing. http://obex.parallax.com/object/532 is the project. Of course you could do the same logic in your custom FPGA sound chip and give it a 'SID' mode.

I am happy that someone is running with this concept and the specs above sound perfect but still cutting edge for that era. I like that floppy usage is in the spec.