Basic command PRINT not yet available?

[dirkwhoffmann]

I've added support for the open-roms in VirtualC64. At the moment they are listed as "unknown or patched" Roms.

After that, I tried to write a simple program:

I didn't use the open-roms before, so I want to make sure that I am not doing something stupid here. Is it true that the PRINT command is not supported yet?

[FeralChild64]

That's true, PRINT is not yet implemented. But at least LOAD from IEC is, and we even have a DOS Wedge :) Kernal is quite complete (although there is still a lot to do), but BASIC... barely anything works. See https://github.com/MEGA65/open-roms/blob/master/STATUS.md - Features Missing chapter.

If you want to recognize Open ROMs in your emulator:

• Kernal contains an identification byte at $FF80 - for Open ROMs you'll currently find $F0 there, I hope there won't be any conflict with any other ROM and we won't have to change it
• BASIC contains identifier at $A004, for Open ROMs you'll currently find MEGABAS2 string there (probably due to historical reasons... but I think it'll stay this way).
• [edit] character ROM does not have any way to identify it, but it definitely won't change often

BTW, in my development branch (https://github.com/FeralChild64/open-roms/tree/master/bin) you'll find a version which should be much more compatible (I did some fixes just few days ago, they are just not merged yet to the official master).

[dirkwhoffmann]

If you want to recognize Open ROMs in your emulator:

Right now, VirtualC64 can only detect the file type by comparing the beginning of a file with a fingerprint. Adding fingerprints is easy, so the Roms from your dev branch are now recognised, too. It starts up without any problems:

I tried to play Fort Apokalypse and Giana Sisters which both habe issues. Internation Karate works fine though 👍:

[gardners]

Hello,

Great to hear that you have added support into Virtual64 :) This is a really important step from our perspective, because once the bulk of emulators include it, it will help grow the interest and community around these ROMs, so that we can get them finished sooner, and find and improve any incompatibility problems.

Thus if you could have them be identified as M.E.G.A. C64 OpenROMs, that would be super. We should really have a version number encoded in there somewhere, so that you could report that, too. @FeralChild do you have ideas where we could stick a version number in the BASIC and KERNAL parts for this purpose?

If you have any ideas on how to detect incompatibilities automatically from within the emulator, that would also be great to know, as anything that can help us automatically find and describe problems, will make it much easier to fix such problems. We already have some horrible thing I made for VICE or Xemu (I forget which), that tries to find all calls into the ROMs, so that ones not yet supported can be identified, but there are much more subtle problems than that to deal with.

Paul.

On Sat, 12 Oct 2019 at 02:49, Dirk Hoffmann notifications@github.com wrote:

If you want to recognize Open ROMs in your emulator:

Right now, VirtualC64 can only detect the file type by comparing the beginning of a file with a fingerprint. Adding fingerprints is easy, so the Roms from your dev branch are now recognised, too. It starts up without any problems:

[image: Bildschirmfoto 2019-10-11 um 18 10 40] https://user-images.githubusercontent.com/12561945/66667339-1e853d80-ec53-11e9-918d-38370bb6fd2f.png

I tried to play Fort Apokalypse and Giana Sisters which both habe issues. Internation Karate works fine though 👍:

[image: Bildschirmfoto 2019-10-11 um 18 10 20] https://user-images.githubusercontent.com/12561945/66667369-2b099600-ec53-11e9-9a9b-e91a34d06ab6.png

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/MEGA65/open-roms/issues/33?email_source=notifications&email_token=AAFCOT565H6ANOBXIN53IJTQOCRQXA5CNFSM4I72S7PKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBAP3TA#issuecomment-541130188, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFCOT25LIPDJBCYNNFSKZDQOCRQXANCNFSM4I72S7PA .

[gardners]

@Dirk: Schick mir auch bitte mal eine Email an paul.gardner-stephen@flinders.edu.au. Ich mache auch Informatikskürse, die 8-bit Rechner benutzen. Würde gern mit dir darüber reden, wenn du lust hast.

