Jump to content

Open KERNAL project


Recommended Posts

https://github.com/MEGA65/open-roms

The Mega65 team were serious enough to document their goals, their process, build a repo, and start.

I’m going to cruise over there and see what’s what.

 

 

 

A project to create unencumbered open-source ROMs for use on selected retro computers. Besides this manifest, the following documents are available:

To download pre-built ROM images, go here.

 

Bruce has noted that our goals are simpler (although I hope still compatible):

Quote

implementing the Kernel interface would be even easier than producing a KERNAL rom image that is compatible with the bulk of C64 games and applications, so a project with the less ambitious goal could take what they have so far and likely complete it substantially faster.

Can that be a separate compile target, or does it have to be a fork, or can it be something in between?

Edited by rje
Link to comment
Share on other sites

Before the deal with Cloanto was made and it was iffy whether they'd be able to continue using the current kernel, they started integrating the open-roms solution into the project.  From what I remember it was mostly usable, but pretty buggy. One downside to it would have been that, since open-roms needs it to be clean of any influences of the original licensed kernel, no one who's seen the original source code can work on it, which means Michael wouldn't have been allowed to work in the areas of code that it covered, and we would have been dependent on outside developers fixing bugs in a separate project.

There's still a switch in the Makefile to compile it rather than the CBM kernel, but it's been broken for a while.  I think the integration of Frank's DOS and FAT32 implementation may have broken it.

Edited by Ender
Link to comment
Share on other sites

7 hours ago, Ender said:

since open-roms needs it to be clean of any influences of the original licensed kernel, no one who's seen the original source code can work on it, which means Michael wouldn't have been allowed to work in the areas of code that it covered, and we would have been dependent on outside developers fixing bugs in a separate project.

Actually the process seems pretty thorough, to the point where anyone's work can be checked and tool-verified (by their metrics) to be "clean" -- again, by their metrics, which seems reasonably conservative.

 

Link to comment
Share on other sites

  • 1 month later...

Tom mentioned in a now-locked thread:

Quote

there's more than enough brains in this community to crowdsource a kernel

All true.  There are a lot of experienced assembly coders / kernal hackers here.

==> My assumption is that "it's harder than it looks."

***

So has anyone sat down and actually counted the cost?  That is, figured out the complexity of the task, broken down the requirements into workable units, and then estimated the level of effort to do it?

I mean, assuming this is not simply a project someone hacks out over a weekend.  Because if it were that sort of project, it'd've been done... as Hillary said, "because it's there".

Someone would've taken the MEGA65 Open KERNAL project and carried it to completion.  Because it's there.  

***

Consider the KERNAL.  Let's go to Michael's own pagetable.com to checkitout.

  1. "done" (KEYLOG) 
  2. "done" CINT
  3. "done" IOINIT
  4. "done" RAMTAS
  5. "done" RESTOR
  6. "done" VECTOR
  7. "done" SETMSG
  8. "done" SECOND
  9. "done" TKSA
  10. "done" MEMTOP
  11. "done" MEMBOT
  12. "done" SCNKEY
  13. "done" SETTMO
  14. "done" ACPTR
  15. "done" CIOUT
  16. "done" UNTLK
  17. "done" UNLSN
  18. "done" LISTEN
  19. "done" TALK
  20. "done" READST
  21. "done" SETLFS
  22. "done" SETNAM
  23. "done" OPEN
  24. "done" CLOSE
  25. "done" CHKIN
  26. "done" CHKOUT
  27. "done" CLRCHN
  28. CHRIN -- partial -- no screen device support
  29. "done" CHROUT
  30. "done" LOAD
  31. "done" SAVE
  32. "done" SETTIM
  33. "done" RDTIM
  34. "done" STOP
  35. GETIN -- partial -- no screen device support
  36. "done" CLALL
  37. "done" UDTIM
  38. "done" SCREEN
  39. "done" PLOT
  40. "done" IOBASE
  41. "partial" NMI vec
  42. "done" Reset vec
  43. "done" IRQ/BRK vec

...Plus over half of the "unofficial" KERNAL routines.  I suspect they didn't need to implement all of them.

"done" means the work is nominally complete on the MEGA65 ROM, with the caveat that they don't support features specifically described as "missing" in the project as a whole.

Plus whatever changes we'd have to do to get THAT to work on the X16.

We get all the extra goodies that Michael (already) added "for free".

 

How long does it take an assembly programmer to code 39 subroutines?  39 weeks?

 

Edited by rje
Link to comment
Share on other sites

On 8/28/2021 at 11:29 AM, Ender said:

since open-roms needs it to be clean of any influences of the original licensed kernel, no one who's seen the original source code can work on it, which means Michael wouldn't have been allowed to work in the areas of code that it covered, and we would have been dependent on outside developers fixing bugs in a separate project.

It was extremely important that the open ROMs be developed separate from influence from the original source.

 

However, the KERNAL part is essentially done.

 

