Hello, Guest the thread was viewed12k times and contains 87 replies

last post from rosettif at the

MemTest64

    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

    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).

    Of course test was done on Nexys4DDR running M65.
    Screenshot is from PEXHDCAP downscaled 'cause device supports up to 1080p.
    I was surprised with result, but now see that Memtest needs fixes.
    I tested also my C128DCR with and without SCPU - only CPU info passed, later hangs. I tested also modded DTV - there was result really true. I do also SYSINFO64 test and post it here this night.
    Miro

    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.

    I did tests by Memetest, Sysinfo64, SIDtest and my program Sysinfo128.

    Results of M65 are here:
    http://www.mirkosoft.sk/memtest.jpg
    http://www.mirkosoft.sk/sysinfo65.jpg

    Used is turbo mode.

    I have also other results, C128, C128 with SCPU, DTV and only from MiST - C16 and C64.
    C64 passed not Sysinfo64 - hangs - like hangs C128 in Memtest.

    And really Sysinfo64 has many bugs in testing C64 mode of C128 and M65 (this failed totally - look at screenshot).
    Also I found new problem with my C128 System Information 7.5 - I connected new 64NIC+ and at NIC detection it hangs... so it needs update.

    Miro

    :: @MIRKOSOFT added on 18 Aug ’17 · 02:05

    Monitor output - if you mean 80 columns mode - is output from M65 native mode, image is from 2 screenshots (top = native / bottom = C64 mode)
    So, C64 can have 80 columns mode, but in 320x200 pixels, so 4x8 characters.
    Miro

    Hello,

    To detect a MEGA65, write $47 then $53 to $D02F instead of the C65 knock values. If you see VIC-III registers, you know for sure you are on a MEGA65, as a C65 will not recognise this knock.

    As for the CPU and DMA:

    1. At present the M65 only uses 4510 CPU mode. 6502 mode is partly finished.

    2. CPU runs at low speed unless you ask for high speed. Fast way to ask for high speed is POKE0,65. POKE0,64 puts it back to normal. All other access to address 0 is normal.

    3. DMA ignores CPU speed, and always runs at full speed, 48MHz on older bitstreams, 50MHz on newer ones.

    4. The little CPU speed difference is due to some residual instruction timing differences, partly 4510 reduced cycle count for implied mode instructions.

    Paul.

    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.

    @rosettif: 16 bit stack pointer (and the E bit in flags register, CLE/CEE etc) and relocatable zero page ("base page" since it's not always the zero page strictly, any more hmmm) is the same. Or it should be. It sometimes turned out that actually C65 hardware does not do what it should, at least there was a case when it turned out that (ZP),Z addressing mode not working for real on every (or all?) real C65 units even if we know it should, by specification too ...

    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).

    At the moment we are not planning to add the 512KB-8MB C65-style memory expansion, but rather have our larger expansion memory space at $8000000-$EFFFFFF. There are several reasons for this, but the main one is that the VIC-III must be able to see the C65 expansion memory, which means we would need to have that memory with only 20ns latency, which is only possible for RAM inside the FPGA. We are hoping to have an option using a larger FPGA that will give 512KB of such memory, but not straight away.

    @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?