LG Paul.

On Sat, 12 Oct 2019 at 10:17, Paul Gardner-Stephen paul@servalproject.org wrote:

Hello,

Great to hear that you have added support into Virtual64 :) This is a really important step from our perspective, because once the bulk of emulators include it, it will help grow the interest and community around these ROMs, so that we can get them finished sooner, and find and improve any incompatibility problems.

Thus if you could have them be identified as M.E.G.A. C64 OpenROMs, that would be super. We should really have a version number encoded in there somewhere, so that you could report that, too. @FeralChild do you have ideas where we could stick a version number in the BASIC and KERNAL parts for this purpose?

If you have any ideas on how to detect incompatibilities automatically from within the emulator, that would also be great to know, as anything that can help us automatically find and describe problems, will make it much easier to fix such problems. We already have some horrible thing I made for VICE or Xemu (I forget which), that tries to find all calls into the ROMs, so that ones not yet supported can be identified, but there are much more subtle problems than that to deal with.

Paul.

On Sat, 12 Oct 2019 at 02:49, Dirk Hoffmann notifications@github.com wrote:

If you want to recognize Open ROMs in your emulator:

Right now, VirtualC64 can only detect the file type by comparing the beginning of a file with a fingerprint. Adding fingerprints is easy, so the Roms from your dev branch are now recognised, too. It starts up without any problems:

[image: Bildschirmfoto 2019-10-11 um 18 10 40] https://user-images.githubusercontent.com/12561945/66667339-1e853d80-ec53-11e9-918d-38370bb6fd2f.png

I tried to play Fort Apokalypse and Giana Sisters which both habe issues. Internation Karate works fine though 👍:

[image: Bildschirmfoto 2019-10-11 um 18 10 20] https://user-images.githubusercontent.com/12561945/66667369-2b099600-ec53-11e9-9a9b-e91a34d06ab6.png

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/MEGA65/open-roms/issues/33?email_source=notifications&email_token=AAFCOT565H6ANOBXIN53IJTQOCRQXA5CNFSM4I72S7PKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBAP3TA#issuecomment-541130188, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFCOT25LIPDJBCYNNFSKZDQOCRQXANCNFSM4I72S7PA .

[dirkwhoffmann]

We should really have a version number encoded in there somewhere

At the moment, VirtualC64 scans a Rom file in two phases (one phase is carried out by the emulator and the other one by the GUI):

First, both the file size and the header signature are checked (first three to five bytes). Every file that passes this test can be added as a Rom. Thus, patched Roms can be added, too (if they match the original Rom in the first three to five bytes).

When the Rom preference panel opens up, the GUI computes a fingerprint (simple FNV 1A checksum) for each of the four installed Roms and compares them against an internal database. The database consists of a list of fingerprints and a name mapping:

struct Rom {

    static let missing                 = 0x0000000000000000 as UInt64

    // Basic Roms
    static let basic_commodore         = 0x20765FEA67A8762D as UInt64
    static let basic_mega65_generic    = 0xF5E925DCABE2D3F0 as UInt64

    ....
}

let knownBasicRoms: [UInt64: String] = [

    Rom.missing:                 "This 8 KB Rom contains Commodore's Basic interpreter.",
    Rom.basic_commodore:         "Commodore 64 Basic V2",
    Rom.basic_mega65_generic:    "M.E.G.A. C64 OpenROM"
]

For a proof of concept, I've already added fingerprints for the Roms in Feralchild's dev branch. They are now recognised and displayed to the user like this:

Once there are officially released and versioned OpenRoms, I can add a fingerprint for each of them and display the correct version number. It'll be hard for me to grab the version number from a distinct place in the Rom, because it would require a lot of internal emulator changes. All Rom recognition stuff is based on fingerprints.

Once the Roms are stable, it's also possible to bundle the Roms with the emulator and add a button in the Rom preferences like this:

Hitting this button could install all three OpenRoms automatically.

[gardners]

Hi Dirk,

