MemTest64

Could anyone try it on a C65 or MEGA65, please?

http://lemon64.com/forum/viewtopic.php?t=65168

:: @rosettif added on 16 Aug ’17 · 17:14

And here is the direct download link:

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

:: @rosettif added on 10 Sep ’17 · 05:09

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

Thank you, Miro! Good to see it works... er, it almost works. Where have you tried and which version (v1.04 should be)? Some of the results seem a little strange to me, that reminds me more of an emulator test.

- it should display "mega65" instead of "4510" if recognized (so my autodetection still fails!)
- 356 scanlines (?)
- the DMA seems way too fast (only 81 cycles for a one kilobyte transfer?)
- it should return to Basic in the end (but breaks at $2200)

Does the MEGA65 not boot up in the 48 MHz mode by default? (It is only in the 4 MHz mode here.)

The C64 mode is ok, yet I need to do a lot of bugfixes for the C65 mode, I think. If anyone still tries it, please try the native mode, and both these ways:

RUN "MEMTEST.PRG"

LOAD "MEMTEST.PRG",8,1
SYS 5133

(or the latter can be: BOOT "MEMTEST.PRG")

Hi,

Robert

Here is the download link for the most recent revision of the test program (v1.04 as of today):

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

May I have a question? What should be the best or surest way to fast and easily (in only a few steps) distinguish the MEGA65 from C65?

I have done it in my code by switching to VIC-IV mode, then switching back to VIC-II mode, and comparing if some special registers (like $d031) change their values according to this (since they must be hidden for the VIC-II and normally just contain $ff there).

But now (if Miro's test was done on a MEGA65) this method does not seem to work.

Also, I thought the intruction set and timing were changed for C64 mode. But then they should be 6510 and 0.93 MHz (instead of those 4510 and 1.13 MHz).

Thank you for your answer! I try to learn from the results, and investigate which one is my fault (even if it is not easy without the hardware).

At first, I need to think out a better way of autodetection (as I have already written that above). Yet, I am not so sure about the other things.

Those 356 scanlines are really weird. But these are here just simply recognized. And it works well everywhere (even on the Plus/4 and VIC-20 etc.). As well as the MHz of CPU. So these must be no problem.

That super fastness of the DMA is also rather surprising, still I think it MUST work here. (If the DMA would not work, then we should get an "error" in the end of that test instead of "ok" if the needed bytes are not copied and do not match.) Probably the DMA is always executed by the FPGA at the maximal speed ever possible (independently of the actual CPU speed setting). Or does it go in parallel (not stopping the CPU)? (If so, then I would need to wait until it's done.)

I have already got an idea for the final crash (its breaking into monitor). Obviously, it must happen at the final RTS (when returning to Basic). So I consequently consider that it must be a STACK problem. Most probably the contents of the stack are overwritten (and not restored) somehow.

When testing the ZP+SP method, I extensively use both the relocations of the Zero Page and Stack Page (throughout the memory). Maybe are these features just not well (or not yet) implemented by the MEGA65?

It works fine in the MESS emulator though.

You say it "hangs" on your C128DCR. Could you please check and write, where exactly it happens? If you have got any kind of very large memory expansions (of several megabytes or so), then the testing of that will last for very long (several minutes or more!). So you then just need to wait a little more.

Thank you again! Could you still post yet another screenshot of my MemTest64 when running on the C128 with SCPU? I am very eager to see the CPU MHz value there (it makes only 8.37 MHz in VICE, whether is the same or different on real hardware).

Thank you, Paul. That's exactly what I am doing, of course. Maybe only not succeded because I assumed they give back $ff when hidden (as normally on a C64), but you rather set them to $00 (or any other value). In the next version, I try to make it a little more flexible for any case.

Are the Zero Page relocation, and the 16-bit Stack Pointer handling implemented on the MEGA65, in the same way as on the C65 hardware? As I described my other problem, it seems to go wrong with something about these.

Okay, thanks for everyone. If I get the time next week, I make a new revision with some workarounds, and "I'll be back". (After fixing the bugs and implementing colour RAM test, I am still planning to make some MEGA65 specific support by scanning the 28-bit/32-bit address space.)

Until then, I have yet another question. I see there is no memory expansion in the classic C65 manner at present (right after the first four banks of 128K RAM + 128K ROM the address space is not used yet, up to 1 MB for the mapper and/or up to 8 MB for the DMA). Are there any future plans to also implement these kinds of expansions? I think it would be great (as for backward compatibility with the original C65 platform at least).

@MIRKOSOFT: Thanks, it's also very useful info momentarily. Now I see where it hangs on your machine: after the CPU test, the VDC detection is coming next. So probably there is something about it. Unfortunately, I have no DCR model to test with (just four "flat" models, two with 64K and two with 16K VRAM). So the problem is either with the DCR, or the SuperCPU. As much as I know, the SCPU128 has an MMU extension built inside the machine, which also stays there when the cartridge is removed. (Right?) What I can try to do for it now as a workaround, that I disable the VDC testing in the next version if the SCPU is detected (and let us see what happens).

There is another program in the package, called as "VDC Dump". That is very simple (you can see it in the source code), only writes the VDC memory full, then dumps it on the screen back four times. (It runs for about half an hour though...) Have you also tried it on your DCR?

@gardners: Maybe it would be a compromise to make it only accessible by the DMA. As the DMA execution time is as flexible.

@MIRKOSOFT: Interestingly, the VDC is not usable at all, if an IDE64 is present. The VRAM goes mad, and almost every read/write attempt gets corrupted (it also conflicts to the I/O spaces of the GeoRAM and REU, so these had to be disabled). Maybe something similar is also with the SuperCPU (have you tried it also in the 1 MHz mode?).