append delete rosettif

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

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

And here is the direct download link:

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

Reply RSS


append delete #1. MIRKOSOFT

Here are results:
native - top
C64 mode - bottom


append delete #2. rosettif

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:


SYS 5133

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



append delete #3. rosettif

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

append delete #4. rosettif

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

append delete #5. MIRKOSOFT

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.

append delete #6. rosettif

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.

append delete #7. rosettif

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.

append delete #8. LoveMega65

Hey MIRKOSOFT....what monitor/tv you used to have the text output like that ont op level? I want my c64c to output like that too...

append delete #9. MIRKOSOFT

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

Results of M65 are here:

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.


:: @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.

append delete #10. rosettif

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

append delete #11. gardners


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.


append delete #12. rosettif

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.

append delete #13. LGB

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

append delete #14. rosettif

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

append delete #15. MIRKOSOFT

Here are screenshots of all done tests

Look at.

append delete #16. gardners

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.

append delete #17. rosettif

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

append delete #18. rosettif

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

append delete #19. rosettif

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

append delete #20. gardners

@rosettif It is available via DMA and also effectively as "slow RAM" for the CPU, i.e., it can be direct mapped and you can run code from it just fine. It is 14MHz or so, so still enough for many CPU purposes, it just is too far out for the 150MHz requirement of the VIC-IV.

append delete #21. rosettif

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

append delete #22. MIRKOSOFT

Today I do more tests and add info about my config.
Here's 2:30AM.


This post was deleted by its owner

append delete #24. MIRKOSOFT

Robert Olessak, want to ask about one item in MemTest...
Measuring CPU clock - I want to measure Z80 CPU in C128 and the same CPU in CP/M Cartridge...
Can you help?

My mail you'll find at

append delete #25. PGSmobile

The expansion memory if present is at $8000000. Only on old bitstreams on original non-ddr nexys4 boards at the moment.


(Leave this as-is, it’s a trap!)

There is no need to “register”, just enter the same name + password of your choice every time.

Pro tip: Use markup to add links, quotes and more.

Your friendly neighbourhood moderators: Deft, gardners, Ralph Egas