51 (edited by WoS 2014-07-04 21:37:25)

Re: C64 core talk

Just some update, the "gory" work towards perfection is happening quite in the background now wink

Did work on the CIA code this weekend to get rid of the (rather complicated) Verilog code from the Minimig code.

I used a proto board, an original 6526 and connected it to a FDIL v2 board  (generating a stimulus to the 6526 and comparing against my new VHDL version - both included on the FPGA in parallel). 

Port I/O and timer functions are quite far in implementation, coding is much less work than preparing test cases for all the different corners (including external I/O corners, which will be probably not important on a C64 with "fixed" system timing, but helps a lot to 100% understand how the CIA is working)...

I am already quite happy with it - when I have the TOD stuff and interrupts correctly implemented as well, I'll put the FDIL board on a real C64 instead of a CIA. When this also works with some test/demo code, I will use/release it with the C64 core soon (I hope still in July, I am currently quite busy at work...). Serial I/O of the CIA will follow later, not my highest prio for the C64 core...

Edit: nearly done with the first shot, put into the C64 and not looking that bad cool

Post's attachments

CIA_Eval.jpg
CIA_Eval.jpg 121.23 kb, 2 downloads since 2014-06-30 

You don't have the permssions to download the attachments of this post.
/WoS

52

Re: C64 core talk

Just checked in a new sdcard/loader.bin file using my fresh CIA 6526 implementation. TOD works now properly (the Amiga CIA code was the new 8520 one with different/wrong TOD setup). Did many comparisons to real CIA, nevertheless there are many possible combinations left which might need further tweaking. With my test setup this will be quite easy to do.

I also checked in a VIC-II test program checking the TOD setup plus some "specialities" of the new VIC-II setup I made, like border sprites.

As there is no activity here (no bug reports on the setup itself or programs running on this core) I assume my C64 Replay core is not really used yet. The games I want to play are working nicely, so I will suspend my activities for now and continue on my Williams core wink

Post's attachments

replay_testpic.png
replay_testpic.png 350.68 kb, 2 downloads since 2014-07-05 

You don't have the permssions to download the attachments of this post.
/WoS

Re: C64 core talk

Hold your horses! The C64 core is way more important than any williams core!! wink
I didn't know that the C64 was in a testable state, i will do some testing then.
I'm sure i'll need just a few mins to break it. wink

I am away from home ATM, but, how well does it handle this demo?
http://csdb.dk/release/?id=129090

Comparison:
https://www.youtube.com/watch?v=Du03j0SoLwk

54 (edited by dirk 2014-07-05 18:59:54)

Re: C64 core talk

wolfgang wrote:

As there is no activity here (no bug reports on the setup itself or programs running on this core) I assume my C64 Replay core is not really used yet. The games I want to play are working nicely, so I will suspend my activities for now and continue on my Williams core wink

Hi Wolfgang,
the c64 core is working nice for a lot of games.
But Fort Apocalypse is hangs after pressing F7, because it needs one SID Register ($D41B) which should generates random values.


greetings
Dirk

Edit.
I have just implemented the random function and can start the game.
There is still an issue in the Sprite detection. The fuel platform doesn´t recognize the helicopter
and so it´s not possible to get fuel.

Re: C64 core talk

Whoa! I hadn't tested this core either because I didn't know it was in a playable state!!
Does it have SID audio connected already?

Re: C64 core talk

Vanfanel wrote:

Does it have SID audio connected already?

Yes, the SID is connected.

Re: C64 core talk

Dirk, the digital part of the SID should be very accurate. The filters are implemented but I think it's fair to say they need some tweaking. I have a number of real devices I am going to hook up and compare with the FPGA version as soon as the Amiga floppy/hd is out of the way.
/Mike

58

Re: C64 core talk

spotUP wrote:

Hold your horses! The C64 core is way more important than any williams core!! wink

