ohi! I got a buncha original game ideas I've been wanting to make for a retro system. I know C++ (done a bit of SDL/OpenGL stuff) and all that but I wanted to get my feet wet with assembler on something.

I've always dreamed of writing a game for a new old styled system and I'd love to be a part of the C256 project as a game developer. I want to write a simple arcade game for starters.

Derek

@Bradsco,

Yes, absolutely! I will. Please come around once in while to see how things goes. Maybe at some point, you will feel that it is going to be time to get involved more.

Thanks for the interests!

Cheers

Stefany

Add me to the list for game development. I have many original designs and would love to produce one for this project.

However, the ML Monitor itself (in JamaicaMON) is public domain by the author. As Jim Butterfield did with SuperMon, Stephen L. Judd did with JamaicaMon as JamaicaMon is a derivative work by Stephen Judd of the public domain work of Jim Butterfield by porting it to 65c816. As public domain, it is even more permissive than any license because the author gave permission to do with it however you want by voluntarily waiving/forfeiting the copyright protection. Ethically, it is just appropriate to give credit or recognition for their work upon doing anything with the work.

Then I read this:

About The Fridge

Just think about the millions of lines of code that have been written for the 64: code for doing everything imaginable. And yet, most of it is lost forever. Therefore most programmers have to continually rewrite things from scratch -- instead of blazing forwards in a really nice car the community is caught up in a wasteful excercise of continually reinventing the wheel.

Hence The Fridge. Entropy does not favor low temeratures. The goal is to have a large base of source code and technical resources such as C=Hacking which programmers may draw upon for their own projects.

If you have some source code you think would be of interest to the C= programming community, please send it on over (in ASCII format!). The Fridge is maintined by the C= community, for the C= community, so make the most of it!

-------------------------------------------------

This basically says:

"The goal is to have a large base of source code and technical resources such as C=Hacking which programmers may draw upon for their own projects."

In short, "draw upon the source code and technical resources and utilize it in your own projects". In practice, the Commodore community does projects like this is essentially implied in a BSD/Apache/MIT license or like free permissive like public domain. The goal is these programs are FREE AS IN COST NOTHING, DO WHATEVER WITH IT... often it's literally PUBLIC DOMAIN especially as it has been employed in C=Hacking and other resources on the "Fridge" portion of FFD2.COM. I'll have to track down any references through the years to clarify things but one thing that was traditionally understood is copyrights do not apply to common routines but applies to a collective composition of works as a whole. A routine to change the border color is not copyrightable in and of itself since it is just a Load and Store ML function to a memory location used by VIC-II memory mapped registers and they have to be used by every program that changes the border color. Just like you can copyright common words. You can claim a copyright a unique work of authorship.

It is also distributed in multiple Commodore websites. I don't think Stephen Judd would have posted the source code in the Fridge section of his website which it is implied in plain English for people to use in their own programs, if he didn't want people to use it. The Fridge was set up literally so people don't have to reinvent the wheel. If you incorporate it, I would recommend referencing Stephen Judd's work and if possible, add to it and reference your contribution to evolving the assembler/monitor and porting it.

JamaicaMON component which is also available in standalone is explicitly stated as public domain in the documentation and source code. No license is required.

In the meantime, we can effectively rely on the "implied license" doctrine in the implied meaning as written expression has set forth which the U.S. does recognize. In legal findings, the quoted part above in larger print would infer an implied consent to use the source codes of programs in the FRIDGE portion of FFD2.com site by Stephen L. Judd. Stephen Judd has through pattern of conduct with the Fridge, expression on an implied intent inferred for people to use the source codes made available by him in that part of his site. Therefore, an implied license which has existing legal recognition in the U.S. intellectual property judicial cases. While Mr. Judd does not explicitly state a license in the codes, there is essentially an implied license inferred.

Legal references:

http://www.constructionlawyerblog.com/2014/08/implied-copyright-license.html

https://digitalcommons.law.scu.edu/cgi/viewcontent.cgi?article=1470&context=chtlj

While there is not an explicitly expressed contractual license given to every work, there is a general implied license due to certain informal expression of an intent for the source code to be used by people in their work. It borderlines an expressed licensed (albeit very informal) and an implied license which expresses an implied intent and permission to use the source.

Yeah, that makes for a huge problem when licensing source code. Fortunately, there are at least two working 65816 assemblers that have a known pedigree, and we won't have to resort to using software that we can't license.