That all sounds great. It would be super, though, if there was a way to pull in the latest OpenROMs in the meantime, since they will continue to evolve for some time, I suspect. It at least gives emulator users something when they have no official roms pre-loaded. I hear what you are saying about the problems with refactoring to handle ROMs with non-constant finger-prints. Would it help if we had some well-known URL with ROMs and the checksums there, that could be slurped down by VC64 when someone clicks the "get openroms" button?

Paul.

On Sat, 12 Oct 2019 at 19:22, Dirk Hoffmann notifications@github.com wrote:

We should really have a version number encoded in there somewhere

At the moment, VirtualC64 scans a Rom file in two phases (one phase is carried out by the emulator and the other one by the GUI):

First, both the file size and the header signature are checked (first three to five bytes). Every file that passes this test can be added as a Rom. Thus, patched Roms can be added, too (if they match the original Rom in the first three to five bytes).

When the Rom preference panel opens up, the GUI computes a fingerprint (simple FNV 1A checksum) for each of the four installed Roms and compares them against an internal database. The database consists of a list of fingerprints and a name mapping:

struct Rom {

static let missing                 = 0x0000000000000000 as UInt64

// Basic Roms
static let basic_commodore         = 0x20765FEA67A8762D as UInt64
static let basic_mega65_generic    = 0xF5E925DCABE2D3F0 as UInt64

....

}

let knownBasicRoms: [UInt64: String] = [

Rom.missing:                 "This 8 KB Rom contains Commodore's Basic interpreter.",
Rom.basic_commodore:         "Commodore 64 Basic V2",
Rom.basic_mega65_generic:    "M.E.G.A. C64 OpenROM"

]

For a proof of concept, I've already added fingerprints for the Roms in Feralchild's dev branch. They are now recognised and displayed to the user like this:

[image: Bildschirmfoto 2019-10-12 um 10 23 44] https://user-images.githubusercontent.com/12561945/66698183-05749f00-ecdc-11e9-9c1e-0d4cd4e70225.png

Once there are officially released and versioned OpenRoms, I can add a fingerprint for each of them and display the correct version number. It'll be hard for me to grab the version number from a distinct place in the Rom, because it would require a lot of internal emulator changes. All Rom recognition stuff is based on fingerprints.

Once the Roms are stable, it's also possible to bundle the Roms with the emulator and add a button in the Rom preferences like this:

[image: Bildschirmfoto 2019-10-12 um 10 44 56] https://user-images.githubusercontent.com/12561945/66698324-66e93d80-ecdd-11e9-80db-3ff51f90bbdc.png

Hitting this button could install all three OpenRoms automatically.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MEGA65/open-roms/issues/33?email_source=notifications&email_token=AAFCOT3C7CX6IYW46LCWYRDQOGF5JA5CNFSM4I72S7PKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBB2EFA#issuecomment-541303316, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFCOTYTD7IHNDS5V4PX7HLQOGF5JANCNFSM4I72S7PA .

[dirkwhoffmann]

Hi Paul,

Would it help if we had some well-known URL with ROMs

I think that's a good idea. If there is a stable URL where the latest OpenRoms can be downloaded from, emulator authors can integrate some smart auto-grabbing feature into their products.

In the long run, I think I can integrate such functionality into VirtualC64. However, I don't think I will have enough time to do this in the short term. I am in the process of implementing an Amiga emulator (called vAmiga) and have only little time left to spend on VirtualC64 at the moment.

What I can easily do is integrate a help button called "Learn more about OpenRoms" that will redirect the user to one of your websites. I think a lot of people would love to try OpenRoms if they knew that they exist. I didn't know about their existence until Detlef Hastik sent me a mail with some background information about the MEGA65 project.

[FeralChild64]

Regarding versioning - I already though about this. According to Mapping the C64, there is a couple of unused bytes at $E4B7, reserved for system patches - so it's unlikely anyone touches this area. My idea:

---

• = $E4B7

.byte #<error_rom_version_mismatch .byte #>error_rom_version_mismatch

• = $E4B9

