Bitte melde dich an, um dieses Medienelement zu sehen.
Still needs some small improvements here and there. Unfortunately, it won't be a part of a standard C64 build, there is no space in ROM for such a luxury - for this custom build, I have temporarily disabled some functionalities. For Mega65 (and Ultimate 64, once the Bitte melde dich an, um diesen Link zu sehen. support is completed) this shouldn't be a problem, though ![]()
Work is underway to make open-source replacement ROMs for the C64
-
mega65 -
7. Mai 2019 um 19:29 -
Erledigt
Es gibt 159 Antworten in diesem Thema, welches 31.972 mal aufgerufen wurde. Der letzte Beitrag (
-
-
Very nice

-
@Paul, I've got two questions:
1. According to Mega65 Book, one can write 65 to $00 to switch the machine to full speed, and 64 to go back to 1 MHz speed. And it works under XEMU, my BASIC commands FAST and SLOW do exactly this. But is there a way to actually read the current setting? Sometimes (tokeniser - despite the optimization it is still slow in the worst cases, tape load, IRQ) I would like to switch to the maximum speed, but restore the previous setting afterwards.
2. Last year you have shown a freeze menu monitor (Bitte melde dich an, um diesen Link zu sehen.). Would it be possible to make it triggerable from the side of normal software? This way we could quickly implement MONITOR command in the open source ROMs
-
Hello,
1. This can only be read from within the hypervisor in $D67D bit 4. There is currently no hypervisor trap to allow reading of this.
2. Yes, by triggering the freezer to start. Or rather, I should say that this SHOULD be done. At the moment there is no way to trigger it, but I'll implement it.
Bitte melde dich an, um diesen Link zu sehen.
2b. Would you like to also be able to trigger the matrix mode display instead of just freezing? Also easy enough to implement.
2c. We need an appendix in the MEGA65 book that documents all the hypervisor traps and function calls.
Paul
-
2b. Honestly, I don't know which one would the average user prefer. But for the assembler programmers being able to trigger the freeze would be very useful for debugging - it would allow to insert "software breakpoints" into the code.
-
Ok. I'll just make it possible to trigger the freezer.
Paul.
-
This is highly appreciated! Thanks a bunch to both of you!
2b) I am pretty sure that it is always good to give users all possible options- if there is a way to do that.
Cheers
Marc
-
It seems the CommanderX16 team is developing an open-source DOS (but for the FAT32 file system), with some special support for GEOS, if I'm not mistaken - license is very liberal (2-clause BSD), and the code seems to be modular. Who knows, maybe someday we will be able to reuse some parts of it

Bitte melde dich an, um diesen Link zu sehen.
-
@FeralChild I always liked to see a 'new' DOS for CBM.8-bit machines.
Especialy the missing timestamps an the use of (sub-) directories is imho a 'must have' nowedays.
-
Just a quick question.. if the roms are supposed to be compatible, wouldnt that mean - due to space limitations - that they ultimately end up duplicates of the roms anyway? I guess what I mean is: if i peek a ROM location and it doesnt have what is expected there, then it's technically not 100% compatible. I mean, you may be able to write some code more efficiently for the end effect, but the in-between wont be the same unless the code is the same. How compatible are you aiming for?
-
Just a quick question.. if the roms are supposed to be compatible, wouldnt that mean - due to space limitations - that they ultimately end up duplicates of the roms anyway?
An example for a "very good" open ROM you can see for the Bitte melde dich an, um diesen Link zu sehen..
You can download here the open81.rom: Bitte melde dich an, um diesen Link zu sehen.
ZitatA free replacement firmware for the T/S 2000 derived from the T/S 1000 ROM.
For curiosity I compared it against the original ZX81 ROM with "fc.exe" and let me say, the guys did an "excellent" job:
100% exactly the same binary file! Every one of the 8192 bytes is the same on the same location! You can't make a better "open rom" !!!!


-
An example for a "very good" open ROM you can see for the Bitte melde dich an, um diesen Link zu sehen..
You can download here the open81.rom: Bitte melde dich an, um diesen Link zu sehen.
For curiosity I compared it against the original ZX81 ROM with "fc.exe" and let me say, the guys did an "excellent" job:
100% exactly the same binary file! Every one of the 8192 bytes is the same on the same location! You can't make a better "open rom" !!!!


I think it can be assumed that this also applies to the ROMS of the other computers?! Very interesting Project,btw.

