126

Re: C64 core talk

thats not really needed - and probably not even wanted (provided you dont just use the c64 for gaming, there are enough situations where you want to see the ram content after reset)

the common solution to this problem is to assert GAME for a small period of time when pressing reset.

127

Re: C64 core talk

For loading other cores or the same core again it is usually no problem. Loading the FPGA binary takes quite a while, the DRAM is not operated (no refresh cycles). This is long enough to invalidate its content (this is also the reason why pressing the reset button long enough on a real C64 works).

If this missing refresh cycle should not be long enough to invalidate the memory, one can always clear the memory in an own core setup by defining an ini file which loads an "empty rom" - just a few bytes at the rom start adress (which is not containing the signature, can be even a simple text file with some bytes of content).

For a reset cycle via OSD/Relay-Keys the issue is more how to define such handling by the ARM in a generic way in the ini file that all cores can use it (such signatures are usually at different locations). Erasing all memory would take quite a while. and as said, there are other features I'd like to add as well (like load PRG including pointer updates). One way would be to define a "reset action" in the ini file with some parameters. People can control then by chosing the ini file if they want to use it or not and developers can set the address/length they need...

/WoS

128

Re: C64 core talk

We could add clear support in file IO, then an INI file could say CLEAR and then a region (in the same way the ROM upload works). This way we wouldn't need to define an empty ROM, and it would be quite fast if sourced from the file IO block. ?

I've seen data hang around in the DRAM for quite some time without refresh. If you play with the loader background image, and swap ini files so you don't reload the image after the FPGA is reconfigured, it hasn't degraded that much. Depends on temperature and specific memory a bit of course.
/MikeJ

129

Re: C64 core talk

this is also the reason why pressing the reset button long enough on a real C64 works

ehrm. no. the VICII refreshes the RAM, and it does it happily during reset. you can press the reset button as long as you want, RAM doesnt change smile

the opposite is true - often the RAM content is even still there after a powercycle. depending on the type of RAM chips in the C64 you can leave the C64 without power for literally minutes before the RAM content vanishes.

as said, just make it so that RESET will assert GAME for some time (just about enough for PC to pass the cbm80 check in ROM) and it will always work. (that will bank in non existing cartridge rom when the check is done, and the check will fail)

130

Re: C64 core talk

Oh sorry, I meant power button (a standard C64 does not have a reset button)...

This solution with GAME is as well core specific, but I would also think to have something like this as well as feature for a "reset action" in an ini file...  (e.g. set/clear dynamic config bits for some time)

/WoS

Re: C64 core talk

Why so complicated? If you reset, you want to go to the Start again. It's not cool to keep your C64 OFF for minutes until RAM is gone (happened to me after playing Popeye on C64c new board it took minutes. First Popeye started again, then it had black Screen, then it worked again normally).

I see no real reason for keeping the RAM. It's more a bug then a feature to me making the useage more annoying rather then enjoyable.

Maybe can you make a Option in the menu like:
RESET: <back to BASIC> / <keeps the RAM reset-proof>

so it would be core specific but you can Change it in the INI file like you want to have it as a Standard.

132 (edited by WoS 2015-11-08 17:26:35)

Re: C64 core talk

...and if I did load a ini with a cartridge in (e.g. simons basic, a fastloader, ...), I don't want it gets lost on such a "warm" reset with memory clear.  So it might be a bug for you, for others it is a feature...  roll

So currently you just load the ini if such a "cartridge hang" happens, which helps in most cases, I can live well with it as simple solution... wink

Or you load an empty cartridge in your ini  - this is also not at all complicated and you get your personal "safe" reset solution (this will always work when re-loading the ini).

Edit:

No need to load a file, there is a way to set some bytes directly.
Example line for your INI to load a file with 6 bytes at cartridge and RAM location (directly after the "ROM=" lines):
DATA = 0x00,0x00,0x00,0x00,0x00,0x00,0x00008000,6
DATA = 0x00,0x00,0x00,0x00,0x00,0x00,0x00018000,6

This will erase the cartridge pointers and the first two byte of the "CBM" signature when loading the INI.



Don't worry, it will be improved. But in a way which is not just a (dirty) hack for the c64 only and to do that it takes a bit time (there are some higher prio things to work on for now)...   Btw. the DDR memory map may still change for the C64 core (this is not visible to users), a too simple ARM solution may not work in future and I would like to avoid starting over again later.

/WoS

Re: C64 core talk

I think that's a good solution.  We just need to wipe out the cartridge vectors really.

Re: C64 core talk

I haven't seen any progress on the C64 core in a while?
What's the current status? How well is the sid simulated?

135

Re: C64 core talk

I am currently busy with another new core, so I have some smaller fixes for this one as well but not yet in any release quality.