My biggest challenge in contacting Stephen Judd has been that he hasn't been seen in like 15 years.

http://www.ffd2.com/fridge/ As it was put into the "Fridge" and the whole resource is there for an implied purpose. To share source code so that people aren't reinventing the wheel. Therefore, all the resource is there so that one doesn't have to reinvent the wheel. The culture of ethics has been to acknowledge (like when you quote someone in a book via citation) the work you borrow from as he did with acknowledging Jim Butterfield do likewise for him.

Quote:

About The Fridge

Just think about the millions of lines of code that have been written for the 64: code for doing everything imaginable. And yet, most of it is lost forever. Therefore most programmers have to continually rewrite things from scratch -- instead of blazing forwards in a really nice car the community is caught up in a wasteful excercise of continually reinventing the wheel.

Hence The Fridge. Entropy does not favor low temeratures. The goal is to have a large base of source code and technical resources such as C=Hacking which programmers may draw upon for their own projects.

If you have some source code you think would be of interest to the C= programming community, please send it on over (in ASCII format!). The Fridge is maintined by the C= community, for the C= community, so make the most of it!

-----

Well, I have to say, if we can get a monitor and an assembler all in one go, that would be fantastic. The biggest part of the porting would then be just changing the I/O code to handle the Foenix's hardware. I'm going to be a little busy this week getting ready for a show this weekend, but I'll be able to dig into this more next week.

Thanks, guys.

I will try to contact Stephen Judd for clarification on licensing of Sirius as that is more than just an ML Monitor but an assembler with a text editor for source code.

Tom: Go here: http://www.ffd2.com/fridge/

Sirius Assembler with JamaicaMON (Jammon): http://www.ffd2.com/fridge/sirius/

JamaicaMON itself: http://www.ffd2.com/fridge/jammon/ ( This one was declared public domain by the author ).

JamaicaMON is more clear about the 'license" as Public Domain. Read this: ( http://www.ffd2.com/fridge/jammon/jammon.docs ) at the bottom: "This program is in the public domain." It was a derivative of SuperMON that was made by and released into public domain by Jim Butterfield. This derivative was redone for 65c816 processor's instruction set (as it was for the SuperCPU) instead of the 6502, 6510, 75xx, and 85xx CPUs.

Tom, jamaicaMON is a SuperCPU monitor. It was evolved from SuperMON by having the 65c816 instruction set which by the way contains 65c02 instruction set which by the way is a CMOS 6502 without the "illegal opcodes" found in NMOS 6502, 6510, and 8502. There is a program also provided for called Sirius which is an Assembler and ML Monitor (uses JamaicaMON). That is why I mentioned it. I referenced them earlier. I was specific in choosing assemblers & ML Monitors for 65c816 processor. This is why I mentioned it.

Tejekion, if you're starting from scratch, do what I did as an 11 year old. Get the VIC-20 programmer's manual and use the VIC-20 emulator in VICE. The VIC-20 programmer's manual is probably the best book on beginning programming I've ever seen. I'm not kidding.

After that, pick up the Commodore 64 guide, the Commodore 64 Programmer's Reference Guide, and James Butterfield's Machine Language for the Commodore 64. Butterfield is a legend, and his books are very approachable.

Once you get through those, you'll understand the basics of BASIC and assembly language. Then you can hit the 65186 manual I linked to above; it's written by the guys who developed the CPU.

Hrmm. I wondering if programming from old C64 mags in VICE would help me out any. I mean, that's what I was doing in the 80's, and I actually learned a little bit.

