Another thing, IIRC all ROMs (not this one) I've ever met before already uses DMA to clear and scroll the screen. It seems this ROM does not. It can mean anything though. Like, early stage of ROM development, not every C65 feature is used yet (as I suppose the development started with using ROM source for another already existing machine probably C128 or who knows), or it simply means that the early C65 model this ROM belongs to, did not have DMA controller or at least it was so buggy that they avoided to use it yet (similar example, C65 ROMs usually avoid using the Z-indexed addressing mode as it's said 4510s were buggy and this addressing mode did not work or had reliability problems at least).
Hallo Besucher, der Thread wurde 5,4k mal aufgerufen und enthält 33 Antworten
letzter Beitrag von adtbm am
C65 Prototype ROM 900321
-
- Sonstiges!
- Snoopy
- Erledigt
-
-
Many BASIC 10 commands (all(?) of the graphic commands) didn't work yet.
E.g. BORDER, FOREGROUND or BACKGROUND for setting colors.
At least you already can use the appropriate POKEs:
POKE 53280,<x> sets the border to color <x>
POKE 53281,<x> sets the background to color <x>
POKE 241,<x> for setting the textcolor does not work yet.
-
Hi guys,
a big thanks for the ongoing discussion and the background information!
I also got some news from my further tests with the very first ROM:
I'm currently working on a Windows 10 64bit machine using the "next" branch of Xemu 64bit, I also did so when it was not working with the C65 Xemu last time.
When I try to run the old ROM on the C65 Xemu it ends up like this:
To activate the old ROM I used the function: ROM / Load custom ROM via right mouse button click on the C65 Xemu.
After that I set up a MEGA 65 Xemu from the same build on the same hardware.
To activate the old ROM on the MEGA 65 Xemu I used the function: SD-card / Update files on SD image via right mouse button click on the MEGA 65 Xemu.
And now it works!
Look at this:
Thank you so much for your efforts!!!
-
The difference can be, that character ROM is not in place in the ROM image ("where it should be"), thus having garbage instead of normal characters on the Commdore 65 emulator. However, MEGA65 works differently, it does not take the character ROM from the actual ROM image but uses it's own area called "WOM" (Write-Only-Memory, funny, but you can really only write and not read, only VIC read it, not the CPU). There is also a bit to tell the source of chargen from ROM, two different addresses, which may not worked the same on early C65 models, and not even implemented in a real MEGA65 and would require double the size of WOM, as far as I remember about the problem. Anyway ...
It's not impossible that early models of C65 for real have their own "discrete" ROM for chargen, thus not part of this ROM image, or it worked different way (mapped to another address than later C65 models what Xemu also assumes).
-
In my first attempt, i've just sent the ROM via the m65connect tool, which failed.
the second go: i've now copied the ROM to the SDcard, unfortunately, that's how far it runs, until MEGA65 R3 board crashes.
-
When I try to run the old ROM on the C65 Xemu it ends up like this
Accidentally loaded as character ROM maybe?
You can still see where the text is, and that's certainly not this early ROM, but a version with the Microsoft copyright line.
-
When I try to run the old ROM on the C65 Xemu it ends up like this:
Strange, here it runs without problems with the "next" branch xc65 (Linux Lite 4.8 LTS):
I only have the ROM file named "c65-system.rom" in the xemu folder /home/snoopy/.local/share/xemu-lgb/c65/.
-
I have now taken a first look through ROM:
The ROM 900321, which is attached in the first post, is only a duplication of this 64 KB prototype ROM. So in "900321_prototype.bin" the range $10000- $1FFFF is an identical copy of the range $00000- $0FFFF.
As far as I can tell, there is no code for graphics, no hexloader and actually no DOS (at least I haven't been able to find any code for it in the ROM yet) in the prototype ROM. Except for the 64 part (which has largely been adopted from the C64), the other parts of the code are obviously still in a very early stage of development.
This map is of course still all "preliminary" and not yet fully studied.
I'll also dig a little deeper into the ROM again. From a historical point of view, that's quite interesting for me.
The ROM is of course still not recommended for current use of the MEGA65.
At least I am not surprised that without DOS routines it is not possible to access discs.
-
-
-
On question, when you said that the C64 Kernel is mainly taken from the C64, can you see, if the Tape Routine is still in or was it removed already ?
There are no (relevant) differences in the BASIC64 of the C65 (even in the last 911210 ROM) to the original C64 BASIC!
The KERNEL64 in this prototype C65 differs only in a few bytes to the original C64 kernal (see below).
I had extracted the BASIC64 and KERNEL64 area to two 8KB big ROMs, which can be used e.g. in VICE. So you can use a C64 with BASIC and KERNEL extracted from this prototype.
With them I was able to load a TAP file without problems. So the tape routines are still there.
I have attached this two file for testing to this post if interest e.g. to use them in VICE.
In detail:
I had compared the BASIC ROM from the C64 "basic.901226-01.bin" (from zimmers.net) with the extracted BASIC 64 from the prototype and the latest 911210 ROM and they are (nearly) exactly the same. The only differences there the $FF instead of the $AA at 31 "empty" bytes and in the prototype ROM at $1F52 a $00 instead of $EC:
Code: Binary file compare 'C64 BASIC' to 'B64 area from prototype ROM'- Comparing files basic.901226-01.bin and B64_prototype_ROM.ROM
- 00001F52: EC 00
- 00001F53: AA FF
- 00001F54: AA FF
- 00001F55: AA FF
- 00001F56: AA FF
- 00001F57: AA FF
- 00001F58: AA FF
- 00001F59: AA FF
- 00001F5A: AA FF
- 00001F5B: AA FF
- 00001F5C: AA FF
- 00001F5D: AA FF
- 00001F5E: AA FF
- 00001F5F: AA FF
- 00001F60: AA FF
- 00001F61: AA FF
- 00001F62: AA FF
- 00001F63: AA FF
- 00001F64: AA FF
- 00001F65: AA FF
- 00001F66: AA FF
- 00001F67: AA FF
- 00001F68: AA FF
- 00001F69: AA FF
- 00001F6A: AA FF
- 00001F6B: AA FF
- 00001F6C: AA FF
- 00001F6D: AA FF
- 00001F6E: AA FF
- 00001F6F: AA FF
- 00001F70: AA FF
Code: Binary file compare 'C64 BASIC' to 'B64 area from 911210 ROM'- Comparing files basic.901226-01.bin and B64_911210.ROM
- 00001F53: AA FF
- 00001F54: AA FF
- 00001F55: AA FF
- 00001F56: AA FF
- 00001F57: AA FF
- 00001F58: AA FF
- 00001F59: AA FF
- 00001F5A: AA FF
- 00001F5B: AA FF
- 00001F5C: AA FF
- 00001F5D: AA FF
- 00001F5E: AA FF
- 00001F5F: AA FF
- 00001F60: AA FF
- 00001F61: AA FF
- 00001F62: AA FF
- 00001F63: AA FF
- 00001F64: AA FF
- 00001F65: AA FF
- 00001F66: AA FF
- 00001F67: AA FF
- 00001F68: AA FF
- 00001F69: AA FF
- 00001F6A: AA FF
- 00001F6B: AA FF
- 00001F6C: AA FF
- 00001F6D: AA FF
- 00001F6E: AA FF
- 00001F6F: AA FF
- 00001F70: AA FF
The original C64 KERNEL "kernal.901227-02.bin" (from zimmers.net) differs to the prototype KERNEL64 in this 90 bytes. It works great e.g. in VICE, so no big relevant differences should be.
Code: Binary file compare 'C64 KERNAL' to 'KERNEL64 area from prototype ROM'- Comparing files kernal_C64_901227-02.bin and KERNEL64_900321.ROM
- 000004AC: 5C 81
- 000004B7: AA 1E
- 000004B8: AA 06
- 000004B9: AA B0
- 000004BA: AA 05
- 000004BB: AA 9D
- 000004BC: AA 4A
- 000004BD: AA 03
- 000004BE: AA E6
- 000004BF: AA D0
- 000004C0: AA A9
- 000004C1: AA 7F
- 000004C2: AA 8D
- 000004C3: AA 00
- 000004C4: AA DC
- 000004C5: AA 8D
- 000004C6: AA 07
- 000004C7: AA D6
- 000004C8: AA 60
- 000004C9: AA 68
- 000004CA: AA A2
- 000004CB: AA 0F
- 000004CC: AA DD
- 000004CD: AA F7
- 000004CE: AA E4
- 000004CF: AA F0
- 000004D0: AA 05
- 000004D1: AA CA
- 000004D2: AA 10
- 000004D3: AA 85
- 000004D4: AA A9
- 000004D5: AA A9
- 000004D6: AA 01
- 000004D7: AA 85
- 000004D8: AA AB
- 000004D9: AA 60
- 000004DB: 21 86
- 000004DC: D0 02
- 0000057C: B5 20
- 0000057D: D9 F0
- 0000057E: 29 E9
- 0000057F: 03 A9
- 00000580: 0D 27
- 00000581: 88 E8
- 00000582: 02 B4
- 00000583: 85 D9
- 00000584: D2 30
- 00000585: BD 06
- 00000586: F0 18
- 00000587: EC 69
- 00000588: 85 28
- 00000589: D1 E8
- 0000058A: A9 10
- 0000058B: 27 F6
- 0000058C: E8 85
- 0000058D: B4 D5
- 0000058E: D9 4C
- 0000058F: 30 24
- 00000590: 06 EA
- 00000591: 18 E4
- 00000592: 69 C9
- 00000593: 28 F0
- 00000594: E8 03
- 00000595: 10 4C
- 00000596: F6 ED
- 00000597: 85 E6
- 00000598: D5 60
- 00000599: 60 EA
- 00000622: ED 91
- 00000623: E6 E5
- 00000A07: A9 20
- 00000A08: 20 DA
- 00000A09: 91 E4
- 00000A0A: D1 A9
- 00000A0C: DA 91
- 00000A0D: E4 D1
- 00000A0E: EA 88
- 00000A0F: 88 10
- 00000A10: 10 F6
- 00000A11: F5 60
- 00000A12: 60 EA
- 00000F94: 85 4C
- 00000F95: A9 D3
- 00000F96: 60 E4
- 00001F7E: 8E 85
- 00001F80: 00 03
- 00001FF6: 52 4C
- 00001FF7: 52 51
- 00001FF8: 42 FA
- 00001FF9: 59 FF
-
Is the difference a GO65 routine by any chance?
-
Now I've got it running on the Xemu C65 too.
The decisive difference was that I've now used the method Snoopy described above, not the way via the right mouse button to load the prototype ROM.
Hmm, that's interesting. Then it seems, this C65 ROM not properly initializes VIC-III so only loading a ROM run-time causes problem and requires the full VIC-III state to be reset, ie running emulator from the start with new ROM. I guess it relies on some default settings of VIC-III to be there already and it does not set everything by its own?
-
Just a small update.
Bo Zimmerman has updated his site to reflect the last missing ROM