We released the sources as requested by some people quite some time ago, so everyone (especially who asked for the sources) is welcome to help out improving e.g. the SID code and post changes or just proposals for changes (on the VHDL code) here. This would be really a big help!

big_smile

This is as well valid for all other cores where the sources are already released...

/WoS

Re: C64 core talk

Good move wolfie!

I just tested the core, i've been away for a long time. I have just browsed around in the OSD for now and mounted a disk.
It would be really nice with an option in the osd for autoload... i.e. Load "*",8,1

Now on to actually running that demo...
smile

Re: C64 core talk

Nice touch with the scanlines btw! Thanks! I hope they make it to the amiga core as well.

Re: C64 core talk

A fastload option would be really nice as well.. big_smile it's taking ages to load this demo.
Maybe Action Replay could be used and the fastload mode from there?

Re: C64 core talk

Hmmm... i loaded Edge of Dissgrace, it asks me to insert Edge of Disgrace disk 1, side A, I do that but nothing happens.
I tried hitting space etc, but the disk change doesn't get detected?

Re: C64 core talk

Shift+F11 to reset the core doesn't seem to work either, is this a thing that should be universal for all cores?

141 (edited by WoS 2016-01-24 12:11:58)

Re: C64 core talk

I think the CPU is now in a pretty good state - but this was also the easiest to fix to a certain extent, as it provides a more "regular" functionality to the system. Other ICs like SID, CIA and VIC may still have some small differences to the original in respect to timing and functional response to the system.

Debugging these differences is very, very time consuming - even to just figure out where to start looking in case e.g. a game crashes after some time.

So I'd appreciate quite low-level analysis on bugs. A big help would be if e.g. demo coders or so could give some more detailed hints (e.g. if some INT is missing or not exactly where expected compared to the original causing some different result) and some test code to execute and to reproduce. No sources required, just throwing some test binaries/PRG on me (I probably would not be even able to compile myself) with some hints where to look and when (e.g. on certain register access) would be perfect.

Edit: yes, F11/F12 keys are used by the OSD system, how the core reacts may still vary... There might be still some dependency on ARM FW and core version, but this should be a really rare case.

/WoS

Re: C64 core talk

I know many of the C64 demo coders, want me to get one here?

143

Re: C64 core talk

Yes, this could really improve and speed-up debugging significantly! big_smile
They would need a Replay board...

/WoS

Re: C64 core talk

OK, I asked the legendary Mahoney (who also is a chip designer by profession!) and one of the most active C64 coders, Pantaloon/Fairlight.

If they are not interested i'll ask some others.

145 (edited by spotUP 2016-01-24 12:27:24)

Re: C64 core talk

Allright! Pantaloon is interested and on his way into this thread! <3

MikeJ; Panta works at DICE, and that means, he lives in Stockholm, a better local C64 coder is impossible to find.
You should let him buy you a beer and sell him a board to make this C64 core kick some serious ASS! big_smile

Re: C64 core talk

I tried to wake Magervalp up from his replay slumber as well big_smile Let's hope he finds his way back here.
He already has a board so that's good!

147

Re: C64 core talk

The beer is on me - and not only one if he likes big_smile
There might be the chance I can buy him one face two face this summer in Stockholm... wink

/WoS

148 (edited by spotUP 2016-01-24 12:38:08)

Re: C64 core talk

Oh, nice!... In that case, call me, and i'll be on the train and we could have a replay get together perhaps!
I could get some other stockholm sceners and stuff to show up as well perhaps.

Re: C64 core talk

Mahoney has cut down his computing time a bit and sadly has no time for the replay as it is. Pff.. cut down computing time, what could he have that is more important than this? A wife? Kids? A life? Pfff... wink

Anyway, he asked me to send you a few of his words of wisdom;

"Getting stuff exacly clock cycle exact is no easy feat. You will need to avoid the normal games, because they generally don't need any perfect timing. But any old-school-effect demo will tell you if you're doing it right. Side border openers, d011-graphics effects like VSP, fld, fpp, you name it, all of them will visually tell you if you're doing it right.

And if you don't get it right. That's where the hard part starts. But generally, reading the VICE source code is a good place to start, but it's boring. So, when a visual error is found and confirmed, you'll need to make a small test program to check, and loads of debugging timing-logging inside the fpga. Fun for some people, but unfortunately, I'm not the person to do that stuff anymore. I did my first 6502-based C64 with SID in an FPGA around 1999-2000 I think. Expensive stuff, back then! smile"

150

Re: C64 core talk

Thanks Spot.
I exchanged a couple of emails with Mahoney after Datastorm a few years ago and he said something similar, and pointed me at the public source for some of his work, which is quite frankly brilliant.

I plan to get back to the SID soon.