Man, I just wished someone could sit down with me and point me in the right direction to even start. I've downloaded several programs that seem like each of them SHOULD be all I need to write programs for at least a SCPU equipped C64, but I don't even know how to get to where I start actually writing the program. Would be easier for a programmer to hire me as the conceptionalist, or idea guy(Visionary?) and make or convert the programs for me. :(

Hey guys.

Wow, I can't believe I didn't see this thread until Stef gave me the heads up.

So on the ML monitor, it wasn't my intent to start with a programming tool (like Supermon), but rather a system configuration and bootstrap utility. The most important thing at the beginning of a hardware project is having a way to talk to the CPU, talk to memory, and get data in from an extermal source. My original idea was to get just enough code running to communicate with a PC via serial port and be able to upload Hex files with code assembled on the PC.

RE JamaicaMON and others: I'm not interested in trying to port a 6502 assembler forward. Like porting CP/M software to MS-DOS, it could be made to work, but it would require as much effort as building it anew, especially as I've got API and data structures in mind that simply didn't exist in the 8-bit days.

However, I'd love to see that Super CPU monitor. That may be just the ticket to jump start this thing, assuming it has a permissive license.

On that note, have you guys checked out CBM PRG Studio yet? It can assemble native SuperCPU programs, and I've already done some preliminary work in validating that as a tool for this project; with the built in assembler and simulator, you can write code and test algorithms very quickly.

Finally, I am going to throw out a book suggestion: Programming the 65816: Including the 6502, 65C02, and 65802, by David Eyes and Ron Lichty. It's free on Kindle Unlimited or around $10 as a purchase.

Writing an ML monitor from scratch isn't easy stuff especially with a decent assembler with it's own "editor". If he knows 65c816 and the SuperCPU info, I think it won't be very hard to make the modifications to the code to run on this machine. The cpu architecture is basically the same. You just don't have to check some register if you have SuperRAM present for the megabytes of RAM. You just have to STA or STX or STY (with the appropriate addressing mode) to the memory locations up to the 3 or 4 MB limit or so that you set for the system. The rest of the work will depend on the KERNAL work. It would be some coordination with the KERNAL / OS / DOS work that is made. It is doable if we don't muck up the layout of memory mapped registers for the chips TOO much. At least the video, and I/O chips should be mapped close enough to how it is on the C64 in bank $00. The traditional SIDs be mapped where it would be on a C64 either with traditional SID locations or like a SID cart or something. Since things like the Commodore Serial bus routines for using drives like the 1541 to that of SD2IEC can be used as peripherals. Otherwise we would have to rewrite a bit of the software involving loading and saving to disk drives. If you have traditional VIC-II registers, it would be great for them to be located in the normal areas. If we take the C64DTV for example, by Jeri Ellsworth, she manages to keep substantial compatibility while providing new video modes.

Hey Richard,

I passed on the link to this post to Tom since he didn't post in the Thread. I guess he will make the decision since he's the one who elected to make a monitor in the first place. Maybe you ought to chat with him... ;o)

Thanks a lot for the information!

Cheers!

Stefany

One option is to use Sirius by Stephen L. Judd, an expanded assembler & ML Monitor (ML Monitor is a the 4.1 version of JamaicaMON). Source was provided freely in an open-source sense so I'd suggest treating it like BSD or other licensed where you retain credit to the source. I'll see if I can track him down on it.

http://www.ffd2.com/fridge/sirius/

As for Tom making an ML monitor. Maybe we can start him off with the source code for JamaicaMON by Stephen L. Judd. Tom could modify as he needs to for this platform but this is an idea. It's based on SuperMON by the legendary Jim Butterfield. There is also an assembler as well that I have a source code for which was originally made for SuperCPU equipped C64 so a few modifications and we be ready to go. This would give him a starting point so we aren't completely reinventing the wheel but modifying. There is a few things that would need to be done in modification. 1) Remove routines that checks for SuperCPU and SuperCPU configuration/registers stuff mapped in memory or detection / enabling routines for SuperRAM as you would have a 65c816 as the main CPU and no need to have a 6510 in RAM or having to check if SuperRAM is present because you'll always have 4 MB present (3+1 based on specifications). In this case, some of that can be trimmed because you'll be able to boot right away.

Also, he may need to modify any instructions that are 6510 specific. But all or most legal opcodes should work the same or close to it between the 6502, 6510, 65c02 and 65c816. I think all the instructions are 65c816 compatible from initial execution point of the program because the SuperCPU (which uses a 20 MHz 65c816) would be enabled and running the ML Monitor & Assembler program.

This would be a starting point. If Tom wants, he could make it a little prettier but it doesn't need to be fancy or super pretty but usable and aesthetically clean and usable for long hours of coding.

I got the source code for JamaicaMon. I'll look at it for modifications as needed for being able to boot on this system. If you can make sure you can get a working Kernal/DOS so a simple LOAD"*",8,1 and RUN works from any number of Commodore serial bus peripherals would be a start.