.text "DEVEL SNAPSHOT" // revision string .byte $00 .byte $xx // configuration file ID

...

error_rom_version_mismatch: // floating routine // display our own version of bluescreen

---

BASIC should know the expected Kernal version, check it during the startup, and jump to 'error_rom_version_mismatch' if there is a mismatch. I don't have any good idea yet where to put the revision string in BASIC ROMs... maybe in the area the keywords or error strings normally reside? We are using different format nevertheless.

By default the revision string should be something generic (like "DEVEL SNAPSHOT") - I create snapshot binaries sometimes quite often, I don't really want to version them. We can have a policy to reject bug reports from such versions.

When doing a release, we should have a script which does some simple replacement, like:

DEVEL SNAPSHOT -> RELEASE 191030

In the future it might be something else like 'VERSION 1.0000'. Or COMMIT 31D181A. Or whatever else we decide. Important: every single startup banner should display the revision string.

I've already added fingerprints for the Roms in Feralchild's dev branch

Not a good idea, I do builds rather frequently :)

---

Regarding compatibility - I don't do much compatibility tests yet, there is a couple of things that should be done first to prevent me from wasting time. The most important still unhandled one: keyboard scanning routine. The current one (from Codebase 64) has some really nice ideas, but... it needs additional memory, it utilizes quite a lot of bytes it considers free (and game developers might consider them free, too...). And trying to extend it to support, for example, C128 numeric keypad (or C65/MEGA65 additional keys) would require even more bytes in RAM. We really need some more compatible routine (won't be as advanced, though), I've already started working on one.

BTW. Emulator-branded ROM releases are a possibility too :)

[gardners]

Hello,

We dont (yet) have such a URL, but we will create one.

Paul

On Sat, 12 Oct 2019 at 21:53, Dirk Hoffmann notifications@github.com wrote:

Hi Paul,

Would it help if we had some well-known URL with ROMs

I think that's a good idea. If there is a stable URL where the latest OpenRoms can be downloaded from, emulator authors can integrate some smart auto-grabbing feature into their products.

In the long run, I think I can integrate such functionality into VirtualC64. However, I don't think I will have enough time to do this in the short term. I am in the process of implementing an Amiga emulator (called vAmiga) and have only little time left to spend on VirtualC64 at the moment.

What I can easily do is integrate a help button called "Learn more about OpenRoms" that will redirect the user to one of your websites. I think a lot of people would love to try OpenRoms if they knew that they exist. I didn't know about their existence until Detlef Hastik sent me a mail with some background information about the MEGA65 project.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MEGA65/open-roms/issues/33?email_source=notifications&email_token=AAFCOT2AX2NYASV4HOEINV3QOGXRRA5CNFSM4I72S7PKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBB5D6Y#issuecomment-541315579, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFCOT5MZTYLJZCZMHNRUI3QOGXRRANCNFSM4I72S7PA .

[gardners]

all sounds good. I'd make the keyboard routine switchable as a feature along with the other selectable things. Is 8 bits enough for feature flags?

Paul.

On Sat, 12 Oct 2019 at 22:36, FeralChild64 notifications@github.com wrote:

Regarding versioning - I already though about this. According to Mapping the C64, there is a couple of unused bytes at $E4B7, reserved for system patches - so it's unlikely anyone touches this area. My idea:

• = $E4B7

.byte #<error_rom_version_mismatch .byte #>error_rom_version_mismatch

• = $E4B9

.text "DEVEL SNAPSHOT" // revision string .byte $00 .byte $xx // configuration file ID

...

error_rom_version_mismatch: // floating routine // display our own version of bluescreen

BASIC should know the expected Kernal version, check it during the startup, and jump to 'error_rom_version_mismatch' if there is a mismatch. I don't have any good idea yet where to put the revision string in BASIC ROMs... maybe in the area the keywords or error strings normally reside? We are using different format nevertheless.

By default the revision string should be something generic (like "DEVEL SNAPSHOT") - I create snapshot binaries sometimes quite often, I don't really want to version them. We can have a policy to reject bug reports from such versions.