That means anyone can debug it.  As long as we don't replace the code with the original, that is.

 

Edited by rje
Link to comment
Share on other sites

  • 2 weeks later...

I have the DESIRE to try to make a working fork of the Open ROMs for the X16.  It will be a learning experience.

I've got to start somewhere, so I'll start with what's there.

 

(1) Repo forked and cloned.

(2) Re-reading the README

(3) Reading the CONFIG options for a custom build.

In particular, I'm going to first look at the config for the CX16, of course.

 

Edited by rje
  • Like 1
Link to comment
Share on other sites

Here, I'm going to walk through the CX16 configuration.

;; #CONFIG# PLATFORM_COMMANDER_X16     YES

Well, yes.

;; #CONFIG# MEMORY_MODEL_38K           YES

Again, yes.

;; #CONFIG# PANIC_SCREEN               NO
;; #CONFIG# DOS_WEDGE                  NO
;; #CONFIG# TAPE_WEDGE                 NO
;; #CONFIG# TAPE_HEAD_ALIGN            NO
;; #CONFIG# BCD_SAFE_INTERRUPTS        YES

Okay.

;; #CONFIG# COLORS_BRAND               NO
;; #CONFIG# BANNER_SIMPLE              NO
;; #CONFIG# BANNER_FANCY               YES
;; #CONFIG# SHOW_FEATURES              NO

Okay.

Not much, really.  

 

  • Like 1
Link to comment
Share on other sites

Maybe it's not that -- it's that clang complains about the syntax.  For example, with nested templates, it errors out when the end-brackets aren't space-delimited.  It errors out on these:

>>>

But is okay when I edit them to this:

> > >

 

It is also erroring on C++11 extensions.  I'll have to enable that in the makefile, I think.  I'm weak on Make.

Found this on Stack Overflow, and will try it out:

 

CXXFLAGS = -std=c++11
Edited by rje
  • Like 1
Link to comment
Share on other sites

Meh, still produces errors.  Setting it on the back-burner and letting my hind brain think about it for awhile.

I suspect the flags aren't getting picked up.  

Or something.

 

On the other hand, ACME builds just fine.

Edited by rje
  • Like 1
Link to comment
Share on other sites

  1. You need a Linux, with GIT, GCC, GNU make, and libpng development libraries (libpng-devel package on Debian, if I'm not mistaken). If you only have Windows - you can use Windows Subsystem for Linux, it should work. I'm not sure about Mac OS - I don't have a Mac.

Maybe this is why.  I have OSX.

Maybe I'll have to try this on a Raspberry Pi running its Debian-ish thing.

Or... or a container.

 

Edited by rje
  • Like 2
Link to comment
Share on other sites

On 10/25/2021 at 9:09 AM, rje said:
  1. You need a Linux, with GIT, GCC, GNU make, and libpng development libraries (libpng-devel package on Debian, if I'm not mistaken). If you only have Windows - you can use Windows Subsystem for Linux, it should work. I'm not sure about Mac OS - I don't have a Mac.

Maybe this is why.  I have OSX.

Maybe I'll have to try this on a Raspberry Pi running its Debian-ish thing.

Or... or a container.

The simplest and fastest approach is probably to use a virtual machine. VirtualBox running Linux is about the easiest way to handle that. 

I tend to try to run Debian VMs with the LXDE desktop (so it's similar to the Pi, which I have like 8 of now), but it might be smartest to use whatever distro they are using, since it sounds like there are some pretty specific requirements going on there. 

I really wish people wouldn't write 65x code using Linux toolchains... it's so frustrating, when there are simpler assemblers out there that can do the same job, but with fewer dependencies. 

  • Like 1
Link to comment
Share on other sites

On 10/25/2021 at 9:09 AM, rje said:
  1. You need a Linux, with GIT, GCC, GNU make, and libpng development libraries (libpng-devel package on Debian, if I'm not mistaken). If you only have Windows - you can use Windows Subsystem for Linux, it should work. I'm not sure about Mac OS - I don't have a Mac.

Maybe this is why.  I have OSX.

Maybe I'll have to try this on a Raspberry Pi running its Debian-ish thing.

Or... or a container.

 

Would be nice if someone already created a docker container (or published a dockerfile) with the stuff you need. That’s usually my go-to solution for compilation that needs a specific platform. 

  • Like 1
Link to comment
Share on other sites

On 10/25/2021 at 5:40 PM, rje said:

That's a good suggestion, Calculon.

 

The attached docker file worked for me.  I've never built the ROMs before, so the best thing I can say is that "it doesn't throw any errors", but maybe it's a head start for anyone not running Linux.  Or who just don't want to install a bunch of stuff.

1. Clone repo

2. Add Dockerfile

3. Run docker build .

I didn't map volumes, so the step of getting the output from the container is left to the next guy 😉

EDIT: Typos

Dockerfile

Edited by Calculon
  • Like 2
  • Thanks 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use