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 ***@***.***> 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 <#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 ***@***.***> 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 > <#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 ***@***.***> 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 <#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 ***@***.***> 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 <#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 ***@***.***> 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 <#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 ***@***.***> 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 <#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 ***@***.***> 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 <#33?email_source=notifications&email_token=AAFCOTYZS7QF3TZOQCEMXQDQPLV6VA5CNFSM4I72S7PKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBXM5JQ#issuecomment-544132774>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFCOT2QRXKAX5ZYQUW7WQDQPLV6VANCNFSM4I72S7PA> .