When doing a release, we should have a script which does some simple replacement, like:

DEVEL SNAPSHOT -> RELEASE 191030

In the future it might be something else like 'VERSION 1.0000'. Or COMMIT 31D181A. Or whatever else we decide. Important: every single startup banner should display the revision string.

I've already added fingerprints for the Roms in Feralchild's dev branch

Not a good idea, I do builds rather frequently :)

Regarding compatibility - I don't do much compatibility tests yet, there is a couple of things that should be done first to prevent me from wasting time. The most important still unhandled one: keyboard scanning routine. The current one (from Codebase 64) has some really nice ideas, but... it needs additional memory, it utilizes quite a lot of bytes it considers free (and game developers might consider them free, too...). And trying to extend it to support, for example, C128 numeric keypad (or C65/MEGA65 additional keys) would require even more bytes in RAM. We really need some more compatible routine (won't be as advanced, though), I've already started working on one.

BTW. Emulator-branded ROM releases are a possibility too :)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MEGA65/open-roms/issues/33?email_source=notifications&email_token=AAFCOT5X4IPI3XJZR5IUEUDQOG4TXA5CNFSM4I72S7PKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBB55BA#issuecomment-541318788, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFCOT6REK6VF63HHDWSYMLQOG4TXANCNFSM4I72S7PA .

[FeralChild64]

I don't mean feature flags - they wouldn't be practical, for example you can already freely specify SID chip addresses - so that Kernal knows what to silence after RUN/STOP+RESTORE. And I'm going to provide configure options for function keys (and SHIFT + RUN/STOP) strings, which would make a bitfield even more unsuitable.

I mean - 0 for generic ROM, 1 for MEGA65 ROM, etc. And yes, the keyboard routine will be selectable during the compile time.

[gardners]

Hello,

Ok, so an enum, effectively?

Paul.

On Sun, 13 Oct 2019 at 00:21, FeralChild64 notifications@github.com wrote:

I don't mean feature flags - they wouldn't be practical, for example you can already freely specify SID chip addresses - so that Kernal knows what to silence after RUN/STOP+RESTORE. And I'm going to provide configure options for function keys (and SHIFT + RUN/STOP) strings, which would make a bitfield even more unsuitable.

I mean - 0 for generic ROM, 1 for MEGA65 ROM, etc. And yes, the keyboard routine will be selectable during the compile time.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MEGA65/open-roms/issues/33?email_source=notifications&email_token=AAFCOT2O7L5TGDKP7D5X6GTQOHI7TA5CNFSM4I72S7PKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBB74XY#issuecomment-541326943, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFCOT5ZRUSI24PCG2SP4FDQOHI7TANCNFSM4I72S7PA .

[FeralChild64]

