MemTest64

@gardners: But where is it now in the address space? My program is looking for the DMA as a contiguous memory starting (or more exactly continuing) right after the first 256K (just until the first byte thence onwards, where the written data cannot be read back from, and so there it stops), and it can be seen as not found in this way. There are two possible causes:

1.) If there are still another not used area in-between (then the expansion starting above it is already not found). I can make it in the next version to also look for there.

2.) Or Miro has only run it on an older bitstream (where it is not yet present).

So you say it is also accessible for the mapper? That's very good news. (Thanks!) Maybe I can do a new test especially for that.

@MIKROSOFT: My actual implementation is a 6502 specific code cycle, which runs exactly for 0.1 sec (by checking for the raster counter to count until 5 or 6 full screen frames for PAL or NTSC), while counting the executed machine cycles of the CPU. There are several embedded cycles by using the X and Y registers for counting the fraction in the x.yy MHz form (plus further variables for the integer part, too). The innermost part must take some 10.000 machine cycles for the decimals (which I also count in the form of 10 x 10 x 100 in embedded rounds). That is pretty simple as a matter of fact, but it needs to very carefully be chosen for exactly the same time (and also to contain the continuous checking for the time period on the raster counter with disabled IRQ of course).

You just need to write the equivalent code cycle for Z80.

The actual method (together with source code) is described here (at page 24):

http://istennyila.hu/dox/cbmcode.pdf

Thanks. My final goal will be to have an advanced MUD-like (realtime, multiplayer, multiplatform etc.) Interactive Fiction, text adventure game engine for all the 8-bit Commodore machines at once (that will be the "Rosetta") one day, but before further working on it, I am still making some smaller projects, like this MemTest, mainly for myself just to better learn and understand or experiment some possible features and the behaviour of all machines.

I had already visited your website sometimes before (beside several other places on the internet for slowly collecting the useful information all over the months and years) and found it helpful. I saw that your operating system would also be a rather ambitious project of this kind, and hope it will be fine finished some day.

@MIRKOSOFT: Thanks. The next revision (v1.05) is almost ready, so probably I can upload it tomorrow or so.

It is also possible if my program conflicts to the RR-Net or some other expansion (although it runs fine on my Turbo Chameleon together with my RR-Net MK3 added). It is especially weird that on one of the pictures the border colour has also become white instead of black (which I absolutely can't explain).

v1.05:

- new test for colour RAM (1K on C64, 2 x 1K on C128 and 2K on C65)
- C65 mapper/DMA total (full address space including non-contiguous blocks)
- MEGA65 total (exploring the 32-bit address space)
- bugfixes for C65/MEGA65 and SuperCPU

http://istennyila.hu/stuff/memtest.zip

http://istennyila.hu/stuff/archive/memtest_v105.zip

:: @rosettif added on 30 Aug ’17 · 02:06

http://csdb.dk/release/?id=158545

V1.06:

- MEGA65 bugfix (total loop is reorganized for safety)

Sorry, but I have still noticed another minor bug in the very last moment, so I had to make yet another upload... Which I really hope now to be the latest (once anyone confirms that it runs well on the MEGA65).

http://istennyila.hu/stuff/memtest.zip

http://istennyila.hu/stuff/archive/memtest_v106.zip

http://csdb.dk/release/?id=158591

Thank you for recognizing this. I have disabled all three tests (REU + GeoRAM + VDC) in this version, so thus neither of the $DE00 nor $DF00 are affected, if SCPU128 is detected... Except for the detection of IDE64 and 1541U, which reads some bytes from $dE60-$DE62 (for IDE64) and $DF1D (for 1541U). So probably it hangs up at this point.

I should rather need to first detect the presence of the Z80 cartridge somehow (and if found, then avoid to touch all these addresses at all). Is there any way to easily and safely detect it? (Without switching to-and fro.)

That makes it a little bit too complicated already, so I am now thinking about what to do...

The other thing I can't understand why it always breaks into the monitor on MEGA65 after returning to Basic in the end. I have absolutely no idea left for that. (I have already made some workaround for stack problems, as well as the switching between VIC-II and VIC-III modes, and some other things... But they do not seem to help by now.)

@PGSmobile: I can't do it as I haven't got the hardware (I only see what Miro posted here). That monitor message does not give me any clue, either. The Program Counter stands at $2200. But I never jump to there (just rather stay within the $1300-$1fff address space). The operating system gets there later in some way, after exiting my program.

However, it doesn't occur in the MESS emulator at all. As much as I know both the MESS and MEGA65 share the same software operating system environment (very same and unmodified Kernal and Basic ROM etc.) whereas only the underlying "hardware" is the difference. So it suggests me that it must be something hardware related.

First I thought the stack was either overwritten and/or relocated somehow which caused a false RTS jump into the nowhere; but it can be excluded now (since I make a whole save and restoration of the entire stack before exiting, just to be sure). Then I thought it had to be that I left the VIC in OldVIC mode (at $d02f), and therefore I also made some changes, to always switch to NewVIC mode when in C65 mode before exiting (and OldVIC mode when in C64 mode as well). And some further minor changes, too. But that issue still remains the same. And I have no longer any ideas.