Will not stop working on it, just let it rest a while and switching over for the Williams finishing the 680x core I started (and maybe also setting up the board already, need to look closer to it when the CPU is ready and I can replace the real one by a FDIL in a Williams board to run some additional analyzer code).

Testing takes a lot of time causing other projects won't proceed. Especially if I try some game which crashes to figure out later it crashes on a real C64 as well - as it maybe came from a bad(ly repaired) floppy... sad   I'll check this thread from time to time for any feedback. Of course I am happy about any bug reports I can fix later on the C64 core, if there is some "critical mass". I mean to have more than one program with a similar symptom, as this makes debugging easier - especially if it is some not working tutorial/demo/etc., where also the source code and maybe even some explanations exist - this would be ideal stuff for debugging!

Further plans: I'd also like to have an expansion board for the Replay with all connections the C64 has (yes: I also want to have a real 1541-, tape-, user-, keyboard- and module-port  wink ). There are several options, I am in discussion with Mike on that for the best solution. But this will for sure take some more time.

I am also improving my IC reverse-engineer platform (I used for the CIA and the 680x CPU) away from the proto board to a "real" PCB with textool socket connected to the FDIL. The connectivity of all the cables is sometimes not really perfect and it is not easy to take it with me when traveling. So I set up a nice small development board I can take away with my notebook...

Just some notes on the core: Everything should be in so far. The lastest bin is in the sdcard folder, but the build.bat should work as well if one likes to do his own build. There is some issue with Mikes SID - the pitch seems to be wrong in some cases  (thus sometimes the sound is a little weird), not sure if it is only one channel - didn't dig very deep into it. And the 1541 does not support writing yet  (write is not really important for playing most games, though...) Here I wait until the fileio setup is fully stable with the Amiga, in principle the new 1541 core supports writing on very low (GCR) level (experimental setup with temporary write to memory is included in the VIC-20 setup to check it out). Speedloaders like jiffydos work as well (I bought a license for the Replay cool).  The VIC-II may still have some smaller issues, but (again) I'd like to set up the mentioned development board first to evaluate a real VIC-II in a stand alone environment to improve the code (e.g. sprite collision is implemented, but the prio/flagging might be still wrong somehow - it is based on some explanations I found from software developers how to use this feature, which was probably too simple to set up the HW properly - at least some examples I found did work...).

/WoS

59

Re: C64 core talk

dirk wrote:

But Fort Apocalypse is hangs after pressing F7, because it needs one SID Register ($D41B) which should generates random values.

Edit.
I have just implemented the random function and can start the game.
There is still an issue in the Sprite detection. The fuel platform doesn´t recognize the helicopter
and so it´s not possible to get fuel.

That is really valuable information! Can you pass the changes along (attach to the post) or check it in to SVN, please?
Thanks a lot!

There is a VIC-II debug function implemented, showing the register content. In can be enabled via OSD menu. This should help to see the corresponding registers to see what is going wrong.

/WoS

Re: C64 core talk

Commited the changes and a new binary.
I have enabled the VIC debug information but can´t see any  infos which are helpfull for me.
Maybe its not a bug in the sprite logic ?
But i found another issue.
Testbild.prg is not working here. Neither with loader.bin Rev.712 nor with loader.bin rev.708

Another small problem  is that replay.prj needs 6 files which are not included in the replay/src folder.
fsm_execution_unit.vhd. Line 43-48.

61

Re: C64 core talk

Ah thanks. This was some residual stuff I forgot to remove after trying out several 6502 implementations...

The debug just gives all VIC registers as hex value, starting from zero (or better $D000). There are some gaps of nonexisten registers (like lightpen X/Y), though. This helps also for orientation and counting the position of an explicit one. There is a second hex value below the register ($D018) which is passed to the VIC from the "outside" (dbgval_i) where I connected the signals required form the most important memory map/bank bits (to know what memory the VIC actually "sees"). Of course technically it can only show the value at the timepoint where the register content is drawn on the screen (in the upper border area of the graphics, and thus updated with the framerate of 50Hz), it will not show any changes happening somewhere in the middle of the picture (like register changes based on raster interrupts or so). So it is a little confusing compared to a software emulator setup which can show register content in principle at any timepint as these are independent from any video generation process...