-
Yes, the X16 6502 FAT32 implementation is quite interesting, and quite likely worth taking a look at. I'll likely have a look at it when I get to fixing lots of the problems in the HYPPO FAT32 code.
LG
Paul.
-
Just a quick question.. if the roms are supposed to be compatible, wouldnt that mean - due to space limitations - that they ultimately end up duplicates of the roms anyway? I guess what I mean is: if i peek a ROM location and it doesnt have what is expected there, then it's technically not 100% compatible. I mean, you may be able to write some code more efficiently for the end effect, but the in-between wont be the same unless the code is the same. How compatible are you aiming for?
It will never be 100% compatible, it won't even by as compatible as JiffyDOS Kernal. For some dirty tricks we can add workarounds, for others... if a copy protection "decrypts" a piece of code by XORing it with ROM content, there is nothing we can do about it. Hard to say how compatible this ROM replacement will eventually be - right now I'm the only active contributor, and for now I mainly work on the features, so that there is actually a reason to use these ROMs.
What I don't expect to work are BASIC extensions - these typically make a lot of assumptions, testing them would require a lot of effort, and most likely it would be necessary to strip the ROMs out of many extensions.
Lack of space is not that problematic, you can always drop some less important features, like RS-232, or tape support - and for Mega65 you can move some routines to one of the extra ROM banks, AFAIK the Ultimate64 community is experimenting with additional ROM banks for Kernal too. -
Yeah thats what I was thinking. A tremendous undertaking, and you have the gratitude of the community. But who knows - these things go viral at times and you might end up with an army of people working on it. I know that BASIC uses a lot of strange entry points to various routines. ie you cant assume there's only one, which makes it all the more annoying. Best of luck to you on this!
-
OpenROM is important. Sure, nothing can be ever 100% compatible as it would mean an identical copy of the original ROM ... However this reminds me to SD2IEC in a sense .... That is: it does not fully emulate a disk drive, just the DOS commands, and also some turbos etc. However the great thing that many new titles try to take attention to this, and old software are patched to be able to work with SD2IEC. Surely SD2IEC was a not so good example, we talk more on the actual ROM of the computer not the disk drive (though in case of C65 the story is bit different with the built-in drive). So what I can expect that even with titles not compatible, will have versions which are. And the C65 mode itself is so seldom used that is not the big problem in term of compatibility but more the C64 mode, what a real C64 can benefit too, to run with some kind of OpenROM, btw. The other thing that C65 mode itself is hard to implement in kind of OpenROM form, since C65 is kinda not so well known platform unlike C64 which is VERY WELL known and understood at least

-
Right, I'm not going to reimplement the C65 native mode - but I have already started working on MEGA65 native mode
Planned features:
- VIC-IV features unlocked (and required by ROM in this mode), 40 MHz CPU by default (but possible to be changed with SLOW / FAST commands)
- C65 keyboard support - already written quite some time ago, but will certainly need some tweaks; not tested yet, waiting for the DevKit
- selectable text mode (with features similar to C128/C65 80-column modes), 40x25 / 80x25 / 80x50 (one of the last two will be the default, I'm not sure which one), with virtual 40x200 / 80x200 screen size (like 'console history' in the Linux world) - I'm working on it right now- loading from tape without blanking out the screen, possibly slightly faster JiffyDOS support (both possible because MEGA65 allows to disable badline emulation)
- some BASIC extensions/improvements will be limited to this mode
It will be possible to switch between modes without losing the loaded program (0x0800-0xFFFF RAM is going to be untouched), just the variables will be cleared (for MEGA65 mode, maybe some day we will move variables outside of C64 address space; that's why I prefer to clear them out). Switching between modes: either by GO 64 / GO 65 commands, or automatic fallback to C64 compatibility mode: if C64 cartridge is detected, if the user loads something below 0x0800 (which means autostart software), if SYS command is encountered in BASIC (I have already implemented NSYS command, which does exactly the same as SYS, but skips switching to C64 compatibility mode).
[edit] I'm open for ideas/remarks. Just please don't ask anything crazy and remember I'm not talking about BASIC here - for now it is going to be mostly Kernal side implementation. -
Paul just wrote a nice Blogpost about the recent Open-Rom achievements.
First, i would like to thank @FeralChild for his continuing work on the Open-Rom. THANKS !!!
This might be really interesting for the whole Commodore community.
(integrated tape-head alignement tool for C64 anyone ?
)But have a Bitte melde dich an, um diesen Link zu sehen.
-
Actually @FeralChild wrote the post, I was just the post man

I continue to be impressed and super appreciative at what he is achieving with this, and super glad that he is doing it, as the result is better than I could have done myself, even if I had the time to work on it, which I don't.
LG
Paul.
-
@FeralChild: Just wanted to say, a thousand THANKS for the awesome work you're doing for the Mega65 project! It is greatly appreciated (I also tried to post this as a comment on Paul's blog, but I have a feeling that blogspot's comment form doesn't play nice with my adblocker...)
On a related note, I'd like to try a few things with the Open ROMs. I can build and install them on my xemu-xmega65 without problems, but somehow once they're installed, I lose the capability of mounting .D81 images... is there any way around this or am I doing something wrong?
Kind regards,
Stephan
-