Hello, Guest the thread was viewed27k times and contains 159 replies

last post from FeralChild at the

Work is underway to make open-source replacement ROMs for the C64

    is there any way for you to implement the roms even on a stock 64 without using that 32k?
    such as writing the roms on a rom and paging(bridging) them properly on its own mapped memory space so the 64k is free? im sure you understand that some type of flag or control must be made in that mem space back out to the system and vice versa.

    perhaps some new features such as a cp/m dir command or so, or a whole load of dos commands and directory listing structures. maybe the option of directory structures for the c64.

    thanks

    What do you mean without that 32KB? The ROMs we are writing already do what you are asking: They run in a stock C64, i.e, fit in place of the original KERNAL and BASIC, and do proper banking so that almost all the 64KB RAM is usable -- only 2KB at each end is reserved for the screen and other miscellaneous bits and pieces.

    As for adding at least a directory command, that will be a matter of how much we cansquish things in. But being open-source, it will be super-easy for people to, for example, ditch some of the trigonometric functions in BASIC in return for a more useful set of extensions.

    Gunstarrhero: You might want to take a look at "Mapping the 64" to see how the memory map works on the C64. Location $0001 in zero page controls if KERNEL and BASIC is switched on/off (directly readable) or the underlying RAM is exposed. It will have to remain that way in the MEGA 65 if it is to remain compatible with the C64.

    you misunderstood, i think everyone did.

    what i was saying was add a small amount of rma space to the rom chips so the roms only occupy those chips on. so when the computer boots it reads 64(whatever)basic bytes free instead of 38911 basic bytes free. on the c64.
    what i was saying was build a bride in the ram space for the actual control to the mother board and back to the chip. this bridge would have to address the kernal etc the same way the c64 would. rom->(this is where the bridge in programming picks up either way from instruction to instruction)(this is also where the the rom would load itself instead of the c64's mainboard ram)(the ram on the motherboard would still be used the same, now when the c64 instructs back from mobo ram or cycle or instruction from the cpu, it goes through this ram space to the rom, leaving all the ram on the mobo open to the user; the only thing different now is that the programmer would reference/instruct/call this particular "address" bridge instruction instead of just going back to the rom. or, the bridge could work so that the user makes their calls the same and the instruction picks up on the call and just reroutes)(it would be much more effective, now we can use the whole computer without having to disable other sections to free up memory, we could even if allotted, utilize that mem space for even more or larger programs or occupations of ram) ram space on chip -> c64 ; c64 ->ram space -> rom

    Commodore 64 by design is able to use the full 64K of RAM, via bank switching, programmer can switch ROMs and I/O space on/off, etc. It was always the case. It's another question that the stock Commodore ROM BASIC as a software does not utilized this otherwise always available hardware feature (AFAIK C64 ROM BASIC is about the same as VIC20's so not so much plus features put in, C64 would provide over VIC20 ... maybe that's the explanation). But it's matter of software, the hardware was capable to do it, on a real C64 as well, surly on Mega65 as well with being C64 compatible. In fact, for example Commodore Plus4 BASIC ROM already used bank switching (though the exact details on the hardware is not the same, but the theory is similar). It's again another question, that C+4 BASIC said to be kinda slow because doing very rapid bank switching at each token/etc fetch. Or so, I can't remember exactly, but anyway it's not the point here either to deal with the C+4 :)

    Paul here I'm surprised.
    You were owner of C65 and work on your M65... both have C64 mode.
    We know that C64 mode has not the same Basic version like C64.
    We can name it anything like Basic 2.2...

    When you press SHIFT + RUN/STOP it forces load first file on disk in disk drive, by:
    LOAD"0:*
    and when want load program from disk, you need write only:
    LOAD"*
    and hit Return, it loads first program on disk, of course asterisk can be exchanged to wished name.
    It never needs and never in past LOAD"*",8
    Why? You know - C65 is missing cassette port and tape support was from Basic removed...
    Of course, this is easy to write when I never owned real C65 and used only M65 core or emulator (but each emulator does the same - Xemu, MESS).
    Other thing is booting.
    I think if is possible to create any modifications to Basic in open-source way better is use command BOOT which is available since Basic 7 in C128 (first appears in Basic 3.6 in Commodore LCD, but it returned only ?UNIMPLEMENTED COMMAND).
    It needs not any file or anything other than correctly written boot sector.
    Other side is BOOT command in C65 Basic 10 - it was changed and it always searches for
    AUTOBOOT.C65*
    In my eyes it is ugly to have any program on disk which needs correct and exact name included in my own programs. This was in my eyes mistake by Commodore 65 designers.
    But it is personal feeling, so this is not important.

    Miro

    I listed the ,8 to avoid confusion for people who may not be familiar with this feature of the C65, especially since we are talking specifically about the C64.

    Adding a BOOT command means expanding the token list and tokeniser, and skipping many tokens in the middle. The result will be quite a lot bigger code. Also "BOOT" takes more key presses than just SHIFT+RUN/STOP.

    I think if you can't correctly name a file, then this is not a problem with the design of the system. There are so many other things that using a computer required you to have correctly spelled file names.

    At the end of the day this is all syntactic sugar: what is important is that it is in some way easy enough to boot from a disk. To me SHIFT+RUN/STOP is the simplest and most efficient way to implement this in a 16KB C64 ROM set.

    Paul.

    The one-character wedge commands are also very useful: @, %, / etc. (@$ for the directory) and they do not need a token. Many people are already used to them.

    Although it is offtopic here, but later when dealing with the C65 ROM's one day, it would be nice to "fix" the v10 Basic ROM on some points where the designers unfortunately broke the backwards compatibility with v7 (and actually with v3.5/v3.6 as well as the v7 is backwards compatible to them, too), for example:

    - gfx commands (particularly GRAPHIC for mode change or COLOR with the appropriate colour codes are different here)
    - dma commands (on C128 there are STASH, FETCH and SWAP dealing with the REU, the same ones could be reimplemented here but dealing with the DMAgic)
    - BANK (to modify if BANK15 is given, that also to mean BANK128 here)

    And so on.

    This would make it possible to write some basic software on the C128 by only using the common command set (or even on Plus/4 with more restrictions) and be able to also run it on the C65/MEGA65 without any further modifications. (Or even to use some existing software of that kind.)

    Agree Paul, new token costs amount of code... So my Q is bit stupid...
    Has C64 Basic all commands implemented? Example is easy to modify Basic 7 without code amount - using unimplemented commands incl. renaming them, most known are Quit and Off.
    But really if are all available commands in Basic 2 implemented, it needs bigger mod. But why look not what a code can be written more effective with less code amount. But problem is in token numbers range and if is any free.

    Basic 10 backward compatibility:
    Sure - true words!
    When we look to Basic 3.5 and 7.0 - no problem with some small fixes.
    Even 3.6 is almost identical with 7.0 - some changes done.
    Even Basic 7.80 - extension of 7.0 to graphics for VDC (from there is name 80), has no one token added. Only graphic commands parameters were extended. 100% backward compatible, only Basic memory free is bit smaller - but not so big difference, so it is near impossible to find problem.
    And this is there where Basic 10 discontinued backward compatibility. In time I was experimenting with C65 graphics and I was near lost - near no documentation and total new commands or commands used in previous Basic versions with new syntax, but reason is totally wrong - these commands have nothing with its function in earlier Basic versions.
    Best way is what was written by Rosettif - modification Basic 10 to be backward compatible.
    Why not? Basic 10 was never released, near no software used it and near no one using/knows it.
    M65 can have M65, C65 and C64 modes - native, true C65 incl. Basic, and currently mod in progress.
    But problem is on other side - C65 or M65 mode is missing progress and is out of focus. C64 mode is only one with progress and people looking for it. I end this post by way how you all on this forum heard from me (and maybe I'm hated for):
    It looks like new C64 is on the way, C65 again dies.
    Sad, sad. When I saw this project in 2013 I was happy like little kid - I could get C65, but it is past.
    My words are sad and my mind see this, said 25 years ago: I want not to be loved for what I'm not, I'll be rather hated for who I am. It said man who decided very wrong.

    Miro

    Hello,

    Yes, it is naturally quite possible to give attention to making the MEGA65's native BASIC backwards compatible with BASIC 7. Of course, this will be easier and more likely to happen if the community contributes to its development, instead of leaving everything to us.

    As for documentation, we are actually already starting to write documentation for the C65's BASIC 10.

    As for the question on the modes of the MEGA65, and your concerns about missing the C65 part, this isn't really true: The MEGA65 is a super-set of the C65 hardware, and can run the C65's original C65 ROMs to give a near-perfect C65 mode. The C65 ROM in turn allows dropping to C64 mode, which is thus supported. Thus the MEGA65 does both the C65 and C64 modes. Then all we have done is provide a number of hardware extensions that could be used to provide a "MEGA65 mode", or because the C65 model is to make it possible to access the higher functions from C64 mode if the program explicitly wants to, the same extensions are available from C64 and C65 mode, if the programmer wants to use them. Thus in the MEGA65 you do get a C64 and a C65, that are faithful to the original, plus the new parts of the MEGA65. But if you want to ignore them and live in C65 mode or in C64 mode, then this is just a case of loading the correct ROM onto the SD card.

    But don't worry, we don't think less of you because you have a different opinion. That is only a thing for politicians and football supporters to do, and I am neither ;)

    Paul.

    @gardners: You wrote before that in C64 mode on MEGA65 the CPU would be switched to 6510 mode for better compatibility unless it enters the Kernal when it is switched to 4510 mode temporarily to handle the v2.2 accessing the built-in drive.

    But this method won't work at all if any of the stock or other existing C64 Kernals is used (or anything else custom-made, but only designed with the C64 in mind) since these Kernals won't tolerate the 4510 mode.

    So how can you then make a difference between these cases?