Maybe some words to the PRG loader. As it is generic (and does not know anything about the underlying core), it just pushes the binary content to the C64 memory. In contrast to a "real" PRG loader, some of the (zero page) pointer variables are not set - as the kernel would do on a proper load (end of program / start of variable area, for instance). So some programs may not start correctly, as they will override their own program when they use this information. Most pure assembly programs don't require them and will work.

Changing this PRG loader in the ARM to take this into account would require much more intelligence by the ARM firmware and in the ini file to keep it fully generic - as the pointers to update are already different between C64 and VIC-20 (and probably other CBM machines which might follow). We can do this in the future, but for now and with the changing fileio I'd rather like to keep it as is for now.

So in this case it is much easier to generate a d64 file, put the PRG file in and use this result correctly via the 1541 core to load to the c64. For convinience, I just checked in such a d64 (it also contains a low-level iec bus delay measurement program I found to check the CIA/VIA implementations of c64/c1541).

/WoS

Re: C64 core talk

Dirk,
Just looking at your SID changes ... The register in question is not a random number generator, it is reading back the envelope level from chan3, which is implemented.
The fact it hangs indicates another problem.....

I'll leave your hack in for now and look at this w.r.t a real SID.
Thanks,
Mike

Re: C64 core talk

For us mere mortals that do not understand all the jargon and technical talk, how far ahead is the C64 core? smile

Cheers!

ɃºïȠǥ!

64

Re: C64 core talk

Then you should check this sticky thread, which is just what you ask for...  wink
http://www.fpgaarcade.com/punbb/viewtopic.php?id=299

Many progs in prg and d64 format can be played, even several ROM modules and extensions (like jiffy dos or other turbo loaders using low-level c64/1541 communication etc.) working, some things need further fixes (e.g. some undocumented 6502 opcodes and maybe some fancy things in some ICs not yet 1000% correct).

All games I want to play are fine for now, I am not going to play all available games out there myself to check which work and which do not work, that's a job I have left to the non-tech guys. I hope I get plenty of complaints about not working games - which means the people really using the core big_smile

Btw: I continued on the C64 core, actually improving the CIA by running tests and comparing with a real one...

/WoS

65 (edited by WoS 2014-09-27 21:49:18)

Re: C64 core talk

Updated the c64 core in SVN with the latest changes of the replay_lib, so it will build again properly. Updates on CIA and VIC will follow soon, working on the sprite collision issue and TOD improvements.

Edit: sprite collisions seem to work now, checked on games like Falcon Patrol, Aztec Challenge, ...

/WoS

Re: C64 core talk

Nice!

67

Re: C64 core talk

About to release a core version implementing GEORAM (=NEORAM) with 4MB memory. That's a first try to support an decent RAM extension for the D64 before diving into the 17xx REUs which is a little more complicated.  Tried to use the expansion with "Maniac Mansion gold" and looks good so far, a NEORAM test I found on the web detected and tested the memory as well. Could not find any other games or programs supporting it except some disk copiers...

I couldn't get the memory expansion working with GEOS 2.0 properly, even with fixing the config/and boot file, as described on the official GEOS website (at cbmfiles.com). The standard v2.0 does not support GEORAM at all - but it works in principle fine with a joystick connected, the 2.0r, 2.5 and 3.3 versions flying around seem not to support joysticks anymore (at least they "get stuck" on the desktop). That seems not to be a Replay issue - as it gets stuck in emulators as well. Need definitely to check out the new GEOS versions more closely, frankly I didn't really use it in the past sad
So I wait with the check-in of this feature until I figured out what's going on when booting this versions...

/WoS

Re: C64 core talk

Very nice. I hope I didn't break the SID, reverted some changes today...

69