Right now just a number. Initial proposal (panic screen takes some space in Kernal - doesn't have to be compiled in, you can choose to just reset the machine instead):

• https://github.com/FeralChild64/open-roms/blob/master/c64/basic/rom_revision/bf52.rom_revision_basic.s
• https://github.com/FeralChild64/open-roms/blob/master/c64/basic/rom_revision/e4b7.rom_revision_kernal.s

Both areas are unused in original ROMs (filled with $AA). I have reserved 16 bytes for a version string (mainly to know how to arrange startup banners), we don't have to use everything in the future. Fortunately, BASIC cold start init routine resides in high ROM area (above $E000) - this way if someone by mistake uses original BASIC ROM with our Kernal it will be detected too.

[FeralChild64]

From now on, all the ROMs I release will have version number embedded in them. We can change the versioning scheme later, for now this is:

DEV - development snapshot 191019 - year/month/day FC - means FeralChild, taken from environment variable (make updatebin tells which variable to set if it isn't set yet) 1 - first snapshot this day

I still want do a couple of things before the merge request.

If anyone is interested, generic and Ultimate 64 builds have new keyboard scanning routine enabled (Mega 65 still has old). Shorter, configurable (features might be disabled to save space), should be more compatible. Handles repeat countdown in slightly different way (once DELAY is down to 0 char is output, KOUNT is only used for the next repeats - can be fixed, but would require some more ROM space, but I don't think this is a problem). I tweaked timing a little, original repeat was always too slow for me. Price to pay: there is no rollover support (it really needs data to be passed between scans) - maybe I'll add some VERY limited rollover in the future by changing how LSTX is handled. Scanning C128 keys in C64 mode probably needs some fixes (I don't fully understand behaviour I see under VICE x128 emulator).

[gardners]

This is all great work. Well done! It would be super if you would like to write a blog post about this recent work. I can post it.

Paul.

On Sat, 19 Oct 2019 at 04:32, FeralChild64 notifications@github.com wrote:

From now on, all the ROMs I release will have version number embedded in them. We can change the versioning scheme later, for now this is:

DEV - development snapshot 191019 - year/month/day FC - means FeralChild, taken from environment variable (make updatebin tells which variable to set if it isn't set yet) 1 - first snapshot this day

I still want do a couple of things before the merge request.

If anyone is interested, generic and Ultimate 64 builds have new keyboard scanning routine enabled (Mega 65 still has old). Shorter, configurable (features might be disabled to save space), should be more compatible. Handles repeat countdown in slightly different way (once DELAY is down to 0 char is output, KOUNT is only used for the next repeats - can be fixed, but would require some more ROM space, but I don't think this is a problem). I tweaked timing a little, original repeat was always too slow for me. Price to pay: there is no rollover support (it really needs data to be passed between scans) - maybe I'll add some VERY limited rollover in the future by changing how LSTX is handled. Scanning C128 keys in C64 mode probably needs some fixes (I don't fully understand behaviour I see under VICE x128 emulator).

[image: screenshot4] https://user-images.githubusercontent.com/48332137/67144077-f27d4400-f272-11e9-80d1-31269d23344e.png

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MEGA65/open-roms/issues/33?email_source=notifications&email_token=AAFCOTYZS7QF3TZOQCEMXQDQPLV6VA5CNFSM4I72S7PKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBXM5JQ#issuecomment-544132774, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFCOT2QRXKAX5ZYQUW7WQDQPLV6VANCNFSM4I72S7PA .

[FeralChild64]

I'll think about it, but I would like to first understand what is the problem with C128 keyboard reading... BTW, it would be helpful if you could answer to this post: https://www.forum64.de/index.php?thread/93387-scanning-the-keyboard-questions/

[dirkwhoffmann]

Sorry I've been so quiet for a long time, but I was working hard on vAmiga. Recently, I started to back port stuff from vAmiga to VirtualC64. The old version of VirtualC64 was quite limited w.r.t. recognizing Roms. I.e., I was only able to compare checksums agains a database which made it difficult to recognize the MEGA65 OpenROMs. The next version of VirtualC64 will be more flexible since the Rom recognition code will be part of the C++ emulator and no longer be part of the Swift GUI.

The next version of VirtualC64 will have a resigned Rom panel which resembles the Rom panel as it looks in vAmiga:

By pushing „Install OpenRoms“, the three MEGA65 OpenRoms get installed (they will ship as part of the emulator).

Of course, I also want to allow the user to drag in the latest OpenROMs by hand. And this directly leads to my question: How can I detect an OpenROM (header signature?) and how can I detect the version number? If I remember correctly, the old OpenROMs didn’t have a version number at a fixed location and you were discussing a proper identification scheme. Did you agree on a scheme in the meantime? The next version of VirtualC64 will be very flexible which means that I can grab the number from wherever it is.

Please continue with the great work! It’s awesome to have a free Rom replacement for the C64.

BTW, I just noticed that Basic has a PRINT statement now 😎:

[FeralChild64]

Yes, the PRINT is there - but it is really basic, can only print constant strings (I'm currently working on string variables - there is surprisingly large number of cases which should be handled if we want them to work efficiently), floats and integers are not handled yet at all, the comma does not do what it does in the original ROMs, and the syntax checking is too strict (original ROM is more tolerant). Current implementation was just to allow me to do some tests (BTW, the BASIC is already extended a little - https://github.com/MEGA65/open-roms/blob/master/doc/Extended-BASIC.md

Regarding the ROM identification - I think it should be safe for now to use these 2 places to identify KERNAL and BASIC:

• https://github.com/MEGA65/open-roms/blob/master/src/basic/rom_revision/bf52.rom_revision_basic.s
• https://github.com/MEGA65/open-roms/blob/master/src/basic/rom_revision/e4b7.rom_revision_kernal.s

I'm not planning to change them unless some compatibility problem is discovered - and you never know: one of the guys helping with Ultimate 64 project is experimenting with more Kernal banks, one of the ideas was to use some magic sequence of memory access to switch the banks (so don't be surprised if someday you'll see a 16 KB Kernal ROM image for the U64).

There is also a MEGABAS2 string as a BASIC identifier, but I think it will be changed eventually for non-Mega65 builds (so that extended Ultimate 64 BASIC can be easily distinguished).

Versioning scheme will probably change in the future, I just don't dare to declare current ROMs anything like v0.1 yet. The numbers you see in the officially released versions are:

YYMMDD.(id of developer who did the release, FC = FeralChild).(#release this day).

Last, but not least - the ROMs are currently bundled with alternative chargen from Retrofan (https://github.com/MEGA65/open-roms/blob/master/bin/chargen_pxlfont_2.3.rom) - IMHO it is much nicer.

[FeralChild64]

This is how it looks like on my development branch (assigning a new value to variable does not fully work yet):

[dirkwhoffmann]

Regarding the ROM identification - I think it should be safe for now to use these 2 places to identify KERNAL and BASIC:

Yes, that works. The identification strings are now displayed in the Rom panel 😎:

[FeralChild64]

If you want to be really user friendly, you could also warn the user if BASIC/Kernal replacement versions do not match (both revision string and CONFIG_ID byte must match, otherwise you will get a "bluescreen").

[gardners]

This is all fantastic work, folks! It would be great to push out a blog post talking about the progress on both. Would either of you like to help write it? The screenshots above are probably sufficient for image content.

Paul

[FeralChild64]

I'll try to write a new blog post (really a lot has happened since my previous one) - but I would like to finish at least the string variables first. For now even my shiny Θ(n) garbage collector is crashing.

[dirkwhoffmann]

garbage collector is crashing

The C64 gets a garbage collector 😮. Very cool.

you could also warn the user if BASIC/Kernal replacement versions do not match

Nice idea. Now, the emulator refuses to power up in that case:

If you need different images for the blog post, let me know...

[Kroc]

These screenshots look lovely! I think it's about time a screenshot was added to the README so user can get an immediate idea of what the project means in a practical sense.

[FeralChild64]

@ dirkwhoffmann - All the CBM 8-bit machines (sans ones without BASIC interpreter) have a garbage collector, but on pre-264 series (like the C64) it's very slow, Θ(n^2). Not a problem for VIC-20 with 3583 basic bytes free, but for C64 with 38911 bytes free it is IMHO unsuitable (even more unsuitable for OpenROMs, which can give the user significantly more BASIC memory, but with slower access). But the faster algorithm has a price: for each string stored outside of BASIC text (including strings from arrays) we need 2 more bytes, for the back-pointer, telling us where the variable descriptor is located.

On the other hand, C64 reserves 7 bytes for each string variable metadata (name, length, address), despite only 5 are needed - for slightly better performance (same amount of bytes for every variable type). For now I 'm following this convention, but I think I'll change it too, so that we won't waste bytes here - I'm just not sure how much it will hurt compatibility in the future.

@Kroc - good idea, I'll put some.

[gardners]

We can also start a book in the mega65-user-guide repo (or using the same LaTeX template) documenting the OpenROMs.

[FeralChild64]

Well, for now I'm just do all the documentation in markdown - I just don't have time for everything.

[gardners]

Totally reasonable.