Hi @eriks5,
First of all thank you for your amazing work on this core. I've just tried and played a bit with Geos in 80col with the latest update of the core and no video issue on my side except that the image is not centered, but is it stable at least it seems to be. I'm using the VGA however, don't know if this has an impact.
かすりん
eriks5 wrote: ↑Thu Sep 14, 2023 7:58 amNice. Thanks guys. Was planning on releasing yesterday but found a last-minute bug. A weird one even. Could you guys check GEOS 128 in 80-col mode? For me, the video output is sometimes unstable. Weird thing is, when I recompile with signaltap, it's stable
So there might be some issue in the synthesis where the result depends on randomness during build time.
For me, I tried a D81 image and a D64 image and both hang on the grey background screen. It seems that the desktop never loads.
Never mind, greedy me read the part where REU and GeoRAM do not conflict so I enabled both. GEOS hates having REU and GeoRAM enabled at the same time, so I disabled the REU and now it boots up.
I toyed around with it a bit and it seems to be fine, no video instability or graphical glitches that I could see in both 40 column and 80 column modes.
Please excuse the horrible photo, my phone camera hates LCD screens for some reason. On my screen, the background is grey, not blue like on the photo. I am using HDMI, if that helps.
{edit}
I just noticed that I have GeoRAM set to 4MB and REU set to 16MB on my C64 core and GEOS loads fine there. Not sure if GEOS hanging with both enabled on the C128 core is due to differences in GEOS128 itself or some bug in the GeoRAM/REU implementation on the C128 core, but I would not consider this issue something to hold up a release for.
Thanks erik5! This is honestly awesome work.
Confirmed a regression with the REU in C128 mode. I initially thought it was only in CP/M mode (for which it never worked), but it's also broken in C128 mode now.
I never touched the REU implementation, it's straight from the C64 core, so time to dive into that. The changes made in the system timing to get the VIC display correct in 2 MHz mode probably causes a timing issue with the REU.
And for the curious, this is what GEOS looks like in the build I wanted to release last Wednesday
It definitely does NOT look like that for me. I have ran GEOS128 several times since my last post just to see if I could make it glitch but the screen looks rock solid to me.
I ran it from cold boot, from warm boot, switched to another core and back to the C128 and ran GEOS128 again and I could not make the screen glitch at all.
{EDIT}
I run JiffyDOS permanently on both my C64 and C128 core. I have attached my video settings, Does it still glitch for you with these settings?
Don't think changing the settings changes it, when it occurs. Just the fact that it occurs on some builds and not others indicates a deeper problem I need to dive into.
New version has been released and should be available from the downloader soon.
@alynna this version should now be stable enough for you to build upon, I expect (hope) no more big changes are needed to the main sysclk state machine
I was testing the official version last night and the improvements are very evident and the 80 column mode now looks great.
Thank You eriks5 you have done a magnificent job
Has anyone tried using GEOS 128 with MegaPatch R11 (https://bitbucket.org/mkgit64/area6510/ ... /releases/) and the latest TopDesk (German thread with a lot of different releases in it - https://www.forum64.de/index.php?thread ... &pageNo=36) ?
I can get MegaPatch to boot with the stock desktop on a real 1571, but get video corruption when attempting to use various versions of TopDesk. I've tried using NTSC/PAL/bunch of different core settings and no luck. I end up with a flashing screen that partially displays TopDesk, which eventually ends up out of refresh range for my LCD/CRT and won't display at all.
Not saying it's the core since there is a lot going on here but thought I'd throw it out there...
The dev of MegaPatch tried it and it works on VICE. I may be running in to this:
Known issues:
VDC non-standard high resolution modes (e.g. VGA-like modes) do not display correctly.
hi
i can't get anymore get mra work like c64 in c128
only me ?
thanks
when i run c64 on c128.mra it say rbf not found
and when i rename to mgl it run but not in c64 mode
can someone help me please ?
Breiztiger,
Can you post the contents of this mra? I myself haven't used mra to launch non-arcade cores but maybe I can try it out and see what is going on.
Did this mra/mgl file work for you before on the C128 core?
As for what FPGA64 said, even in the C128 core, you type go64 to switch over to C64 mode. There are other ways of course, like holding the Commodore key (Left ALT on keyboard) while booting up the core or resetting it. Of course, loading "most" cartridges also puts it into C64 mode.
The MRA file requires a copy of the 128 core in a directory called "cores" (inside the computers folder).
That C64 on C128 MRA rigged it so that it came up in C64 mode directly. It had issues with resetting though, so you could not inject PRG files or anything, so it was not useful to me.
The mra are from here
https://github.com/MiSTer-devel/C128_Mi ... master/mra
I have c128 core in _computer/cores
I don't know what to tell you. You need the specific C128 ROM file also, I think in the MAME folder (yes, I know). It did work but docs say it's only experimental. I stopped using them and just made custom ROM files to load.
To be clear the c128 core work well itself !!!
It just the mra that doesnt work
Ok. Now I got it.
So, of course this whole MRA on for the C128 core is experimental, as mentioned on the C128 repo.
I will give you an example of what I did to make C64 on C128 mra work....
First, just like rcade mentioned, you need to download the C128Rom.zip file from the same repo and directory as the MRAs and place it in the games/mame folder. (Make sure you click on the Download button or the Raw button in github to properly download it.)
Then make a folder (if you didn't already) called cores in Computers (or in whatever folder you place the MRA in) ex: Computers/cores
Now when you select "C64 on C128", the core will launch and place you in C64 mode.
Also remember, that the "core" settings, Disk Images and Cartridge files will be based on the name used in the MRA under the field "setname" (in this case it's C64_C128) so settings will be stored to config/c64_c128.cfg and the game folder will be games/C64_C128.
Flandango's instructions are correct. You need to place (a copy of) the core's .rbf file in the Computers/cores directory (there's an underscore before Computers, but the forum doesn't want to show it). You'll need to update the .rbf file that you copied to Computers/cores manually after each new release of the core as the updater script will only update the .rbf file in the Computers directory directly, not in the Computers/cores directory.
It's best to also update the .mra files you copied from the repository after each new core update, and if you made your own .mra files, check if these need to be updated as well. Nothing changed to the .mra files in the release from a few days ago, but in the January release there was a change to them.
I wasn't aware of the reset bug in the C64 on C128 mra, I'll look into that. I don't read this forum that often, if there are any other known issues, please create a ticket in the issue tracker.
To follow up on my original Post Go64 also works in the 128 core as it should. Once booted into C128 just ypue Go64 and the machine will then reset itself to a C64.
I must admit to being a little baffled as to why you want to launch the C128 into C64 mode, since we have a C64 core and as far as I know there is no difference between the C64 cores , the real one and the one in the C128
For me as the core developer the C64-on-C128 feature is useful to find unintended changes to the C64 mode due to changes made for the C128. But yes, for users there is (or, should be) no noticeable difference as it's 99% the same logic.
