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.
On Zimmers you can find a "patched" version from the 8th of october (911008), i am not sure, what they've patched, i havn't found a difference, tp the 911001.
If you load the original ROM in the MESS emulator, then it comes with a small Basic demo program bundled, which runs automatically every time (and you have to press Run/Stop to break it and get to the OS). In the patched version, however, it has been changed to enter the Monitor instead (so you have to type an X command to exit the Monitor and get to the OS).
Interestingly enough, in the XEMU emulator nothing of the above happens (it just boots up normally like the other ROM's).
(No idea where and how it takes the built-in demo program from, but after having been started, it even tries to load some more additional programs from a Fred Bowen demo disk, which fails, of course, as the disk is not present. It's also interesting that the tried-to-be-loaded additional program list always depends on the actual memory expansion detected, thus setting either to 128K or 640K or more in the emulator makes to try a different program list to start with. Also no idea why the whole action is completely missing if started in XEMU.)
Now yet another possible answer has come into my mind: maybe it has something to do with addressing the second SID. Consider these two facts:
1.) The first SID is paged to $D400, while the second to $D440 - however on a plain C64 thanks to mirroring both address spaces belong to the same single one.
2.) There are NewVIC and OldVIC modes of the VIC-III, and by default in C65 mode the former, while in C64 mode the latter is set up by the system (for hiding the extended I/O registers for compatibility).
But I don't know if hiding the registers, then whether or not the second SID gets hidden, too... So maybe by default when a C64 SID player software is running in the C64 mode, virtually playing only with a single SID known to it, the sound accesses might address both physical SID's at once somehow. But when you try to set up the fast mode, and in order to do so you first enable NewVIC mode, you might unintentionally page in the second SID with it, yet the software is not prepared for stereo, so thus it will be just mute. (Just a theory, it should be confirmed on a C65 by anyone...)
That's funny: I edited my post when noticing I made a typo where typing "loosing" instead of "losing" - but now I've just read it again and seen the typo is in the original text already. Nevertheless I can't imagine you would need to worry about damaging a chip just because you try to read or write its registers. In native mode, it is at 3.5 MHz almost all the time, and if it does not do any harm, then it won't do in the C64 mode, either (as technically, i.e. hardware wise, it makes no difference).
I mentioned the CBM-II as an example for it is indeed at 2 MHz there - and it is a kind of documented "feature" of that system that it becomes write-only.
Actually in the C128 it is at 1 MHz (as well as the two CIA chips, too), since the C128 hardware does the so-called clock stretching, which means restricting the I/O access to 1 MHz always, even if the machine is in fast mode (which is controlled transparently in the background). But the VIC-IIe works, too, it is only unable to access the memory bus then, and consequently displaying some garbage on the screen (random values instead of the valid data). The operating system only blanks the screen to the hide this garbage from the users' eyes (but you can turn it back on if want to see that and it won't harm anything in hardware).
I remember reading this message once long before somewhere and I guess the phrase "losing a SID" here does not refer to a physical damage, but rather that you can't access it in fast mode. It is also mentioned that the SID is the only "slow" device in the C65, which can only be accessed at 1 MHz, so when using it, one needs to perform a SLOW command before (or the built-in Basic v10 musical commands do so by themselves). In the 2 MHz CBM-II machines the SID is already write-only because of the speed; but at 3.5 MHz probably a write access is not possible, either.
Leider ohne USB gibt es keine einfache Lösung um eine moderne Maus anzustecken (mindestens ohne einen externen Adapter zu haben). Oder habt ihr statt etwa andere Pläne dafür? Man kann heute keine 1351 kaufen. Und zum Beispiel GEOS ohne Maus wäre nicht so toll.
Klingt gut, aber bei so einem Preis werde ich eher abwarten bis es Testberichte vom Gerät gibt. Ev. wäre eine Lite Version mit normaler Tastatur und ohne Diskettenlaufwerk, Vga, Handbuch als Pdf noch eine gute Idee. Wenn der mehr als 300€ kostet darf mein Frauchen den Preis nie erfahren.
Du kannst veilleicht als "Lite Version" einfach das originale Nexys 4 FPGA board kaufen (und mit einer C64 Tastatur in einem C64 Gehäuse benutzen).
Basicstart in C65 mode is $8100 or $8101?
$2001 (8193) by default, but you can manually set it lower, even as low as $1301, because the memory in between is not used (exactly like on the C128, where it is called as "Application Program Area"). This way one can gain almost +3K more for Basic program size (or use it up for ML code instead).
For example, the Super Mario Bros C64 port released last year uses the fast mode bit in C64 mode to avoid the slowdown, or probably the Prince of Persia port from 2011, which is also a very good test program for EasyFlash emulation someday (if it is still planned). Though these are just top games (very demanding on hardware). There are several simpler applications, too. Hopefully in future more and more (since other devices have also got this feature, e.g. the Turbo Chameleon 64).
I remember having these very same discussions from three years ago... I have only thought it's already enough time passed away to re-check what has been changed meanwhile again. And see that many things have been fixed and improved since then, which is a great result, of course (and thank you for your work!), just wanted to mention here which part not yet (because it is always more interesting to everyone).
The reversed bit problem is important to fix, as it will surely crash or fool all programs relying on it.
I have just used my own open-source MemTest64 application, which had already been discussed before (and can always be downloaded from here: http://csdb.dk/release/?id=158763 ). Since it has been run on a real C65 prototype machine currently (by a Facebook C65 fangroup member who bought the machine on an eBay auction), where it measured 1.02 MHz in C64 mode, which right exactly matches that 1.02 MHz clock frequency mentioned in the C65 Preliminary, both its accuracy and the usage of the dummy cycles on the original machine have been confirmed in this way.
I assumed the dummy cycles are already emulated though... (So if it is not part of XEMU yet, it may cause the difference of course; but then the problem is that it has not been done.)
It does not only affect the MEGA65, but also the C65 emulation, which is simply not true to the original hardware yet.