Probably patching would be easy (only two bytes should be changed). However, once you do so, then it can't be called a "C65 Kernal" any more (since it will stop working on C65).
Basic 10 is not even backwards compatible to itself: e.g. the simplest colour codes are sometimes ranging from 0 to 15, but sometimes from 1 to 16... or there are three different tokens for DMA (each with different syntax, not to mention their C128 equivalents), and so on.
Now I have tried out the small test program uploaded by Snoopy (thank you, Snoopy!) and have got some interesting results:
1.) If I simply try to start it with BOOT"BACKGROUND", then nothing happens here.
2.) If I start it with LOAD + SYS, then it runs (the background gets coloured).
3.) And here comes the interesting part: if I first start it with LOAD + SYS, then reset the emulator, and afterwards type BOOT"BACKGROUND", then it works again! (Because the first loaded code remains in the memory and can be started again.)
Thus it gives a clue what's going on. At the end of BOOT command it jumps onto the start address for execution (like SYS), so that part is OK. However, still beforehands, while loading, the BOOT command either does not load anything from disk, or it loads that into somewhere else in memory. And that must be because of the DMA: probably the DMA writes into some wrong place.
That's interesting, especially if LOAD + SYS works (but BOOT does not), since then it seems ROM does something stupid. The "DMA writes its own registers"means that DMA was instructed of a memory transfer, where the destination hit the DMA registers itself, thus creating a kind of recursive problem. I would have the idea that the program would use an older DMA chip revision than what is currently emulated, but it cannot be the case too much, if it works with LOAD + SYS otherwise.
This is why I mentioned I tried both the earliest and latest Kernals (910111.bin and 911001.bin), since the first one relies on the older, while the other on the newer DMAgic (Rev2 vs. Rev5 motherboard). The result is the same with both of them. But when I start up the MESS emulator with the very same two Kernals, both of them are working well.
Thus, at least one of the two emulators must be false somewhere. (Maybe MESS is too loose and so unintentionally "fixes" an old hardware problem and lets it go; and/or maybe XEMU does something wrong.) It depends on the behaviour of the real thing.
(By the way it's an interesting side question, how can the DMA come to write its own registers? I guess it always writes to RAM, and the registers are not in RAM, but part of the I/O area, so they can't be reached this way.)
Freddy On C128 it loads the boot sector of the disk (track 1 sector 0). On C65 for the same action, BOOT SYS must be typed.
On C65 a single BOOT command is only a shortcut replacing RUN"AUTOBOOT.C65*". Thus the same syntax hides different operations on both machines (also performed at the powerup).
However BOOT"filename" should work the same way everywhere (and it does work the same as well indeed, except in XEMU for some reason I don't know).
Freddy BOOT without any filename doesn't do so: it searches for AUTOBOOT.C65* (not the first file) and RUNs it. That's quite different, since it will be loaded as a Basic program then and automatically started with RUN.
There is some problem with the BOOT command in XEMU. (That's not a new thing though, since it had not been working in the older versions, either. I just mention it now, because I can't understand, why.)
The BOOT command on C65 (as the same as on the C128) simply loads a program code to memory and jumps onto its first byte. It can be replaced with a LOAD and SYS command by hand. However, whenever I try it in XEMU, only the LOAD and SYS combo works always, but the BOOT doesn't. (It crashes with a "DMA writes its own registers" message.) Interestingly, it works well in the MESS emulator with the very same ROM's attached (but I don't know what's the case on real machines).
Neither in xc65 or xmega65 (both react the same).
I checked for doing it with my MemTest64 at many times, both in xc65 and xmega65, both with the earliest and latest ROM attached (910111.bin and 911001.bin), even with its bugfixed versions by Snoopy till now (from AB to AH).
If I start it in this way, it runs:
That's the very same that BOOT does. But if I try to start it so, it crashes:
Maybe it is only my misunderstanding, but actually a "better" C64 emulation would be worse. It ought not to be better, nor worse, but should rather possibly match the behaviour of the C64 mode of the original hardware, which is in this case the MEGA65 (or in case of xc65.exe that's an original C65 etc.). Indeed, when writing a C65 or even a MEGA65 emulator, one should really not care about the C64 mode at all, since it is just part of the same system, so is just a mere consequence of the whole thing in itself. However, once an oddity or anomaly appears in it, that signs a mistake of the whole system (thus it can be considered backwards).
Certainly VICE is the best C64 emulator today, which is very good, of course, but it still also has so many problems with the other machine types. Especially the C128 emulations (but also the CBM-II, Plus/4 etc.) are so far from the original in some respects (or only so loose instead of accurate) that it often happens that someone uses them to write some new software and later surprisingly gets disappointed seeing as it crashes (or is running strangely) on a real machine.
VICE is the best one for C64, yet luckily by now there are better emulators for the other machines (e.g. YAPE for Plus/4 or Z64K for C128).
I can't even understand why people want to use a MEGA65 emulator as a C64 emulator
From the developer's point of view: for testing.
Even if one is making a new C64 title actually, he may want to check for and ensure if it will also run on a MEGA65 (and not only on a real C64 or C128, or even a C65 or DTV etc.).
And even if a C64 title has been started from a C64 mode of any other hardware, it may likewise optionally check for any extensions sometimes (like available turbo mode or extra memory).
But an emulator is only useful for this purpose as far as it truly reflects the behaviour of the emulated hardware.
Yes (sorry for the typo). I only meant the Initialize command, because it is always fast and straightforward enough, and mostly harmless, too (unlike the above-mentioned Validate, which starts to look for allocated sectors and free them up etc.), thus it can be issued at any time, e.g. before every LOAD or SAVE attempt in an actual program. It doesn't fix the errors of the DOS code, of course, but might be a kind of workaround.
Have you tried to send an I command (Initialize)? That should refresh the FAT from disk.
Also, if I remember well, on C65 there is no such feature (unlike the other CBM machines) that you can read from ROM and write to RAM being on the same address at the same time, because of the mapping which is an integral part of the 4510 CPU (unlike the C64 or the C128 which have their own separate PLA or MMU).
How will it be handled on the MEGA65?
Maybe, at least in C64 mode, it could be partly changed somehow, for better C64 compatibility (as C64 programs often rely on this feature).
There are basically three things:
- setting up an actual memory layout with mapping (see above)
- port bits of $00/$01 (for C64 compatibility reasons)
- some bits at $d030, too
The latter two may have some effect more or less independently of the first (enabling some ROM areas here and there) which is meant for fast accessing the Kernal and DOS code etc. so you also need to put them out of the way in order to access all the RAM.
The concept of banking is rather virtual and meant for Basic applications only, thus it's better not to think in 64K banks (like on C128 or CBM-II series), but consider the 1 MB address space as a whole instead, which is more flexible (although a bit more complicated, too).
On a C65 that's 128K RAM + 128K ROM + another 256K empty space (left over for cartridges both containing RAM and ROM, but finally not populated in real) + another 512K RAM if having an expansion.
The DMA access can extend that up to 8 MB if available. (That might seemingly be translated as having up to 128 "banks" in Basic when using PEEK and POKE which also apply DMA.)
If you want to see the first 64K contiguously (as you see it in the C64 mode), the mapping is simply all zeroes:
(Don't forget about setting the $01 and $d030 bits and later an EOM, too!)
Or return back to the default layout (in native mode):
(But these are just some examples, of course.)
Thank you for doing this, again! But have you got a list of what exactly changed in each version? (Where are the AC and the AD?)
If you are still planning to go on with this patching in the future, there is a particular thing you (or anyone else) could also investigate some day... Most of the newer Kernals (just except for the good old earliest 910111 which I seem to be stuck on mostly for some similar reasons by now) have got some strange system variable placements, which were certainly just meant to be temporary by the developers originally (but they finally remained so, unfinished), so that should be fixed, too.
I mean they place some important variables in the stack page (within the $01xx in memory) at the initialization on powerup, which is obviously very dangerous, as they will be overwritten by the user application program, sooner or later. They would need to find a better placement instead (preferably in the $02xx or the $03xx pages, or if it is not possible, then in the $11xx or the $12xx pages at least).
The best example of the above is the system DMA tables (which are being used for DMA operations all the time, so thus if they are damaged, then it is a serious problem).
Those tables can be found at $03ce-$03e5 when using the the earliest (910111, Rev2B) Kernal, which is good... However all of the newer Kernals put them in the $01xx area instead. E.g. by the newest (911001, Rev5) it is at $0120-$015c.
I wrote an article some years ago, where I described it in more detail, just read the following PDF at pages 44-48, please:
Probably there are some more such cases, too (but I only found these ones). Yet maybe not so easy task to find and change all of them everywhere, of course...
I have filled the area ($4000 to $6FFF) with $FF in the next patch "AB", so the demo files are gone.
Better to fill it with $00 for at least the first 6-7 bytes. Until that code is found and disabled which copies the demo program from the ROM into the Basic RAM and tries to RUN that, it would be safer, since the zero bytes are surely harmless as meaning an empty or non-existing Basic program, but having a lot of $FF instead may lead to a ?Syntax error or some other side effects.
Looks great, thank you! Have you also managed to remove the Basic demo application completely?
Ok, I found them (it was not that hard...):
POKE 720,255 (top of program space in bank 0)
POKE 58,248 (top of variable space in bank 1)
POKE 46,x (start of program)
POKE 48,y (start of variables)
Both x and y are =32 by default, but they can be set to lower for increasing the space (x down to 19 see my previous post... y is not sure).
There must be two Top Of Memory vectors at least somewhere among the Basic system variables being set to $8000 (that should be set at $ff00 for bank 0 and $f800 for bank 1 normally). Hopefully that's enough to find them and manually change their values (then perform a NEW command). Now the question is just where they are...
Maybe they are only set so for reserving some space for gfx (somewhat similarly to the C128 and Plus/4 where the Basic start is shifted upwards to $4001 when performing a GRAPHIC command by the user).
Actually the start vectors can be changed to lower, too. For example POKE46,19:POKE4864,0:NEW sets the program start to $1301 instead of $2001 and adds almost 3K to the code space (this trick is also working on the C128).
Maybe - at least as a kind of first aid - it would be enough to fill up the first few bytes with zeroes starting at $4000 for changing the built-in program to an empty one (since it is in the patched version has not been completely eliminated, but rather a "0 MONITOR" Basic one-liner is there).
As I started listing out the Basic demo program (which seems to be written by Fred Bowen), I spotted another strange thing.
It uses the FRE(2) function to determine whether a memory expansion is present (that gives back the number of the extra banks). While FRE(0) and FRE(1) indicate the free bytes in the first two banks (as available program code and variable memory). But the latter two here only give back about 24K. Does anyone know why?
Both of them should report 55K at least (or more) as they generally do (since in both banks the used space is starting at $2000, although it can be manually increased a little downwards yet).
With that 24K displayed, it seems the free space is only counted until the 32K boundary for some reason now.