Anyone who actually did write computer video games and applications, tools, etc. for the Commodore 8 bit platform would be bes because Unity is a 3d video game engine that simulates 2d games. In practice, it would be more challenging to port a game even on Unity to C64 due to the graphics are not really 2d. I've worked in this before. My experience goes back nearly 30 years with TI-99/4A, C64, C128, Plus/4, Apple II, IIc, IIe, IIgs, Amiga (Motorola 68K based systems), Atari 8-bit (namely the Atari 800), and later systems.

I've worked with Unity and UE4. Also I worked with basic GCC tools using the AmigaAnywhere and AmigaAnywhere v2 SDK (API with a basic compiler tool chain), Java, Visual Basic, Forth, and other computer languages. Preferably, I would think an ML Monitor or assembler (like the one on the IIgs) and port it would be good. If we could modify Turbo Macro Pro Assembler with a full 65c816 instruction set, it would be great to have so when someone wants to code they can code right on the system. We'll need tools like these ported with extensions for this platform: ( http://codebase64.org/doku.php?id=tools:start ) as there are differences in the 65c816 instruction set from that of the 6510. There would also be differences in the VICKY to that of the VIC-II, obviously.

There would need to be tools for the sound chip to be ported from platforms with the sound chip in mind. These are some thoughts I have in mind. Some of these tools will probably work as is with minimal modifications in the port but they will only be able to capture the systems capabilities to a limited degree as they would be on a C64.

I'd use TMPx if we add the 65c816 as a CPU target and C256 as a system target for cross platform development. Alternatively, XA65 - ( https://www.floodgap.com/retrotech/xa/ ) or WLA DX ( http://www.villehelin.com/wla.html ). I don't mind the WDC tools but it's easier to program when the assembler has the platform covered but then having an assembler / ML Monitor for native development and already built to support the systems DOS would be nicer. If we can make at least a port of the ML monitor of the IIgs with appropriate modifications, that would be a starting point for native ML programming. This would be a good tool to port or one be made like it so it's there. Until there is adequate C256 emulators to test, it would be necessary to have a functional native development platforms.

It doesn't need to be fancy but it needs the instruction set and access to the memory range.

Modify this ( JamaicaMon V2.2 SCPU ): http://commodore.software/index.php?option=com_jdownloads&view=download&id=2416:jamaicamon-v2-2-scpu&catid=56&Itemid=126 for running on ROM and this would be a good start. Since you won't be having a SuperCPU per se because the CPU is the same one used in the SuperCPU but ou won't be using the SCPU roms and CPLD/GAL stuff. It shouldn't be a hard modification and then tweak it so it runs from ROM like a ROM cartridge or ROM on the board and launched when the Kernal/BASIC/DOS operating system detects the proper key presses or the proper command such as monitor is typed in. Then we have at least a basic ML monitor to get started. Since it has been declared in the document that the program is in the public domain, we should be able to do with it as we need.

It was originally written by Steve Judd if I recall correctly. We can always develop a better ML Monitor/Assembler as we go. If the VICKY memory maps like it does with the VIC-II or even the VDC or whatever, it should be mapped in memory. We'll need a "Mapping the C-256" document to make a friendly introduction to the new features of the C-256 including the memory mapped registers.

At least a well documented memory map that is updated frequently as the hardware is revised but documented.

I'm putting it here so it is here and documented so don't worry if you don't remember all of it as you work on the project. They are ideas. The choice of JamaicaMon as a base point for a monitor on ROM would be it's size, simplicity, and a starting point for making any program and also is PD in that you don't need to contact Apple Inc. to get a license to IIgs's ML monitor. Aside from a modified BASIC, I think we can do just about anything with a basic ML Monitor. At least, it would get us going before fancier tools are ported/developed to support the C-256 as a target. So as long as I can theoretically address 16 MB (long address), I'm good. I understand the specs indicated for 4 MB of memory (3+1 MB). 6502/6510 monitors are kind of hard coded for 64KB addressing and 6502/6510 instruction set.

I may look into the JamaicaMON assembly for porting it.

Hey Richard,

As you are probably aware, there are already some tools from WDC for the 65C816 to compile and simulate on a PC, they are free and available today. Obviously, till the system is finished and all the custom chips design is done, there is very little somebody can do. However, Tom is looking into making a ML Monitor for it.

Besides that, I agree with you, that a full tool chain with a C256 simulator would be the best, hence this very early calls for anybody who would be interested to get on board with either that or getting down to business directly on the machine as it was my goal to have a full debugger on board.

I understand that Unity and Unreal programmers are not necessarily the best target for the system, but anybody who has a past of game programming is to me a good starting point to discriminate who will get a development system and who will not. Besides, if one Unity programmer has programmed a 8 bits pixel art style game, there could be a chance that it could be ported over. Granted, pretty much everything would have to be programmed from scratch but at least you could possibly have all your graphics and music assets done already cutting down on development time.

Anyway, I am glad you are interested to work with the machine and I am sure we will have more occasion to talk soon!

Thank you for your involvement!

Cheers!

S

" I know, I know it is very early, but I thought I would create a section for anybody who would be willing to either port or create a new game from scratch on the C256. Granted, you will need hardware and documentation at some point. The deal here is really to start collecting names and when the time will be right, then some will be chosen and Early Game dev platform will be released for early adopter to start developing new games.

So, at this point, if I am going to give away development version of the C256 early on, I will need to interview and make sure the platform will be used for its purpose and not wasted. So, keep that in mind. Any works you have done on Unity for example would be a great start to qualify you as a early game developer for the C256 Foenix.

Thanks for your time and support!"

Hello Stefany,

Let me start with a few things, I've done some work for C=, Amiga, Apple IIgs, NES/SNES, etc. over the years. This is a 65c816 platform as I understand it so I don't think software experience with Unity or Unreal Game Engine experience is going to be particularly useful other than broad game design thinking. One of my last projects I did, in this case as a graphician, was Spork 64 as can be found on CSDb and possibly Gamebase 64.

One of my business is developing software/video game targetting modern computer systems including augmented reality & VR systems. I'm currently working on a 2d variant of a project that is for modern systems with 3d graphics/VR/AR technology. The 2d variant would be targetting systems on legacy 2d graphics technology. To understand that project, exactly... we will need conduct the discussion on it in private at this time under non-disclosure because not just for the 2d project but information related to the 3d project which is not being publically talked about at this time. They are parallel projects with shared concepts.

Honestly, for a 16-bit Commodore based platform would require understanding assemblers or ML monitor programming for 65xx family of microprocessors, video graphics modes like VIC-II modes and their color attribute limitations like how many colors you can use in a 8x8 pixel character cell. C= graphics have been basically cell/tile based similar to NES/SNES was like but also the same way as they were on the TI-99/4A. Programming for this platform sounds like programming at a low-level basis. My development environment for C= have been ML Monitors, assemblers, various graphics tools, and VICE for run-time tests. There are some cross-platform tools that would be useful but there will need to be some tools for developers to get started for initial development. Personally, an emulator of the C256 would be a nice thing to have. Here's why? When we are learning things like how the VICKY works, its new modes and all, we can test run before running it on the C256. If you have an ML Monitor or Assembler built in, GREAT. That would be a great start because from their tools can be made for VICKY graphic modes beyond that of the VIC-II,so a complete development tool chain would need to be put together. Whether it be porting, porting with modifications, etc. It isn't insurmountable but it is some work.

I think prior application and game development experience with the C64, C128, Apple IIgs, and SNES/Super Famicom would be appropriate for this project. In early stage, I would argue that development of development tools and porting development tools like assemblers would be important. There will need to be a number of those individuals brought on board early on. Then other developers start developing. First and foremost, the first tool we need is a 65c816 assembler/ML Monitor tool. This is crucial to being able to develop other applications. Having them on the system similar to how you launch the ML Monitor in the C128. Cross-platform tools can be useful but it would come its due course. It's a little old school but that's how we programmed on these systems on these systems. It would be a good place to start.

I'm interested in developing for this system among others.

Sincerely,

Richard Balkins

Reflected Light Entertainment, LLC. / Lightforce Softworks, LLC. / etc.

Once I get comfortable programming, I am going to port some of my fave programs(Mostly apps), over from the C64, and if I can find the source code, the C128. I am also going to be looking convert some Amiga stuff over as well. I know that stuff was written for the Motorola 68000, but it shouldn't be much harder to port over with the source code would it? I also have plans for some original software, that I think would be great for the online community as well. Unfortunately, not having a time frame for getting my disability started is REALLY putting a damper on things. It's extremely hard to do the things, or even learn the things I want to learn in a homeless shelter. And there you have it. My motivation, for wanting so badly to be successful at this. I can't work regular jobs, due to multiple injuries. So the only chance I have is to get back on my feet again, is to jump on the leading edge of a possibly huge (And in this case, totally cool) project.