Re: C64 core talk

Will have a look. By the way, I checked in some stuff in the sdcard/demo/sid directory. E.g. the "SIDWizard v1.6". Some demonstrations I found will work already - only very "heavy" stuff (especially newer demos) needs more debugging (most likely some very detailed timing issues on the CIA/VIC or undocumented opcode stuff - several ones start off well and just crash at some point, but I saw that some new ones also have some GFX issues as well - I probably have not designed all VIC/CIA bugs in yet smile).

But for me demo stuff is not really of use (and they are also hard to debug as well), I am more interested in getting some specific games running, as my earnings at the end are much higher - when spending some hours to play them after fixing the core - testing is an important task  big_smile

FYI: I have the "int_dla_core_debug" constant on the c64.vhd toplevel to switch on the processor bus tracing, the dbg directory contains a proper project file for CS (core_cpu_6510_codetracing.cpj). This allows e.g. to trace only specific register accesses/sequences when running some software (I just set the window size to 1 and just trigger on the actual read/write event on the bus, then I use the listing view to export such register sequences in test files for further investigations).

/WoS

70

Re: C64 core talk

Pls. take care when building the new c64 core. Changed to a more "PLA-aware" structure which can be debugged more easily (and will improve the way to attach expansions later on, as I currently experiment with the 4MB GEORAM module), this might have broken some (minor) stuff which did already work. Thus I did not update the sdcard tree yet there on purpose, it still contains an older version...

I am also going to add the generic fileio interface soon, including TAP support (also interesting for the VIC-20, which get the same updates, as there are especially many vic games on tape out there).

/WoS

71

Re: C64 core talk

Updated core and put new binary to SVN. Now GEORAM is fully configurable to its HW spec (min. 512kB to max. 4MB or disable).

Tested with GEOS 2.0r and boots fine with it (set to 512k, as the original used). Shows a 1541 drive (from c1541 emulation with a d64 file) and a 1571 RAM drive (from GEORAM), GEOS can be used with a joystick in the lower Replay port. I also tested "Maniac Mansion Gold" which also supports NEORAM (=GEORAM), for now the RAM can not be stored (missing ARM function to save a part of the DRAM to a file, no big deal but not available yet...).


So everything prepared to add DMA for a full-blown REU. Standard GEOS 2.0 works of course as well, but does not support GEORAM.

/WoS

72 (edited by JimDrew 2014-10-28 22:00:32)

Re: C64 core talk

Please make sure you allow the REU to access up to 16MB of memory - like the real REU can.  smile  There are LOTs of 16MB demos available that load from a custom loader (SD2IEC device, hard drive, etc.) that install entirely into the REU for playback.  Muuvies are done this way too.

73

Re: C64 core talk

Yes, no problem - the Replay has plenty of memory, I can use even separate mappings for REU + GEORAM and there is still quite some space left wink

/WoS

74 (edited by JimDrew 2014-10-29 18:12:11)

Re: C64 core talk

Great!  That will be a big plus.  Now, we just need a real IEC interface so you can use SD2IEC devices, hard drives, etc. so we can fill that 16MB!  smile

I would really like to define some pins on the expansion port for this, and make an adapter available that let you use a PC floppy drive for the Amiga/ST cores (maybe even 5.25" drive support?), and a IEC interface for CBM disk drives.

75

Re: C64 core talk

Why sd2iec?  Put the stuff on the sdcard, push the card into the Replay and select the disk files via OSD - this is already in and fully compatible to a real 1541 + c64  for any fastloaders.

If you have the jiffy ROMs for the c64 and 1541 (I prepared c64_jiffy.ini for that already), it's also pretty fast (as they work synchronous to each other, it is even a little more efficient than a real setup of c64 + 1541).

Apropos:
Is there any good parallel fastloader + ROM out there worth implementing? I had one in my past but can' remember. This C64 I had is long gone... Should be no big deal to set up for this core (again with optional enable via OSD).

/WoS