Okay, then it is the best decision if I leave this code as it is now here. Although it does not do anything at the moment, yet it won't cause any harm later; and it won't be needed, either, once the ROM gets write-protected anyways.
With the latest bitstream, tested on Nexys4DDR board:
memtest v107: runs, however ends up in the monitor :(
v108: not even runs, enters into monitor without anything output from the program, in C64 mode, empty screen with READY. only.
@LGB: So when I set that bit, it screws up the system immediately. My above mentioned sequence for the switchover is right exactly there, a few bytes earlier (at $1598-$15aa). I take it out of the final version then.
The $0215b0 address gives some clue about what's going on: a ROM gets paged in place of RAM (unless it should be $0015b0 I guess).
OK, I think, let's defer this topic till the ROM protection thing is blessed by Paul to works well :) I have some ideas that it's maybe not (I even got checksum problems when reset'ed the board from KS). No wonder of some interesting thing in this phase of M65 development, I think it's fair enough. But your project sounds nice, some real-world example (like writing a program for a - new - hardware, etc) almost always can generate some talk, and maybe changes, considerations too :)
@LGB: Thank you, it is still useful to see it for me, because I can notice now that my original never-changing monitor problem must also have some similar causes: the PC address also indicates the same BANK2 in the monitor ($02200d) just instead of the BANK0 (which it should). I have always misread that address for some sensual or psychological reasons before, and thought that it is $2200 instead... Rather interesting to suddenly see it from this new point of view now. :D Maybe it is not my problem any more.
I shall roll back to the latest working v1.07 revision and add my final fixes to that tomorrow, then close it down.
When you are in the hypervisor $d640-7f are saved machine state and config registers. But when you are not in the hypervisor, touching those registers causes a trap into the hypervisor to occur. So the same addresses have different meaning if you are in the hypervisor compared with if you are not.
@PGSmobile Surely, I've got the point since then, that I made a silly point there, sorry about that :-O But still I am unsure a bit about the rest.
Nothing silly at all :) I'm not sure which points are still unclear though. Please list them and I will try to answer them.
@PGSmobile: OK, but I guess I go into private with this chat with you, since it's kinda off-topic for most people, and I can write a *LOT* as you "probably" know already ;-P
- rolled back to v1.07 and final fixes added
- the MEGA65 total loop is once again revised and re-written
- this is the FINAL revision (no longer to be maintained by me)
And once again: thank you to everybody for helping!
I did last tests with Memtest 1.09.
Commodore 128 really passed, even with CP/M Cartridge...
But when I started/reseted C128 with holding C= key - direct jump to C64 mode, testing VDC RAM produces error.
It during tests increments value to 15 and then displays error memory testing. Other tets after have no problem.
Results are placed here: http://www.mirkosoft.sk/memtest109.zip
@MIRKOSOFT: Hm, I have also tried it on my machines, and it looks like it is a general problem. (On my machines, the VDC is not detected at all.) Probably the VDC is not initialized by the operating system in this case, and this is why it behaves so unreliably. (I have only seen this issue with the IDE64 before, and thought that it is a hardware conflict caused by the IDE64 card, but it rather seems now that it is just because that card also forces the machine to directly boot into the C64 mode.)
My other test program (called as "VDC Dump") also fails this way. Thank you for spotting it again.
Now I need to write yet another little tool (I will call it "VDC Init") for "manually" initializing the VDC chip from the C64 mode, and that should be first run, still before running any of the test programs.
I don't know how to do it at the moment, but I am looking for some disassembly of the C128 mode Kernal, to repeat the same steps as the system does.
Once it is written, I will add it to the package, too.
Your friendly neighbourhood moderators: Deft, gardners, MARCOM